以太坊核心开发者会议 #83

以太行星
更新于 2020-03-23 22:26
阅读 2517

以太坊核心开发者会议 83

**会议：** 以太坊核心开发者会议 #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网络成本

EIP-2046

* 柏林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.  会议结束。

** **

**与会开发者：**

Abdelhamid Bakhta

Alexey

Alex Bereg. (axic)

Alex Forshtat

Alex Vlasov

Daniel Ellison

Giulio

Greg Colvin

Gullaume

Hudson Jameson

Ian Norde

James Hancock

Jason Carver

John Adler

Karim Tam

Karalabe

Louis

Mariano Conti

Martin Holst Swende

Pawel Bylica

Pooja Ranjan

Ratan

Tim Beiko

Trenton Van Epps

Wei Tang

** **

**更多参考内容：**

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

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

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

以太坊：

0x7Ba18D8d4B0E4EB06a720aF2BeC29603078c806b

Gitcoin:

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

![](https://img.learnblockchain.cn/pics/20200602162317.png!/scale/20)

会议： 以太坊核心开发者会议 #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网络成本

EIP-2046

柏林EIPs
讨论可能的叔块规则的变化
测试更新
回顾之前会议决定的行动事项
以太坊开发者调查问卷

会议主要内容：

会议开始，照例由Hudson主持。按照会议议程，第一议题是EIP回顾。James提议先过Berlin的EIP。
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

EIP#2515，James的难度炸弹。他还在根据社区意见汇总改进，没有太多更新，之后他会更新Github上面的。

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

EIP#2315，subroutine的。Greg介绍说除了一些小的改动，已经接近代码完成。Martin说他提议了一个很小的改动，不影响大局。最后他们表示在魔术师论坛上有一些讨论，希望大家去EIP下面的讨论区看看。

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

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

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

正式的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