会议：以太坊2.0会议 #39

会议日期: 2020年5月14日，星期四

会议时长：1.5小时

会议视频链接： https://youtu.be/7uZtEy0nNbw

会议日程：

1. 测试和版本更新

2. 客户端更新

3. 测试网更新

4. 研究更新

5. 网络更新

6. 规范讨论

7. 开放讨论/总结

会议主要内容：

1. 会议开始。主持人Danny开始第一个议题：测试和版本的更新。Danny介绍说现在主要力量都集中在v0.12的版本上面，要合并升级后的BLS曲线草案7和相应的测试内容，今明两天应该能够完成。还有一些是前一次网络侧会议结束后的升级和更新。Danny向参加网络侧会议的开发者们表示感谢。另外，还会有极端情况的测试，主要针对区块在状态转换的过程中，同时又在进行多个不同的操作的情况下的测试，Danny认为这个阶段容易出现问题。

Mehdi接着介绍。他们在结构化模糊测试上面做了卓有成效的工作。他先展示了一个帖子，里面详细记录了他们最近的工作。他们已经在以太坊2.0里面实现任意的类型定义，因此可以自定义类型。他认为这是一个很大的进步，同时这些更新已经有了PR。前两周他们和Teku、Nimbus合作，发现了一些问题。Teku上面比较严重的问题是有一个无限循环的错误，出现这个错误是因为SS代码中编码流的结尾没有结束标志。Nimbus则是出现了分段故障（Segfault）。原因是最终状态确认的函数里出现栈溢出。奖杯列表（Trophy List）里面还有18个未解决的问题。

同时，他们在整合Serenity和Prism的版本，但是碰到了不少情况，目前正在协调中。他们为信标模糊测试提议了一种新的结构，并发出帖子，希望大家能给出意见——这种结构主要是把信标模糊测试分成了三种不同的工具，帖子里面有一个很好的图表可以解释这个原理。Mehdi说因为很多人一直想为以太坊2.0贡献自己的力量，所以他们也在准备Docker镜像，这样整个社区都可以用这个工具来发现错误。最后一件事就是他们已经在查看Lodestar。

Mamy问了一个问题。他说三周前发现一个事项是信标状态不能被信任。他想了解这个问题有没有更新。Mehdi回应说这就是拆分信标模糊测试架构的原因之一：为了避免对此产生混淆，不要依赖信标状态是可信输入的假设。Mehdi告诉Danny说其实有一个还未提交的PR正在解决这个问题，他认为他们团队可能需要在某些节点同步信标状态并且不能太依靠于假设的信标状态的信息。他在Lighthouse中就发现在处理不正确的信标状态的时候，会出现栈溢出，因此他也觉得结构化的模糊测试有助于解决这个问题。

Danny补充说，在网络运行几周后（现在）有两种同步网络的方法：

1）设置一个检查点，从创世开始同步，并确保检查程序达到了这个检查点；

2）从一个可信状态开始，这样的用户体验更好，但有一个小概率的坏处就是有存在状态被污染的风险。

https://blog.sigmaprime.io/beacon-fuzz-04.html

2. 下一个议题是客户端更新。首先分享的是Teku的Jim。他说他们在Gossip PRC上面增加了Snappy压缩，也支持Ping和getMetadata。他们对此做了优化，在同步的时候大幅降低了内存的使用。最后Teku也开始支持Schlesi测试网络。Danny询问内存使用量是什么水平，Jim回复大概是900Mb左右。

接着是Lodestar。Lodestar表示他们这周终于开始做同步Schlesi测试网络的工作。他们同步了许多的代码但还未同步结束。同时修改了一些错误，包括gossip协议的和同步方面的错误。Lodestar希望在接下去的几周能稳定系统，现在的不稳定是因为Disc V5还没有工作，正在解决这个问题。

下一个是Nimbus的更新。Nimbus表示和Lodestar一样，也解决了一些同步问题，尤其是在Snappy上面。同步功能能正常使用而且稳定，但就是速度很慢。现在正在提升效率，尤其是在window上面。还发现了内存泄漏的问题。他们增加了内存使用的监控工具，发现一部分内存占用是来自于Libp2p，还有一些来自于区块的缓存。现在也正在解决这个问题。

Trinity接着发言，他们表示这次更新内容不多，主要工作是移植到一个不同步的框架上，同时也更新了最新的信标节点的验证器的API。最后介绍说来了两个全职的新同事，马上能帮助Trinity开展这些工作。Nethermind下一个发言，但他们表示这周几乎没有更新，他们正在测试和Mothra的同步工作。

