一文看懂以太坊2.0可执行信标链提案

11 月 27 日，以太坊开发者 Mikhail Kalinin 提出了名为“Executable Beacon Chain”的 Eth1-Eth2 过渡提案。 据悉，该提案最初的想法来自于以太坊联合创始人 Vitalik Buterin以太坊2.0上海升级，旨在将 eth1 数据（交易、状态根等）嵌入到信标块中，并强制信标链提议者生成可执行的 eth1 数据以消除复杂性。

以下是提案的详细信息：

特别感谢 Vitalik Buterin 的想法，@djrtwo、@zilm 和其他人的评论和有益的贡献。

最近提出的以汇总为中心的路线图建议将数据分片作为以太坊 2.0 中执行的主要缩放因素，允许在单个执行分片上进行缩放并简化整体设计。

Eth1 分片设计假设通过信标链与数据分片进行通信。 如果具有多个执行分片的第 2 阶段稍后推出，这种方法将很有意义。 由于目前关注的是以汇总为中心的路线图，将以太坊 1.0 放在专用分片（即独立于信标链）上会给共识层带来不必要的复杂性，并增加了这最大限度地减少了在分片上发布数据和访问它们之间的延迟在 Eth1 中。

我们建议通过将 eth1 数据（交易、状态根等）嵌入信标块并强制信标链提议者生成可执行的 eth1 数据来消除这种复杂性。 这使得 Eth1 的执行和有效性成为共识的一等公民。

提案概览

Eth1 引擎由系统中的每个验证者维护。 当验证者打算提议一个信标块时，它会要求 eth1 引擎创建 eth1 数据。 然后将 Eth1 数据嵌入到正在生成的信标块体中。 如果 eth1 数据无效，它也会使承载它的信标块无效。

根据之前的方案，Eth1 shard hub、Eth1 engine 和 eth2 client 是松耦合的，通过 RPC 协议进行通信（查看 Eth1+eth2 client 关系了解更多细节）。 eth1 引擎继续维护交易池和需要自己的网络堆栈的状态下载器，它还应该为 eth1 块提供存储空间。

当前的提案移除了 eth1 区块的概念，eth1 引擎有两种可能的方式来处理这个变化：

将信标块携带的eth1数据合成生成eth1块； 修改引擎，使得交易处理不需要eth1块，而是使用eth1数据；

我们使用术语“可执行数据”来表示包括 eth1 状态根、交易列表（包括收据根和布隆过滤器）、coinbases、时间戳、块哈希以及 eth1 状态转换功能所需的所有其他数据位的数据。 在 eth2 规范中，它可能看起来像这样：

class ExecutableData(Container): coinbase: bytes20 # 收集 txs 费用的 Eth1 地址 state_root: bytes32 gas_limit: uint64 gas_used: uint64 transactions: [Transaction, MAX_TRANSACTIONS] receipts_root: bytes32 logs_bloom: List of our engine with ByteList[LOGS_B the eth1分片有类似的职责。 主要观察结果是：

对于事务执行，eth2 客户端将可执行数据发送到 eth1 引擎。 eth1 引擎通过处理数据来更新其内部状态，如果共识检查通过则返回 true，否则返回 false。 高级用例，例如即时存款处理，可能还需要在结果中包含完整的交易凭证。 对于交易池维护，Eth1 引擎使用 ETH 网络协议在网络中广播和跟踪交易。 待处理交易保存在内存池中，用于创建新的可执行数据。 可执行数据创建，Eth2 客户端发送先前的块哈希以及 eth1 状态根、coinbase、时间戳和创建可执行数据所需的所有其他信息（交易列表除外）。 Eth1 引擎返回一个 ExcecutableData 实例。 状态管理，Eth1 引擎维护状态存储以能够运行 Eth1 状态执行功能。 4.1 涉及到最终触发的state trie剪枝机制，需要基于beacon区块链的state trie版本控制； 注意：长时间没有最终结果，会导致存储中产生大量垃圾，从而消耗额外的磁盘空间。 4.2 当无状态执行和“块创建”到位时，eth1 引擎可以选择作为纯状态转换功能运行，这可以禁用状态存储，减少磁盘空间需求。 JSON-RPC 支持，为了便于使用和采用，保留对以太坊 JSON-RPC 的支持很重要。 这个责任将在 eth2 客户端和 eth1 引擎之间分担，因为 eth1 引擎可能失去独立处理 JSON-RPC 端点子集的能力，例如块号和基于哈希的调用。 这种分离将在稍后解决。

ExecutableData 结构取代了信标块主体中的 Eth1Data。 此外，信标链与eth1的同步过程可以实现即时充值，因此可以将充值从信标区块体中取出。

