会议： 以太坊2.0会议#42

会议日期: 2020年6月25日

会议时长： 1小时

会议视频链接：

https://youtu.be/P1AEmUt9ltg

会议日程：

1.测试和版本更新

2.测试网更新

-Altona测试网

-Attack测试网

3.客户端更新

4.研究更新

5.网络侧更新

-一些亟待讨论的网络互操作项目

6.规范讨论

7.开放讨论/总结

会议主要内容：

1.会议开始，主持人Danny先开始第一个议题，即测试和版本更新。Danny介绍说这次改动还有相当一部分工作没有完成，其中还加入了一部分测试项，比如无需获悉状态就进行Gossip验证的网络侧确认。这些改动都比较细微，等它们都完成以后，可能很快就会出一个新的版本。

Proto介绍他们的进展。他说他们扩展了Rumor工具来做区块的链测试，通过使用比现有RPC命令更高级的命令，很多工作比如同步测试、基准测试、分叉选择测试等,比将测试单独集成到每个客户端更加容易。Proto表示,如果审核人员发现了任何问题，尤其是发现规范相关的错误，请及时反馈给他。

2.第二个议题，测试网更新。

Altona 测试网

Danny说社区里有很多关于Altona的讨论，还有一些想法试图返回到Genisis上。Afi说他们已经满足了最小抵押合约的数量，也满足了MIN_GENESIS时间。但是因为有些抵押合约需要重写，所以看起来Geinsis要拖延到周末。他担心没有工具在周末来观察Genisis。除了时间问题，其它都没问题，随时可以开始测试。Afi也表示他从周一开始会有几天不在，但并不影响测试工作，因为他并没有成功控制任何Genisis的验证节点，他希望客户端能帮助他控制。Danny提议延长4天时间再开始发布测试网，至于其它细节和Afi约定会后再讨论。

Attack 测试网

Danny说他已经转发了一些介绍文档。他先解释了一下发布Attack测试网的原因。他说Altona是给开发者用作一般用途的，而Attack测试网的成立则是专门给那些有兴趣去破坏测试网、测试安全性的用户使用的。Danny计划当Altona稳定一些的时候，就让EF运行在有稳定的验证节点的客户端上面，然后争取快速迭代。之后也可以让客户端更多地参与进来。Danny说这是大概的计划，时间上计划2周。然后询问大家有无意见。Terence问Attack测试网是否在RPC端点（end point）用到测试替代方法？如果是的话,有没有相关的规范和标准？Danny回答说现在没有，他觉得开放RPC的端点还是比较危险的，先不要接触到主网，先测试一下类似DoS这种类型，然后慢慢的增加开放的程度。

3. 客户端的更新

Prysm：Rual介绍说过去的两周很有效。Quantstamp的审计工作结束了，发现了很多问题，现在正努力地修改找到的错误。Onyx比较稳定了，他们可以控制到2万个验证节点的一半了，内存的使用情况也在改善。他们还在改善惩罚协议，这种改善很大程度上提高了磁盘IO的性能，让他们能够更加容易地在测试网上捕获惩罚状况。同时他们根据关于密钥储存的EIP的讨论，也在做验证节点的账户或者密钥的修改翻新工作。

https://github.com/ethereum/eth2.0-specs/issues/1931

Trinity：Grant说规范从v0.9.4升级到了v0.11.3，同时也工作在v0.12.1上。Alex赶在分叉选择工作之前做预备性的代码重构工作,他们还在进行信标节点的同步工作。一旦这些工作完成，后面将继续尝试连接到Altona测试网。他们预计会碰到一些性能问题，之后再来解决。

Teku：用非阻塞代码替换了阻塞代码和网络侧RPC代码,并且开始了Supranational开源的 Blst BLS库的整合工作。他们通过限制内存中存放的区块数量来提高内存的使用效率，同时也在优化储存的效率和重构分叉选择的代码架构。最后合并了v0.12.1的软件分支到主线上面去，做好准备支持之后默认的Altona测试网的工作。

