Ethereum Core Devs Meeting #85以太坊核心开发者会议纪要

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

会议日期: 2020年4月17日，星期五

会议时长：1.5小时

会议视频链接：

https://youtu.be/KlzwFLOj6Bw

会议日程：

1. 柏林EIPs

    - EIP-2315: 用于EVM的简单子程序

    - EIP-2537: BLS12-381曲线操作

2. EIP回顾

    - EIP-2515: 难度炸弹

    - EIP-2456: 基于时间戳而不是区块数进行升级

    - EIP-2046: 降低对预编译程序进行静态调用的Gas成本

3. 柏林时间表

4. EIP-2565: EIP#198 ModExp 预编译的价格调整

5. EIP-2602: 禁止在EC recover预编译合约上使用值为空的哈希消息验证

6. EIP-2583: 对访问账户树内不存在的账户实施惩罚

7. Quilt 团队账户抽象工作的告知

8. 测试回顾

9. EIPIP调查

 

会议主要内容：

1. 会议开始。主持人Hudson开始第一个议题，柏林的EIPs。James接过话筒说现在确定的已经在客户端实施升级并会加入柏林分叉的两个EIP是EIP#2315和EIP#2357。还不确定是否加入柏林分叉的是EIP#2515和EIP#2456。首先讨论EIP#2315。Martin介绍EIP到最后阶段没有太多内容上面的更新，但是他要求增加一个基于Geth实现的测试案例。他还询问开放以太坊的Parity客户端要做哪些实施方面的工作。Artem回答说已经开始测试了。接着Besu客户端的Tim说已经开始在实施了，PR已经弄好，大概下次会议前能够完成。同时Nethermind的Tomasz也说虽然还没有开始实施，但是不应该有问题。James解释说之前的重点是关注EIP本身的内容更新，现在到了实施阶段他会更关注于客户端实施的更新。

https://ethereum-magicians.org/t/eip-2315-simple-subroutines-for-the-evm/3941

2. EIP#2357。Alex介绍说这个已经完成而且根据最新的规范更改了。更改的内容是参考意见后把一个预编译器改成两个了，这样会更清晰。也根据IETF的草案变化更新过了。他解释说IETF草案更新过了，变的更简单实用，但是因为更新的草案会改变函数的输出，所以之前的代码也需要配合更新。Martin询问这个和现有的以太坊2.0有无联系。Alex回答说他觉得不应该有联系，他的理由是以太坊2.0是基于更早期和过时的规范。所以，对他们来说，即使是规范的早期版本也会破坏更改。Martin又认为是否应该把这个EIP分成两个，因为他觉得Danny提出了一个办法，但是Axic好像又反对这个方法。他觉得现在是否可以讨论到底哪一个办法比较好。Alex补充说Axic的建议是把现有的9个不同的预编译器集成为一个再加一个二进制的接口，而Danny会认为之前有8个，很难决定哪一个要拿出来。他觉得这个选择就是到底要分开的功能还是集成的功能加一个超级复杂的二进制接口。Axic接着说他还是坚持想要集成为一个预编译，因为这是从一个开发者的经验角度来看待的。他觉得最初的四个预编译是SHA256，很容易恢复身份，而且所有语言都支持真正的语言结构。而且他们已经在deposit proxy中看到了一个引入复杂性的例子，结果并不太好。他认为需要让扩展系统使用一个很好理解的ABI编码，接着Martin, James, Alex和Axic对于ABI编码又有了一些技术讨论。最后大家同意把ABI编码分成两个而不是一个，因为会更加清晰。James又询问这些代码实现需要的工作量和大概时间节点是如何的。Alex回答说为了这个预编译器，他们现在有两个完整的办法实现。一个是之前EIP#1962遗留下来的，他已经完成。另一个是Go的代码实现。现在开始了单独的模糊测试，后面还要交叉测试和集成。James又依次询问了几个客户端Besu，Geth，Nethermind和开发以太坊，他们均表示实施起来应该不会有大问题。

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

3. 下一个议题是EFI的EIP回顾。首先是EIP#2515，难度炸弹。James介绍说距离上一次他谈论这个已经比较久了，他会先介绍一个最新的大概情况（他也给出了一个链接）。他说这个EIP做的其实和难度炸弹非常相似，只不过它会从一个特定的区块开始。他举例说如果你现在在一个编号为X的区块上，你就在这个点上，冻结难度，然后永久的在之后的每个区块上连续增加0.001%的难度。这样的结果就是区块时间增加，难度增加。我们只知道它什么时候会发生。更新后的设计是线性增长，而不是冻结，这会是一个更好的设计。James更新了EIP，但是他需要和大家确认的是1）这个是否是大家想要的2）如果是，那够不够时间集成到柏林里面去。3）难度增加的功能是纯线性的，还是说类似0.001%的就足够了？James继续说他做了很多问卷调查和调研，现在希望听到大家的意见。Tomasz立刻表示了不同意见，他认为线性增长有点危险，因为它与实际的哈希曲线脱节，而且有可能暴露在矿工面前，这实际上与难度炸弹的想法背道而驰。他又介绍了他的想法：改变目标区块时间而不是改变难度。因为难度计算参数之一是告诉我们创建区块的频率。他建议增加这个参数，然后整个系统应该会表现正常。因此，根据哈希率、哈希曲线自动调整区块时间，但同时又能达到难度炸弹的目的，因此块会越来越长，并且仍然与每个区块呈理想的线性增长。接着James和Tomasz还有Martin又进行了深入的讨论，他们认为应该做一个图表来更好的验证如何增加难度系数。James说会议离线后他会制作图表并在这个基础上再和大家讨论。

