以太坊可执行信标链

摘要：可执行信标链作为ETH2的一种替代执行模，除了可执行碎片化之外，还通过在信标链上增加对单个执行线程的支持来实现

Vitalik先前发表的文章“以汇总为中心的路线图”提到，数据碎片作为ETH2执行中的主要扩展因素，允许在单个执行片上进行扩展，并简化了总体设计。

ETH1碎片的设计是基于它通过信标链与数据碎片进行通信。如果后面会介绍第2阶段的多执行切片功能，那么这种方法是有意义的。使用以汇总为中心的路线图，将ETH1放在专用切片上（即，独立于信标链并且频繁地与信标链交互）将给一致性层带来不必要的复杂性，并且增加在切片上发布数据和在ETH1中访问数据之间的延迟。

我们建议将ETH1数据（事务、状态根等）嵌入信标块中，并要求信标链块提议者生成可执行的ETH1数据以消除这种复杂性。也就是说，一等公民以ETH1的实施和有效性为核心达成共识。

提案概述

ETH1引擎由系统中的验证器维护。

当验证者打算提出信标块时，他将通过ETH1引擎创建ETH1数据。ETH1数据随后将被嵌入其提议的信标块中。

如果ETH1数据无效，则其信标块也无效。

ETH1发动机的改造

根据前面的介绍，在以ETH1片段为中心的设计中，ETH1引擎和ETH2客户机是松散耦合的，通过RPC协议进行通信（更多信息请参阅ETH1+ETH2客户机关系一文）。ETH1引擎不断维护它的事务池和状态下载器，这需要它自己的网络堆栈。它还应该存储ETH1块。

当前的方案取消了ETH1块的概念，ETH1引擎有两种可能的方法来处理此更改：

通过综合，由信标链块的ETH1数据生成ETH1块

修改引擎：事务处理不需要使用ETH1块，而需要使用ETH1数据

信标区域块根可以用来保存当前状态管理所需的链概念

与两者相比，后者是一个较长期的选择。它允许ETH1客户机更快地转换为ETH1引擎，ETH1碎片概念验证（POC）已经证明了这一点。

我们使用术语“可执行数据”来表示包含ETH1状态根、事务列表（包括接收根和Bloom过滤器）、CoinBase、时间戳、块哈希以及ETH1状态迁移函数所需的所有其他数据位的数据位。可执行数据在ETH2规范中表示如下

类别；可执行数据（容器）：CoinBase:；字节20；#ETH1地址；即；收集；txs公司；费用；状态根：字节32；气体限值：uint64公司；所用气体：uint64公司；交易记录：[交易]；**交易量]；收据根目录：字节32；原木开花：ByteList[原木BLOOMSIZE]

ETH1引擎的责任列表类似于ETH1片段的责任列表。主要包括：

事务执行。ETH2客户机向ETH1引擎发送可执行数据。ETH1引擎通过处理数据来更新其内部状态，如果通过一致性检查则返回true，否则返回false。诸如即时存款处理之类的**用例也可能要求结果包括完整的交易凭证。

事务池维护。ETH1引擎使用ETH网络协议在网络上广播信息和跟踪事务。等待打包的挂起事务保存在事务池中，然后用于创建新的可执行数据。

可执行数据创建。ETH2—客户机发送上一个块哈希、ETH1状态根、CoinBase、时间戳和所有其他信息来创建可执行数据（事务列表的一部分）。ETH1引擎返回可执行数据的实例。

国家管理

ETH1-引擎维护状态存储，以便可以运行ETH1状态执行函数。

它涉及最终确定性触发的剪枝机制，需要基于信标区块链的状态树版本控制。

注意：长时间不完成块将导致大量垃圾数据积累，从而消耗额外的磁盘空间。

当无状态执行和“块创建”完成后，ETH1引擎可以选择作为纯状态迁移函数运行，并在此基础上承担一些责任。例如，可以禁用状态存储以减少对磁盘空间的需求。

on rpc支持。出于可用性和适用性的考虑，保持对以太坊on-rpc的支持是非常重要的。这个责任将由ETH2客户机和ETH1引擎共同承担，因为ETH1引擎可能会失去单独处理on-rpc终端集的能力，例如那些基于块号和散列的调用。这种分离将在稍后解决。

信标块处理

