以太坊核心开发者会议 #88
- 以太行星
- 更新于 2020-06-04 20:13
- 阅读 2644
以太坊核心开发者会议 88
会议： 以太坊核心开发者会议 #88
会议日期: 2020年5月29日，星期五
会议时长： 1.5小时
会议视频链接：
会议日程：
1.柏林EIP – 集成更新
-EIP-2315：用于EVM的简单子程序。
-EIP-2537：BLS12-381曲线操作
2.EFI EIP回顾
-EIP-2046:降低对预编译程序进行静态调用的Gas成本
-EIP-2565:EIP-198 ModExp 预编译的价格调整
3.EIP-2666：预编译和Keccak256功能的价格调整
4.EIP-1559更新
5.EIP：initcode的最大限制
6.柏林时间表
7.EIPIP工作小组/调查
8.测试回顾
9.前次决定的回顾
会议主要内容：
1. 会议开始，主持人Hudson开始第一个议题，柏林硬分叉相关的EIP的集成更新。James介绍他做了一个EIP-2657，里面为进入柏林硬分叉需要集成的EIP做了一个表格，记录集成测试的结果，同时也可以分享给客户端。以后还会做更多客户端的集成测试。Hudson补充说会议进程内容可以参考下述Google表格。James共享了屏幕，展示了EIP-2657。他介绍说他把流程分为标准的EIP处理和网络升级处理。现在EFI的EIP是网络升级处理的第一步。他说他的策略是为可能出现的问题做好准备，不管最后是否真的出现。
现在临时测试网络Yolo已经发布了，各个客户端都可以去同步这个网络，做客户端的测试。现有的两个EIP都没有确定最后进入主网的版本。所以核心开发者也会参考测试结果和测试出现的问题再改进。James强调Yolo的目的是让各个客户端用来测试EIP的集成过程，而不是用于其它测试目的，比如测试代码或者测试生产。
屏幕共享展示了Yolo上总共需要测试三个EIP。第一是EIP-2357，BLS曲线操作。EIP已完成，各个客户端可以开始集成。第二个是EIP-2315，用于EVM的简单子程序，目前正处于合并规范的过程中。第三个是EIP-2565，预编译的价格调整，基于OpenEthereum的一些反馈信息，最后决定不合并进规范。James强调这些状态只存在于Yolo上，和主网没有关系。他展示了一个表格，显示各个客户端的三个阶段：Signal（客户端打算加入其中），Spec（客户端同意当前规范）和Merged（客户端实施规范）。
Martin询问是否可以在上面做状态测试？他认为客户端应该可以在上面做状态测试，并把Yolo作为状态测试的一个分叉。随后有一些讨论，大家普遍都比较支持这个想法。Hudson提醒大家继续更新EIP。对于EIP-2315, Martin表示他创建了一个PR，更改了Gas成本。他得到的反馈都比较积极。等到OpenEthereum给他反馈后，他会合并PR。另一方面，关于Axic提议的限制的部分是否会被并入，还在讨论中。现在Yolo里用的是Greg的无限制版本的子程序。James询问OpenEthereum的意见，OpenEthereum回复说会议结束后讨论一下。这里有一些关于版本的疑问，最后James澄清说现在用在测试网上的是无限制的子程序。后续再讨论Axic提议的限制的版本，包括限制多少和如何限制。Axic说在操作代码方面有一个小改动，不影响功能，Martin表示可以和他的PR一起合并更新。
https://ethereum-magicians.org/t/eip-2315-simple-subroutines-for-the-evm/3941
下一个是EIP-2357。James介绍各个客户端实施的情况。客户端Geth的Peter介绍说，他们有一个PR包含了预编译的代码，但这个PR暂停了。两周前开始合并测试，但是他一个人就发现了不止三个共识相关的问题，还有网络崩溃，Martin和Alex也发现了一些类似的问题。他们计划用汇编代码来作为Go实施的一种替代，但现在发现汇编代码不匹配，同样的输入出现不同的结果。更遗憾的是汇编代码有大约14,000行，而且这个PR在四天前被人更新了，现在里面的代码又全部换掉了。
Alex说两周前他曾发推文介绍说如果汇编有问题，可以降级到原始的Go实施办法的版本，这个和提议的预编译版本还有Gas成本都是兼容的。现在他认为需要Geth来决定到底是否需要汇编代码。Peter说他担忧的不是是否使用汇编，而是着急要分叉的时候不能使用已经知道有问题的汇编代码。Alex认为应该减少曝光任何潜在的攻击或者共识问题。现在应该先去掉所有的汇编语言，释放更多CPU资源，集中力量给一个新的没有汇编的实施办法或者其它形式的实施办法。
Greg表示有几种不同的实现办法的好处是可以做差分模糊测试。真正的死机是很罕见的。他担心在Go实施办法和Rust、还有C语言实施办法之间会有不同，然后这种差异会产生共识问题。因为这个问题很复杂，所以之前没有做过不同的实施办法的交叉混合。所以他预计首先需要几周的工作来做不同客户端的不同实施办法的交叉混合测试，接着重做基准测试来看Go的实施能否和原有的Gas用量计划相符合。不过他认为这个不影响与测试网络的合并，只是大家对此抱有怀疑。Alex说有人在GO实现方法的基础上外接了RUST的库，从而能够不用客户端来对比测试不同实施办法的库文件。他自己也做了测试，没有在汇编上发生问题。他建议就去掉汇编，把更多的时间用在模糊测试上面。Greg表示这也需要几周的时间，随后和Alex做了一些工作量上的讨论，比如模糊测试的策略，白盒还是黑盒等。
James询问到底能否合并到Yolo里面去，能否预测大概的工作量？Peter回答说合并本身不会很慢，但是他们担心会影响到Yolo。Hudson表示Geth团队担忧的是安全性的问题，但是他觉得这个可以和Geth团队以及PR的发起人讨论解决。Alex说发起人不在会议中，会后他会再和他讨论。不过现在可能更好的做法是去掉汇编的部分，起码那些没被测试的引擎，不会影响性能。Hudson和James强调网络的安全性始终是核心开发者最关心的内容之一。
James继续EIP-2357的实施汇报。OpenEthereum表示他们没有问题，在测试中，结果没问题就合并了。Besu表示已经合并了。Nethermind的Thomaz表示这周末会开始合并工作。他考虑两个事情，一是能否只用他们现有的Harami代码。另一个是，是否在这个PR里面引入的新的操作需要转换代码。不过周末应该可以完成合并的工作。James表示第一个议题结束。
https://github.com/ethereum/EIPs/pull/2537
2.Hudson开始第二个议题，EFI的EIP的回顾。这次有两个EIP，一个是EIP-2046，一个是EIP-2565。Husdson表示之前James提到过EIP-2565，因为OpenEthereum的反馈信息，所以决定不会将其并入规范。James确认说这个EIP暂定不进入柏林，或许可以进入Yolo，这个还可以再讨论，主要是Gas成本等方面的问题还需要作进一步讨论。Hudson表示EIP-2046和EIP-2666的第三项有关系，他询问谁可以更新并解释一下？
Alex表示他可以介绍一下EIP-2666。EIP-2046是他激进的EIP-2666的一部分。他认为可以把预编译的调用成本降到0，然后把多余的成本吸收到预编译器里面。这个办法已经包含在已发布的EVM里的Keccak函数和不同预编译器的计价方案调整里。这个EIP首先给大家展示了现状，给定一个客户端，Go或OpenEthereum，现有的效果是如何的。其次展示了复杂的计价方案。跟之前不同，价格只和输入的每32位的字节的哈希计算的单价有关系，现在价格和哈希计算的内部的结构有关。现在哈希计算公式能接受一个数据块作为输入，这样就不一定和之前一样每次都是32位字节长度。输入不同长度的字节或者数据块可能会产生相同的价钱。这就是根据实际哈希计算所需要的时间来定价。所以这两个提议都是想根据实际的哈希计算的时间来调整价格。
Hudson询问EIP-2046是取代了EIP-2666，还是一个新的提议？Alex回复说Axic要求去除直接把价钱降到0的提议（即EIP-2666），所以他希望起码要保留EIP-2046这个价格调整提议。但他也强调，其实逻辑上说这两个EIP有很多联系，如果一个EIP内的预编译调用的价格改变了，那么另一个EIP内的计价方案也会被影响和调整。
Hudson请Axic来更新EIP-2046，并说说EIP-2666上是否也有新的关于EIP-2046方面的讨论。Axic表示在一两个月前的会议上，当时决定EIP-2046提议的价格不是最终数字，还需要基准测试来决定。随后大家的意见是确认将提议的价格作为最终数字，但是BN的预编译的价格上需要加上限制。同时决定分开做其它预编译器的价格调整。Axic建议找一个专门的时间地点来讨论，现在的核心开发者会议并不是一个专门讨论预编译价格调整的好地方。Hudson表示同意，James表示他会来提议会议时间地点，通知想参与讨论的核心开发者，并和Axic确定时间地点。
现在开始讨论EIP-2565。Kelly回顾说之前有两个办法来调整价格，一个是直接改参数然后升级库，另一个办法是稍微复杂的修改计算公式。最终他们确定选择第二种更改公式的办法。他们和OpenEthereum团队合作，计划用另一个库文件，但是因为Windows系统的原因失败了。他们做好了调整计价公式的PR草案，然后他正在处理和更新反映计价公式调整的EIP，最后他会和Gas团队一起完成这个PR。Geth和OpenEthereum同时在推进，OpenEthereum的PR已经准备好，Geth的也快了。
https://ethereum-magicians.org/t/eip-2046-reduced-gas-cost-for-static-calls-made-to-precompiles/3291
https://eips.ethereum.org/EIPS/eip-2565
https://github.com/ethereum/EIPs/pull/2666
3. 下一个是EIP-1559。Abdelhamid Bakhta介绍说，他们首先创建了去掉区块大小和交易大小的附加条款（rider）的PR。因为这个PR不是EIP-1559必需的，因此还在讨论是否要把这个PR和EIP-1559联系起来，以及讨论是否继续在测试网上用附加条款。这些内容他们需要尽快决定。与此同时，他们也在考虑EIP-1559在非工作量证明网络中是否会有价值，在应用之后，对网络会造成哪些冲击。另外，他们也在讨论如何验证这个EIP，是通过仿真一些用户还是在测试网络中让用户去测试。Hudson说关于EIP-1559的实施者会议（implementers call）已经上传到Youtube上去了。James补充说，那个会议很有内涵，希望大家可以去看看。
https://github.com/ethereum/pm/issues/172#issuecomment-635410574
4. 下一个是新的EIP草案, 限制initcode的大小。Martin介绍说这是一个改动很小的建议。他提议给任何的initcode增加最大限制，最大不能超过2倍合约代码的最大限制。合约代码的最大限制来自于之前的EIP-170。这么做的原因有两个，第一是initcode可以被用户用来发动对jumpdest分析的攻击。加上限制可以去掉这个安全隐患。第二潜在的原因是如果以后EVM的简单子程序被加上了限制，那么对于客户端来说jumpdest分析就会变得更加复杂。所以不论以后加不加简单子程序的限制，加上这个最大限制会让客户端不那么容易遭受攻击，所以他觉得改动虽小，但是作用还是大的。
https://github.com/ethereum/EIPs/pull/2677
5. 下一个议题是柏林硬分叉的实施时间。James说现在先把Yolo和BLS的实施做好，然后再来讨论时间。
6. 下一个议题关于EIPIP工作小组和调查。Edson自我介绍说他来自于以太坊协调志愿小组（组名：以太坊铲屎官）。EIPIP工作小组正在组织一个调查来了解大家的意见。EIPIP工作小组是为了提高EIP的处理流程、进行更准确的目标设置和更快速地解决问题。为了达到这个目的，工作小组设置了这个调查，问一些感性的问题，比如遇到过最大的挫折是什么，现有流程里最不喜欢的地方等。也有些问题类似现有流程中最喜欢的地方，而这些问题的回答就会在流程改进中保留下来。最终他们希望这个流程的结构是合理的，聚焦在技术上，进入低门槛，批准高门槛，并且透明，平等。
7. 测试相关方面没有要讨论的，所以跳过。下一个是前次会议做的决定和所需行动的回顾。Hudson回顾了一下，上次会议的决定都执行了，所需的行动除了客观不允许的都执行完毕。
8. Artem提出他还有个疑惑，他想知道现有的EIP流程中有没有一个状态，可以让他明确知道这个EIP是否能被合入测试网络进行测试了。Hudson说应该没有，因为之前从来没有类似Yolo的操作。Martin提议是否可以用临时测试网络的规范注释来标注这个状态？James认为可以考虑，接着他说除了EIPIP工作小组的调查，作为EIPIP工作小组工作的一部分，他也在改进EIP的流程。他再次共享屏幕，展示了一个流程。
他说现在的规范形成放在了留存的末尾，这样就区分出已被包含的EIP和不被包含的EIP两类。紧接着那些定型的EIP（规范定型）就可以在Yolo上面实施。之后，如果EIP再有升级，就执行定型后的升级。Hudson提出疑问，如果在已知很短时间内再次需要升级，是否需要规范定型？James表示这也需要很长时间的讨论，或许可以在下一次的EIPIP会议中提出。
9. Hudson宣布会议结束。
更多参考内容：
http://github.com/etherrum/pm/
欢迎转发，本内容遵循CC BY-SA 2.5协议：
https://creativecommons.org/licenses/by-sa/2.5/
你的支持，是对我们的认可。来打赏我们一杯咖啡吧！ 打赏地址：
以太坊：
0x7Ba18D8d4B0E4EB06a720aF2BeC29603078c806b
Gitcoin:
https://gitcoin.co/grants/468/ethplanet
