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

以太行星
更新于 2020-04-06 10:28
阅读 2306

以太坊核心开发者会议 84

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

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

**会议时长：** 1.5小时

**会议视频链接：**

https://www.youtube.com/watch?v=JqxVvJBhTxo

**会议日程：**

1. EIP 回顾

* EIP-1962 and EIP-2537

* EIP-2515 – 难度炸弹

* EIP-2315 EVM的简单子网络

* EIP-2456 基于时间的升级

3. 柏林时间

4. Penalties for trie misses

5. 测试更新

6. EIPIP 调查问卷

**会议主要内容：**

1\. Hudson主持会议开始。他告知大家James Hancock不能参加这次会议，他已经列好了需要讨论的EIPs，方便大家回顾和讨论。

2\. 首先是EIP#1962和EIP#2537。因为很多人还不了解，Alex Vlasov介    绍这两个EIP和它们的区别。他说EIP#1962是想要实施一个预编译机制。但是里面有很多曲线可以选择，实施的方法太多，太复杂，在之前大家的讨论里面都没有一个定论，然后就决定先做一个简化的版本，即EIP#2537，有三个预编译，对应着三个曲线。同时，简化版本因为比较容易实现，所以还来得及有机会能够被集成到柏林里面去。Alex继续介绍说规范两周前已经确定，但不知道什么原因还没有合进去。实施办法已经通过测试，所以已经到了最后的阶段。Rust上的实现已经全部完成并通过了测试。Go上的实现也完成了，正准备做模糊测试。以太坊2.0上的实施也正在做。这里有一些关于如何在以太坊2.0上面实施的技术讨论，重点集中在如何给智能合约创建一个代理合约上。接着Hudson问这个能否在4月底前完成，给柏林准备好，Alex回答说他还需要了解一下具体进度，主要是了解测试还要多少时间。经过一些讨论后，Tim提议既然大家都认同这个结果（EIP closed），就应该让所有的客户端都去实施这个更改，做测试，看看有没有什么问题会报出来。

https://github.com/ethereum/pm/issues/152

https://medium.com/@ralexstokes/what-eth2-needs-from-eth1-over-the-next-six-months-86b01863746%E2%80%A9

3\. EIP#2515，难度炸弹。James今天不在，所以在其他人没有发言的情况下就跳过了。

4\. EIP#2315，Simple Subroutine for EVM。Martin说他提议了一个更改，在系统结构侧。主要是增加一个return_stack来解决堆栈是如何被填充的，然后他更新了测试的内容和Geth上的实施方法。最后他说这个spec允许“walking into a subroutine”。意思是可以让程序计数器直接作用在subroutine上面而不引起错误。这个曾经在Github和魔术师论坛上引起过一些讨论。Greg继续说到这个是一个小的更改，他觉得没必要禁止walking into subroutine，他们要把这个机制做的影响很小，不做很明显的流量控制。如果有需要可以在软件里面加一个STOP代码就能停止这个机制，一点不困难。最后他总结说在Go上已经实施了，开放以太坊也做了一小部分工作，但是Besu和Nethermind还没有开始，但是应该不会有问题。主持人问还需要再做点什么。得到的回答是这样就可以了。主持人说既然这样，那么这个EIP就能够来得及集成进柏林里面去了。

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

5\. EIP#2456，基于时间的升级。因为James的缺席，不能有太多的讨论。但是Peter指出Fork ID是个问题，这是一个重要的没解决的事项，而且他坚持认为这个没有解决前不能移交给柏林。

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

