Ethereum Core Devs Meeting #82 以太坊核心开发者会议

首页 > 币界资讯 > 矿业前瞻 2020-04-22 19:00:07

会议：以太坊核心开发者会议 #82

会议日期: 2020年3月6日，星期五

会议时长：3小时

会议视频链接：

https://youtu.be/kham8c0qhmw

会议日程：

1. 先讨论Eth 2.0 BLS signature/EIP-1962相关问题

EIPs #2537

https://github.com/ethereum/EIPs/pull/2537

EIPs #2537

https://github.com/ethereum/EIPs/pull/2539

EIPs #2541

https://github.com/ethereum/EIPs/pull/2541

2. 再讨论ProgPoW，又分三个议题

ProgPoW的技术更新
ProgPoW社区同意/反对意见
ProgPoW下一步计划

其中，支持ProgPoW的代表：

Kristy-Leigh Minehan
Michael Carter (a.k.a Bits Be Trippin)

反对的代表:

Martin Köppelmann
Matt Luongo

折衷想法的代表:

Ben DiFrancesco

会议主要内容：

1.会议由Hudson Jameson主持。他先过了一遍agenda，第一个小时会先讨论BLS曲线签名的事宜。后面一个小时主要讨论关于ProgPow的技术问题和下一步的计划。原定这是一个两个小时的会议，但是事后看，这两个topic都很大，都引起了广泛的深入的讨论，最后导致这次会议长达到了惊人的3个小时。

2.第一个议题开始，由James Hancock来主持BLS讨论。主要是讨论在以太坊2.0的phase 0阶段，到底如何来实现BLS曲线. 他也说以太坊2.0的phase0阶段的智能合约会用到BLS曲线签名。他还说已经对椭圆曲线密码进行了预编译的工作。这个BLS 曲线和之前EIP1962之间，有一些开发者有一些疑问。需要解释一下。接下来James请Alex Vlasov来介绍现在BLS 的现状。

3. Alex说到已经准备了三个PR，分别是BLS12-381, BLS12-377 和零知识执行曲线（Zexe Curve见更多参考内容）这三个都和EIP1962有关。他说它们遵循同样的预算，只是具体一点。而且因为只有一个主要区别，所以这三个的实施办法并不困难，所以建议大家三个一起接受。Martin问EIP-2537是否涵盖了ETH2.0所需的一切，是否增加了不必要的复杂性？Alex说可以通过预编译的办法来解决，而且也能增加智能合约的可靠性和安全性。Vitalik说其实人们对这些曲线很感兴趣，因为这个理论在零知识证明上表现的更加高效，也能帮助很多应用提高隐私和扩展性。接着Martin和Alex和Vitalik进行了一些深入的讨论。最后的结论是虽然长期来说这个功能的有无对以太坊不是最关键的，但是对开发者来说是好的。但是他们还有一个焦点就是到底要在BLS里面做几种曲线实施办法。他们需要找到一个平衡点。因为一方面如果有多于一个的曲线实施办法，会给开发者带来便利，也方便以后的开发，升级。但另一方面，这么做又会增加系统的复杂性，容易导致系统的不确定性，会增加错误，也不容易实现。而且以后支持起来会比较困难。Alex更强调了如果有三个曲线方案给开发者选择的话，那现在他知道的就有五种以上的实现办法。他很担心不止系统的复杂程度会增加，他更担心安全性的问题。他断言肯定会造成安全性的下降。同时，Alex提到实现的工作量并不是很大，也不是很难写的代码。

4. 最后James总结到说最好还是从一个曲线的选项开始，把三个预编译的EIP转移到EFI里面去。他说柏林可以只包含一个预编译，其它的可以包含在以后的分叉中，时间上这个应给和Eth2.0保持一致。

