以太坊 2.0 开发更新 - Prysmatic Labs

点击上方“统一时代”订阅！

unitimes.io

全球视野，独到见解

Prysmatic Labs 团队每两周更新一次以太坊 2.0 Serenity 路线图的开发进度。

最新研究进展更新

01

信标链 CBC Casper

Casper CBC（Correct by Construction）和Casper FFG（Friendly Finality Gadget）自提出以来引起了广泛的讨论。 然而，我们需要知道的是，这并不是两种相互竞争的权益证明 (PoS) 模型：CBC 是一种推理共识协议的方式，而 FFG 是基于权益证明的具体实现共识协议。 提议。 在过去的一段时间里，CBC 一直被批评在确保复杂性和协议效率方面负担过重。 尽管 CBC 具有很高的安全性，但 Vitalik 已经很好地解释了如何在不牺牲效率的情况下使用以太坊 Serenity 客户端。 在这种情况下，受益于CBC的概念，如下图所示：

两者的主要区别在于CBC的分叉选择规则：与FFG模式相比，CBC模式在时间复杂度上更加低效，因为在交换消息时需要更多的验证者（注：时间复杂度同样的问题可以用不同的算法来解决，算法的好坏会影响算法甚至程序的效率。）Vitalik 建议通过在伪随机选择的验证者子集上运行 CBC 来修改 CBC 分叉选择规则，而牺牲少量的容错性。 最终，这将为客户端带来 CBC 的健壮性，即使有一些权衡，也是值得的。 更多信息请参考Vitalik发表的ETHResearch（以太坊研究）文章，链接：

02

验证者抵押合约的最新变化

Prysmatic 团队更新了验证者质押合约（

) 来实现 Solidity 0.51 规则并匹配 spec 2.0 规范中的 Vyper 示例代码。 该团队发现使用 abi.encodePacked 比使用 mergeBytes 消耗更少的 gas，但差异并不大。

该团队优化并彻底测试了 toBytes()、mergeBytes() 和 getReceiptRoot() 的操作。 此外，还添加了 Safemath 库来防止抵押时间戳单元的溢出和下溢。

代码合并、合并请求和其他事件

01

最新的区块处理操作已经完成

在最新的规范中，信标链状态转换主要包括 3 个场景： 未接收区块的定期槽处理； 块处理； 纪元处理。 也就是说，即使某个时隙（slot）没有出块，信标链仍然会进行一些记账工作。 然而，在收到区块时，信标链的一些重要细节已经发生了变化。

以太坊 2.0 Prysmatic Labs 开发人员 Raul Jordan 发推文：根据最新规范，所有以太坊 2.0 操作包括 Casper 削减、验证处理、存款处理和 100% 测试的 RANDAO :) - 2019 年将是伟大的一年#Ethereum @prylabs

在状态转换期间，块处理将按以下顺序进行：

团队根据规范完成了上述所有工作。 团队的块处理实现已完成 100% 测试，这是团队代码库中关键代码路径的最佳实践。 详情请参考：

02

最新的epoch操作已通过权益证明

纪元处理是状态转换的下一部分，它在信标链中每 64 个时隙发生一次。 在一个新纪元开始时，验证者受到奖励或惩罚后，将轮换验证者，基于 Casper 权益证明确定区块，并处理所有分片交联。 Prysmatic Labs 团队成员 Terence Tsao 完成了一系列提案，其中包括：

03

状态转换功能已经完成

当前的规范更改涉及必须重构团队的大部分核心操作以适应这些更改。 最大的变化是如何进行状态转换以及这将如何影响团队的区块链服务。 目前，状态转换分为两种转换方式，即per-slot transitions和per-epoch transitions，其中per-slot transitions主要关注聚合签名验证和临时记录（证明记录除外）的存储； per-epoch Transitions主要负责validator注册记录的变更和区块认证定案的管理。 在epoch转换期间，验证者的质押余额将根据其收到的奖惩相应调整，同时激励/驱逐验证者。

基于规范的状态转换函数

由于规范中的这些重大变化，团队不得不重构主要的区块链服务以适应这些变化。 目前，Prysmatic Labs 节点的内部进程依赖于块处理，即在收到块之前不会发生状态转换。 因此，状态将保持一段时间的延迟，在此期间没有接收到任何块，并且在信标节点接收到块之前，状态不会更新到正确的时隙。 目前，块处理如下：

一旦区块如上验证通过，该区块就会被送到状态转换函数，在这个函数中会进行一系列的操作，即上面提到的per-slot transition（执行相关的block操作）和per -epoch transition（验证器注册表受到挑战，如果当前槽在 epoch 范围内，则该块将被最终确定/证明）。

04

通过Tree Hashing算法完成Simple Serialize

Jie Hou 是 Prysmatic Labs 团队的贡献者，完成了以太坊 Serenity 序列化格式的整个 Simple Serialize 规范。 在以太坊1.0阶段，RLP（Recursive Length Prefix Encoding）被用于序列化，Simple Serialize（SSZ）是RLP的替代品。 SSZ 的整个规范已经通过一系列提案完成并合并。 详情请见：

SSZ规格

此外，SSZ 还指定了 Merkle Tree 哈希算法，通过适当的序列化，使访问轻客户端和状态更容易、更高效。 详情请见：

05

纯状态转换函数端到端测试

