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引擎。
有人可能会说,当前的提议固定了执行模型,并在需要时降低了引入更多可执行分片的能力。
另一方面,引入几个可执行分片可能会引发一些问题,例如跨分片通信和共享帐户空间等,这些问题与执行模型的预期转变同样重要,但也难以解决。
本站所有软件信息均由用户上传发布,版权归原著所有。如有侵权/违规内容,敬请来信告知邮箱:764327034@qq.com,我们将及时撤销! 转载请注明出处:https://czxurui.com/zx/53106.html
发表回复
评论列表(0条)