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

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

会议日期: 2020年5月15日，星期五

会议时长：1.5小时

会议视频链接：

https://youtu.be/bGgzALuyY3w

会议日程：

1.柏林EIP回顾 – 整合更新

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

• EIP-2537：BLS12-381 曲线操作

2.EFI EIP 回顾

• EIP-2515：难度炸弹

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

3.柏林时间表

4.EIP-2565：EIP-198 ModExp 预编译的价格调整 – OpenEthereum基准测试结果

5.EIP-2481：给ETH协议请求和反馈对象增加请求ID

6.EVM384：在EVM上的另一种预编译方式来支持BLS12-381

7.测试更新

8.基于前次决定的回顾

会议主要内容**：**

1.会议开始，主持人Hudson先开始第一个议题，以太坊柏林升级将包含的EIP提案的回顾。他展示了一个excel表格，列出前一次会议几个可能纳入柏林升级的EIP。James介绍说首先他决定撤回EIP-2515难度炸弹提案，因为他要确保为了以太坊2.0，柏林升级能够顺利的推出。

同时，他指出虽然自己不太清楚EIP-2046的状态，但他知道还没有结束，所以他认为没必要继续等待这个EIP完成。他建议柏林升级完成后，如果这个EIP也完成了，可以再加进去。

接着James说到了另外两个确认加入柏林升级的EIP，他想得到更新的客户端的结果。首先是EIP-2315，用于EVM的简单子程序。客户端Geth首先汇报，Peter说规范还未完全确定。Martin马上补充指出，是在PR的最后阶段且实施方法也经过了测试，虽然他和Greg最近对此做了一点改动，但不会有大的影响。客户端OpenEthereum说他们一个月之前已经在主分支合入这个补丁，但是如果最近有改动，那应该没有加进去。Martin要求OpenEthereum再看看最后的测试项，他想确保OpenEthereum通过了这些测试用例。客户端Besu的Tim说他们也做好了PR，但是没有完成的最主要原因就是规范还未最终完成。Greg回复说计划下周一和周二就会完成规范。客户端Nethermind这次会议没人出席，所以没有更新。

然后James开始询问另一个EIP-2537：BLS12-381曲线操作在各个客户端的情况。Geth客户端的Peter说已经整合了，但是因为有一万六千多行代码，所以还需要一点时间。OpenEthereum的Artem说他们有很大的改变。他们有两个PR做这个事情，用了不同的实施办法。一个是Alex的Matlab的办法，另一个用了Lighthouse开发的库。他们会同时测试两个并准备好。Besu客户端的Tim说他们也是PR好了，需要等待最后预编译的地址，一旦获得很快可以合并代码。

James再次重申，EIP-2315和EIP-2537会纳入柏林升级中，EIP-2046推迟和EIP-2515撤回。OpenEthereum表示他们已经整合EIP-2046。Tim询问关于EIP-2046客户端到底要不要整合，以后怎么做一直还不清楚。Alex也发表了自己的建议。他说3-4个会议之前就表示BN预编译应该是EIP-2046的一部分，因为这个是必须的，Gas成本是被低估的。而其它几个预编译的价格调整，应该被分离出来，因为不是必须的，只是价格调整对用户有好处，不是安全原因。但是之后并没有太多进展。James表示可能现在没有人愿意来做这方面的工作。Martin又表示他认为7月份之前Geth可能没办法准备好BLS12-381的曲线操作。他又询问Peter怎么考虑。Peter说这的确是个很大的PR，他也不能估算出完全实施好所需要的日期。Hudson说如果找来熟悉Go语言的加密学的专家，再帮助做一些检查和实施，会不会有帮助？比如说以太坊2.0的人？Peter和Martin表示可以同意。Hudson接着说他会议后可以再详细了解，确保他能找到合适的人来帮助。

接着Alex，Peter等有一些技术上的讨论，主要是实施代码后的模糊测试，是否需要测试网和配置等。最后他们考虑新建一个测试网来专门测试BLS曲线操作，还考虑要加一个赏金给那些能够提出安全隐患的人。但是Peter考虑下又觉得新建一个测试网络，但是只有BLS曲线操作的测试内容不完善，要不就把所有的EIP都加入，那样就变成柏林的测试网了。Tim也表示同意这个方案，建议把EIP-2537也加进去。另外也可以让以太坊2.0的开发者帮忙设置抵押合约和相应的代理合约，还有一些手动测试。他认为不需要很高的网络交互的数量，只要功能测试就足够。