6\. 主持人说开始下一个柏林时间的议题前，还有没有其它EIP需要提出来的。Alex认为可以讨论一下EIP#2046。这是一个关于Gas成本的问题，他说这个问题前次会议时候已经提起过，然后他又重新做了包含预编译的测量工作。这个EIP的目的是要把调用预编译的成本从700调整到40。之前的700应该是偏贵了。现在问题是需要知道是否预编译支持这个调整。在开放以太坊里面他已经测试过了是支持的，但还是需要检查其它所有的预编译是否支持。接着他说现在需要大家的意见，判断这个改变到底是否安全，是否需要？Alex表态说基于他的测量，他觉得可以调整，因为有些预编译的成本大大超过实际计算的时间。他希望得到大家意见是否全部重新调整还是如何部分调整，但是现在这个从700到40的调整，他觉得应该没问题，应该可以执行。随后就有人表示反对，觉得不应该把这么多改变放到一个EIP里面去。也有人问是在哪里测试的，是一个客户端，还是很多？Alex说他就在开放以太坊里面测试了，但是他认为这个核心的东西对于不同客户端来说不会改变很多。Martin表态说还是需要测试一下，主要他还是担心这个成本调整低了，不能覆盖预编译的计算时间。一些争论后，主持人Hudson说是否需要做一个测试看看这个成本减少的改变是否值得。Alex强调说每个版本的预编译都会受益，因为预编译本身的成本不会受到影响，只是调用预编译的成本下来了。一些讨论后，又发现Blake2函数有疑问。Blake2函数的成本高于Keccak。Martin提出两个需要考虑的地方：他说对于客户端来说，第一个是看看用40Gas成本调用预编译是否可行，有没有影响效率问题，第二个是看看去掉了700这个门限值的情况下，40Gas的成本下预编译的执行时间如何，是否有效率。热烈讨论之后，主持人说结论是EIP#2046暂时不去到柏林，因为还有很多不同可能性。暂时先观察不同的客户端测试下来的情况再做决定。Louis还提出如果40这个数字能够再往下调整的话，对很多最终用户很有帮助。原因是他知道大量工作在运行中，这些工作都想提高Blake2函数的效率。后面又有一些关于代码和Blake2的技术讨论。

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

7\. Hudson说下一个议题柏林时间。他表示希望五月做完，最晚六月。他问询大家的意见。Martin说他觉得应该先定EIP的实施方案，再来计划柏林时间。测试工程师Dimitry说客户端都还什么都没有做。Tim说现在是需要选择一下的时候，是快速开始柏林，但是只有一个2537集成进去；还是把其它EIP都加进去，但是风险可能是柏林会推迟。所以对于EIP应该有一个优先级排序。Hudson表示他准备把这个决定留给James，他对于EIP的情况更了解一下。这时候Alex提出一个问题就是EIP#2537和抵押合约到底有什么联系？两个Alex和Tim有一些技术上的讨论，最后认为还是应该有个书面的文档能解释在以太坊1.0和以太坊2.0中2537的BLS 曲线和抵押合约的关系。Tim贴出了最近的一个文档来说明这个事情的。最后关于柏林时间，总的意见（包括Martin，Alex等人）觉得一个多月不太可能实现这么多功能，还是要排列优先级出来。在一些讨论后，大家觉得从时间的角度出发和从代码已经完成度的角度出发，应该是EIP#2537第一位，然后是EIP#2315，最后两个是EIP#2515和EIP#2046。最后一个最不可行，因为还要看客户端测试的结果，这个就意味着还有不少工作要做，包括测试和来来回回的调试。

https://medium.com/@ralexstokes/what-eth2-needs-from-eth1-over-the-next-six-months-86b01863746

8\. 下一个EIP#2583,Martin说这是引入一个Gas惩罚的提议。Martin解释说现在随着状态树的增加，储存的寻找使用率也增加了。现在的机制是如果客户查找一个不存在的地址，成本会提高。但是他发现这个并没有太好的效果，因为很难判断到底什么情况下才能提高Gas成本，而且这使得系统容易被攻击：攻击者可以强迫一个节点不停的寻找一个不存在的地址来让磁盘上查询操作达到极限。所以他觉得可以修改一下这个机制。他现在想的办法是如果查询一个不存在的地址，则立刻扣除一个惩罚性的Gas。他认为现在在一个1000万Gas 的区块里可以做到13000次查询。但是引入一个大概1000Gas的惩罚，可以让这个查询数量下降41%左右。但如果惩罚太高也没用，会被想办法被绕开。这个机制的好处是不影响很多东西，但是坏处是惩罚可以被部分绕开。他初衷是想引入这个机制，保护系统不要被攻击。他希望听到大家的建议。Peter最后说到，这个机制应该是增加一个惩罚，但如果代码做合理的事情，那几乎不受影响，但是如果做不合理的事情，就会受到很大的影响。这样才能起到作用。

