EIP-7732（ePBS）如何优化区块验证过程？

作者：0XNATALIE 来源：chainfeeds

EIP-7732 的背景及动机

由于 MEV 的问题很难从根源解决，所以采取公平竞争的措施是避免造成安全隐患的必经之路。在以太坊合并之后，为了保持公平，减轻大型质押池对 MEV 提取的规模效应，Flashbots 推出 MEV-Boost，通过采用 PBS（Proposer-Builder Separation）机制来减少验证者直接参与 MEV活动的机会，将 MEV 利益相关者多样化。目前 MEV-Boost 区块占比已经超过 90%。

随着 MEV-Boost 的广泛采用，以太坊社区开始担忧依赖这种第三方服务可能带来的安全风险，因此，便产生了在以太坊协议内实施 PBS 的想法，称为 ePBS（Enshrined Proposer-Builder Separation）。最近，ePBS 被赋予了正式的 EIP 编号：EIP-7732。EIP-7732 是共识层的更改，无需更改执行层。核心是将执行验证从共识验证中逻辑上和时间上分离出来，将执行验证推迟至共识验证完成后进行。

EIP-7732 的提出，除了解决验证者依赖第三方（如 MEV-Boost）构建执行有效负载的问题，还旨在优化验证过程中的效率。当前验证者必须在极短的时间（4 秒内）完成所有共识和执行状态转换功能，这对计算资源和网络带宽的要求极高。在这个窗口期内，验证者需要验证和确认大量的交易信息，并更新区块链的状态，这不仅增加了单个节点的计算负担，也加大了出错的可能性。通过将执行验证和共识验证分离，确保在关键的 4 秒窗口内，节点只需要完成相对较少的任务，从而减轻了计算负担，加快网络传播速度。

EIP-7732 的核心内容

EIP-7732 创建了新的角色「构建者」，这是验证者的一种新的可选职责，任何拥有足够资金在信标链上进行质押和有能力执行区块构建任务的验证者都可以成为构建者。构建者负责构建和提交执行有效负载的承诺。验证者现在可以将执行有效负载的构建任务外包给构建者，自己则更专注于共识层面的任务。

执行有效负载（Execution Payload）是区块中最核心的部分，包含了所有的交易和状态变更信息。构建执行有效负载的过程包括从内存池中选择交易、排序交易、依次执行交易、所有信息打包形成执行有效负载。

为了实现这一分离，EIP-7732 移除了 ExecutionPayload 字段，该字段包含了与交易执行相关的所有数据，比如交易列表和状态转换结果等。通过移除这个字段，执行内容的创建和验证被从信标块的创建和验证中分离出来。作为替代，EIP-7732 引入了新的数据结构 SignedExecutionPayloadHeader，它包括了构建者对未来将揭示的执行有效负载的承诺。

整体流程

构建者的任务：构建者负责创建执行有效负载，并生成即将公开执行有效负载的一个承诺。该承诺被封装在 SignedExecutionPayloadHeader 的数据结构中，其中包括执行有效负载的哈希和对此哈希的数字签名，以确保数据的不可篡改性和来源的验证性。这个承诺表示构建者将在未来某一确定时间内公开完整的执行有效负载，并规定了支付给信标块提议者的金额，以激励信标块提议者包含此承诺。

信标块提议者的任务：信标块提议者（验证者）与构建者合作，在创建新的信标块时不需要直接处理交易的执行细节，而是包括由构建者提供的承诺，然后将整个信标块广播到以太坊网络，以达成共识。只包含承诺可以减轻网络的负担，加速信标块的传播和共识验证过程。处理了构建者的承诺后，承诺里的小费将从构建者的信标链余额中扣除，并记入信标块提议者。在信标块提议者成功地广播了含承诺的信标块后，构建者需要在规定的时间窗口内公开完整的执行有效负载。

PTC 验证：为了监控构建者是否及时公开执行有效负载，信标链网络随机选出的一组验证者组成有效负载及时性委员会（PTC）。PTC 负责检查构建者是否在规定的时间窗口内公开了与承诺相匹配执行有效负载。如果构建者未能及时且正确地公开，PTC 将广播一个负面的结果，构建者会面临削减质押的惩罚。如果 PTC 验证通过，则执行有效负载的完整验证被推迟到下一个信标块期间单独处理，也就是延迟验证。

除此之外，提案还引入了针对 PTC 的监管规则和新的惩罚机制，以确保整个验证过程的严格性和公正性。同时，由于执行有效负载和信标块的分离，分叉选择逻辑也进行了调整，以适应新的验证流程，这些改变预计将显著提高网络的安全性和效率。通过一系列的设计，EIP-7732 改善了以太坊的处理效率，降低了网络延迟。