链乔教育在线|以太坊2.0时代2021年最新进展及展望（一）

以太坊2.0的验证结点质押也在如火如荼的进行,相较于其他基于PoS共识的公链,以太坊2.0的活跃质押者数已经遥遥领先。

ETH2.0的重点是从工作量证明（POW）转向权益证明（POS），实现ETH2.0以后不仅网络性能得到大幅提升，投资者也可以减少重资产的投入(+slf0037)。共识协议Casper及分片技术落地，对网络的底层协议作出巨大的改变，还进一步推动了区块链扩容技术向前发展，不断达到商用的标准。截至2021年1月7日16时已经有超过230万个ETH被锁定在该网络中，占以太坊总供应量的2%。然而，这仍然只是更新的第一阶段。

何为以太坊2.0？

以太坊2.0也叫ETH 2或「宁静」，是以太坊区块链的下一次重大升级。自以太坊诞生的那刻起，开发团队就已为它制定了四个发展阶段，分别是前沿（Frontier）、家园（Homestead）、大都会（Metropolis）、宁静（Serenity）。

以太坊2.0有何不同之处？

相比ETH1.0，ETH2.0阶段 主要引入两个改进：PoS（权益证明）和分片链（Shard Chains）。对于矿工来说，以太坊2.0与以太坊1.0最大的不同在于，它将采用“权益证明（PoS）”机制替换当前采用的“工作量证明（PoW）。

想象一下，以太坊1.0是一条繁忙的道路，每个方向都只有一条车道，这意味着在拥堵的时候，所有的车辆都要以缓慢的速度爬行通过。

以太坊2.0将引入分片，其效果是将区块链变成一条有几十条车道的高速公路，所有这些都将提升可以并发处理的交易数量。

可执行信标链

取消了eth1区块的概念。eth1引擎有两种可能的方式来处理这一变化。提出了可执行数据（executable data）这一概念结构，包含eth1状态根、交易清单(包括收据根“receipts root“和bloom filter)、coinbase、时间戳、区块哈希以及eth1状态迁移函数所需要的所有其他数据位。

Eth1-引擎的职责清单与此前eth1分片的职责类似。主要有：交易执行、交易池维护、可执行数据创建、状态管理、JSON-RPC支持、信标区块处理、访问EVM的信标状态、直接状态访问。

可能的改善：

1.?????网络带宽：取决于区块利用率，预期的增长在10%~20%之间。

2.?????区块处理时间：很难腿短出信标链的处理时间。

3.?????固化该设计可能削弱了引进更多可执行分片的能力；另一方面，一些可执行分片会引发一些问题，这些问题与执行模型的预期转变同样重要且难以解决。

提案概览：

Eth1-引擎由系统中的验证者维持。

当验证者打算提议一个信标区块时，他会通过eth1-引擎创建eth1数据。然后eth1数据将被嵌入到其提议的信标区块中。如果eth1数据无效，其所在的信标区块也同样无效。

Eth1引擎的修改：

当前的提案取消了eth1区块的概念，eth1-引擎有两种可能的方式来处理这一变化：

1.????通过合成的方式，从信标链区块的eth1数据中创建eth1区块

2.????修改引擎：交易处理过程不需要使用eth1区块，而是使用eth1数据信标区块根可用于保存当前状态管理所需要的链的概念两者相比，后者为比较长期的选项。

我们使用术语“可执行数据”(executable data)来表示包含eth1状态根、交易清单(包括收据根“receipts root“和bloom filter)、coinbase、时间戳、区块哈希以及eth1状态迁移函数所需要的所有其他数据位。

可执行数据在eth2规范中表示如下：

class ExecutableData(Container):

coinbase: bytes20# Eth1 address that collects txs feesstate_root: bytes32

gas_limit: uint64

gas_used: uint64

transactions: [Transaction, MAX_TRANSACTIONS]

receipts_root: bytes32

logs_bloom: ByteList[LOGS_BLOOM_SIZE]

当验证者打算提议一个信标区块时，他会通过eth1-引擎创建eth1数据。然后eth1数据将被嵌入到其提议的信标区块中。如果eth1数据无效，其所在的信标区块也同样无效。

Eth1-引擎的职责清单与此前eth1分片的职责类似。主要有：

交易执行。Eth2-客户端向eth1-引擎发送一笔可执行数据。Eth1-引擎通过处理该数据来更新其内部状态，并且如果通过了共识检查则返回true，否则返回false。

交易池维护。Eth1-引擎使用ETH网络协议来广播信息并跟踪网络上的交易。等待被打包的交易(pending transactions)保存在交易池中，然后用于创建新的可执行数据。

可执行数据创建。Eth2-客户端发送之前的区块哈希、eth1状态根、coinbase、时间戳和创建可执行数据的所有其他信息(交易清单的一部分)。Eth1-引擎返回一个ExcecutableData实例。

状态管理。Eth1-引擎维护状态存储以便能够运行eth1状态执行函数。

它涉及在最终确定性上触发的状态树修剪机制(pruning mechanism)，该机制要求基于信标区块链的状态树版本控制。

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

JSON-RPC支持。为了可用性和应用性，保留以太坊JSON-RPC的支持十分重要。该责任将由eth2-客户端和eth1-引擎共同承担，因为eth1-引擎可能失去了单独处理JSON-RPC终端子集的能力，如那些基于区块号和哈希的调用。这种分离将在之后解决。

信标区块处理。可执行数据ExecutableData结构代替了信标区块体中的Eth1Data。此外，信标链和eth1的同步处理允许即时存款。因此，存款可以从信标区块体中移除。

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的数据)。

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

使用此操作码，就可以创建更高级别的信标状态访问库，从而为智能合约提供便捷的API。该模型消除了状态访问延迟。因此，通过对信标链操作和eth1执行进行适当的排序(eth1执行在后)，并且在slot N上可以访问slot N-1分片数据的交联，可以允许rollup以最快的方式对数据打包进行证明。

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

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

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

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

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

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

分析

网络带宽。

当前提案通过可执行数据的容量来扩大信标区块。不过，由于该提案允许使用更高级的存款方案，因此很有可能删除Deposit操作。取决于区块利用率，根据eth1平均区块容量(这略微影响网络接口的需求)，预期的增长在10%到20%之间。

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

区块处理时间

平均处理时间：

操作平均时间，毫秒信标区块12Epoch64以太坊主网区块200

减少时段边界(epoch boundary)处理时间的方法是，提前处理epoch，而不是等到下一个slot的开始，以防最近一个epoch的最后一个区块准时产生。异步状态访问模型允许另一种优化方式。在这种情况下，process_executable_data可能与主要的process_block，甚至process_epoch的有效负载并行运行。很难推断出信标链的处理时间，尤其是，特别是在验证者子集相对较大以及需要处理交联的情况下(如果分片上线)。也许在某个时候，epoch处理将与eth1执行几乎同时进行。

固化该设计

有人可能会说，当前提案将执行模型固定下来，并削弱了引进更多可执行分片的能力(一旦我们需要它们)。另一方面，一些可执行分片会带来诸如跨分片通信、共享账户空间等问题。还有一些其他的问题，而这些问题与执行模型的预期转变同样重要且难以解决。

—-

编译者/作者：链乔教育在线

玩币族申明：玩币族作为开放的资讯翻译/分享平台，所提供的所有资讯仅代表作者个人观点，与玩币族平台立场无关，且不构成任何投资理财建议。文章版权归原作者所有。