5. 在进行下一个ProgPoW议题之前，Hudson要求James简单更新一下另外三个议题。第一个是EIP2315。James团队的Greg说这个关于EVM subroutine的问题，他们还在更新代码，还没有太多的更新。第二是EIP2416，是关于难度炸弹（difficulty bomb）的，也没有更新，最后是James自己的2515，也是关于难度炸弹（difficulty bomb）的，他说他今天才发了一个帖子（应该在Github上），所有的更新都在里面，所以他就不多说了。

6. 接下来Hudson就开始了下一个议题，就是ProgPow的讨论。他首先说关于ProgPow需要说三个事情。第一个是技术上的更新，第二个是社区的同意与反对。最后是ProgPow的下一步规划是怎么样的。接着他又介绍了几个人。这个有点像介绍辩论队的选手一样。他说先介绍支持ProgPow阵营的选手，再介绍反对ProgPow的选手。他也请几个人自我介绍一下自己的背景。首先是Kristy。她来自于IfDefElse，她参与和负责项目的软件硬件，她也是EIP1057的提出者。下一位是来自于BitsBeTrippin（BBT）的Michael Carter。他代表了BBT channel矿工的一方。他从2013年就开始做矿工相关事情，他代表了矿工的社区支持的一方。接下来三位是反对的阵营。一个是Martin Koppelmann，是咨询公司Gnosis的联合创始人，他从以太坊一开始成立时候就在了。一个是Ben Di，他说他是软件工程师，他运营一个咨询公司Scopelift，专注于数字密码学。他没有太强烈的意见，他刚把他的意见放在了Eth Magicians上面，他想在这里可以详细说说。最后一位是Matt Luongo，他说他2013，14年为BTC工作，2017年来到了以太坊里面，他现在是CEO也是工程师。

7. 接下来就先是技术更新。Hudson请Kristy发言。她先从Least Authority的审计开始。两个建议。一个是增加Dag items的数目，另一个是Keccak的实现，尤其是Keccak周围的填充。她说她们Keccak最终定稿规范中的值，清楚地表明她们没有添加任何额外的东西。所以，她们如何处理Keccak是在官方Keccak的范围内。接着说了一些技术的细节。另一个她说是Least Authority的一个关注点是制作一些额外的文档。她随后又提到两个事情，虽然不在之前的EIP说的范围之内，但是会有帮助的是：一个是建立一个安全的框架去评估ASIC resistance，另一个是了解，监控硬件的趋势和发展。接着她具体说了KIK方法的三个假设，第一个是用户节点的自己实现，有自己的pool之类的。第二个要求对每个块的头散列进行修改，这是矿工设备目前没有提供的功能，最后是需要能够生成足够的Keccak，以便在以太坊的阻塞时间内绕过这些内存访问，当前在12到14秒之间（取决于网络状态）。接着她又说了她的提议（这些应该都可以在Least Authority的audit的文档里面找到）：当前的哈希混合使用初始Keccak循环生成的所有256位种子，建议Keccak只使用64位种子，这样能确保在哈希的所有阶段中256位的安全性。这是一个最小的修复，不会影响哈希算法性能。接着Martin问了说Hash 的Dag会超过4GB，这个会导致哈希算力的下降，大概预测会有40%。他说他希望这个问题能够得到讨论，解决。接着Louis也在这个基础上提了另一个技术问题，关于infrastructure的。接着Kristy和他们有一些讨论。后面Alex也加入了，讨论了很多硬件相关的问题和对系统有什么影响。（具体是关于GDDR内存控制，GDDR5还是6，SRAM硬件升级，多少纳米的芯片之类的。还有就是硬件升级上成本和能力的平衡。）

8. 接下来谈论了DAG是好事还是坏事。Kristy她了解下来矿工已经开始逐步升级GPU到6GB。她说BBT的人可以再详细解释一下。 BBT的Michael继续说矿工的确在升级，有些已经到了8GB了。接着Trenton问到ProgPow是否影响DAG的size，Kristy回答说不影响。后面还有一些问题和回答是关于4GBit ASICS和40% 哈希算力下降的。