更新的信标块主体：

class ExecutableBeaconBlockBody(Container): randao_reveal: BLSSignature executable_data: ExecutableData # Eth1 executable data graffiti: Bytes32 #任意数据 # Operations List[SignedVoluntaryExit, MAX_VOLUNTARY_EXITS] 我们修改 process_block 函数如下： body) 曾经在这里 process_operations(state, block.body) process_executable_data(state, block.body) 在process_operations完成后处理可执行数据是合理的，因为有很多地方操作处理可能会使整个块失效。 然而，这种方法可能不是最优的，这为客户端优化留下了空间。在 EVM 中访问信标状态

我们更改了用于返回 eth1 块哈希的 BLOCKHASH 操作码的语义。 现在，它返回的是信标块根，它允许检查信标状态的证明或块中包含的从槽 256 到前一个槽的数据。

异步状态读取有一个主要缺点。 客户端必须等待一个块，然后才能创建一个交易，该交易的证明链接到该块或它产生的状态根。 简而言之，异步状态访问至少延迟一个时隙。

直接状态访问

假设 eth1 引擎可以访问代表整个信标状态的 merkle 树。 然后可以使用操作码 READBEACONSTATEDATA(gindex) 提供 EVM 功能，以提供对任何信标状态的直接访问。 这个操作码有几个不错的属性。 首先，这个读取的复杂度取决于gindex的值，并且很容易计算，因此可以很容易地推断出gas price。 其次，返回数据的大小为 32 字节，非常适合 EVM。

使用此操作码，可以创建更高级别的信标状态访问器库，为智能合约提供方便的 API。 例如：

v = create_validator_accessor(index) # 创建访问器 v.get_balance() # 返回验证器的余额 v.is_slashed() # 返回斜线标志的值 该模型消除了状态访问延迟。 因此，通过对信标链操作和 eth1 执行适当的排序，可以在插槽 N 中访问插槽 N-1 分片数据的交叉链接，从而允许汇总以最快的方式证明数据包含。

此外，这种方法还降低了信标状态读取的数据和计算复杂度。

注意：可能值得首先使 READBEACONSTATEDATA 操作码的语义独立于特定的承诺方案（即 merkle 树）以允许轻松升级。

直接访问的成本增加了 eth1 引擎的复杂性。 读取信标状态的能力可以通过不同的方式实现：

将状态与可执行数据一起传递。 这种方法的主要问题是处理大型状态副本，如果您限制直接访问需要将一小部分状态传递给执行的状态数据子集，它可能会起作用。 双工通信通道，有了双工通道，eth1 引擎将能够向信标节点请求 EVM 同步请求的状态片段。 将能够同步向信标节点询问 EVM 请求的状态。 根据通道的设置方式，延迟可能成为执行具有信标状态读取的事务的瓶颈。 嵌入式eth1引擎，如果eth1引擎嵌入到信标节点中（例如作为共享库），它可以通过节点提供的主机功能从相同的内存空间读取状态。

根据块利用率和平均 eth1 块大小，预期增长在 10% 到 20% 之间以太坊2.0上海升级，对网络接口要求的影响最小。

值得注意的是，如果 rollup 使用 CALLDATA，那么 eth1 区块大小在最坏情况下（gas limit 为 1200 万）可以增长到 200kb，使得可执行信标区块大小在 300kb 左右，增加了 60%。

2. 区块处理时间平均处理时间如下：

信标块 12 毫秒 Epoch 64 毫秒 以太坊主网块 200 毫秒

减少纪元边界处理时间的一种潜在方法是，如果纪元的最后一个块及时到达，则不必等待下一个时隙的开始，就可以更早地处理纪元。 异步状态访问模型允许另一个优化。 在这种情况下，process_executable_data 可以与主 process_block 甚至 process_epoch 负载并行运行。

改进这个设计

有人可能会争辩说，当前的提案会一成不变地设置执行模型，并降低在需要时引入更多可执行分片的能力。

另一方面，一些可执行分片引入了跨分片通信、共享账户空间等问题，这些问题与预期的执行模型转变一样重要且难以解决。

关于该提案，Vitalik Buterin 评论道：

“干得好！我确实担心 eth1 执行和信标链之间的同步交互。原因是使用同步交互虽然更简单，但永久强加了验证 eth2 块需要运行相应的 eth1 实现的要求。例如，它排除了其他选择，比如允许 eth2 节点成为 eth1 的无状态客户端，并且只验证 eth1 方是指定委员会的一部分。所以即使可执行数据直接在信标块中，我也倾向于保持它的可执行性数据和信标链逻辑之间的通信是完全异步的。”

本文链接：