一文领会以太坊2.0可执行信标链提案_数字货币

[2021-02-10 09:29:52] 来源：编辑：wangjia 点击量：

评论 点击收藏

导读： 报告 | “区块链+数字孪生”，我们能看见怎样的未来世界？我们可以确信，数字孪生在区块链的构建系统下，能够获得深入应用，并在未来某一天实现“共智”，建立镜像世界。11月27日，以太坊开发者Mikh

报告 | “区块链+数字孪生”，我们能看见怎样的未来世界？

我们可以确信，数字孪生在区块链的构建系统下，能够获得深入应用，并在未来某一天实现“共智”，建立镜像世界。

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

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

特别感谢Vitalik Buterin的创意，@djrtwo、 @zilm以及其他人的谈论和有用的孝敬。

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

Eth1 分片设计假设通过信标链与数据分片举行通讯。若是具有多个执行分片的第二阶段（Phase 2）在以后推出，那么这种方式将是有意义的。由于当前主要集中在以rollup为中央的门路图上，将以太坊1.0放在一个专用的分片上（也就是说，自力于信标链）给共识层带来了不必要的复杂性，并增加了在分片上公布数据以及在Eth1 中接见它们之间的延迟。

我们建议通过将eth1数据（买卖、状态根等）嵌入到信标区块中，并强制信标链提议者天生可执行的eth1数据来消除这种复杂性。这会把eth1执行和有用性作为共识的一等公民。

提案概述 Eth1引擎由系统中的每个验证者卖力维护。当验证者计划提出一个信标区块时，它会要求eth1引擎建立eth1数据。然后，Eth1数据会被嵌入正在天生的信标区块体当中。若是eth1数据无效，它也会使得承载它的信标区块失效。 Eth1引擎修改

凭据之前的方案，Eth1分片中枢、Eth1引擎以及eth2客户端是松散结合并通过RPC协议举行通讯的（请检查Eth1+eth2客户端关系以领会更多详细信息）。Eth1引擎继续维护买卖池和需要自己网络客栈的状态下载器，它还应该保留eth1区块的存储。

当前的提案删除了eht1区块的观点，eth1引擎有两种潜在的方式来处置这种转变：

由信标区块携带的eth1数据合成天生eth1区块；修改引擎，使买卖处置不需要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分片的职责类似。主要的考察项有：买卖执行，eth2客户端向eth1引擎发送可执行数据。eth1引擎通过处置数据更新其内部内部状态，若是共识检查通过，则返回true，否则返回false。高级用例，好比即时存款处置，也可能需要效果中的完整买卖凭证。买卖池维护，Eth1引擎使用ETH网络协议来广播和跟踪网络中的买卖。守候中的买卖保留在mempool中，用于建立新的可执行数据。可执行数据建立，Eth2客户端发送先前的区块哈希以及eth1状态根、coinbase、时间戳以及建立可执行数据所需的所有其他信息（买卖列表除外）。Eth1引擎返回ExcecutableData的实例。状态治理，Eth1引擎维护状态存储以能够运行Eth1状态执行函数。4、1 它涉及到最终触发的状态trie修剪机制，需要基于信标区块链的状态trie版本控制；注重：长时间没有最终效果，会导致存储中泛起大量垃圾，因此会消耗分外的磁盘空间。 4、2 当无状态执行和“区块建立”停当时，eth1引擎可选择作为纯状态转换功效运行，它可以禁用状态存储，从而削减对磁盘空间的需求。 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引擎的复杂性。读取信标状态的能力可以通过差别的方式实现：

通报状态以及可执行数据。这种方式的主要问题在于处置大的状态副本，若是将直接接见限制为状态数据的一个子集，而该状态数据的子集需要将一小部分状态通报给执行，那么它可能会起作用。双工通讯信道，有了一个双工通道，eth1引擎将能够向信标节点请求EVM同步请求的状态片断。将能够同步向信标节点询问EVM请求的状态。凭据通道的设置方式，延迟可能会成为执行具有信标状态读取的买卖的瓶颈。嵌入式eth1引擎，若是eth1引擎被嵌入到信标节点中（例如，作为一个共享库），它可以通过该节点提供的主机功效从统一内存空间读取状态。剖析 1、网络带宽现在的提案通过可执行数据的巨细来扩大信标区块。不外，由于该提案允许使用高级存入方案，因此有可能删除Deposit操作。

凭据区块利用率，以及平均eth1区块巨细，预期的增长在10％到20％之间，这对网络接口要求的影响很小。

值得注重的是，若是rollup使用CALLDATA，那么eth1区块的巨细在最坏的情况下可能会增长到200kb（gas限制为1200万），从而使可执行信标区块巨细在300kb左右，增加了60%。

2、区块处置时间平均处置时间如下：信标区块 12 ms Epoch 64 ms 以太坊主网区块 200 ms 很难推断出信标链的处置时间，尤其是在验证器集和交联（crosslink ）处置相对较大的情况下（由于分片已推出）。也许在某个时刻，epoch处置将与eth1执行险些同时举行。

削减epoch界限处处置时间的潜在方式，是在epoch的最后一个区块实时到达的情况下，不必守候下一个slot的最先而提前处置epoch。异步状态接见模子允许举行另一种优化。在这种情况下，process_executable_data可以与主process_block甚至process_epoch有用负载并行运行。

改善这项设计

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

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

对于该提案，Vitalik Buterin谈论称：

“干得好！我确实忧郁eth1执行和信标链之间的同步交互。原因是使用同步交互虽然更简朴，但会永远性地划定了验证eth2区块需要运行响应的eth1执行的要求。例如，它排除了允许eth2节点成为eth1无状态客户端等替换方式，而且仅验证eth1方是否是指定委员会的一部分。因此，纵然可执行数据直接在信标区块中，我也会倾向于保持可执行数据与信标链逻辑之间的通讯完全异步。”