Ethereum Core Devs Meeting #87以太坊核心开发者会议

haoyun   |     |   285 次阅读

Default featured image huge


会议:以太坊核心开发者会议 #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

 
0 人喜欢