https://github.com/ethereum/EIPs/blob/db1e389aae4e05654703d24862b0db91040bf745/EIPS/eip-draft-trie-penalty.md

9\. 下一个议题是关于测试的。主持人询问Dimitry有什么要更新的。Dimitry说首先他重写了可以产生区块链测试的代码，而且这个代码也不用一定在Aleth上面运行。这个意味着任何客户端都可以产生这个测试了。VM测试可以在Hive上面运行了。还有一些新功能测试的结果和数据，是在一些客户端像Geth，Aleth和Besu上面做的，他把这些内容都更新在了测试网页上了。另外他说Nethermind不太满意这个测试的协议，他已经在开发者协商，觉得可以组织一个测试和开发的会议，商量如何配合可以把测试做的更好。Hudson建议他可以把Gitter上面的测试频道设置成公开的，然后测试人员和开发人员可以在这个上面沟通。

https://gitter.im/ethereum/tests

10\. 最后，Hudson介绍说有一个EIPIP团队的调查问卷，只有六个问题很简单，希望核心开发人员都做一下。Tim说现在在以太坊网页上面也有EIP的信息，可以大概了解现在的EIP状况。

11\. 会议结束。

**与会开发者：**

* Alex Beregszaszi

* Alex Vlasov

* Artem Vorotnikov

* Daniel Ellison

* David Mechler

* Dimitry

* Edson Ayllon

* Greg Colvin

* Guillaume

* Hudson Jameson

* Ian Norden

* Jason Carver

* JosephC

* Karim Taam

* Louis Guthmann

* Mariano Conti

* Pawel Bylica

* Peter Szilagyi

* Pooja Ranjan

* Rai

* Tim Beiko

* Tomasz Stanczak

* Trenton Van Epps

* Wei Tang

**更多参考内容：**

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

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

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

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

会议时长： 1.5小时

会议视频链接：

https://www.youtube.com/watch?v=JqxVvJBhTxo

会议日程：

EIP 回顾

EIP-1962 and EIP-2537
EIP-2515 – 难度炸弹
EIP-2315 EVM的简单子网络
EIP-2456 基于时间的升级

柏林时间
Penalties for trie misses
测试更新
EIPIP 调查问卷

会议主要内容：

1. Hudson主持会议开始。他告知大家James Hancock不能参加这次会议，他已经列好了需要讨论的EIPs，方便大家回顾和讨论。

2. 首先是EIP#1962和EIP#2537。因为很多人还不了解，Alex Vlasov介绍这两个EIP和它们的区别。他说EIP#1962是想要实施一个预编译机制。但是里面有很多曲线可以选择，实施的方法太多，太复杂，在之前大家的讨论里面都没有一个定论，然后就决定先做一个简化的版本，即EIP#2537，有三个预编译，对应着三个曲线。同时，简化版本因为比较容易实现，所以还来得及有机会能够被集成到柏林里面去。Alex继续介绍说规范两周前已经确定，但不知道什么原因还没有合进去。实施办法已经通过测试，所以已经到了最后的阶段。Rust上的实现已经全部完成并通过了测试。Go上的实现也完成了，正准备做模糊测试。以太坊2.0上的实施也正在做。这里有一些关于如何在以太坊2.0上面实施的技术讨论，重点集中在如何给智能合约创建一个代理合约上。接着Hudson问这个能否在4月底前完成，给柏林准备好，Alex回答说他还需要了解一下具体进度，主要是了解测试还要多少时间。经过一些讨论后，Tim提议既然大家都认同这个结果（EIP closed），就应该让所有的客户端都去实施这个更改，做测试，看看有没有什么问题会报出来。