Alex又贴出一个他的Github小仓库的链接，里面有模糊测试的代码，也可以同时运行RUST。他放了一些代码在里面。这些代码是没有被合并到Geth上面去的。他认为他可以在这个上面测试，和现在已经合并PR的Besu以及OpenEthereum对比。他觉得这样是比较有效率的方式。

最后主持人总结说如果要做一个新的测试网，那就需要覆盖所有需要进入柏林的EIP，而且需要投入资源，不只是做模糊测试，也可以让用户在上面做其它的事情。所以现在需要确定一个日期，什么时候实现新的测试网。同时在此之前，他和James会协调，看看有哪位专家可以在密码学方面帮助Geth团队。

这时候Alex又提出一个问题关于代理合约的。他认为之前的代码是审计过的，也能够验证用户的密钥。如果又新增一个代理合约而又不验证那些密钥请求，就会有安全性的考虑。James和Hudson也表示他们知道在以太坊2.0上面有不少伪密钥在使用。这里又有一些关于安全性的讨论，这方面也需要以太坊2.0开发者的协助。

接着主持人Hudson说不管怎样，这是一个好机会可以和以太坊1.0和2.0的开发者们开展一些合作，同时他建议还是先把这个包括所有柏林EIP的测试网络先搭建起来，然后让其他人 (包括以太坊2.0的开发者) 先用起来。Tim强调要解决这两个EIP，还有没有处理的事情，需要尽快完成解决办法。Alex最后也指出关于BLS曲线，还要注意IETF的版本的更新。AlexV 快速回答说现在是版本7，一周多前更新的，现在的代码已经是更新过的了。

https://docs.google.com/spreadsheets/d/1BomvS0hjc88eTfx1b8Ufa6KYS3vMEb2c8TQ5HJWx2lc/edit?ts=5ebe9851&pli=1#gid=0

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

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

2.开始了下一个议题，柏林升级的时间表。Hudson表示EFI EIP先跳过，因为确定不纳入到柏林升级中。关于柏林时间表，今天出现很多新的信息，所以又不能给出确定的日期。James说先看新的测试网的完成日期，他希望是在六月的第一周能够有初步规模，然后后面才能开展合作的事情。

3.Hudson说下一个议题是EIP-2565：EIP-198 ModExp 预编译的价格调整。Kelly说他给大家做一个简单的更新。他说这个EIP是一个月之前开始的，当时他们在Geth上面做了基准测试，发现预编译的价格过于高估了，大约是十倍之多。于是他们采取了简单调整参数（GQUADDIVISOR）的办法，把这个值从20调整到200左右。

接着Kelly展示了一个表格，来说明在Parity和Geth上基准测试的数据。Parity的EC Recover的运行速度比较慢，大约是Geth的2-5倍，这样通过这个简单调整参数的办法不能调整Parity上的价格。接着他们分析发现Rust GMP在预编译里面对时间的影响很大。Kelly继续说在这个基础上，就有两个方向的解决方案。第一是简单的参数调节+Parity里面库（Rust GMP）的调整。他们测算的结果是20-25百万的Gas每秒，和标准的预编译的价格差不多了。

这个方向的隐患是他们知道在Rust GMP可能在Windows操作系统的Visual Studio里面不能编译。但他不知道这个隐患有多大。第二个方向是更加复杂的计价公式的改变+微小的Parity库的改变。Kelly就询问大家有什么想法，到底应该朝那个方向走？Artem表示他下周正准备测试Windows下面Visual Studio的工具链和GNU的工具链，然后他会告诉Kelly结果，他认为下次会议才能确定。但Peter表示希望下周就能决定到底哪个方向，两周时间有点长。

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

