区块链进化之路：众比特币|以太坊2.0可执行信标链

金色财经报道，北京时间11月26日，以太坊核心开发人员Mikhail Kalinin在以太坊研究者论坛发起了一个从Eth1到Eth2的过渡提案“可执行信标链”。根据该提案，这个Eth2执行模型可以替代可执行的分片，并支持信标链中包含的单个执行线程。该提案的初衷是通过将eth1数据（交易和状态根等）嵌入到信标区块中，并让信标提议者生成可执行的eth1数据，以降低复杂性。

Eth1的分片设计是假设通过信标链与数据分片进行通信。如果多个执行分片的第2阶段能够顺利推出，那么这种方法就有意义了。但由于目前以rollup为中心的路线图，将Eth1放在专用分片上会给共识层增加不必要的复杂性，并且增加在分片上发布数据和访问分片之间的延迟。

因此，我们建议通过将eth1数据（交易，状态根等）嵌入信标块中，并让信标链的验证者生成可执行的eth1数据来摆脱这种复杂性。

提案概述： - Eth1引擎由系统中的每个验证者维护。当验证者打算提出一个信标块时，它会要求eth1引擎创建eth1数据，并将该数据嵌入正在生成的信标块的主体中。如果eth1数据无效，那么携带该数据的信标块也会变得无效。

Eth1引擎的修改： - 根据之前的内容，以Eth1Shard为中心设计，eth1引擎和eth2客户端通过RPC协议松散耦合进行通信。Eth1引擎维护自己的网络堆栈、交易池和状态下载器，并保留eth1块的存储。 - 当前的提议删除了eth1块的概念，eth1引擎有两种可能的处理方式： 1. 从信标块携带的eth1数据中综合创建eth1块。 2. 修改引擎，使交易处理不需要eth1块，而使用eth1数据。

Eth1引擎的责任列表类似于之前对Eth1Shard的责任。主要包括： - 交易执行：Eth2客户端将可执行数据发送给eth1引擎，eth1引擎通过处理数据来更新自己的内部状态。 - 交易池维护：Eth1引擎使用ETH网络协议传播和跟踪线路中的交易。待处理的交易保存在内存池中，并用于创建新的可执行数据。 - 可执行数据创建：Eth2客户端发送以前的块哈希和eth1状态根、coinbase、时间戳以及创建可执行数据所需的所有其他信息（交易列表的一部分）。 - 状态管理：Eth1引擎维护状态存储以能够运行eth1状态执行功能。

在信标块处理中，Eth1Data被ExecutableData结构替代信标链和eth1的同步处理可实现即时存款，从而可以从信标块主体中去除存款。

在EVM（以太坊虚拟机）中访问信标状态时，我们更改了BLOCKHASH操作码的语义，使其返回信标块根而不是eth1块哈希。这样可以用于检查信标状态或块中包含的那些数据的证明。

直接访问信标状态有一个主要缺点，就是需要等待一个块才能创建带有连接到该块的证明或其产生的状态根的交易。简而言之，异步状态访问至少要延迟一个插槽。

为了解决这个问题，我们可以假设eth1引擎可以访问表示整个信标状态的merkle树。然后，通过在EVM中引入操作码READBEACONSTATEDATA(gindex)，可以直接访问任何信标状态。使用这个操作码，可以创建更高级别的信标状态访问器库，为智能合约提供方便的API。

这种模型消除了状态访问的延迟，并且通过正确排列信标链操作和eth1执行（后者遵循前者），可以在一个插槽中访问到插槽分片数据的交叉链接。这样一来，rollup可以以最快的方式证明数据，并且降低了信标状态读取的数据和计算复杂性。

直接访问信标状态会增加eth1引擎的复杂性。读取信标状态的能力可以通过不同的方式实现，例如传递状态以及可执行数据、双工通信通道或嵌入式eth1引擎。

有人可能会说，当前的提议固定了执行模型，并在需要时降低了引入更多可执行分片的能力。

另一方面，引入几个可执行分片可能会引发一些问题，例如跨分片通信和共享帐户空间等，这些问题与执行模型的预期转变同样重要，但也难以解决。