https://ethereum-magicians.org/t/eip-2515-replace-the-difficulty-bomb-with-a-difficulty-freeze/3995

4. 下一个是EIP#2456，基于时间戳而不是区块数进行升级。主持人说之前是Danny接手在处理，但是现在他不确认谁在处理。James回应说他的理解是最好是能够做到基于时间的分叉。但会面对的问题是如果使用现有的叔块规则，那为了安全就要有一个回看机制。但是不管是客户端的开发者用户经验还是合约开发者的用户经验都不赞同这个功能。如果要修复，可以修复现在的叔块规则，争取更多的时间为了安全性的考虑，那样就不需要用到回看机制。但这又是很复杂的修改，需要有人愿意认领这个EIP并带头做下去，并且需要得到社区的人的支持。这个看起来很困难，但这就是当前的EIP的现状。接着Hudson表示如果暂时没有人带领去做那只能放在过期的EFI里面。

https://ethereum-magicians.org/t/eip-2456-time-based-upgrade-transitions/3902/11

5. 下一个是EIP#2046：降低对预编译程序进行静态调用的Gas成本。主持人说之前已经讨论了如何在开放以太坊中进行测量，发现降低这些成本是安全的。但是需要在不同的客户端继续验证。后面还有一些关于是否可以降低其它预编译的成本或提高成本的讨论。但是他不确认是否能得出一个确定的结论认为Blake2的成本高于Keccak。他询问这个是否是Axic负责的，有没有更新。Axic回复说Alex V已经做了很多基准测试，都还没有将这些结果纳入EIP。但他发现预编译端有两个价格有点低，所以需要向上调整。Martin和Tim都表示自己的客户端都在做测试，还没有最后的结论。接着Alex V说他开始写一个更激进的建议，他认为应该通过更多的方法来重新编译所有的预编译，否则对不同客户机之间的性能差异会有更严格的限制。同时他也提议，把实际使用调用数据和预编译的成本变为零，并始终将进行Gas估计的成本计入预编译成本本身。这样贡献会固定的增加，并且将为预编译的实际工作付出合理的代价。同时，这也将使Blake功能可行，因为这将改变Keccak预编译以便更好地反映它的内部结构。它实际上在0到128字节之间没有任何区别。最后他说他还没有完成这个构想的规范。Hudson表示很这样的想法很棒，对所有的预编译做一个大范围的扫描，看看如何调整，使它在客户端上处理得更有效。他继续表示希望客户端继续做更多得测试和测量。

6. Hudson和James开始讨论柏林的分叉时间。James表示他需要具体知道BLS曲线在客户端实施到底需要多少时间，因为他觉得这个是最重要也是工作量最大的一个需要集成的EIP。他个人觉得这个预估为4周，再加4周的时间做测试。随后客户端的工程师表示时间上的预估不是很准确。因为BLS有9个预编译但是Alex现在只是在Go和Rust上面测试过。还有不少工作要做。随后他们同意先把前面讨论的两个EIP的优先级提高，并现在就开始在客户端上面实施，这样等到下次会议时候就能够给出一个准确的预估的时间。James表示同意并表示关于另外一个升级的EIP，他会把它从需要集成进柏林的EIP列表里面移除但是仍然放在EFI里面并标注需要有人认领。

https://ethereum-magicians.org/t/eip-2046-reduced-gas-cost-for-static-calls-made-to-precompiles/3291