9. 下面Hudson就说技术讨论差不多了，就开始社区同意不同意的讨论了。他先说了19年1月开始有了ProgPow，产生了硬分叉。现在硬分叉里面又准备包含进ProgPow。所以community就有了一些不同意见。所以他先请反对ProgPow的人，Martin先来阐述一下社区里面反对的人是怎么想的。

10. Martin说他一开始就反对这个，但是他觉得他不是反对技术本身，他是觉得这个计划想要达到的目的不是他所希望的。他觉得以太坊的一个核心观念是减少平台的风险，不会让任何在上面和周边开发的人认为他们的工作是无效的。所以当以太坊平台把他踢出去之后，他觉得很受伤。接着他谈到了ProgPow和ASICS的关系。他觉得ASICS在现阶段还不清楚到底对ProgPow有没有用，也不确定ProgPow能否达到ASICS resistance。他说到现在开发ASICS在ProgPow下面会造成事情发展的更坏。接着最后他说到，他现在个人的意见已经不重要了，重要的是社区里面的大部分人都不喜欢这个主意，而且据他所知，没有一个项目是支持ProgPow的。

11. 下面主持人请Matt说两句，请他总结一下反对方的观点。Matt说他自己并不是反对这个技术。但是他觉得实现这个ProgPow的过程有问题。他觉得自己虽然还不清楚ProgPow的好处是具体是什么，但是他已经觉得这个好处抵不过带来的分裂的坏处了。他说他也看到了很多团队，公司不喜欢这个主意了。他也说社区觉得没有一个好的地方可以来开诚布公的讨论这个问题（是否执行ProgPow）。他也知道起码有两个团队准备支持客户而不使用ProgPow他说当年比特币分裂的结果是好的，但是对于以太坊他觉得不好，因为有太多stateful projects。

12. 接着主持人又请支持的BBT的Martin来解释一下。Martin先说有一个稍微不同的看法。他从技术上并不反对ProgPoW。他反对的是这样的管理失误，对社区来说这是一个封闭的问题，然而实际上并不是封闭的。他感觉进展得太快了。他也强调说他不认为ProgPoW的好处（对他来说还不清楚）抵得过社区分裂的风险。这个是他论点的关键所在。所以最终需要社区从系统的角度来了解这个转换的风险，是否值得。因为他觉得重要的还是系统的稳定性。接着他说他尊重社区的不同意见，他觉得当有大概40%的网络上是ASICS时候，反而是一个好的机会去改变这个算法。他还说他认为最好不要在有这么多社区人反对的情况下面做下一步行动。他还说作为一个生态圈里面，最好大家再仔细的分析谈论现在的分歧点，不要阻拦以太坊2.0的升级。他也希望大家都参与进来。他也会把他的观点，发现等等放在一个帖子里面，希望能够回答一些反对者的担心。

13. 接下来主持人请Kristy再说几句。于是她说ProgPow这个技术18年就发展起来了，那是第一次提到ASICS。接着当时有很多EIP在谈论ASICS resistance。但是当时她们对这些提议很沮丧，因为大部分都是短期有好处，但长期对系统没有好处的，而却没有考虑到硬件和软件算法的匹配。她说现在2020年了，以太坊有很多的DApp了，她不希望看到分链。她虽然已经在2.0上面做一些实验性的项目，但她也看到很多投资正在ETH1.0挖矿上面进入，她希望1.0主链安全，她也不觉得在未来六个月的时间内会消失，她也希望在1.0上面所有人，所有设备都可以很好的运行。她说到关于ProgPow其实应该叫EthHash2.0，因为ProgPow的意愿之一是加强hash算法去实现之前黄皮书上说的。另一个是确保挖矿的ASICS不去挤压GPU的地方。她说现在ProgPow还是一个proposal的阶段，需要经过实现测试等很多过程。她希望ProgPow能作为一个正常的技术升级，也希望圈子里面的每一个人都能满意。她也承认之前的教育工作没有做好。

