可执行信标链(3)

class ExecutableBeaconBlockBody(Container):    randao_reveal: BLSSignature    executable_data: ExecutableData  # Eth1 executable data    graffiti: Bytes32  # Arbitrary data    # Operations    proposer_slashings: List[ProposerSlashing, MAX_PROPOSER_SLASHINGS]    attester_slashings: List[AttesterSlashing, MAX_ATTESTER_SLASHINGS]    attestations: List[Attestation, MAX_ATTESTATIONS]    voluntary_exits: List[SignedVoluntaryExit, MAX_VOLUNTARY_EXITS]

我们修改了  process_block 函数：

def process_block(state: BeaconState, block: BeaconBlock) -> None:    process_block_header(state, block)    process_randao(state, block.body)    # process_eth1_data(state, block.body) used to be here    process_operations(state, block.body)    process_executable_data(state, block.body)

在 process_operations 完成之后处理可执行数据是合理的，因为在很多情况下，operation processing 可能会使整个区块无效。虽然，这种方法可能不是最优的，无法让客户端优化达到最优效果。

访问 EVM 的信标状态

我们更改了 BLOCKHASH 操作码 (此前用于返回 eth1 区块哈希) 的语义，现在用来返回信标区块根。这允许验证被打包进信标状态或区块的数据 (包括从前 256 个 slot 到最近一个 slot 的数据)。

异步状态读取有一个主要的缺点。客户端必须要等待一个区块产生，才可以使用链接到该区块的证明或使用该区块的状态根创建一个事务。简单地说，异步状态访问至少要延迟一个 slot。

直接状态访问

假设 eth1-引擎可以访问代表整个信标状态的默克尔树。那么 EVM 可能可以凭借 READBEACONSTATEDATA(gindex) 操作码，以提供直接访问信标状态任何部分的功能。这个操作码有几个良好的属性。首先，这种读取复杂性取决于 gindex 值并且易于计算，因此可以轻松地计算 gas 费。第二，返回数据的容量为 32 字节，完全适合 EVM 的 32 字节字。

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

v = create_validator_accessor(index) # creates an accessorv.get_balance() # returns balance of the validatorv.is_slashed()  # returns the value of slashed flag

该模型消除了状态访问延迟。因此，通过对信标链操作和 eth1 执行进行适当的排序 (eth1 执行在后)，并且在 slot N上可以访问 slot N-1 分片数据的交联，可以允许 rollup 以最快的方式对数据打包进行证明。

此外，使用这个方法不需要将证明广播至网络并进一步由合约验证，从而减少了信标状态读取在数据和计算方面的复杂性。

注意：在一开始使 READBEACONSTATEDATA 操作码的语义独立于特定的承诺方案 (即默克尔树) 是有意义的，这有益于更轻松地实现升级。

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

将可执行数据和状态一起传递。该方法的主要问题是处理大容量的状态副本。如果将直接访问限制为状态数据的一个子集，而该状态数据的子集需要将一小部分状态传递给执行，那么它可能会起作用。

双工通信通道。有了双工通道，eth1-引擎将能够同步向信标节点询问 EVM 请求的状态。根据通道设置的方式，延迟可能会成为执行那些具有信标状态读取的交易的瓶颈。

嵌入式的 eth1-引擎。如果将 eth1-引擎嵌入到信标节点中，它可以通过节点提供的托管功能从同一个内存空间读取状态。

分析

网络带宽

当前提案通过可执行数据的容量来扩大信标区块。不过，由于该提案允许使用更高级的存款方案，因此很有可能删除 Deposit 操作。

取决于区块利用率，根据 eth1 平均区块容量 (这略微影响网络接口的需求)，预期的增长在 10% 到 20%之间。

值得注意的是，如果 CALLDATA 由 rollup 利用，那么在最坏的情况下，eth1 区块容量可能会增长到 200kb (gas limit 为 1200 万时)，使得可执行信标区块容量增长 60% ，容量变为 300kb 。

区块处理时间

平均处理时间：