登录
手机号码
+86
验证码
获取验证码
会议：以太坊核心开发者会议 #83
会议日期: 2020年3月20日，星期五
会议时长：2小时
会议视频链接：
https://www.youtube.com/watch?v=vDGj660uZE0
会议日程：
- EIP 回顾
EIP-2537
EIP-1962 fuzzing test
EIP-2542
其他（预）EIP提议
- 传输postdata (草案 EIP-2242), EVM无法读取传输中的新字段
- 用预编译对传输postdata处理（支持多线程数据处理）
- 用于Merkle化和Merkle分支验证的新预编译
- Calldata Gas成本降低到每字节1-2 Gas
- 当前传输哈希操作码，将进一步降低Optimistic Rollup网络成本
EIP2046
- 柏林 EIPs
- 讨论可能的叔块规则的变化
- 测试更新
- 回顾之前会议决定的行动事项
- 以太坊开发者调查问卷
会议主要内容：
1.会议开始，照例由Hudson主持。按照会议议程，第一议题是EIP回顾。 James提议先过Berlin的EIP。
2. EIP#2537，这个EIP是单个BLS曲线，取代了之前的EIP#1962，Alex Vlasov介绍说最新状态是规范已经定型，后面计划准备测试。定型的规范还可能需要有一些ABI 升级，但是不会有很重要的改变。他继续介绍哈希曲线分成两个部分。一个field element，可以在EVM里面完成，可以选择不同的哈希函数，所以可以不预先实施在预编译器里面，但可以保留这个功能。另一个是映射field element，这个需要实施在预编译器里面。主持人问以太坊2.0的phase0阶段是否需要这个功能，Alex表示不确认，但觉得应该要有。Vatalik补充说这不是以太坊2.0的phase0阶段必要的，但是如果有会很好，会让以太坊2.0的轻客户端可以运行在以太坊1.0的链上面。
https://github.com/ethereum/EIPs/pull/2537
3. EIP#2515，James的难度炸弹。他还在根据社区意见汇总改进，没有太多更新，之后他会更新Github上面的。
https://ethereum-magicians.org/t/eip-2515-replace-the-difficulty-bomb-with-a-difficulty-freeze/3995
4. EIP#2315，subroutine的。Greg介绍说除了一些小的改动，已经接近代码完成。Martin说他提议了一个很小的改动，不影响大局。最后他们表示在魔术师论坛上有一些讨论，希望大家去EIP下面的讨论区看看。
https://ethereum-magicians.org/t/eip-2315-simple-subroutines-for-the-evm/3941
5. EIP#2456，基于时间的升级。James认为当区块链有叔块的时候，会造成一个时间的问题，就是块的高度和时间戳会不统一，有些情况下叔块会有现在高度但是又会有一个比较晚的时间戳。这可能是因为引入的回看机制造成的。回看机制需要用到之前1000个块。这就会引起一些其它问题产生。Vitalik还提出说，两个块具有相同的时间戳是非法的，而且既然哈希算法的代码里面已调用了之前256个块的信息，建议就不要用到之前1000个块，用256个块的信息就可以了。最后James团队的Jason工程师又建议是否完全不用回看机制，而用纯时间戳的方式并且把叔块时间戳规则规定的更严格。因为时间关系，主持人说不能进行深入讨论了，但是更多的讨论可以在以太坊魔术师论坛上面进行。
https://github.com/shemnon/EIPs/blob/d771a0d82de6975bdd0b395b35fa6675fcb0fade/EIPS/eip-2456.md
6. EIP#1962的模糊测试。Alex Akhunov介绍说这个EIP虽然定下来不集成进柏林，但还是很值得测试一下。现在已经有三个不同的实施办法和一些模糊测试。他觉得这个EIP是一个很复杂事情，需要很多专家的时间和帮助。他想引入一些自动化的测试来减轻负担。这个想法不仅对现在的具体测试有好处，更是为以后做准备，毕竟开发过程中肯定还会有复杂困难的时候。接着他说了具体现在做的。首先是回顾现有的模糊测试的机制。现在是一个黑盒测试，会产生一些随机的比特流作为输入，再观察输出是什么。但是碰到的问题是输入的内容是随机的，所以很容易产生一种情况就是输入的比特流太随机了，导致输入后触发了系统验证输入比特流的有效性去了，而根本没有到测试代码的这个环节。另一个工程师Giulio说现在他们更新了测试输入，产生了虽然还是随机、但是有点意义的比特流，然后会指向随机选择的曲线上面去。这样能确保产生正常的曲线后并正确的指向这个曲线。后面还有一些技术的讨论。最后Alex总结说两点，一个是希望继续进行模糊测试，因为他觉得这个对BLS381是绝对有用的，也能帮助以太坊系统的包容性提高。另一个他觉得有必要告知大家这个方向，这是一个对系统以后有益处的方向，看看大家有什么意见，就相当于流程的优化。
https://eips.ethereum.org/EIPS/eip-1962
7. EIP#2542，是关于代码里面增加TxGasLimit，CallGasLimit和TxGasRefund的三个值。Alex Forshtat说之前在EVM的代码里面这几个限制的参数都太简单了。所以他觉得有必要加上这三个参数。AlexV, Alex AK, WeiTang, Martin等人就这个代码怎么运行探讨了很多关于Gas技术的问题。最后James提出这个与之前的UNGAS的提议不太一样。感觉有些人觉得不应该让EVM层面接触到关于Gas用量的信息，觉得代价太高，可能有安全性的考虑，可能有用户引用后比较容易出错的考虑。但是从本质上讲，不可能完全向EVM隐瞒与Gas有关的一切，毕竟可以通过检查余额然后计算出交易的费用，并计算出交易中使用的Gas。所以如果不可能完全向EVM隐藏Gas信息，那么引入一个东西在Gas限值的上方是一个可能的方法。最后讨论很多，主持人说让Alex留下邮件联系方式，方便会后继续讨论。
https://github.com/ethereum/EIPs/pull/2542
8.正式的EIP讨论好了，下面主持人开始讨论几个预EIP的议题。首先是EIP#2046。这是Alex Beregszaszi最早提议的。他提议在预编译的合约中的静态调用(staticcall)把Gas成本从700降低到40。Alex Vlasov说这个减少会大大提高做哈希算法时候的效率。他已经在开放以太坊上面做了测试，减少的数目是合理的。他认为应该可以变成EFI并且可以在现在预编译器的Gas极限调用函数BLAKE2b上验证。Louis也同意这个观点并且说BLAKE2b函数应该而且必须比Keccak更快、更便宜。但是主持人和Martin有一些讨论，他们并不太同意把这个价钱从700调低。他们认为成本是在预编译中考虑的，这些预编译是经过分析后定价的，其中700个被认为是一个比较好的数字，如果对该值进行了更改，则需要重新进行所有计算，以确保利润损失不会妨碍后期的工作。他们有一些技术上面的争论。Alex觉得成本的下降的确提高了效率。最后主持人建议准备一份赏金，在Gitcoin或者Twitter上面，试着做一些精确的基准测试，再根据结果来定下一步。
https://eips.ethereum.org/EIPS/eip-2046
9.主持人发现剩下的几个预EIP几个都是有联系的，都是John Adler来主导的。所以就让他一起介绍。John说，他首先想把改动的几个地方告诉大家，目的就是看看是否值得做下去，因为后面马上要进行开发测试。如果有很强烈的反对意见的话就不用直接进行下去了。
-第一个是EIP2242草案，是在交易过程中一个新增加的数据，叫postdata，不能够被EVM读出来的问题。
-第二个是用预编译去执行postdata，这会允许多线程的数据处理。
-第三个是增加新的预编译，用于Merklization和Merkle分支验证。
-第四个是减少Calldata的Gas成本。
-第五个是增加现在交易哈希操作的代码。进一步降低Optimistic Rollup网络的成本
随后有人问了两个需要解释的问题。主持人建议说是否准备一个帖子，来解释他们团队这么做的动机和准备如何开发这个工作，包括安全性的考虑，指定的规范是如何的等。另外Alexey也提出了类似的意见，不同的是他强调因为这个牵涉到储存，他希望在开发之前能都调查一下有关系统设备运行的代价。另外一个工程师Louis也表示有兴趣。John最后说收到了很多好的建议，有些提议是他没有想到的，他会后需要再仔细考虑，然后找个地方再和大家继续讨论。
https://github.com/ethereum/EIPs/pull/2242
10. 会议结束。
与会开发者：
欢迎转发，本内容遵循CC BY-SA 2.5协议：
https://creativecommons.org/licenses/by-sa/2.5/
你的支持，是对我们的认可。打赏地址：
以太坊：
0x7Ba18D8d4B0E4EB06a720aF2BeC29603078c806b
Gitcoin:
https://gitcoin.co/grants/468/ethplanet