14. 主持人又要求Ben总结一下他的提议。Ben说就像他之前说的他并没有强烈的反对ProgPow。但是他发现有很多问题还没有解决，所以这个就导致了分裂。他觉得现在不可能有一方能够说服另外一方，或者说短时间之内都不会发生。他说很明显没有人喜欢分裂，大家都是为了系统的安全，为了让以太坊做的最好出发。所以即便现在大家对于如何升级有不同意见，我们必须有所妥协，聚焦在大家都已经一致的意见上是一个比较好的办法。所以他的提议是ProgPow必须全部实现在主要客户上，但是不用在柏林或其它功能升级的硬分叉上面。客户那边可以加一个开关，由操作员来控制是否打开ProgPow。接着再准备一个测试的网络，如果开关打开就可以用测试的网络，反之不用。这样他觉得网络会安全，大家转移的过程也会比较舒服。同时我们可以把ProgPow当作一个测试的或者备用的挖矿算法，而不是直接用，导致很多人觉得有风险不愿意用。最后他总结说最终，要么会有一个链路分叉，要么就会团结成一个社区，围绕着一个明确的需要去做一件事。所以我们希望可以避免发生这样的未来。但至少现在给了我们一条路，让我们认识到ProgPoW的工作并试图利用它作为一种更好地保护网络和网络未来的方法，并允许我们继续沿着这条道路进行混乱的分散治理过程。

15. 接着针对他的提议Martin提到有一种可能是GPU的hash power可以替代挖矿。Ben回复说可能会降低挖矿的难度但是他强调不是马上在以太坊上用ProgPow，而是觉得风险值得尝试的时候再去做。

16. 后面一些人又有了一些相关的讨论。说到ProgPow从代码和工作量的角度来说不是一个大的改变，但主要是影响hash算法。客户那边升级也不用花费太多的时间。 Hard fork带来的问题等等。还说到主要集中在ASICS如果有40%的drop是否又会给GPU的人带来益处。这些讨论自然的就把meeting引导到了前面主持人说的最后一个话题，就是ProgPow接下去的进程，现在有很大的分歧，但是下一步到底要怎么做。好像还是不少人比较支持之前BBT的提议。BBT也强调了必须也要平衡各方的利益，不能偏袒支持的或者反对的。

17. 接着Ameen说到他觉得人们觉得软件的改动很小是因为没有考虑到那些bug。实际操作起来还是很多工作量的。接着他觉得不值得去冒险硬上ProgPow，导致分链。他还是比较支持BBT的提议。这些又引起了激烈的讨论。接着Tim说我们花费太多时间在讨论上面了，这可能会讨论到很长甚至一年的时间。所以他也比较支持BBT的提议，各方有一些妥协，减少争论的时间，同时先开展实际工作。

18. 又有了一些讨论之后，主持人Hudson提出要有一个流程去定义接下来如何做，是否需要改变EIP？在一番讨论后，他说到除了在这个核心开发者会议上面讨论，线下也要更好的和社区和其它核心开发者们合作讨论，因为不仅很多人已经有想法在讨论了，更要去确保所有的人，都能够听到这些声音，听到不同的想法。等这些都确保了之后，可能是几周或者两个月，我们再来做更多的讨论，并且这些讨论也能更好覆盖之前没有覆盖到的地方。接着主持人觉得今天讨论的很充分。他说虽然还有不同的认识，但是大家一致的就是ProgPow不会很快的实现。接着还有些人表示了对社区有这么强烈的反对的担心。虽然技术上可以实现，但是的确应该考虑社区里面为什么有这么多人反对。

19. 最后BBT的Ben说我们在一个阶段就是双方都试图说服对方，这个耗费了很多时间精力。他认为我们应该跳过这个阶段，虽然不能达成一个共识是比较令人沮丧的。Tim又说最好有一个另外的EIP来描述这个事情，这样就像有个不同的名字，可以开始实际做起来的样子。

20. 最后的最后，主持人说每个人都参与了会议，他就没有必要总结任何东西了，每个人应该都有了自己的结论。

与会开发者：