https://github.com/ethereum/pm/issues/152

https://medium.com/@ralexstokes/what-eth2-needs-from-eth1-over-the-next-six-months-86b01863746%E2%80%A9

3. EIP#2515，难度炸弹。James今天不在，所以在其他人没有发言的情况下就跳过了。

4. EIP#2315，Simple Subroutine for EVM。Martin说他提议了一个更改，在系统结构侧。主要是增加一个return_stack来解决堆栈是如何被填充的，然后他更新了测试的内容和Geth上的实施方法。最后他说这个spec允许“walking into a subroutine”。意思是可以让程序计数器直接作用在subroutine上面而不引起错误。这个曾经在Github和魔术师论坛上引起过一些讨论。Greg继续说到这个是一个小的更改，他觉得没必要禁止walking into subroutine，他们要把这个机制做的影响很小，不做很明显的流量控制。如果有需要可以在软件里面加一个STOP代码就能停止这个机制，一点不困难。最后他总结说在Go上已经实施了，开放以太坊也做了一小部分工作，但是Besu和Nethermind还没有开始，但是应该不会有问题。主持人问还需要再做点什么。得到的回答是这样就可以了。主持人说既然这样，那么这个EIP就能够来得及集成进柏林里面去了。

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

5. EIP#2456，基于时间的升级。因为James的缺席，不能有太多的讨论。但是Peter指出Fork ID是个问题，这是一个重要的没解决的事项，而且他坚持认为这个没有解决前不能移交给柏林。

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

6. 主持人说开始下一个柏林时间的议题前，还有没有其它EIP需要提出来的。Alex认为可以讨论一下EIP#2046。这是一个关于Gas成本的问题，他说这个问题前次会议时候已经提起过，然后他又重新做了包含预编译的测量工作。这个EIP的目的是要把调用预编译的成本从700调整到40。之前的700应该是偏贵了。现在问题是需要知道是否预编译支持这个调整。在开放以太坊里面他已经测试过了是支持的，但还是需要检查其它所有的预编译是否支持。接着他说现在需要大家的意见，判断这个改变到底是否安全，是否需要？Alex表态说基于他的测量，他觉得可以调整，因为有些预编译的成本大大超过实际计算的时间。他希望得到大家意见是否全部重新调整还是如何部分调整，但是现在这个从700到40的调整，他觉得应该没问题，应该可以执行。随后就有人表示反对，觉得不应该把这么多改变放到一个EIP里面去。也有人问是在哪里测试的，是一个客户端，还是很多？Alex说他就在开放以太坊里面测试了，但是他认为这个核心的东西对于不同客户端来说不会改变很多。Martin表态说还是需要测试一下，主要他还是担心这个成本调整低了，不能覆盖预编译的计算时间。一些争论后，主持人Hudson说是否需要做一个测试看看这个成本减少的改变是否值得。Alex强调说每个版本的预编译都会受益，因为预编译本身的成本不会受到影响，只是调用预编译的成本下来了。一些讨论后，又发现Blake2函数有疑问。Blake2函数的成本高于Keccak。Martin提出两个需要考虑的地方：他说对于客户端来说，第一个是看看用40Gas成本调用预编译是否可行，有没有影响效率问题，第二个是看看去掉了700这个门限值的情况下，40Gas的成本下预编译的执行时间如何，是否有效率。热烈讨论之后，主持人说结论是EIP#2046暂时不去到柏林，因为还有很多不同可能性。暂时先观察不同的客户端测试下来的情况再做决定。Louis还提出如果40这个数字能够再往下调整的话，对很多最终用户很有帮助。原因是他知道大量工作在运行中，这些工作都想提高Blake2函数的效率。后面又有一些关于代码和Blake2的技术讨论。

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

