1. 首页
  2. 技术

一文了解以太坊2.0可执行信标链提案

11月27日,以太坊开发者Mikhail Kalinin提出了一种名为「可执行信标链」的Eth1-Eth2过渡提案,据悉,该提案的最初想法来自以太坊联合创始人Vitalik Buterin,其旨在将eth1数据(交易、状态根等)嵌入到信标区块中,并强制信标链提议者生成可执行的eth1数据来消除复杂性。

一文了解以太坊2.0可执行信标链提案

以下是该提案的具体内容:

特别感谢Vitalik Buterin的创意,@djrtwo、 @zilm以及其他人的评论和有用的贡献。

最近提出的以rollup为中心的路线图,提出数据分片作为以太坊2.0中执行的主要扩容因子,允许在单个执行分片上进行扩展,并简化了总体设计。

Eth1 分片设计假设通过信标链与数据分片进行通信。如果具有多个执行分片的第二阶段(Phase 2)在以后推出,那么这种方法将是有意义的。由于当前主要集中在以rollup为中心的路线图上,将以太坊1.0放在一个专用的分片上(也就是说,独立于信标链)给共识层带来了不必要的复杂性,并增加了在分片上发布数据以及在Eth1 中访问它们之间的延迟。

我们建议通过将eth1数据(交易、状态根等)嵌入到信标区块中,并强制信标链提议者生成可执行的eth1数据来消除这种复杂性。这会把eth1执行和有效性作为共识的一等公民。

提案概述

  1. Eth1引擎由系统中的每个验证者负责维护。
  2. 当验证者打算提出一个信标区块时,它会要求eth1引擎创建eth1数据。然后,Eth1数据会被嵌入正在生成的信标区块体当中。
  3. 如果eth1数据无效,它也会使得承载它的信标区块失效。

Eth1引擎修改

根据之前的方案,Eth1分片中枢、Eth1引擎以及eth2客户端是松散结合并通过RPC协议进行通信的(请检查Eth1+eth2客户端关系以了解更多详细信息)。Eth1引擎继续维护交易池和需要自己网络堆栈的状态下载器,它还应该保存eth1区块的存储。

当前的提案删除了eht1区块的概念,eth1引擎有两种潜在的方法来处理这种变化:

  1. 由信标区块携带的eth1数据合成生成eth1区块;
  2. 修改引擎,使交易处理不需要eth1区块,而是使用eth1数据;

前者看起来比后者要更容易实现,它允许更快地将eth1客户端转换为eth1引擎,并且已经被eth1分片poc证明。

我们使用术语「可执行数据」来表示包括eth1状态根、交易列表(包括收据根和bloom过滤器)、coinbase、时间戳、区块哈希以及eth1状态转换功能所需的所有其他数据位的数据。在eth2规范中,它可能如下所示:


class ExecutableData(Container):
coinbase: bytes20 # Eth1 address that collects txs fees
state_root: bytes32
gas_limit: uint64
gas_used: uint64
transactions: [Transaction, MAX_TRANSACTIONS]
receipts_root: bytes32
logs_bloom: ByteList[LOGS_BLOOM_SIZE]

eth1引擎的职责列表与我们以前对eth1分片的职责类似。主要的观察项有:

  1. 交易执行,eth2客户端向eth1引擎发送可执行数据。eth1引擎通过处理数据更新其内部内部状态,如果共识检查通过,则返回true,否则返回false。高级用例,比如即时存款处理,也可能需要结果中的完整交易凭证。
  2. 交易池维护,Eth1引擎使用ETH网络协议来广播和跟踪网络中的交易。等待中的交易保存在mempool中,用于创建新的可执行数据。
  3. 可执行数据创建,Eth2客户端发送先前的区块哈希以及eth1状态根、coinbase、时间戳以及创建可执行数据所需的所有其他信息(交易列表除外)。Eth1引擎返回ExcecutableData的实例。
  4. 状态管理,Eth1引擎维护状态存储以能够运行Eth1状态执行函数。4、1 它涉及到最终触发的状态trie修剪机制,需要基于信标区块链的状态trie版本控制;注意:长时间没有最终结果,会导致存储中出现大量垃圾,因此会消耗额外的磁盘空间。 4、2 当无状态执行和“区块创建”就绪时,eth1引擎可选择作为纯状态转换功能运行,它可以禁用状态存储,从而减少对磁盘空间的需求。
  5. JSON-RPC支持,为了便于使用及采用,保留对以太坊JSON-RPC的支持非常重要。这一责任将由eth2客户端和eth1引擎分担,因为eth1引擎可能会失去独立处理JSON-RPC端点子集的能力,例如基于区块号和哈希的调用。这种分离将在以后解决。