4.下一个议题是EIP-2481：ETH协议请求和反馈对象增加请求ID。Christoph介绍说这个EIP是改变以太坊网络侧协议，从以太坊协议65改到66。增加一个请求ID给所有请求回复。目标是为了改善网络侧的效率，不用检查所有的进来的请求，如果有数据回来，可以有效的找到是哪一个请求要求的数据。他继续介绍说这个实施方法也是尽量的简洁，比如说这个ID不一定是按照顺序的，所以各个客户端软件可以自由的实施，几个不同的请求类型可以共享一个ID。又不如说这个ID可以被复制的，也可以放一个常量，比如0，这样就等于关闭了这个ID功能，没有ID，结果就是整个协议机制和之前相同（对那些不喜欢这个机制的人来说）。

Artem表示他也觉得这个EIP提议很容易实施，他表示OpenEthereum还没有更新到协议65。一旦更新后应该很方便就能够实施。Peter表示这个EIP的确会让一些请求变得简单，有时候请求的数据是一起取回的，之前的机制就要很仔细的去把返回的数据匹配之前的请求，特别是当返回的数据是空的时候。他现在想到对核心开发者和OpenEthereum可能会遇到的问题是一些老的协议（协议62，63等）或许不能支持这个功能。但是他认为这是一个好的方向。Artem说最终都会停止支持协议64，64，65。但Peter回应说现在很多还在63上面，所以还是要考虑到这一点。Piper说是理论上可以设置一个最后支持协议63的日期。

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

5.Hudson向Christoph和Piper表示他并没有一开始就包括客户端Trinity。他询问他们同步到以太坊1.0主网的状态如何，以后在和OpenEthereum、Geth、Besu、Nethermind等客户端讨论主网事宜的时候，是否需要把Trinity包含进来？Christoph回复说他们升级工作正在进行，Beam Sync进行的还不错。他们计划能在2-3个月内升级到Beta，但是柏林的EIP还未合并进来。他们希望能被包括进来（他们注意到了之前的表格里面没有Trinity）他们也在努力工作希望不久将来就能被当作主网的客户端之一。

6.下一个议题是EVM384：在EVM上的另一种预编译方式来支持BLS12-381。 Axic介绍说他知道包括以太坊2.0在内的一些团队想把BLS12-381作为一种递归SNARKs。同时Wasm团队也做了基准测试。接着他请大家看他分享的一张在Gitter上的基准比较的图表。这个图表上就表明了Wasm团队应用了BLS12之后的测试结果。一种是用了原始的Rust的库，另一个是用了Wasm SNARK的BLS12的实施办法。图表明显的体现了，没有用主机函数优化的执行时间是接近500毫秒，原始的Rust库只有5毫秒，而用了Wasm SNARK代码优化后是大约15毫秒左右，很接近原始的速度了。Axic表示还可以进一步优化。然后他想在EVM上面也做同样的事情。于是他引入了三种新的代码（addmod384、submod384和mulmodmont384），并且只在内存执行这三种代码。然后经过两周左右的测试，在EVM上也得到了比较好的结果，和Wasm基准测试中用了主机函数的结果类似的好。这就说明可以在EVM里面更好的支持BLS12，提高运算速度。接着和Alex等又进行了一些数据的讨论和解释。Martin询问增加的这三个新的代码到底有多少复杂。Axic回答说用C语言，大概是150行左右，不是很多。

https://notes.ethereum.org/@axic/evm384-preview

7.Hudson最后总结今天会议达成的一致行动。首先是新建一个柏林测试网络YOLO，包含两个准备进入柏林的EIP（2315和2537）。EIP-2565是否包括要看OpenEthereum下周二左右出来的基准测试结果。Greg和Martin下周二也应该解决EIP-2315最后的规范问题。Alex下周初也会完成EIP-2537 BLS12-381曲线操作的预编译地址，最后完善这个EIP。James补充说EIP-2515最终决定从柏林撤回了。会议结束。

与会开发者：

• Alex Vlasov

• Alex Beregszaszi (axic)

• Andrea Lanfranchi

• Ansgar Dietrichs

• Artem Vorotnikov

• Daniel Ellison

• Daniel Weaver

• David Mechler

• Dimitry

• Greg Colvin

• Karim Taam

• Kelly (Supranational)

• Hudson Jameson

• Mariano Conti

• Martin Holst Swende

• Michael Carter

• 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