以太坊2.0 Casper + shading开发更新#13 — Prysmatic Labs

我们整个Prysmatic Labs团队在以太坊2.0上每两周更新一次

研究更新

批量跨碎片交易费支付

提出了一个重要的问题,如果用户想在任何分片上发送交易该怎么办? 他们是否需要在所有分片上存储以太坊以支付费用? 正如Vitalik在这篇研究文章中提到的那样,我们可以在协议中或作为第2层系统构建这种类型的服务。

Vitalik提出了费用结算合同。 想要发送交易的用户必须将ETH存入合同。 每个分片中都有一个费用转送合同。 当用户从分片1向分片99发送交易并收费时,会发生以下情况:

  1. 执行交易时,块生产者以费用金额作为参数调用当前分片的费用远期合同
  2. 费用远期合同将记录费用金额,块生产者的地址和费用支付者。
  3. 在每个周期结束时,费用结算合同向主费用结算合同发送一个包含所有先前收集的记录的单个交叉分片调用。
  4. 主费用结算合同将处理所有记录,并增加/减少所有帐户余额。

这种类型的第2层解决方案提供了一种高效且可扩展的方式来促进跨分片事务。 如果您有兴趣继续研究,请联系我们!

合并代码,拉取请求和问题

提案人验证者责任

以太坊2.0的关键是提议者的概念,这是一个验证器,已被授予创建信标节点中包含分片交叉链接的块的权限。 验证器会在给定的64个信标节点周期内进行洗牌,并可以向该节点提出块,然后由证明者对该块进行表决。 在当前代码中,我们已经完成了对提议者的责任,该责任者作用于分配的插槽,汇总证明记录,并将分片交叉链接打包为一个结构,然后成为信标块。

我们的提议者连接到正在运行的信标链节点,并通过我们的gRPC库通过RPC调用提交软件包。

证明者验证者责任

以太坊2.0的另一个重要方面是Attester的概念。 证明者是一种验证者,已被赋予在给定插槽的区块上进行表决/签出的权利。 当证明者证明一个区块时,它需要验证该区块是有效的,并且需要在本地被视为链的头。 如果该块有效,则可能意味着证明者已经处理了该块,已经处理了该块中的所有证明,并在该块上应用了分叉选择规则。 要重申,要处理一个块,在块验证期间必须满足以下条件:

1.)确保父块已处理

2.)确保PoW链参考指向PoW链上的已处理块

3.)确保本地时间足够大以处理该块的插槽

4.)验证父区块的提议者的证明已包含在链中

我们已经完成了在指定插槽上作用的证明者职责,它从信标节点接收传入的头块,然后将其分片ID,索引插入位域块哈希中并创建证明。 然后,通过RPC方法将证明发送回信标链节点。

RPC验证程序交互

验证者将需要与信标节点进行通信,以交换块和证明。 提议者将先前块的证明聚合到提议的块中,然后将提议块发送到信标节点。 然后,信标节点获取提议的块,并将其发送给证明者以获取要证明的块。 在证明者验证该块然后对其进行证明之后,他们将其证明发送回信标节点。

最初,对于与信标节点的验证者交互,我们决定使用p2p,但经过大量讨论,我们决定提议者和证明者应仅通过gRPC与信标节点交互。 原因主要是从安全角度出发,因为使验证者客户端使用p2p来传递阻止和证明数据会带来安全性问题,因为任何恶意参与者都可能向验证者客户端发送无效证明或阻止。 考虑到这一点,我们决定使用gRPC而不是p2p在验证程序客户端之间实现消息传递。 此功能已在此PR中合并。

信标链处理和叉子选择

在以太坊2.0中,可以提出一个区块的时间间隔称为slot ,并且临时定义为恰好为8秒。 在运行客户端时,至关重要的是时间的概念在会话和其他客户端之间必须保持一致,因此我们将利用单调时钟来跟踪自发生时间戳以来的秒数,并除以8以确定客户端当前的插槽特别是,这允许我们在每个新的时隙间隔开始时运行分叉选择规则,如果有任何待处理的块。 在生产中,重要的是要确保所有客户端(与某些NTP服务器相比)都验证其时间戳,以确保每个人都同步。

我们已经重构了信标节点和验证器客户端,以便在此处利用插槽的时间性质。

即将开展的工作

信标链+验证器系统的有意义的演示

我们最新工作的一大动力是包装信标链+验证程序客户端的本地开发演示。 我们希望贡献者和社区成员能够在其计算机上旋转一个节点,并根据系统的不同部分(包括分叉选择,块同步,验证器改组和状态转换)看到链前进。

我们朝着这个目标取得了良好的进展,并在此处创建了一个跟踪问题

对各种数据库进行基准测试

存储引擎LevelDB是我们从Geth分支继承而来的一款软件。 作为用Go编写的简单的嵌入式键/值存储,LevelDB运作良好。 但是,在看到Badh在Geth中的实现和数据库损坏问题之后,我们决定留出时间自己调查其他选择。

我们的第一个要求是存储引擎是嵌入式的。 验证需要简单,并且单独的数据库过程将阻碍该目标。 第二个要求是用Go编写数据库。 RocksDB和LMDB在纸上看起来不错,但我们认为使用C绑定的开销会太高。 考虑了这些要求之后,我们决定更深入地研究三个选项:Bolt,Badger和LevelDB。 Bolt使用B + tree来索引键值对,而LevelDB和Badger使用LSM-tree作为基础数据结构。 LevelDB和Badger之间的区别是,仅密钥在LSM树中建立索引,而值则写入仅附加日志。 实际上,这会导致更快的读写速度,尤其是在SSD上且具有较大的值时。

在对所有三个选项进行测试和基准测试之后,我们认为Bolt将是我们用例的最佳选择。 尽管LevelDB和Badger在重载基准测试中的表现优于LSM树,但两者之间的差异并不大。 另一方面,Bolt在重载基准测试中的表现要好得多。 我们还注意到,与其他两个选项相比,Bolt占用了更多的磁盘空间。 但是,一个关键的要求是,不会丢失对数据库的写入,而Bolt在那里提供了最有力的保证。 LevelDB长期存在数据损坏和写入丢失的问题。 迁移到Bolt时的一项要求是,将来可以扩展数据层。 我们仍然可以接受其他选择,但现在对我们的选择感到满意! 如果您想了解我们如何测试每个数据库,请看一下基准测试。

杂项

新的贡献者,良好的第一期刊物和奖励

在过去的两周中,我们已经打开了许多新期刊,并收到了几位新撰稿人的要求。 我们很高兴与社区互动,并特别感谢Gitcoin帮助我们悬赏了三个新问题。 与往常一样,我们正在寻找新的贡献者来帮助构建以太坊2.0并将他们自己的观点带入该项目。 如果您有任何想法或建议,请提出问题或与他人讨论。

以太坊分片实施者呼叫#3

我们一直在寻找有兴趣帮助我们的开发者! 如果您了解Go或Solidity并想为以太坊研究的最前沿做贡献,请给我们留言,我们非常乐意为您提供帮助:)。

在Github上查看我们的贡献准则和开放项目。 每个任务和问题以及它所属的特定项目(与智能合约相关的任务,公证节点任务等)都分为第一阶段里程碑。

与往常一样,在Twitter上关注我们,在这里或在Discord服务器上给我们留言,让我们知道您想提供的帮助-我们需要我们能够获得的所有协作

Prysmatic Labs乙醚捐赠官方地址

0x9B984D5a03980D8dc0a24506c968465424c81DbE

Prysmatic Labs ENS官方名称

拟态