信标区块处理

ExecutableData结构替换信标区块体中的Eth1Data,此外,信标链和eth1的同步处理可实现即时存入,因此,可以从信标区块主体移除deposit。

更新的信标区块体(block body):


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完成后处理可执行数据是合理的,因为在许多地方,操作处理可能会使整个区块失效。不过,这种方法可能是次优的,这为客户端优化留下了空间。

在EVM中访问信标状态

我们更改用于返回eth1区块哈希的BLOCKHASH操作码的语义。现在,它返回的是信标区块根,这允许检查从256个slot开始直到前一个slot的信标状态或区块中包含的那些数据的证明。

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

直接状态访问

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

有了这个操作码,人们可以创建一个更高级别的信标状态访问器库,从而为智能合约提供便捷的API。例如:


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

该模型消除了状态访问延迟。因此,通过对信标链操作和eth1执行适当的排序,可以在slot N中访问到slot N-1 分片数据的交联(crosslink),从而允许rollup以最快的方式证明数据包含在内。

而且,这种方法还降低了信标状态读取的数据及计算复杂性。

注意:可能值得一开始就使READBEACONSTATEDATA操作码的语义独立于特定的承诺方案(即merkle树),以便于轻松升级。

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

  1. 传递状态以及可执行数据。这种方法的主要问题在于处理大的状态副本,如果将直接访问限制为状态数据的一个子集,而该状态数据的子集需要将一小部分状态传递给执行,那么它可能会起作用。
  2. 双工通信信道,有了一个双工通道,eth1引擎将能够向信标节点请求EVM同步请求的状态片段。将能够同步向信标节点询问EVM请求的状态。 根据通道的设置方式,延迟可能会成为执行具有信标状态读取的交易的瓶颈。
  3. 嵌入式eth1引擎,如果eth1引擎被嵌入到信标节点中(例如,作为一个共享库),它可以通过该节点提供的主机功能从同一内存空间读取状态。

分析

1、网络带宽

目前的提案通过可执行数据的大小来扩大信标区块。不过,由于该提案允许使用高级存入方案,因此有可能删除Deposit操作。

根据区块利用率,以及平均eth1区块大小,预期的增长在10%到20%之间,这对网络接口要求的影响很小。

值得注意的是,如果rollup使用CALLDATA,那么eth1区块的大小在最坏的情况下可能会增长到200kb(gas限制为1200万),从而使可执行信标区块大小在300kb左右,增加了60%。

2、区块处理时间

平均处理时间如下:

  1. 信标区块 12 ms
  2. Epoch 64 ms
  3. 以太坊主网区块 200 ms

很难推断出信标链的处理时间,尤其是在验证器集和交联(crosslink )处理相对较大的情况下(因为分片已推出)。也许在某个时候,epoch处理将与eth1执行几乎同时进行。

减少epoch边界处处理时间的潜在方法,是在epoch的最后一个区块及时到达的情况下,不必等待下一个slot的开始而提前处理epoch。异步状态访问模型允许进行另一种优化。在这种情况下,process_executable_data可以与主process_block甚至process_epoch有效负载并行运行。

改善这项设计

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

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

对于该提案,Vitalik Buterin评论称:

“干得好!我确实担心eth1执行和信标链之间的同步交互。原因是使用同步交互虽然更简单,但会永久性地规定了验证eth2区块需要运行相应的eth1执行的要求。例如,它排除了允许eth2节点成为eth1无状态客户端等替代方法,并且仅验证eth1方是否是指定委员会的一部分。 因此,即使可执行数据直接在信标区块中,我也会倾向于保持可执行数据与信标链逻辑之间的通信完全异步。”

该内容来自于互联网公开内容,非区块链原创内容,如若转载,请注明出处:https://htzkw.com/archives/33365

联系我们

aliyinhang@gmail.com