Prysm接着发言。他们表示过去几周他们都在做Topaz测试网的维护工作，解决了一些从用户报告过来的错误和一些网络侧的错误。已经全部同步到v0.11.2的规范上，且正在升级到v0.12上面。做了一些不错的同步方面的优化工作，现在能达到每秒100个区块的速度。不足的是这个是没有证词签名的验证，所以继续优化签名验证中。罚没（Slashing）监测做好了，backhand slashing service能正常工作，网络中的罚没代码也正常运作。测试方面他们正在做压力测试和不活跃状态下的最终化测试（inactivity finality test）。增加了一些内部矩阵来监控，截至现在还未发现问题。这个压力测试会继续做几周再观察下会发生什么。Danny询问测试时短时隙的速度，有没有发现分叉的程度（degree offorking)？Prysm回答说现在是1秒一个时隙（slot）的速度，没有特意观察分叉程度，但发现验证节点只有85%的参与度而不是99%，参与度不足的原因是超时。

Lighthouse介绍说他们正在为BLS做分层密钥派生和BLS钱包。他们很自豪地宣布在周一和Trail of Bits公司一起开展了外部的安全检查。他们在运行好几个16,000个验证者的测试。现已经解决了两个问题，也做了大量的内存优化，300M就可以运行信标节点和2,000个验证者节点。正在解决一个共识的问题，现在Lighthouse默认的配置就是Schlesi，而discv5移到独立的仓库中。Lighthouse将所有内容更新成为稳定的版本，这个巨大的升级工作几近完工。最后他们在做RPC的错误处理。

3. 客户端更新完毕，现在的议题是测试网络的更新。Afi首先发言。他介绍过去几周他计划做客户端的测试网络，结果失败了，原因是以太坊2.0的时间戳比最短的创世时间戳要短。不过这个错误很快得到解决，所以两周前多客户端的测试网络Schlesi和Prysm和Lighthouse一起发布了。Schlsei起初表现不佳，但进步很快。他特别强调需要感谢客户端团队的大力帮助。所以到最后一周的结局几乎是完美的。随后Teku、Lodestar和Nimbus都加入了这个测试网络。Afi想知道Trinity加入的计划是什么。

考虑到目前Schlesi的稳定性，他们开始准备v0.12规范版本的多客户端测试网，同时会用上16,000个创世验证节点。希望能找到三个不同的客户端来做这个版本。这个时间点计划是在7月，同时也不能确认实施的时间，所以也和大家讨论一下。Proto补充说他实验性质的把Nimbus和Lodestar同步到Schlesi上面，Lodestar只同步了10%左右，而Nimbus已经快好了，距离头部大概还有100多个区块的距离。他增加了对EthicsStats的支持。

Danny表示说他会放一个区别标志在v0.12版本里面，这样客户端可以知道升级需要多长时间。同时Danny也说大部分网络侧的区别是小的，但是最大的区别是对BLS曲线的支持。他表示Java和Milaca的实施状态不清楚，他询问是否有人了解。有一个工程师回答说他们团队基本做好了Java。Danny表示他知道，也马上要支持Python了。

4. 下一个议题是研究更新。Ewasm团队的Axic说很久没有更新过了，上一次还在几个月之前。他表示一周前他们发布了Eth1x64。在以太研究（https://ethresear.ch）上面有解释的文章，在GitHub的仓库里面也有代码和基于Solidity的例子。Eth1x64使用收据在分片之间传输，发送分片产生收据，然后提交在接收分片里面。Axic说一个简单的例子就是两种代币，在每个分片上面都有DAI。他们下一步是想做新的变种，思路还未确定。但他们大概有两个想法：第一种是yanking，之前已经有相类似的提议了。Axic还提到了一种富交易（rich transactions），这是一种更加高级的yanking；第二种就是ETH传输对象（Eth transfer object），这个之前也有人作为以太坊2.0的特点提出来过。Axic特别强调做这个的目的不是要把以太坊2.0阶段带到EVM里面去，而是在影响最小的情况下来做这方面的实验，并且也想吸引更多的开发者，让他们知道分片是什么样子的。这也是为什么他们在Github的仓库上面提供了例子。长期来看，保留EVM也许并不是一个好办法。因为他们认为以太坊1.0的人都不情愿改动EVM。但是如果新的技术改动很多，那已经可以替代EVM的很多工作，因此也没有保留的必要了。如果我们想在未来做出根本性的改变，不妨改为Wasm。

