一份改钱包按钮排序的提案和一份改区块结构的提案，在评审桌上受到的拷问完全不同，可如果没有成文的区分标准，这种不同很容易沦为「谁嗓门大谁有理」。2015 年 11 月提交、当月定稿（Final）的 EIP-4 干的就是给拷问定标尺的活：它把标准类提案按所属系统层归入四类——共识层、网络层、API/RPC 层、应用层，并明说一条原则：层号越低，互操作性要求越苛刻，达成一致的难度越大。这份提案的作者 Joseph Chow 在摘要里交代了出处——整套思路改编自比特币的 BIP-123，等于把邻居家已经跑通的分类法移植过来。
四个层各管什么
按 EIP-4 的原文，四层各有明确的任务边界。共识层定义密码学承诺结构，职责是让任何人能本地判断一段历史和状态是否合法、提供结算终局性、保证 eventual convergence（协议里常说的「最终会收敛」）。它专门强调自己不管消息怎么在网路上传播；共识层上的分歧后果最重——不同节点可能接受互不兼容的历史，也就是分叉，提案里又把共识层变更细分为软分叉与硬分叉：旧规则下合法的某些结构在新规则下不再合法，是软分叉；旧规则下不合法的变得合法，是硬分叉。网络层规定以太坊的线协议与轻客户端子协议（原文把 RLPx 排除在外，指向 devp2p 仓库单独管理），并指出基础互操作只需要子协议的子集，新子协议可以边加边废弃旧的，整个网络能不带断崖地升级。API/RPC 层管应用能调到的上层接口：这一层不影响基本组网，允许竞争性标准并存。应用层则是让不同应用能共享数据和功能的抽象与惯例，自由度最高。
分层为什么有用
分类法表面是文档整理，实际是风险定价。共识层的改动要求全量节点几乎同时升级判断标准，错一步就是链裂成两条，所以该层提案天然要经历最长的辩论、最重的测试、最保守的节奏；而应用层提案哪怕彻底失败，也只是某个生态工具没人用。把这条梯度写进流程文本，等于给「为什么这个提案审了两年还没动」提供了不依赖情绪的答案。反过来它也提醒提议者：很多想法根本不必挤进共识层，在网络层、RPC 层或应用层做同样的事，成本可能低一到三个数量级——后来以太坊大量能力（钱包接口、批量调用、显示元数据之类）确实沉在接口和应用层而不是共识层，与这套分层观念互为因果。
它和今天的分类字段什么关系
需要说清的一点：EIP-4 定的是「按互操作性分层」的框架，而今天你在提案仓库头部看到的是另一种按领域划分的字段（核心、网络、接口、元信息、ERC 等标签），两者解决的问题不一样——前者回答「改错了会有多疼」，后者回答「归哪拨人评审」。EIP-4 本身是元提案（Meta 类型），不规定任何线上行为，2015 年 11 月 17 日创建、很快标记为 Final，属于流程文档而非功能开关；把它理解成「给提案建了个消防等级制度」比理解成「一条协议规则」准确得多。
快速问答
问：分层会影响提案能不能通过吗？ 答：不直接决定通过与否，但决定了默认审查强度、兼容承诺和升级方式，实际筛选掉了大量本不该进共识层的想法。
问：一个提案可以跨多层吗？ 答：EIP-4 的文本假定一个标准类提案归入一层；现实里大特性常拆成多份提案，各自落各的层，这也正是分层的用法。
问：这套分类法以太坊原创吗？ 答：不是，摘要明写改编自比特币 BIP-123，后者给 BIP 分了类似的四层加共识层细分。
常见误区
一是把「层号低」读成「更重要所以优先做」，实际含义恰好相反——层号低意味着更慢、更贵、更难撤销；二是把四层与提案当前的领域标签混为一谈，拿旧框架去解读新仓库的目录结构会得出错误结论；三是以为分了层就能防住有提案同时改变共识与网络行为，分类管的是文档归类，管不了设计本身的一致性，那要靠评审。
风险提示：本文介绍提案流程文档，不构成投资建议；判断某项协议变化的影响请以其原始提案与当期客户端文档为准。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。