Lighthouse：Paul介绍说目前他们主要在做接入Altona测试网的准备工作，同步Teku，Trinity等客户端。规范v0.12已经准备好被合入了。为了进行优化,他们重新写了Discv5，也重构了分叉选择的代码。团队优化了节点控制，增加了一个积分系统在里面,并计划做一个验证节点用户界面的认证计划。为了保证一致性,他们还向数据库添加了原子性（atomicity）,然后下一步计划合并新的Blst BLS库，进行密钥的管理工作等。

Nethermind：Tomasz介绍说他们目前正在优化抵押合约的效率，然后下一步是进行信标节点的优化。Tomasz表示,相比其它客户端团队,他们的工作有点延误并且还有很多工作需要做，尤其是关于对等节点互联的工作以及规范的最后升级。

Lodestar: Cayman介绍说,团队的主要工作在v0.12的更新上，但不包括Gossipsub。他们认为还没有准备好可靠地同步到Altona测试网，还有大量调试的工作需要做。最近新加入一个兼职的成员，希望能帮助加快速度。至于密钥管理方面，他们重写了验证节点的CLI代码。

Nimbus：Mamy介绍说和大家一样，团队目前正在做同步到Altona测试网的准备工作。他们做了一些哈希运算的优化的工作，包括通过缓存密钥将开始和重新加载的时间提高了20-100倍，尤其是经过长漫游节点(long roaming node)的时候，也包括内存泄漏的优化，优化后向后同步的速度比向前同步要快。Mamy说,他们还解决了信标节点模糊测试的问题。验证节点分离（validator split）工作有点进展了。他们还准备开始做BLS库后端的工作，具体是Milagro, Herumi还是Blst仍未决定。但Nimbus默认已经到v12.1规范上。网络侧方面，Gossipsub，Discv5有一些进展，同时引入了一个Discv5的矩阵。测试网方面，Oynx测试网已经完成，准备同步到Altona测试网。

4. Danny开始下一个议题，研究更新。

Aditya首先发言。他分享了他在弱主观性（weak subjectivity）方面的研究进展。他在准备一份文档，里面推荐了客户端安排弱主观性检查点的方法。从安全性考虑出发，他推荐客户端从比Genisis更早的时间开始同步。经过缜密的计算,他得出最佳时间是在Genisis之前的14天开始同步。在客户端的工作流程中，从时间上看检查点的分布间隔大约是7-10天。他说还有很多需要讨论的地方，比如检查点在代码中如何分布，是放在客户端的代码中，还是p2p的结束点上。更多的讨论建议放在Discord频道或者下一次会议的时候。Danny回复说，文档他已经看过了，写的很好。

Danny询问Carl说有没有关于密钥存放标准EIP的进展。Carl回复说,关于密钥处理这个问题，上周开会已经讨论过,并对许多事情达成一致。具体来说，EIP-2333在密钥派生上有了一个突破性的变化，同时放宽了撤销密钥的路径要求，在某些条件下,用户可以选择自己设定的路径。关于密钥存储，处理Unicode密码有了进展.经过讨论,他们决定使用与助记符生成（mnemonic generation)相同的机制。现在还有一个描述字段，可以让用户备注。

Danny询问是否和客户端达成了一致？有没有制定一个完善的标准？Carl回复说上次讨论的EIP-2335密钥库是客户端都一致同意的存放和交换密钥的标准。这也是客户端应该做到的最低标准。至于标准制定，Carl希望在标准制定仓库中添加最低限度的实践指南，来代替完整的标准。

Vitalik发言说推荐一个在以太研究上发表的关于GKR的在snark中做哈希运算的帖子。这个研究对于证词压缩很有用，效率很高，可以取代多项式承诺和Verkle树。从数据大小上来说也很有优势：Verkle树根据不同的操作大概有100字节的费用开支，而新的办法的费用开支的字节数可以为零。Dankrad提醒道,新方法使用了代数哈希函数，并没有解决安全性的问题。