对于以太坊，跨客户端兼容性至关重要。 如果 Prysmatic Labs 代码与 Lighthouse、Pegasys 或 Lodestar 等客户端不兼容（反之亦然），那么该团队将无法读取相同的协议，从而使 Prysmatic Labs 的工作变得毫无意义。 因此，Prysmatic Labs 遵循以太坊 1.0 的传统，以 YAML 等常见格式进行广泛测试。 使用 YAML，该团队通过为将在所有客户端上运行的一些内部信标链逻辑编写一个简单的测试用例来确保合规性。 该团队称之为合规性测试。 例如，下图显示了在某些插槽之前测试状态转换并验证状态转换确实以正确的方式完成。

Prysmatic Labs 将使用 YAML 编写所有端到端测试，让任何人都可以轻松地在信标链中执行状态转换操作，并验证相关操作是否按预期执行。 Prysmatic Labs 已经进行了相关操作，详见：

Prysmatic Labs 还有一个 CLI 工具，可以更轻松地在 Prysm 上运行 YAML 测试，请参阅：

06

Go-BLS 签名项目准备就绪

Prysmatic Labs 将 1/4 的工作时间用于 BLS 签名聚合的研发。 期间，他们经历了多次实施失败，最终锁定了一个代码库，由原Dfinity项目的密码学家Herumi锁定。 他使用了一个非常好的纯 C/C++ 实现组合，链接：。 Prysmatic Labs 创建了自己的 Go 包装器以太坊地址批量生成，并已拨款 1000 美元用于使用 Prysmatic Labs 的构建系统 Bazel 构建项目。 这个项目的完成要归功于 Robin Thomas() 的辛勤付出！ Prysmatic Labs 将根据 Ethereum Serenity 规范的要求使用该项目进行所有聚合签名和信标链验证。

基本上以太坊 Serenity phase 0 的所有关键部分都已经完成或正在进行中，包括 RANDAO、BLS、Simple Serialize 等 :)

下一份工作

01

2019 年第一季度

Prysmatic 计划在 2019 年第一季度发布 Ethereum Serenity Phase 0 测试网。Prysmatic Labs 目前正在努力提供一个健壮的实施，目前几乎没有剩下的可靠组件。 请密切关注有关 Prysm 客户端在未来几周内如何工作的文档和信息，以及有关测试网的信息。

02

完成验证者轮换

规范中仍将针对每个时期的信标链验证者轮换进行少量返工和优化，这是规范中最后需要做的事情之一，以完全符合核心逻辑。 总体而言，大多数规范更改本质上都是基于优化的。 Serenity Phase 0 的核心理念设定了一些合理的变化。

03

信标块的批量同步模式

Prysmatic Labs 已合并到一项提案中，该提案将允许节点分批请求区块，而不是逐个请求。 与之前的方法相比，这种方法的优点是效率更高，因为在发送多个区块时只需要广播一条消息，减少了节点同步到区块头的时间。 未来的提案还将着眼于验证收到的区块批次的方法，以及如何处理不完整的批次或恶意行为者发送的响应。

04

测试网准备：服务健康检查

Prysmatic Labs 团队成员 Preston Van Loon 一直致力于整合团队测试网架构的各个部分，并强调了对信标链节点的所有组件进行服务健康检查的重要性。 通过让用户了解 RPC 服务、区块链服务、节点的 p2p 等状态，用户更有信心运行信标节点。 这些部分对于扩展 Prysmatic Labs 的测试网集群和确定架构的稳定性至关重要。 Prysmatic Labs 对多个 Prysm 服务进行了安全检查，请参阅：

05

验证者客户端返工

由于当前规范的更改，Prysmatic Labs 不得不重新检查其验证器客户端架构，请参阅：

#heading=h.4d4hnezaletr

规范更改将要求验证者客户端在提议区块时在将区块发送到信标节点之前签署区块提案数据。 区块提议者在提议区块时还需要向信标节点请求状态根。 在客户端之间发送和接收这些数据结构将需要一种全新的 RPC 方法。 目前，这个提案正在致力于解决这个问题：

各种各样的

01

Gitcoin 资助计划

特别感谢 Hibero、Econoar、tyndallm 和 wbobeirne 对 Prysmatic Lab 的 Gitcoin Grants 的财政支持，并感谢 Gitcoin 创建如此出色的项目来资助开源项目。 这些资助将使 Prysmatic Labs 团队能够在 2019 年招募更多的开发人员，进一步推进以太坊 2.0 的实现。

02

信标链实施者电话会议

最近的以太坊 2.0 实施者电话会议于​​ 2019 年 1 月 3 日举行。单击下面的链接可查看会议讨论的主题：

有兴趣参与吗？

Prysmatic Clabs 团队一直在寻找愿意为团队做出贡献的开发人员。 如果你了解 Go 或 Solidity 并想为以太坊研究的前沿做出贡献以太坊地址批量生成，你可以加入团队 :)

团队的参与指南可以在Github上查看：

#contribution-guidelines)

团队的开源项目：

Prysmatic Clabs 推特：

你也可以在Discord服务器上留言：

Prysmatic Labs 官方以太坊捐赠地址：

0x9B984D5a03980D8dc0a24506c968465424c81DbE

Prysmatic Labs 官方 ENS 域名：

prysmatic.eth