以太坊2.0开发更新＃35 – Prysmatic Labs
我们每周两次更新由整个Prysmatic Labs团队撰写的关于以太坊宁静路线图的更新。
互操作性事件回顾：成功
Interop取得了成功参加这次静修的每个人都很棒，特别感谢Consensys负责物流。通过libp2p传递信息，团队能够将7种不同的实现互相配合。仅此一项就是一项巨大的成就，更不用说客户正在同步块，证明和最终确定链条。我们在超越的时候超级充满了兴奋的未来
为Devcon V做准备
发布互操作，有更多预期的工作，团队的首要任务是关注同步弹性，这意味着节点可以断开几个插槽，重新上线并赶上其同行。另一个优先级是增强我们的同步策略，从请求来自单个对等体的块到以循环方式从多个对等体请求块。第二层优先级是SSZ弹性，测试覆盖率改进和UX改进。
合并代码，请求和问题
与最新的网络规范一致
我们已经完成了Prysm repo与以太坊Serenity最新最好的官方网络规范的协调。拥有标准的，可升级的网络规范是客户无缝通信的关键，并确保我们有一个很好的方式来处理p2p级别的Eth2的重要功能。最新的网络规范使我们能够更好地处理节点之间的初始握手，以及在节点之间发送带有大量数据的流，以加快通信速度。由于块响应现在被分块而不是作为整体响应发送，这允许节点终止来自早期发送坏数据的对等体的流。您可以在此处查看此跟踪问题的全套更改。
通过Attestations改进性能
原型是以太坊2.0中最常见的网络对象。节点可能每秒处理数十个证明，因此这些代码路径是明确的优化候选者。自上周的互操作事件以来，我们一直在分析并仔细审查任何优化机会的代码，例如尽可能并行处理不同的证明。当我们将测试网络带入完整的主网规模时，这些优化将变得越来越重要。
客户端互操作性实用程序内置于Prysm
为了准备互操作，我们需要与如何快速启动Prysm客户端以确保其他人使用的标准保持一致。其中一个重要特性是能够从创世状态文件启动信标节点，然后可以在客户端之间使用它来测试各种功能。
另一个重要的部分是能够快速简单地进行“冷启动”，这意味着您只需指定验证器的数量和创建时间，系统即可快速旋转，无需任何其他需要。自上次更新以来，我们将这两个功能包括在内，并证明它们对于互操作中的简单原型设计至关重要，甚至可以让我们每天进行本地开发。如果您想了解更多有关此功能以及如何设置Prysm这种方式，头部到我们的互操作性文档在这里。
即将开始的工作
BLS密码学前进
这是因为我们的BLS签名验证库，https://github.com/phoreproject/bls，是THE在Prysm最大的瓶颈和阻碍我们扩展到验证数量庞大的真正重要的东西。看看我们队友Ivan的火焰图，看看我们处理一个块及其底层数据时BLS需要多长时间。
是的，BLS大约占我们运行时间的99.9％……
当我们进入生产准备阶段时，我们确实需要一个替代方案，我们一直关注https://github.com/herumi/bls作为替代方案，但由于局限性而无法整合到Prysm中cgo及其传递依赖性。BLS正迅速成为我们的首要任务，我们将在未来几个月继续探索各种选择。
更大的测试覆盖率，模糊测试，负载测试
为生产做好准备的一部分意味着不仅要测试以太坊信标链运行时的“快乐路径”，还要考虑意外情况，不良数据，垃圾数据和恶意活动。许多官方的以太坊Serenity规范测试确保每个客户端在计算状态转换等方面具有相同的行为，但规范测试肯定不是模糊测试，这是我们迫切需要的。
模糊测试
简而言之，模糊测试意味着将随机数据输入系统以确保它不会爆炸。例如，具有奇怪格式化信息的块，RPC端点接收随机形成的请求等。模糊测试广泛用于诸如序列化库或其他通用工具之类的实用程序，这些工具应该处理某些形状的“通用”数据。或形式。我们现在正在探索广泛的模糊测试功能来测试Prysm并确定其边缘情况。
准备生产的另一个重要方面是对信标节点进行负载测试。关键问题是，是否有一些人发送垃圾邮件节点的开放端点会杀死节点？是否有内置的DoS保护？我们能用这种方式识别微妙的攻击向量吗？通常，可公开访问的Web服务器在投入生产之前会进行负载测试，并且释放Ethereum Serenity也不例外。在这方面期待我们的更多工作以及一些有趣的结果。
档案信标节点功能
Eth1节点可以选择以` – archive`模式运行，该模式存储以太坊区块链的整个状态，包括除了达成共识所需的所有账户和合约数据。通常，块浏览器或其他数据密集型应用程序需要此功能，这些应用程序用于跟踪以太坊网络的历史信息。我们相信它也是Eth2的一个重要特性，这就是为什么我们设计了我们的信标链RPC端点来查询旧数据（如果请求）。对于这一点，我们把一个设计归档数据存储在这里，并通过我们的设计DB API为此开始了工作在这里。
大多数所需的归档信息不是存储每个信标状态，而是相当于验证器集的变化，例如验证器激活，削减，自愿退出等。我们决定存储以下数据结构：
消息ArchivedActiveSetChanges { 重复uint64 activated = 1; 重复uint64退出= 2; 重复uint64弹出= 3; 重复uint64 proposers_slashed = 4; 重复uint64 attesters_slashed = 5; 重复VoluntaryExit voluntary_exits = 6; 重复ProposerSlashing proposer_slashings = 7; 重复AttesterSlashing attester_slashings = 8; }
每个纪元以及有效验证器索引及其余额。我们现在正致力于确保我们的整个后端支持存档，使我们的RPC API对第三方用例更有用。
循环网络同步
照片来源：preact.co.uk
为了提高效率并减轻同伴的个人负担，Prysm正在利用循环同步策略来检索块。该机制将均匀地在对等体之间划分批量块请求。与多个对等体同步减少了服务分叉链或有目的无效块的单个对等体的攻击机会。此外，它减少了单个对等体的负载，因为它们只服务于整个请求的子集。我们希望此策略在加入网络时提供更快，更安全的初始块同步。
使用指数退避进行状态生成
对于具有弱主观性的系统（如ETH2.0）而言非常重要的一个客户端功能是状态生成。ETH2客户端必须设计为重新生成过去的状态，直到至少最近的最终状态。这是为了重新组织我们的链以与fork对齐。我们还可以为RPC调用或依赖于我们具有某种过去状态的任何其他事件重新生成先前状态。
我们将使用一种称为e xponential backoff的策略来生成状态，这意味着我们只保存从当前状态到2的幂的状态，直到最近的最终状态。例如，如果自上次最终确定状态以来我们有2个完整的纪元（128个插槽），我们会将状态保存在128,64,32,16,8,4和2个插槽中。由于我们从最终点保存所有块，我们可以使用它们从保存的点向前重新生成状态。这比为每个槽保存状态要轻得多，因为reorgs最常发生在最近的状态中。
对贡献感兴趣？
我们一直在寻找有兴趣帮助我们的开发者。如果你知道Go或Solidity，并希望为以太坊的研究做出贡献，请给我们留言，我们非常乐意帮助你。:)
查看我们的贡献指南以及我们在Github上的开放项目。每个任务和问题都分为0阶段里程碑及其所属的特定项目。
与往常一样，在Twitter上关注我们或加入我们的Discord服务器，让我们知道您想要提供哪些帮助。
官方，Prysmatic Labs以太坊捐赠地址