7. EIP#2565: EIP#198 ModExp 预编译的价格调整。主持人要求Kelly来介绍一下。Kelly说Vitalik在几年前为边际指数运算引入了EIP 198，它是各种密码操作的基础运算。Vitalik一开始是为RSA签名验证而引入的，之后他们一直在使用它进行VDF验证和各种其它加密操作。但他们发现这个定价明显比其它的要贵。通过屏幕共享，Kelly指出这个EIP的定价是每秒100个百万Gas，而最近用的Blake 2 EC Recover是每秒20-30个百万Gas。所以EIP#2565的核心就是把EIP#198中的定价共识的一个参数改到20到100之间，这样会让屏幕共享图表里面的无序的蓝色曲线靠近黄色的定价曲线。这样每次操作的成本会降低10倍左右。Kelly继续表示他们也探索了其它办法可以提高预编译的效率和更加精确的定价算法，但是并不推荐因为这个修改的成本很高。Martin追问这个比较测试是基于什么客户端平台的。Kelly回答说暂时是Geth上面。这个问题引发了在不同客户端上会有不同测试结果的讨论，原因是用到的底层的库不同，Geth用的是Google提供的Go库，而Parity用的是标准的Rust库。Peter建议还可以考虑Open SSL，好处是非常快，但坏处就是需要很多C代码，而且也损失了易移植性。后续还有一些关于不同客户端不同实施办法导致调整参数但性能提高不一样的讨论。但是Kelly强调说他们追求的，并不是想把这个价格降低到像EC recover或Blake 2预编译那样的水平。他们追求的只是通过简单的参数改变来实现这个目标就足够了。Hudson询问Kelly最终的目标是想到得到什么。Kelly回应说边际指数用于编写密码操作，验证RSA签名，验证VDF证明，RC累加器作为Merkle根的替代等等，基本上大量的密码操作将受益于这种重新定价。

https://eips.ethereum.org/EIPS/eip-2565

8. EIP#2602: 禁止在EC recover预编译合约上使用值为空的哈希消息验证。EIP拥有者Wei介绍说这是非常简单的EIP。EC Recover预编译的目的是为了曲线进行签名验证。上周他意识到这个预编译是低级别的，它允许用户直接传递任何他们想要的哈希消息。但有一种情况是如果用户传递了新的空哈希消息（000000），那么签名是可以伪造的，所以在这种情况下使用简单的哈希消息是不安全的。他认为如果使用正常使用EC recover和哈希函数，那么整个过程是安全的，因为正常使用的哈希函数而获得新哈希消息的机会几乎为零。但是如果合约做了一些奇怪的事情碰巧产生一个新的空哈希消息，那么它就变得不安全了。EIP就是建议禁用新哈希消息的验证。Alex贴出一个链接是关于Vitalik在之前的以太坊研究中碰到的一个用例。他认为如果禁用哈希消息那么它可能会变成一个公用的钱包。EIP应该作为安全漏洞发布，合约开发者要么升级，要么提出一个特有的要求。没有零哈希消息去验证签名可能会影响正常工作的某些实际想使用这个的合约。Wei表示他会参考这个链接上的案例。

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

9. EIP#2583 对访问账户树内不存在的账户实施惩罚。Martin说这个最初的想法已经有一些扩展方案了。他在思考这个是否应该做下去并且询问大家有没有什么看法。Tomasz说他觉得这个问题对无状态以太坊也有用处。Martin表示已经和对方沟通过了。但他也说这对于主网是一个急迫的需要，但是对于无状态以太坊是个研究，所以没有这么急迫。Wei和开放以太坊表示实施起来他们不会有问题。

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

10. Quilt团队的账户抽象工作的公告。主持人请Quilt团队的Will给大家一个简洁的介绍。Will介绍说这个主意最早是Vitalik在魔术师论坛提出来的。现在已经在实施账户抽象的最小化工作。他们准备了文档解释这个实施办法和一些这么做的好处。现在他希望大家了解这个事情，并且以后会走完正常的EIP的流程。之前他们小组花费了大量精力在以太坊2.0的第二阶段的执行环境里，现在他们会主要集中在以太坊1.0到2.0的长期合并迭代中。他们小组有四个人，任何人有问题都可以找四个人中的一个。James表示现在在以太坊1.0上的账户抽象的工作是给以太坊2.0做准备。Will回应说的确是这样，在他们的文档里面已经写清楚需要做什么，并且等完成后会转移到以太坊2.0上面去。

https://ethereum-magicians.org/t/implementing-account-abstraction-as-part-of-eth1-x/4020

11. 测试相关的更新。Dimitry介绍说他们和Go团队合作在做一些测试。Go团队觉得状态转移的工具很好用也很容易在客户端开发中实施。他们会继续工作并收集反馈，最终会推广到每个客户端上面。

12. 最后主持人呼吁大家做EIP的调研。会议结束。

 

与会开发者：

•     Alex Vlasov

•     Alex Beregszaszi (axic)

•     Ansgar Dietrichs

•     Artem Vorotnikov

•     Daniel Ellison

•     Daniel Weaver

•     David Mechler

•     Dimitry

•     Greg Colvin

•     Karim Taam

•     Kelly (Supranational)

•     Hudson Jameson

•     Mariano Conti

•     Martin Holst Swende

•     Pawel Bylica

•     Péter Szilágyi

•     Pooja Ranjan

•     Rai Ratan Sur

•     Robert Drost

•     Sean

•     Tim Beiko

•     Tomasz Stanczak

•     Wei Tang

•     Will Villanueva

 

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

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

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

以太坊：

0x7Ba18D8d4B0E4EB06a720aF2BeC29603078c806b

Gitcoin:  

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