https://ethresear.ch/t/using-gkr-inside-a-snark-to-reduce-the-cost-of-hash-verification-down-to-3-constraints/7550

Leo介绍说他们在评估不同类型的gossipsub。希望能够和客户端合作，收集他们曾经遇见过的奇怪的状况。Danny解释说Leo正在深入研究gossipsub攻击防御的事情。

https://github.com/leobago/BSC-ETH2

TXRX介绍说他们正在研究验证节点的去匿名化（deanonymisation）。在以太研究上写了一个叫Packetology的系列。第一个就是关于去核化验证节点的草案。同时他们也在做phase1的客户端。

https://ethresear.ch/t/packetology-validator-privacy/7547

5. 下一个议题是网络侧的更新。Danny表示Rual发现现有的规范里面是支持Snappy以及非Snappy的，所以Danny询问客户端有没有明确的使用场景是用到非Snappy的？一开始是什么原因决定要两种规范都支持的？Jacek回复说当初两个都决定支持是因为要给客户端时间去做Snappy支持。Danny说他认为可以去掉非Snappy了，但还是等待大家的决定。

Jacek说其实对于Snappy压缩我们到现在还没有做全面的分析，我们只是直觉认为证词的比特字段（attestation bit fields）压缩的很好，但是没有确切的数据，所以建议要做一次测试，拿到点数据。Danny表示赞同，应该像做健康检查一样给压缩率做一个测试，分成单个证词，多个证词和一系列区块等情况测试压缩量（compression number）是多少。Leo自愿来完成这个任务。

Danny继续发言谈到yamux技术的支持。他说这是一种先进的技术，他认为这是一种更好的多路复用器（multiplexer），现在还没有人能够支持。Lighthouse和Prysm两者之间还有兼容性的问题，所以最好先屏蔽这个功能直到能够兼容和调试。

Jacek又提出客户端Witti很难连接到Noise上去，感觉规范变了，但很多其它客户端还在运行着旧版本的规范。Danny询问有没有人知道Noise的规范是否已经归档了？Jacek说他不清楚版本，但是他知道第一次的代码实现和现有代码有着很大的差别。Paul也表示Lighthouse和Prysm现在不能连接到Noise上。Danny说可能因为网络侧回退到了secio。Danny建议关闭secio,会后会在网络侧的Discord频道做更多的讨论，包括规范版本以及是否关闭secio。

Jonny询问一个问题，他发现规范上设定了最大的时钟偏差参数是500ms，他询问这个是如何验证的？Jacek表示他不知道如何得出这个数值，但是在之前的审计中他发现这个数值越大效果越好，因为留给进来并且需要验证的数据的时间越长，丢包的情况就越不容易发生。他表示更合理的办法是做一个排队的缓存来存放接收到但来不及处理的数据。Jonny决定调查一下，想找出还有哪些参数和这方面有关，不同参数的调节会得出什么样的效果。最后他会弄一个图表出来。

6. 规范讨论和开放讨论这次没有更新。Danny预祝Altona在即将到来的周一发布成功！会议结束。

与会开发者：

Aditya Asgaonkar

Afr Schoe

Age Manning

Alex Stokes

Ben Edgington

Carl Beekhuizen

Cayman

Danny Ryan

Dankrad

Grant Wuerker

Guillaume

Hsiao-Wei Wang

Jacek Sieka

Jonathan Rhea

Joseph Delong

Lakshiman Sankar

Mamy

Matt Garnett

Mehdi |Sigma Prime

Pooja Ranjan

Protolambda

Raul Jordan

Terence (Prysmatic)

Tomasz S.

Vitalik

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

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

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

以太坊：

0x7Ba18D8d4B0E4EB06a720aF2BeC29603078c806b

Gitcoin:

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