7. Hudson说下一个议题柏林时间。他表示希望五月做完，最晚六月。他问询大家的意见。Martin说他觉得应该先定EIP的实施方案，再来计划柏林时间。测试工程师Dimitry说客户端都还什么都没有做。Tim说现在是需要选择一下的时候，是快速开始柏林，但是只有一个2537集成进去；还是把其它EIP都加进去，但是风险可能是柏林会推迟。所以对于EIP应该有一个优先级排序。Hudson表示他准备把这个决定留给James，他对于EIP的情况更了解一下。这时候Alex提出一个问题就是EIP#2537和抵押合约到底有什么联系？两个Alex和Tim有一些技术上的讨论，最后认为还是应该有个书面的文档能解释在以太坊1.0和以太坊2.0中2537的BLS 曲线和抵押合约的关系。Tim贴出了最近的一个文档来说明这个事情的。最后关于柏林时间，总的意见（包括Martin，Alex等人）觉得一个多月不太可能实现这么多功能，还是要排列优先级出来。在一些讨论后，大家觉得从时间的角度出发和从代码已经完成度的角度出发，应该是EIP#2537第一位，然后是EIP#2315，最后两个是EIP#2515和EIP#2046。最后一个最不可行，因为还要看客户端测试的结果，这个就意味着还有不少工作要做，包括测试和来来回回的调试。

https://medium.com/@ralexstokes/what-eth2-needs-from-eth1-over-the-next-six-months-86b01863746

8. 下一个EIP#2583,Martin说这是引入一个Gas惩罚的提议。Martin解释说现在随着状态树的增加，储存的寻找使用率也增加了。现在的机制是如果客户查找一个不存在的地址，成本会提高。但是他发现这个并没有太好的效果，因为很难判断到底什么情况下才能提高Gas成本，而且这使得系统容易被攻击：攻击者可以强迫一个节点不停的寻找一个不存在的地址来让磁盘上查询操作达到极限。所以他觉得可以修改一下这个机制。他现在想的办法是如果查询一个不存在的地址，则立刻扣除一个惩罚性的Gas。他认为现在在一个1000万Gas 的区块里可以做到13000次查询。但是引入一个大概1000Gas的惩罚，可以让这个查询数量下降41%左右。但如果惩罚太高也没用，会被想办法被绕开。这个机制的好处是不影响很多东西，但是坏处是惩罚可以被部分绕开。他初衷是想引入这个机制，保护系统不要被攻击。他希望听到大家的建议。Peter最后说到，这个机制应该是增加一个惩罚，但如果代码做合理的事情，那几乎不受影响，但是如果做不合理的事情，就会受到很大的影响。这样才能起到作用。

https://github.com/ethereum/EIPs/blob/db1e389aae4e05654703d24862b0db91040bf745/EIPS/eip-draft-trie-penalty.md

9. 下一个议题是关于测试的。主持人询问Dimitry有什么要更新的。Dimitry说首先他重写了可以产生区块链测试的代码，而且这个代码也不用一定在Aleth上面运行。这个意味着任何客户端都可以产生这个测试了。VM测试可以在Hive上面运行了。还有一些新功能测试的结果和数据，是在一些客户端像Geth，Aleth和Besu上面做的，他把这些内容都更新在了测试网页上了。另外他说Nethermind不太满意这个测试的协议，他已经在开发者协商，觉得可以组织一个测试和开发的会议，商量如何配合可以把测试做的更好。Hudson建议他可以把Gitter上面的测试频道设置成公开的，然后测试人员和开发人员可以在这个上面沟通。

https://gitter.im/ethereum/tests

10. 最后，Hudson介绍说有一个EIPIP团队的调查问卷，只有六个问题很简单，希望核心开发人员都做一下。Tim说现在在以太坊网页上面也有EIP的信息，可以大概了解现在的EIP状况。

11. 会议结束。

与会开发者：