作为基准测试的一部分，他们也在测试以太坊1.0的预编译器。但如果有了Wasm，以后应该不会保留这些预编译。预编译器的运行结果还是好的，不管是BN128，还是BN256。但是这些都要用到一个功能叫做大整数主机函数（big integer host function）。这个函数类似预编译器，但其实是更加原始的操作，比如2056位比特的加法（Wasm没有这个操作），同时他们也在256位比特上提议了Montgomery乘法，但在BN128上面他们没有达到很好的速度。过去几个月都在研究BLS12，并达到了和初始速率接近的速度。这些速度和解释器（interpreter）有关。一开始他们检查了在RUST上的基础版本的BLS实现办法的速度，但没有达到他们想要的要求。

作为比较，他列举说RUST原始速度是5ms，而最早的Wasm是500ms。接着Snark被加入并做了很多优化，现在达到14ms，他有信心再提高到8ms，这样跟原始速度就很接近了，这是个很好的结果。因为这个结果表明，在Wasm上面也能用BLS的预编译器了。现在他们想尝试是否能在EVM上复制这些结果。所以有了EVM384项目。这个项目大概第二天就能发布。在之前的测试中，三种操作代码被加进EVM进行384位比特的数字的操作。一种是Butler加法，一种是Butler减法和Montgomery乘法。因为时间紧张，不能完全实施BLS12，就用了一种合成的实施办法来代替。他们得到的结果是比较好的，因此在考虑是否已不需要在EVM里面加入BLS12。

https://ethresear.ch/t/the-eth1x64-experiment/7195 https://ethresear.ch/t/eth1x64-variant-1-apostille/7365

Vitalik下一个发言。他正在研究给私密信息检索的同态加密（homomorphicencryption），同时发了一个帖子，请求密码学家帮助解决多项式承诺问题。他也在做监护证明（proof-of-custody）的一阶段简化的工作。Danny建议，既然提到了监护证明，那么可以看一下Dankrad在以太研究上面发表的最新的帖子。其中建议从实际的签名中去掉比特，Danny认为是个很不错的想法。Vitalik表示他也有不错的想法准备发帖。他准备减少密码暴露的频率，这样能减少50%以上的监护证明的复杂程度。

https://ethresear.ch/t/a-0-001-bit-proof-of-custody/7409

下一个是TXRX。Mikail在做以太坊1.0-2.0的合并研究工作，并在上周在以太研究上面发了一个帖子。他还在起草以太坊1.0-2.0的通信协议和一阶段的PoC。在网络监控方面，发现Lighthouse在正在发送未经请求的UDP数据包，创建了PR来纠正。为了分叉选择的测试，构建了一个转译工具，同时也在Teku中发现了问题。在一阶段的Python规范的转译工具中发现了3个错误。已经在JVM libp2p上实现了Gossipsub 1.1。

https://ethresear.ch/t/the-scope-of-eth1-eth2-merger/7362

Danny询问Guillaume在给RPC共识引擎上有没有进展。Guillaume答复说做了一个PR。虽然和许多人经过讨论有了大致的框架，但是还没有具体的实施。

5. 下一个议题是网络侧更新。Danny说上次的网络侧的会议讨论了很多事情。Felix发言说抱歉他没能参加上次的会议，他有一些进展可以分享。他表示他仍在进行discv5的规格更新，也在想办法提高性能，并解决错误消息。新一版的规范即将出版。他期望能从实施团队那里获得反馈，尤其是不愿意升级的原因。因为根据他的经验，在实际网络上的升级应该会更加复杂。随后Danny和Felix有一些关于何时推出这个升级包的讨论。

6. 最后一个议题是规范的讨论。Danny表示他看到一些一阶段的错误和相应的PR。但是现在重点是准备规范v0.12版本。Mamy询问关于分叉选择测试的状态。Danny说要询问一下Alex才能确定是否能在v0.12版本中包含进去。Hsiao-Wei接着发言，她表示有一个PR是关于1阶段的BLS的0签名问题，她已经解决问题但希望大家有兴趣的24小时内去检查一下，这样后面的测试能继续下去。

https://github.com/ethereum/eth2.0-specs/pull/1812

7. Danny宣布会议结束。

欢迎转发，本内容遵循CC BY-SA 2.5协议：

https://creativecommons.org/licenses/by-sa/2.5/

你的支持，是对我们的认可。来打赏我们一杯咖啡吧！**打赏地址：**

以太坊：

0x7Ba18D8d4B0E4EB06a720aF2BeC29603078c806b

Gitcoin:

https://gitcoin.co/grants/468/ethplanet