先按职责拆，不按宣传图叠层
讨论区块链协议层时，先问一笔请求依次经过哪些职责，而不是直接背诵“六层架构”海报。ethereum.org的Networking layer写明：以太坊是点对点网络，网络层是让节点互相发现并交换信息的协议栈，既包括一对多的gossip，也包括一对一的请求响应；执行客户端与共识客户端各自有独立的网络栈，彼此还要互通。
同一页把执行层网络再拆成UDP上的discovery与TCP上的DevP2P：前者给新节点找同伴，后者承载会话与信息交换。RLPx负责会话的发起、认证与维持，并用RLP编码消息。这些接口描述的是“如何连上并传对信息”，并不等于“如何改状态”或“如何跑合约字节码”。
执行层：状态机与EVM不是网络模块
EVM文档把区块链从“分布式账本”推进到“状态机”：规则约束谁能如何改状态。EVM以深度1024的栈机执行，条目为256位字；执行时还有不跨交易持久化的瞬时内存，以及按合约账户保存的持久存储。合约账户在创建时写入编译后的字节码，被消息调用时再执行。
因此，网络层把交易gossip出去，并不自动完成状态转移；状态转移与字节码解释属于执行环境的职责。把“协议层”笼统写成一个盒子，容易把发现节点、维持会话、执行操作码和持久化存储混成同一次API调用。
对照：NEAR把区块链层与运行时层分开
NEAR Architectural Overview给出另一组分层：大致分为blockchain layer与runtime layer，并强调二者可独立——区块链层理论上可挂不同运行时与计费；运行时默认不关心交易从哪来，也不知道自己是否跑在分片链或何种共识之上。共享的不变量包括transactions与receipts：交易由用户经RPC等在节点外创建，收据则是内部消息传递结构。
该材料描述的是NEAR，不是以太坊客户端实现。这里只用它说明：协议职责可以按“共识/分片路由”与“交易执行环境”切开；宣传图里的“协议层”若不同时标明接口边界，就不能当作实现说明书。
读分层材料时的边界
读网络层材料时应核对：讨论的是执行客户端还是共识客户端、discovery还是DevP2P会话、以及消息是否已经进入状态转移。读EVM材料时应核对：栈/内存/存储各自的生命周期，以及字节码执行与网络gossip不是同一模块。
本文未实现客户端、未测量延迟，也不把任一架构总览写成某公链投资结论。归档时应记录文档页的更新时间、对照的链（以太坊文档 vs NEAR架构），以及“网络 / 执行 / 区块链层 / 运行时层”各自回答的问题。