可执行数据结构替换信标块体中的ETH1数据。此外，信标链和ETH1的同步处理允许即时存款。因此，沉积物可以从信标块中清除。

以下是更新的信标块体：

类可执行BeaconBlockBody（容器）：randao_uo揭示：BLS签名可执行数据：可执行数据ETH1可执行数据涂鸦：Bytes32任意数据操作；提议者签名：列出[提议者签名，**提议者签名]证明者签名：列出[证明，**证明]自愿退出：列表[签名自愿退出，**自愿退出]

我们修改了进程块函数：

DeFi process block（状态：BeaconState，块：BeaconBlock）-无：process block标题（状态，块）process randao（状态，块）；块体)处理数据（状态）；块体)在这里使用；处理操作（状态；块体)处理可执行数据（状态；块体)

在进程中，在操作之后处理可执行数据是合理的，因为在许多情况下，操作处理可能使整个块失效。这种方法虽然不一定是**的，但不能使客户端优化达到**效果。

访问EVM的信标状态

我们更改了blockhash操作码（以前用于返回ETH1块哈希）的语义以返回信标块根。这允许验证打包到信标状态或块中的数据（包括从前256个时隙到最近的时隙的数据）。

异步状态读取有一个主要缺点。客户端必须等待生成块，然后才能使用链接到块的证书或使用块的状态根创建事务。简而言之，异步状态访问至少延迟一个插槽。

直接状态访问

假设ETH1引擎可以访问表示整个信标状态的Merkel树。然后EVM可以使用readbeaconstatedata（gindex）操作代码提供对信标状态的任何部分的直接访问。这个操作码有几个好的特性。首先，读取复杂度取决于gindex值，并且易于计算，因此可以容易地计算气体电荷。其次，返回数据的容量是32字节，这完全适合EVM的32字节字。

使用这个操作码，我们可以创建一个更**的信标状态访问库，从而为智能合约提供一个方便的API。例如：

v=创建验证器访问器（索引）创建；访问器获取balance（）#返回；validatorv.isslashed（）#返回slashed标志的值

该模消除了状态访问延迟。因此，通过对信标链操作和ETH1执行（ETH1执行更晚）进行适当排序，并访问n槽上n-1槽片段数据的交叉链接，可以允许rollup以最快的方式证明数据打包。

另外，该方法不需要向网络广播证据并通过合同进一步验证，从而降低了信标状态数据读取和计算的复杂性。

注意：首先，让readbeaconstatedata操作码的语义独立于特定的承诺方案（即Merkel树）是有意义的，这有利于更容易的升级。

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

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

双工通信信道。通过双工信道，ETH1引擎将能够同步地向信标节点询问EVM请求的状态。根据通道的设置方式，延迟可能成为执行信标状态为read的事务的瓶颈。

嵌入式ETH1引擎。如果ETH1引擎嵌入到信标节点中，它可以通过节点提供的宿主功能从相同的内存空间读取状态。

分析

网络带宽

目前的建议是通过可执行数据的容量来扩展信标块。不过，由于这项建议容许更先进的存款计划，存款业务很可能会被取消。

根据块利用率，基于ETH1平均块容量的预期增长在10%到20%之间，这对网络接口的需求影响不大。

值得注意的是，如果rollup使用calldata，那么在最坏的情况下，ETH1块的容量可能会增加到200KB（当gas限制为1200万时），使得可执行信标块的容量增加60%，变成300KB。

块处理时间

平均处理时间：

托莱多的灯塔有16000个验证器，而主网络上的go以太坊有1200万的气体限制。

信标链的处理时间很难推断，特别是当验证器子集较大且需要处理交叉连接（如果片段在线）时。也许在某个时刻，epoch处理将与ETH1执行几乎同时发生。

减少历元边界处理时间的方法是在下一个时隙之前处理历元，以防止新历元的**一个块按时生成。

异步状态访问模允许另一种优化方法。在这种情况下，进程可执行数据可能与主进程块相关，甚至进程的有效负载也并行运行。

巩固设计

有人可能会说，当前的方案修复了执行模，削弱了引入更多可执行片段的能力（一旦我们需要它们）。

另一方面，一些可执行分片会带来跨分片通信、共享账户空间等问题。还有其他一些问题与执行模的预期转换一样重要，也同样难以解决。