摘要
2026年以来，以太坊协议层的演进正经历一场从"性能扩容"向"去中心化与审查抵抗"并行的深层重构。过去一年，主网Gas上限从3000万一路抬升至6000万，区块吞吐能力翻倍的同时，也让人们重新思考去中心化网络承载大规模应用的代价与边界。然而真正构成这场变革灵魂的，并非单一的性能指标，而是一系列结构性升级他们对共识机制、区块构建权力分配和交易排序权之间关系的重新定义。
本文聚焦于2026年协议路线图上已被确认或高度确认的四大核心协议升级：区块访问列表（Block-Level Access Lists）、内嵌式提议者-构建者分离（ePBS）、分叉选择层强制包含列表（FOCIL）以及持续中的DVT分布式验证器技术商业化落地。这些升级不是孤立的技术补丁，而是在面对"扩容优先"还是"去中心化优先"的二元对立时，以太坊社区选择走出的第三条道路在维持区块生产能力增长的同时，用协议层面的构造约束弥补经济集中化带来的结构脆弱性。
我们将从Gas扩容的技术现实与其对验证者负载的影响讲起，逐步深入ePBS如何将区块构建的经济博弈嵌入共识协议本身、BAL访问列表如何通过前置声明约束区块对状态的索求、FOCIL机制怎样在分叉选择层面嵌入交易强制包含规则以抵抗提议者级审查，以及DVT技术如何从根本上分散验证器私钥的存放形态以瓦解质押集中化。每一部分都将配有详细的架构图解说明，并为开发者与协议研究者指出未来6-12个月最值得关注的工程实现细节与部署时间表。
一、引言：当Gas上限再次跃迁之后
2026年1月，以太坊社区通过Glamsterdam硬分叉将主网Gas上限从4500万抬升至6000万。这次升级的直接动因是显而易见的——在高频DeFi交互、L2批量结算和AI代理链上交易同步增长的压力下，L1的执行空间逐渐被推到承载极限。但这并不是一次纯粹的刺激方案。以太坊基金会在1月的协议优先级更新中明确提出，Gas扩容不是终点，而是一种手段，旨在配合Block-Level Access Lists（EIP-7928）等结构性优化来测试网络在更高负载下的健康度，同时为之后朝向1亿Gas的远期目标建立客户端基准测试数据。
Gas上限的提升在带来吞吐增益的同时，也引发了对验证者硬件门槛同步攀升的担忧。在权益证明共识下，每一个验证者节点都必须在该slot的极短时间内完成区块提议、执行验证和分叉选择计算。当区块越来越满，构建和验证区块所要求的计算资源也在稳步上升。如果没有对应的去中心化补偿机制，高Gas上限最终可能演化为一种无声的"准入门槛"，把那些无法在高端硬件上运行的独立验证者挤出网络。
这正是2026年协议升级故事的核心矛盾：能力增长与去中心化之间的张力。我们既需要更大的区块来支撑真实用例，又必须确保支撑这条链的验证者集合不会因为经济压力而向更少的、更集中化的服务提供者收敛。而2026年的协议路线图上给出的应对方法，是从三个维度同时发力：
- 构建层（Block Building）：用ePBS把中继层从外部信任实体变为协议内嵌的拍卖规则，削弱对中心化中继的依赖。
- 执行校验层（Execution & Access）：用BAL（Block-Level Access Lists）让区块在开始执行之前就声明自己将要触及的全部状态访问路径，为并行验证和轻节点安全提供结构化前提。
- 分叉选择与审查层（Fork Choice & Inclusion）：用FOCIL（Fork-choice enforced Inclusion Lists）在分叉选择规则中嵌入对提议者偏见性过滤交易的约束。
这三者彼此互补但并非线性依赖：ePBS解决的是谁构建区块的问题，BAL解决的是区块内部怎么访问状态的问题，而FOCIL解决的是构建完毕后如何确保交易含有权不可被审查的问题。其组合效果相当于一个完整的契约体系，从出块延伸到出块后的社会性契约。
在此基础上，分布式验证器技术（DVT）则试图从根本上改变验证者存在的物理形态——将单点私钥拆分为多方分片，用密码学和共识的冗余替代硬件的冗余，从而使"个人操作验证者"这件事在密钥安全层面重新成为可能。
接下来的章节将按顺序展开每一层的技术细节、协议设计与工程实践考量。我们的目标不是给出一份路线图式的概览，而是进入每一个EIP或协议的具体决策点，理解其背后的工程学取舍和社区博弈。
二、Gas扩容的真实成本：数据、硬件与网络同步压力
2.1 扩容并非没有代价
2025年初，以太坊主网的Gas上限还停留在3000万——这一数字自2024年下半年以来基本维持稳定。然而到2025年2月，通过研究员发起的客户端参数共识调整，Gas上限被临时推升至3600万。随后在2025年7月提升至4500万，2025年11月又跨越至6000万，并在2026年1月正式通过Glamsterdam硬分叉将其协议化。这一系列升级的直接目标是让以太坊L1能够承载更多的状态计算与存储写入，以缓解L2批量结算和DeFi协议日益增长的交互密集度带来的竞争。
然而，每次类似参数调整的背后都有一个被算法层面忽略的经济与硬件现实。权益证明共识要求全网超过90万个活跃验证者（包含退出队列中的节点在内超过120万）必须在一个slot（12秒）内完成对新区块的提议、执行验证和分支选择投票。当Gas上限从3000万爬升至6000万，区块内可以容纳的状态读写操作数量翻倍，而每个验证者节点都必须独立完成这些状态验证。这意味着什么呢？
对于运行完整执行客户端（Execution Client）与共识客户端（Consensus Client）的验证者而言，硬件需求不是一个静态状态。2024年时，一个合格的验证者节点需要约1TB的NVMe固态存储和8GB以上的内存。而到了2026年初，在6000万Gas压力持续运行的情况下，客户端基准测试数据开始指向一个更高的门槛：16GB内存以上、2TB NVMe存储可能从"建议"逐渐变成"隐性必需"。更关键的是，区块验证不再是"我能还是不能"的二元问题，而是"我能多快完成验证并在分叉选择中按时投票"的连续体问题——延迟投票会直接降低节点的共识参与者权重，继而在质押收益层面受到经济惩罚。
如果你在运行一个独立验证者，维护硬件和存储不是全部。网络同步的带宽压力也需要认真评估。6000万Gas的区块意味着更大的区块体（block body），而每个共识消息的广播延迟又是固定的。如果下载一个完整区块体的时间超过了你本地的网络延迟预算，你的验证行为就会落后。这是一个非常实际、但很少在路线图讨论中被量化的约束。
接下来的架构图将帮助我们可视化这个验证者体验的全栈流程、以及其中哪些地方在高Gas环境下开始出现瓶颈。
2.2 验证者执行流程与瓶颈定位
为了更精确地理解高Gas区块对验证者的影响，我们来梳理验证者在每个slot中需要完成的全流程。这一流程大致可以划分为六个阶段：网络数据接收、共识层投票验证、执行引擎调用、状态树更新、分叉选择计算、以及最终的Attestation广播。其中每一步在Gas扩容方案下都有可能成为新的瓶颈点。
flowchart LR
A["网络接收<br>区块体与见证消息"] --> B["共识验证<br>检查CL签名状态与有效性"]
B --> C["执行准备<br>解析区块并传递至EVM"]
C --> D["状态计算<br>按Gas限制执行交易序列"]
D --> E["状态检查<br>生成新的Merkle树根"]
E --> F["分叉选择<br>更新LMD-GHOST投票"]
F --> G["广播<br>发送Attestation与本Slot确认"]
style D fill:#e8d5c4,stroke:#8b5a2b,stroke-width:2px
style E fill:#e8d5c4,stroke:#8b5a2b,stroke-width:2px我们从左到右依次浏览这个流程图。首先是"网络接收"阶段——验证者的共识客户端通过libp2p P2P网络从它已连接的对等节点下载完整区块体，同时接收同一slot内来自其他验证者的Attestation预签名消息。在6000万Gas限制下，区块体的体积可能接近1.8-2.0MB（取决于交易是单纯转账还是涉及大量calldata和存储写入的状态密集型交易），这比3000万Gas时代大约翻倍。如果你的出块连接性（peer connectivity）不够密集或者网络带宽约束，这个下载时间就会显著增加。
第二阶段是"共识验证"，验证者需要检查当前区块提议者的合法性、验证其签名路径是否符合分叉选择的预期逻辑。这一步的速度主要取决于共识客户端的纯密码学运算效率，与Gas大小基本无关。
第三到第五阶段则是真正对执行负载敏感的部分。"执行准备"需要将区块中的交易列表注入本地执行客户端（如Geth、Nethermind或Reth）。"状态计算"是在EVM中逐条指令执行，每条指令有一个对应的Gas消耗。6000万Gas意味着EVM计算总量增加，而这部分计算几乎无法被共识层并行处理，因为每笔交易之间可能存在状态依赖。最后"状态检查"是重新计算整个状态树的Merkle根，而这一步与状态写入变更量正相关——更多的账户修改意味着更多的树节点需要重新计算和哈希。
图中的两个标红节点——"状态计算"和"状态检查"，正是2026年客户端优化团队投入最多的方向。Nethermind在2025年底引入的状态树差异续算（partial state root caching）和部分内存缓存优化，Reth通过Rust异步I/O对状态读取的管道化并行，都是在尝试把这两个阶段的延迟压回3000万时代的水准。在新的2026年客户端节点基准（EIP-7870的实际目标也就是对这类硬件的推荐规范），社区希望为Validator设定一个明确的性能基线。
不过，单纯提高硬件标准只是缓解而非解决矛盾。真正被社区寄望以更根本的方式处理这一问题的，是将区块构建的权力从验证者手中剥离出来也就是说，让专业构建者负责组装和执行级优化的区块，而验证者只需对构建好的区块做快速的共识验证。这种思想催生了ePBS（Enshrined Proposer-Builder Separation），也就是接下来我们要讨论的核心协议升级。
2.3 从性能到经济：扩容背后的幂律分布
需要额外指出的是，Gas扩容带来的成本增幅在验证者人群中并非均匀分布。在2026年初的实时监控数据中，运行独立节点的验证者（通常是持有少量质押额的个人质押者）大约占活跃验证者集合的18%，而其余相当一部分通过中心化质押服务商或流动质押协议间接参与。对后者而言，6000万Gas意味着他们所委托的节点需要更强的硬件、更高的带宽和维护投入。这笔增加的运营成本在薄利润市场中最终会通过费率结构传导给终端质押者也就是在实际上提高了"入场门槛"。
而在去中心化共识网络的语境下，这种门槛的抬升是一个隐性但严重的攻击向量。它可能削弱网络在面对国家级审查或大型云服务商政策变动时的韧性——一旦网络中运行节点的硬件参照指南变得过于狭窄，可选的物理托管地点和人就同步减少。理解这一点有助于理解为什么后文将要讨论的ePBS、DVT和FOCIL在2026年被放在与"扩容"同样重要的位置。
三、ePBS：将区块构建的信任从外部中继移入共识协议
3.1 问题的根源：为什么需要Enshrined
在深入理解ePBS之前，我们先回顾当前以太坊区块生产的核心权力结构构造。在权益证明下，每12秒一个slot内，协议用RANDAO（可验证延迟函数）伪随机地选出一个验证者作为区块提议者（Proposer）。但这个提议者的职责远不只是"提出"区块，它还要负责:\n- 从内存池中挑选交易、排序并打包成候选区块
- 运行交易以确定正确的状态根、receipt根
- 向网络中的其他验证者广播这个完整的区块体
这一系列操作给了提议者极大的弹性和唯一的经济激励：通过交易排序规则可以从MEV（最大可提取价值）中获益。如果提议者能在自己出块的slot中优先安排一笔能够杠杆套利的交易序列，如果它在同一区块中对DEX流动性池A的交易在交易B之前，这种先后顺序的调整可以在一个区块内产生可观的收益。
问题是，绝大多数验证者——尤其是个人质押者——并没有足够的信息、算力和网络延迟优势来有效捕获这种MEV。于是"区块构建者"（Block Builder）这个经济角色应运而生。构建者利用私有交易池（private mempool）、高速网络连接和复杂的模拟算法来构建最具经济价值的候选区块，而提议者只需把这些区块原样提交到网络。
但这一构造在牛市高峰期间出现了严重的信任集中化问题。在2023年到2025年的实践中，大多数构建者通过一个被称为"中继"（Relay）的外部服务向提议者传递区块。中继负责：接收候选区块、验证其合法性、检查链上承诺支付（builder bid）、并向前传递给提议者。然而，这些中继是链下实体，部分由组织运营，他们的运行逻辑、过滤标准和数据保密政策，都不受协议约束。这导致了至少两个结构性风险：\n1. 审查风险：中继可以只向提议者转发满足其条件的区块，从而系统性地将某些交易排除在区块构建之外。\n2. 单点故障：如果一个或数个中继失败，整个MEV供应链将在该slot内崩塌，提议者被迫回退到本地内存池构建低效区块。\n
ePBS（EIP-7732）的核心设计目标，就是让中继从外部的信任角色降级为纯粹的信息传递角色，将中继所做的核心功能——特别是出块者经济竞价和验证逻辑——直接写入共识协议。一旦ePBS被内嵌，提议者将直接在共识层中接收来自多个构建者的"承诺+竞拍"，协议自身会负责验证承诺与支付兑现，而不需要信任中继本身的运营方。
3.2 EIP-7732：核心协议变化拆解
EIP-7732的改动并不抽象。它让共识区块（BeaconBlock）中的ExecutionPayload字段不再由提议者直接提供，而是被一个精简的签名承诺取代——一个包含执行区块哈希和指向构建者竞价值的承诺对象。这个承诺对象由构建者签名，并明确指定了将向提议者支付的竞价。
sequenceDiagram
autonumber
participant BP as 区块构建者(Builder)
participant PR as 提议者(Proposer)
participant CL as 共识协议(CL)
participant EL as 执行客户端(EL)
participant VL as 验证者网络
Note over BP,CL: 竞拍阶段：在Slot内约定窗口内发生
BP->>PR: (a) 发送SignedExecutionPayloadBid<br>含blockhash、竞价值、签名
PR->>CL: (b) 将Bid嵌入BeaconBlockBody
CL->>VL: (c) 广播不带ExecutionPayload的共识区块
Note over EL,VL: 稍后：构建者在多余时间内公开完整执行负载
BP->>CL: (d) 在约定时间点公开ExecutionPayload
CL->>EL: (e) 验证Payload与之前承诺的blockhash匹配
EL->>VL: (f) 验证者执行验证并广播Attestation我们按编号逐步梳理这个序列图，因为这是理解ePBS工作原理的核心。第一阶段（步骤1与2）构成了ePBS关键的时间窗口压缩。构建者通过加密的P2P通道向提议者发送一个签名的承诺，这个承诺并不包含完整的交易列表——它只是一个区块哈希加上支付额度。提议者在收到多个此类承诺后，选择竞价值最高的那个嵌入到正在构建的共识区块中。注意的是，此时提议者并不知道承诺背后的交易内容是什么，它只能验证签名的真实性和竞价值的大小。
第二阶段（步骤3）是共识区块的广播。这里与当前机制产生最大变化：被广播的Beacon区块本身不包含交易信息，只包含指向交易包装的哈希承诺。这意味着共识层验证者可以在极短时间内下载并验证这个轻量级的共识区块，完成分叉选择计算，而无需等待完整ExecutionPayload的到达。这实际上为验证赢得了大量的时间——因为完整区块体的下载和执行验证被延后到了一个预定的"公开时限"之后。
第三阶段（步骤4与5）发生在slot的中后期。胜出构建者现在必须公开匹配承诺的完整ExecutionPayload。共识客户端将这个Payload转交给本地执行客户端进行验证——执行客户端需要验证每笔交易的合法性、状态转换的正确性，并检查最终的区块哈希是否与承诺对象的哈希完全一致。如果一致，说明构建者没有食言；如果不一致，构建者的竞价质押会被协议自动罚没，提议者可以在随后的slot内重新组织（重组）该区块。
第四阶段（步骤6）是所有验证者执行验证并且广播Attestation。到这一步时，验证者已经拥有了足够的信息来决定是否支持这个区块，而整个流程依然在slot的时间预算内——ePBS的关键工程假设就是：因为共识验证和对完整执行负载的执行被分成了两个时间子窗口，所以每个窗口内的操作量更小、更容易被当前硬件完成。
3.3 为什么这种分离是硬件压力的缓解器
假设验证者在12秒slot内有4秒需要完成必须完成的纯L1共识签名验证与分叉选择更新，这就是它的硬性时间窗口（attestation deadline）。在当前没有ePBS的世界里，验证者必须先下载完整执行区块（可能1-2秒），然后立即开始执行验证（2-3秒），然后才进入分叉选择计算——如果任何一步迟到，Attestation就过期了。
ePBS把这个死锁拆解了。在步骤1与2中，验证者只需要下载几百字节的轻量级共识区块。在步骤4与5中，执行负载可以等到attestation deadline之后到达和验证，因为共识层已经先行"锁定"了构建者的承诺。即使执行验证来不及在slot内完成，验证者仍然可以先在共识层投票"该区块看起来合法"（因为构建者的竞价质押已经锁定了其不可撤销地承担经济代价），然后在随后的slot内补充完成执行验证。这是ePBS极端情况下容错的关键。
这也回答了我们在第2.2节中提出的那个问题：如何把验证者从高密度执行计算中解放出来，从而在更高的Gas环境下保持去中心化的可行性。ePBS并不减少总计算量——6000万Gas的区块仍然是6000万Gas的区块——只是把时间线重新铺排，使得对attestation有严厉时间约束的参与者可以先行完成共识投票，再去做更重的执行验证。
3.4 ePBS部署时间表与工程关注项
截至2026年6月，EIP-7732已被确认为Glamsterdam硬分叉的一部分，其共识层执行细节（CL层面的builder-拍卖和惩罚机制）已在Prysm、Nimbus中有了初步实现。工程团队接下来的重点在于：\n- 构建者网络的P2P通道建设，确保承诺拍卖过程能够在每个slot的严格时间窗口内可靠完成交易；\n- 构建者竞价的质押保证金（collateral）和罚没机制的经济参数校准；以及\n- 大区块在P2P网络中的分段传播协议优化，降低高Gas环境下数据包延迟的波动。\n
对于协议研究者而言，值得关注的一个后续升级方向是ePBS与PEPC（Proposer-Builder Separation with Explicit Commitments）的结合。PEPC让提议者在选择构建者承诺的同时，还可以附加额外的"包含列表"要求这篇文章后面还会专门讨论这个机制的技术细节。
四、BAL与状态预热：让执行客户端提前知道区块要做什么
4.1 从"盲执行"到"预声明"
在第3章中，我们看到ePBS如何把验证者的共识投票与执行验证拆了两个时间子窗口。但一个显然的回退路径是：如果执行客户端在最后一步（即完整ExecutionPayload到达之后）才开始逐笔交易解析，那么执行阶段仍然要承担不可压缩的拉取-执行-写回延迟。有没有办法让验证者提前知道后继区块将要触及哪些状态数据，从而把I/O密集型状态读取操作并行化或预加载到缓存中呢？
EIP-7928 提出的答案是：要求区块提议者或构建者在区块头中明确地声明该区块将要访问的全部地址和存储槽位集合，也就是所谓的Block-Level Access Lists（BAL，区块级访问列表）。这听起来像是一个简单的元数据补充，但它的实际影响是深远的——它把执行客户端从"盲执行"（在不知道将读取什么状态的前提下开始执行）变成了"有准备执行"（提前调度所需状态的磁盘I/O和内存访问）。
具体而言，当一个构建者准备好一个6000万Gas的候选区块时，它不仅要在区块头中放入所有交易的Merkle根和状态根，还要新增一个字段，列出该区块中每一笔交易将要调用或读取的地址列表（address list）和存储槽位列表（storage slot list）。这个列表必须是完整的如果构建者遗漏了某个将被调用的合约地址，协议会在执行阶段检测到不一致，将该区块标记为无效。
4.2 为什么BAL对并行化和缓存优化如此关键
现代以太坊执行客户端在处理单个区块时，面临的最大性能瓶颈往往不是计算本身，而是随机状态读取。以太坊的状态存储在一个巨大的键值数据库中（通常是Merkle Patricia Trie的某种后持久化表示），账户余额、代码、存储槽位都分散在磁盘的不同位置。当一个800笔交易的区块涉及数百个不同合约和上千个存储槽位的读写时，客户端必须从磁盘上随机查找每一处的数据。这种随机I/O在大容量NVMe设备上虽然比传统HDD快得多，但在6000万Gas级别的吞吐量下，仍可能成为验证延迟的主要变量。
Block-Level Access List让客户端在拿到完整区块体之前，就可以利用这个列表去做I/O前调度：先将所有声明需要访问的状态树节点批量预热到内存缓存中，优化读取的局部性；在执行阶段可以设定交易级别的并行化——如果两笔交易访问的地址和存储槽位集合没有交集，它们就可以在独立的CPU线程中同时执行。
graph TB
subgraph 前置阶段["收到BAL之后"]
A1["解析Access List"]
A2["调度磁盘I/O"]
A3["预热状态缓存"]
end
subgraph 执行阶段["执行Payload"]
B1["交易1 & 交易2 并行"]
B2["交易3 串行"]
B3["存储槽位并行更新"]
end
A3 --> B1
A3 --> B2
A3 --> B3
B1 --> C1["验证BAL完整性"]
B2 --> C1
B3 --> C1
C1 --> D1["生成新区间根"]我们详细阐释上面的流程。上半部分"前置阶段"在共识层接收到BAL之后立即启动，不需要等到执行payload本体到达。验证者客户端解析Access List，解析出所有涉及的状态地址和存储槽位ID，然后向执行引擎发出一个"warm-up"请求，触发从磁盘到内存的状态树节点缓存加载。这一步的I/O是高度可并行的——不同于执行阶段的顺序约束。
中间"执行阶段"是拆分可并行的交易和必须顺序化的交易。EVM的优雅之处和诅咒都在同一个地方：任何交易之间的状态依赖关系在理论上都可以在事前通过read-write set的冲突检测来定出。如果交易A和交易B访问完全不重叠的状态集合，那么它们的结果不会因为并行执行顺序而改变。BAL提供了一个声明式的方法来事先声明这种重叠关系，使客户端的执行调度器能够比传统方法更可靠地做出并行化决策。
最后阶段是验证BAL完整性。执行引擎必须检查：实际执行过程中触及的状态集合是否完全落在了预先声明的访问列表之中。如果实际执行过程中发现有一个预先未被声明的状态读取，那么该区块无论如何都必须被拒绝。这种机制确保了声明的诚实性——构建者必须极其保守地预先列出所有可能触达的地址。对于一个调用外部合约的复杂DeFi交易，这意味着构建者需要提前完整模拟该交易，或者让交易发起者提供访问提示（Access List hints），这在复杂交易合约中是需要被认真讨论的工程问题。
4.3 工程挑战：构建者侧的BAL生成成本
对于区块构建者而言，BAL增加了额外的工作负担。在构建一个6000万Gas的区块时，构建者已经需要执行所有交易以确定候选区块的精确状态根。现在它还需要额外做两件事：\n1. 收集每个交易触及的全部地址和存储槽位；\n2. 将这些访问集合打包成压缩的声明格式，确保其大小不会让区块头膨胀。\n
访问列表的压缩是一个值得工程优化的方向。EIP-7928中提出了基于前驱区块访问模式的delta编码和范围化表示（range-based encoding），利用交易之间通常共享大量公共访问模式的观察来压缩声明大小。但最终，BAL的生成是构建者的纯额外工作量（虽然这一部分高度可缓存和复用），这在主网测试网中的实测数据中被证明会增加构建者在每slot内的计算窗口约200到400毫秒，对于一个争分夺秒的slot预算来说并不算无关紧要。
此外，还有一个用户体验层面的考量：由于BAL的存在，提议者在接收到构建者的候选区块时，可以提前判断这个区块是否可能在某些验证者硬件上产生不可接受的高I/O门槛。如果BAL显示一个候选区块涉及的状态读取极其碎片化且极大量，提议者可以选择拒绝这个对网络验证者不友好的高负载区块，即使它提供了更高的竞价。这实际上为一种隐性的社会性"区块健康度"评分机制提供了数据基础。
五、FOCIL：在分叉选择层面嵌入强制包含规则
5.1 审查问题的协议层解决方案
到目前为止，我们讨论了ePBS如何将区块构建从外部信任实体移入协议层面，以及BAL如何让执行过程可以通过预声明获得加速。但问题还没有结束：即使区块构建是内嵌的、即使构建者不知道提议者是谁（理论上），一个恶意的提议者是否仍然可以通过不使用某个构建者的区块、或选择自己构建一个排除了某些交易的区块，构成对特定交易的审查？
回答是肯定的。在ePBS当前设计下，提议者保留了选择接受哪个构建者承诺的全部权力。这意味着：如果一个提议者有动机（来自监管压力、利益冲突或纯粹恶意）拒绝包含包含某些"敏感"交易的区块，它只需忽略那些带有这些交易的构建者承诺，转而选择包含一个"干净"的区块。由于提议者的选择是在协议层面不受强制约束的，这种审查行为无法被共识协议在事后证明和惩罚。
这正是EIP-7805（FOCIL，Fork-choice enforced Inclusion Lists）试图解决的问题。FOCIL让协议在每个slot中强制要求：任何被共识分叉选择算法所接受的区块，都必须包含一个由协议随机选出的Inclusion Committee（包含委员会）预先指定的交易列表。换句话说，提议者不能因为个人好恶或外部压力而把计算委员会指定的交易排除在其所提议的区块之外。如果提议者这样做，该区块将被共识分叉选择规则拒绝。
这听起来是一个简单的规则添加，但塞入以太坊现有共识体系并非一个容易的设计决定。
5.2 FOCIL的技术实现： Committees、IL与分叉选择整合
在每个slot中，除了本来的提议者以外，协议还会通过RANDAO伪随机地选出一组验证者作为Inclusion Committee成员。这个委员会的任务是：在进入该slot之前（通过观察内存池中等待被打包的交易），它们选定一个短名单作为该slot的Inclusion List（IL，包含列表）。IL中的交易被硬性规定如下：当前slot的区块提议者所提议的（或通过ePBS选择的）任何候选区块，都必须包含IL中的全部交易，否则该候选区块在分叉选择层面将被视为无效。
graph LR
A["Slot N-1<br>区块确认期"] -->|"内存池观察"| B["Inclusion Committee<br>形成包含列表IL"]
B -->|"IL广播至P2P网络"| C["委员会成员<br>签名并验证彼此IL"]
C -->|"聚合IL"| D["Slot N<br>构建者/提议者组装区块"]
D -->|"候选区块必须包含聚合IL"| E["分叉选择验证"]
E -->|"缺少IL交易的区块被分叉选择拒绝"| F["Attestation投票"]
F -->|"只有含IL的区块可以累积权重"| G["主链确认"]我们来逐步解析上面这个流程图。第一步，在slot N-1的末尾，Inclusion Committee的成员开始观察当前内存池。它们不是随机选择一笔交易放进IL中，而是遵循一套称为"交易可见性规则"的启发式逻辑：往往选择已在内存池中持续待了一个给定时间量、支付了合理Gas费用、且未被之前区块包含的交易。这种选择逻辑被设计为抗操纵的——委员会成员不能针对性地过滤某一类交易，因为只要交易在内存池中公开广播且待的时间足够长，它就应该出现在IL中。
第二步，委员会成员各自签名其观察到的IL版本，然后通过P2P网络广播。其他委员会成员接收到彼此的版本后，会执行聚合和一致性检查——如果大部分成员看到同一笔待处理交易，它就会出现在最终聚合IL中。这个聚合过程类似于Attestation的BLS多签聚合，通过密码学手段将多个签名压缩为一个。
第三步到第五步是关键。在Slot N，构建者或提议者即使想故意排除某些交易，也不得不面对分叉选择规则的约束：如果他们的候选区块缺失了聚合IL中的任何一笔交易，验证者客户端在本地分叉选择算法中会拒绝这个区块使其无法被投以Attestation。没有Attestation的区块在权重竞争中会被舍弃，提议者将损失该slot的出块奖励和MEV收益。
这种机制的逻辑层次非常清晰：ePBS解决了构建者与提议者之间的信息不对称和信任问题，而FOCIL在这个基础之上增加了对提议者决策权力的协议层约束。两者并不替代彼此，而是互补。
5.3 FOCIL工程落地与2026年下半年部署预期
EIP-7805 已被确认纳入2026年下半年名为Hegota的硬分叉升级路线图中。目前的工程实现集中在两个层面：\n- Inclusion Committee的随机选与聚合协议：这部分已经在以太坊研究团队的spec草稿中完成验证，核心共识是委员会大小应控制在约256个成员左右，以平衡去中心化与聚合效率，但需要进一步的大规模模拟测试确认其网络负载影响。\n- 内存池可达性假定：FOCIL的理论安全性有一个重要假设——待包含的交易必须已在内存池中被相当比例的委员会成员"看到"。如果某些交易被网络分割（network partition）隔离，委员会成员可能无法统一将它们放入IL中。研究社区正在将交易传播保证（EIP-7805的"Gossip-forwarding requirement"）作为配套要求提出。\n
对于协议研究者而言，一个极富启发性的后续问题是：如果FOCIL和ePBS两者都内嵌之后，是否还存在其他审查形式？例如：承诺不包含某些交易的构建者可以在ePBS竞拍中给出更高的竞价（因为回避了"敏感"交易意味着减少了Gas消耗，或免受后续争议风险），而提议者可能纯粹出于经济理性选择这种"洗白"区块。这已经引发了关于BAL中是否应内嵌"公开交易集合"透明性要求的讨论，但这已超出当前EIP-7805的部署范围，属于更长期的协议研究课题。
六、DVT（分布式验证者技术）：瓦解验证者身份的单点工程形态
6.1 质押集中化的密码学根源
当我们谈论去中心化时，真正在链上被计数的是活跃验证者的数量——截至2026年中，这个数字约为90万至100万（含活跃和退出队列入列者达120万以上）。但这个数字本身是有迷惑性的。一个验证者节点背后可能是一个独立质押者，也可能代表着数千个32 ETH的存款汇集于同一台服务器同一组私钥，托管在某个中心化服务商。
以太坊的权益证明共识要求每个验证者持有一份唯一的私钥（BLS签名密钥），用于签署区块提议、Attestation和Sync Committee消息。如果私钥泄露，攻击者可以用它进行双签（double signing），触发协议的罚没（slashing）机制，使该验证者的质押本金部分或全部丢失。因此，私钥需要以最强的安全方式存储——最好是永远不在联网设备出现，而只在签名的一瞬间被加载。
但现实中，运行一个独立验证者是一种需要DevOps专业知识的操作：你需要配置、监控服务器，处理客户端升级，管理密钥库的加密与备份，并保持节点24/7在线。对大多数人而言，将这些操作委托给专业的质押服务（如Lido、Coinbase Staking、中央交易所的质押产品），或中间件协议（如Rocket Pool）是更合理的选择。结果非常自然：链上验证者数量虽然庞大，但少数几个质押服务控制了其中的大部分。
分布式验证者技术（DVT）试图从根本上改变这一结构：与其让单一节点控制一个验证者的私钥，不如让私钥本身通过门限密码协议（Threshold Cryptography）被分割为多个"密钥分片"（key shares），分别存放在多个独立运行且可能在不同地理位置的节点上。只有当足够数量的节点（例如7个中的5个）协同签名时，该验证者的消息才被网络视为有效。这样，即使一两个节点离线或故障，验证者仍然可以出块和投票；即使一个密钥分片被窃取，攻击者也无法使用该分片伪造签名（因为需要达到门限数量）。
6.2 门限签名与共识层的对接
理解DVT如何与现有共识协议交互是关键。传统验证者节点在本地用完整私钥签名Attestation或区块，然后通过P2P网络发送。在DVT架构下，签名过程被分散化：
graph TB
subgraph 密钥层["密钥管理"]
SK["验证者私钥<br>由DKG生成"]
SK -->|"门限分割"| S1["密钥分片1
运算符A"]
SK -->|"门限分割"| S2["密钥分片2
运算符B"]
SK -->|"门限分割"| S3["密钥分片3
运算符C"]
SK -->|"门限分割"| S4["密钥分片4
运营商D"]
SK -->|"门限分割"| S7["密钥分片N
运营商E"]
style SK fill:#ccffcc,stroke:#228B22,stroke-width:2px
end
subgraph 共识签名["门限签名流程"]
CL["共识客户端请求签名"]
CL --> S1
CL --> S2
CL --> S3
CL --> S4
CL --> S7
S1 -->|"部分签名1"| Agg["聚合部分签名"]
S2 -->|"部分签名2"| Agg
S3 -->|"部分签名3"| Agg
Agg -->|"完整的BLS签名<br>从t-of-n恢复"| Net["P2P网络广播"]
end上图描述了DVT从密钥派生到实际网络签名的全流程。上半部分是密钥层：在验证者创建之时，全体参与方运行一个分布式密钥生成（Distributed Key Generation, DKG）协议。重要的是，在整个过程中，完整的私钥在任何单个时间点都不需要被任何一个单一节点所知晓。DKG的输出是多个密钥分片，每个分片只掌握部分私钥信息，但没有任何一个分片能够推导出完整私钥或代表单独伪造完整签名。
下半部分是签名流程。当共识客户端（Prysm、Nimbus、Lighthouse、Teku等）需要提交一个Attestation时，签名请求被平行发送给持有密钥分片的多个节点。每个节点用自己的分片对消息计算"部分签名"（partial signature），这部分签名本身在密码学上不是一个有效的BLS签名，但它携带了可以被门限聚合的数学贡献。当一个聚合节点收集到足够数量（达到或超过门限数t）的部分签名后，就可以通过拉格朗日插值在组合层面重构出一个等同于完整私钥直接签名的有效BLS签名。从外部看——即P2P网络上的其他验证者看来——这个签名与由单一节点完成的签名没有任何可区分性。这意味着DVT对共识协议本身是完全透明的，不需要修改以太坊的P2P规范、分叉选择算法或罚没机制。
这一点的协议兼容性优势是DVT目前最大的卖点。与ePBS或FOCIL不同，DVT不是一个需要被以太坊主客户端升级才能实现的基础层升级——它是一个叠加层。所有的签名聚合可以在共识客户端外部的一个DVT客户端（或"中间件"）中完成，而共识客户端只需要按照正常方式调用签名API即可。
6.3 Obol与SSV的技术路径对比
当前DVT生态有两条主要技术接收：Obol（Obol Labs）和SSV（svv.network）。二者在门限密码学实现上共享相同的数学基础（BLS12-381门限签名），但在网络拓扑、运营商激励模型和离线容忍机制上存在显著差异。
Obol采用一个相对简洁的DV集群模型：一组想要共同质押的人（或机构）可以自定义组建一个"Distributed Validator CLUSTER"，其中每个参与者运行一个Obol Charon中间件客户端。Charon在本地与每个参与者的共识客户端和执行客户端配对，负责门限签名的协调。整个集群的配置是半开放的形成之后，集群成员相对固定。一个新的运营商要加入某个验证者的DVT集，需要其他成员重新运行一轮DKG，以生成更新后的门限参数。这种设计偏向于"联盟式质押"，适合机构合作、大型组织的内部节点冗余、或高级质押者之间的自愿协作。
SSV则采用一个完全去信任注册的中间件层，构建了一个公开可参与的分布式运营商网络。质押者通过SSV智能合约（位于执行层）注册自己的验证者，并选择一个运营商组合（比如选择7个中的5个作为门限参数）。这7个运营商可能是来自不同地区、不同组织的公开节点。SSV网络在共识层上引入了BFT（实用拜占庭容错）风格的门限签名共识，在P2P子网中确保运营商之间的通信可靠性。运营商通过合约经济模型获得服务收益——质押者向合约存入服务费，由合约按照运营商服务质量（在线率、响应延迟）自动分配。SSV的路径更适合个人质押者，因为质押者不需要认识或信任任何特定的运营商，只需要随机或按声誉选择一个运营商组合，并付出经济费用。
这两种模式在实践中并非互斥。Lido Finance已经在其核心质押基础设施中通过SimpleDVT模块同时引入Obol和SSV——该模块将一部分Lido的验证者操作从单一运营商迁移到DVT集群运行，以增加去中心化程度。在2026年初的协议监控数据中，通过DVT运行的以太坊验证者的比例约估计为4%-6%，距离影响力临界点尚有距离，但增长势头在持续。
6.4 Native DVT：协议层的远期讨论
尽管Obol和SSV已经提供了业界可用的覆盖层方案，以太坊研究社区内部仍在讨论是否以及如何将DVT概念"原生化"进协议。2025年末，Vitalik Buterin和研究社区中提出了一个被称为"Native DVT"的路线图议题，其核心思路是将DKG和门限签名验证的某些环节直接写入执行层或共识层规范，以使DVT集群的操作成本进一步降低。
当前最大的生态摩擦点在于：对于想加入DVT的质押者而言，整个过程仍然是高度手动和技术化的——你需要找到其他运营商同伴、配置DKG参数、监控集群健康度，并且在某个节点掉线时手动或半自动重新平衡。如果协议层面能内嵌一种"委员会随机器"（committee randomizer），自动将质押者分配到由协议全局随机算法选出的、地理分散的委员会中，那么就能在保持密码学安全保证的前提下，将参与门槛降低到与单独质押等同的水平。这曾经是一个遥远的讨论，但在2026年协议路线图将Gas扩容、审查抵抗和去中心化硬件结构列为同等优先级之后，Native DVT的优先级也在悄然提升。它代表了以太坊社区对"协议层协调比信任第三方中间件更第一性"这一信念的持续坚持。
七、综合展望：一条更完整的协议演化叙事
7.1 四条升级路线的组合效应
回看2026年整个共识层协议升级的全景：BAL改变了区块进入网络之前的"信息结构"，让执行客户端得以预知要做的工作量；ePBS改变了"谁有权力决定区块内容"这一问题的回答方式，使构建者之间的竞争被注入协议本身，从而削弱了对第三方中继的信任依赖；FOCIL在分叉选择层面对超越经济理性的审查欲望施加了硬约束，而DVT则从验证者存在的数字形态入手，将单节点单密钥的构造拆解为多方门限结构。
这四者之间是互补且交织的，而非简单的串联。比如，BAL为ePBS的有效运行提供了工程基础：由于ePBS将执行验证从共识验证中时间解耦，如果执行客户端能利用BAL的预先声明来在下载完整Payload之前进行I/O预热，那么整个slot内的时间窗口就可以被更充裕地用到Attestation阶段。又比如，ePBS让构建者负责实际打包交易，而FOCIL让提议者不能在此基础上过滤包含列表中的交易——这两种力量之间的张力在协议博弈论意义上将构造一个更平衡的区块内容筛选机制：构建者有动力最大化MEV打包，而包含委员会通过IL确保最低层级的"必须包含"交易不被遗漏。
这些升级的合并效果，是一个非常明确的信号：在越过2022年"合并"（The Merge）从工作量证明转向权益证明这一历史性节点之后，以太坊的协议卓越性不再是关于"哪一条链更去中心化"或"哪一条链更快"的简单对比，而是关于"如何在持续扩容的同时不牺牲去中心化安全假设"这一更复杂命题的系统化响应。
7.2 值得关注的工程与实验动向
对于协议开发者、客户端实施团队以及独立研究者而言，2026年下半年至2027年上半年有几个状态转换特别值得跟踪：\n- ePBS在公共测试网的部署日程：当前ePBS的工程实现主要停留在客户端层面，但还需要组合所有主要执行客户端与共识客户端的互操作性。首个跨客户端公共测试网的运行将是一个决定性的里程碑，届时区块构建者和验证者可以开始模拟真实的MEV竞拍环境。\n- BAL与DVT的交互：如果一个DVT集群中的某些节点承载能力较弱，BAL提供的信息可以让它们更高效地把I/O密集型操作提前调度到更空闲的时间窗口或性能更好的节点中。这种组合虽然尚未形成明确的EIP或产品路线，但它的优化潜力非常明显。\n- FOCIL的博弈论模拟测试：FOCIL的安全模型假设委员会成员是诚实且可达的，但在真实网络中，网络分区会导致成员无法统一观看到内存池中的同一笔交易。大规模的分布式模拟（如通过Shadow Ethereum或基于Kurtosis的测试框架）是验证这些边缘情况安全边界的关键。\n- Native DVT的研究进展：虽然短期内不可能在主链落地，但共识层团队对Native DVT的潜在规范探索很可能在2026年末或2027年初产生一个共识层后续升级的Research Prototype，这将是一个需要密切关注的长期结构性变化。\n
7.3 结论：去中心化不是静态属性，而是一种持续的博弈
在技术社区关于扩容与去中心化的争论中，以太坊2026年的协议升级路线给出了一个清晰的立场：二者并不是一种简单的此消彼长。通过在协议层内嵌更丰富的激励、约束和结构，协议本身可以在更大的硬件压力和市场集中化力量下持续补偿那些试图维持网络开放性的参与者。
Gas扩容让我们看到了性能边界；BAL让我们看到了如何用预声明的结构信息来补偿性能提升带来的执行压力；ePBS让我们看到了如何用协议内嵌的经济竞争来替代外部信任中介；FOCIL让我们看到了分叉选择规则如何被用作审查抵抗的武器；而DVT则从密码学的最底层向网络展示：验证者的隐私和安全不需要以失去去中心化为代价。
去中心化不是以太坊在2020年某个区块高度获得的徽章，而是一种需要随着每一次协议升级、每一次社会性攻击尝试和每一个新涌现的经济集中化压力而持续重新争夺的属性。对于站在2026年中这个时点的技术观察者来说，最值得关注的或许不是任何一个单一EIP本身，而是这些EIP共同讲述的那个叙事：一个成熟的去中心化协议如何在自身中持续迭代地植入更深刻的博弈结构，使其能够同时在性能、安全和开放性三个维度上继续生长。
本文由技术研究与分析内容生成，信息基于截至2026年6月的公开协议规范、EIP文档及客户端状态更新。技术描述采用定性分析框架，协议部署时间线以以太坊共识开发者社区公告为准。文中涉及的工程数据仅供研究参考，不构成任何形式的部署、投资或配置建议。
评论
0评论加载中…