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

会议日期: 2020年7月10日

会议时长：1.5小时

会议视频链接：

https://youtu.be/RUZ3eJ81c0k

会议议程：

1.EIP讨论

-EIP-1559 更新

-账户抽象更新

-EIP-2046 基准测试

-EIP-2718 深入思考

-EIP-2711介绍

2.网络健全

-继续上次会议内容讨论

-客户端实施方法深度解析

3. 前次会议的决定和实施回顾

会议主要内容：

主持人 Hudson Jameson 欢迎大家来到第91次以太坊核心开发者会议，他说这次交给James主持，他来做会议记录。James欢迎大家到来，并说这次会议议程是先讨论几个EIP的更新，然后主要时间还是继续上次会议关于网络健全的讨论。他强调这个议题很重要，希望大家都参与进来各抒己见。

James开始EIP讨论。第一个是EIP-1559，Besu团队的Tim来更新。他表示，简单来说他们做了一个测试网连接Besu和Geth客户端，Besu完成了所有准备工作，测试网在一周内很快就将发布。EIP-1559会是一个比较大的变化，社区很多人关注着，所以同时他们也在联系有才能的人来专业设计和分析，确保1559能够实现预设的目标。Tim说这是两个主要的更新点，具体的内容可以去看前一次的实施者会议，下一次的实施者会议也会讨论相关内容。James表示很多技术内容也在R&D EIP-1559的Discord频道上。

James开始账户抽象的更新。Ansgar说之前是Will负责，但是今天他不能参加会议，所以他代表Quilt团队来更新。他说这周他们发布了一个账户抽象的练习区（playground，有没有更好的翻译），可以让大家通过简单的步骤创建自己的账户抽象。他说账户抽象的概念已经提出有一段时间了，他知道还有一些质疑，比如效果如何，稳定性如何等。但他提醒大家，当前发布的这个练习区并不是用来做这些测试的，只是让大家能够熟悉相关的操作流程。他们团队正在做效果测试，有了正式的报告后会及时发布。至于那些质疑，大家后续可以在这个测试基准上再进行讨论。他们会先验证在Eth1.0环境下的可行性，因为这个想法最初是想在Eth2.0的环境下搭建。如果大家有任何批评建议都可以在github上面分享。

https://github.com/quilt/account-abstraction-playground

James接着邀请Light客户端的Matt来更新EIP-2718的深入思考和EIP-2711的介绍。Matt介绍说EIP-2718是关于包含交易类型的交易格式，主要引入了一种新的交易变量，第一位用RLP编码来确认交易格式，第二位被解码后代表真实的交易类型。上次会议介绍了这个EIP的原理，现在过去了两周，不知道大家有没有新的想法。

Piper回应说关于这个EIP昨天在Discord频道里面讨论了，他觉得这个EIP提议的办法是需要拆开一个区块，因为需要改变头文件，交易运算的根也需要重新计算，而且最复杂的地方是需要支持历史悠久的Dev P2P协议类型的交易。客户端之前的版本都是支持比较老的Dev P2P版本的，新的交易类型可以被转换和降级到老的平台。但是现在引入新的交易变量，相当于正式宣布不支持那些老版本。Matt回复说他不太清楚老的P2P协议，但是他理解交易类型本质其实是一些被协议定义的晦涩的数据结构。所以当引入这个新的交易类型时候，是否就真的不能处理老协议定义的交易类型？Piper认为如果要支持老的协议，做到向后兼容，那么需要客户端去修改老协议的数据类型，这样会造成很大的混乱。他解释说他并不觉得这是阻止这个EIP通过的一个原因，但是他知道的确有很多Eth63版本或者更早版本的客户端还在使用。Matt询问是否老的P2P协议对应着一种交易类型？Piper说这个就是需要去搞清楚的地方，而且还有很多细节需要确认，他提议线下在论坛和Github上再去讨论。

Matt随后询问还有没有其它意见。得到没有其它意见的回答后，他开始介绍EIP-2711。他说2711是建立在2718的基础上的。EIP-2711是在通用的交易类型上引入了三种新的功能。第一种功能叫做赞助交易，顾名思义这种交易可以被交易发起人以外的人来支付。第二种功能叫做批量交易，适合在批量的连续的交易场合中使用。第三种是有时间限制的交易，在交易类型里面加上了时间戳。时间戳过了之后交易就失效了。Cayman询问为什么不用区块号码而是时间戳。Matt说时间戳比较容易实现，而且更重要的是离线期间时间戳也可以用。James感谢Matt的介绍和解释。

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

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

2.下一个议题就是延续上次会议的关于网络健全的讨论。James表示Alexey在论坛上有很多讨论，Piper也写了一个很详细的帖子阐述自己的想法，所以他想邀请这两位首先来发言。Alexey表示上次会议谈论了很多潜在的办法，但是就如同Piper之前说的，没有花时间去分析问题，找出问题的根源。所以他不多说，直接让Piper谈谈他的想法。

Piper说抱歉上次会议没有参加，但是他之后听完了整个会议也很欣赏大家的讨论。但是他觉得有些讨论并没有朝着一个可以解决现在问题的正确方向前进，这样就很难认清问题根源。他举例说上次讨论说到很多小客户端团队没有得到很好的支持，他认为一些团队的确是因为支持不够，但是另一些小客户端并不是因为这个原因，同时考虑到Besu团队比Geth还要大2-3倍的规模，所以支持问题并不是小客户端不能成长的问题的根本。

Piper表示经过思考他得出的结论是要开发一个以太坊的客户端太困难了。我们需要把这个过程简化。这是他的结论，他想听听大家的意见。Alexey表示这就是他想做的事情，他说能做事的人都在这里，但需要找对做事的方向，这样才能让事情进行下去。讨论半天而没有行动是最差的结果。

Piper接着表示他继续抛砖引玉谈谈想法，大家看看是否有更好的方向值得深入探讨。他觉得无状态以太坊很不错，虽然没有让网络状态更易管理，但能够让大家一定程度的忽略网络状态。这是一个状态问题。第二个问题是网络协议本身太庞大了，变成了巨无霸软件，导致要想开发一个客户端就需要实施所有的网络协议，而这就变成了开发新客户端的一个巨大障碍。比如作为一个矿工，需要知道的就只有gossip协议，但实际情况是如果不实施所有的网络协议，这个矿工就不能参与到网络中来，因为其它客户端会询问你网络状态。有些客户端要求你知道所有现有的网络状态以及所有链和区块。这就给开发一个客户端提出了很高的要求。要解决这个问题就需要给客户端松绑，或者彻底不要实施整个网络协议。Piper建议可以把网络协议分成三块：1）Gossip，代表了纯粹的交易信息2）区块链的历史数据，包括老的区块，receipts（这个单词一般就是翻译成收据，因为是它真的是以太坊交易的收据,haha） 3）当前状态，方便客户端同步最新的状态而不用同步整个历史数据。如果网络能被划分成这样，那就能开发不种不同类型的客户端，专门为了某些特定应用，不用非要是一个大而全的客户端。Piper表示这是他的建议，网络划分不一定非要是三个类型，但宗旨就是把网络分成几个特定的应用，每种应用可以对应自己的客户端。他询问大家有什么想法？

Alexey表示他想就刚才说到的一个团队大小的事情继续讨论。他说前面提到Besu比Geth团队有更多的人。他想知道为什么Besu没有和Geth一样成为主流客户端。Tim回答说这可能有点误解。他说最开始Besu有20个人，做了一个以太坊的存档节点（archive node），之后他们并没有完全聚焦在主网上，而是做了私有链和Eth2.0。所以现在只有4-6个人全职工作在以太坊上，还包括无状态以太坊。所以结论是Besu团队虽然比较大，但是主网的客户端只是他们全部工作的三分之一或者四分之一。

Alexey接着询问其它几个客户端有多少资源在主网上。他解释说他还是想搞清楚复杂的网络协议到底是不是一个问题。他认为网络协议，虽然代码很大但是可以做成层级的结构，而不是单一巨无霸形式。所以如果网络协议代码规划的好，只要有足够多的人，是可以让一个团队来共同管理，而不是非要等着一个超级天才出现，负责所有的代码。

Tomasz表示考虑到资源，他们Nethermind团队有2个资深成员为以太坊和私有链工作，还有两个一般的工程师做测试和其它一些不直接联系到以太坊的工作。Artem介绍说OE有三个工程师，同时一直在找RUST工程师，但是很难找。他们主要工作在代码纠错和代码简化的事情。

Alexey说他的团队有6个人，之前用了比较长的时间来学习，现在慢慢开始熟悉了。他认为资源的多少，团队的大小在最初阶段是一个关键因素，而且会越来越重要。所以他们还决定再找一个工程师来帮忙。Piper介绍说他们团队现在有三个全职的工程师做Eth1.0，不包括他自己。曾经有过最多5个人来做客户端和Python。现在感觉没有资源再扩大了。Geth团队的Martin介绍现在有五个人在做编码工作，其中两个是新人。但Guillaume说他数出来是十个人包括一个项目经理。

Alexey解释说他问团队大小是为了他的下一个问题。他说道，一个假设前提是以太坊的网络协议是一个类似巨无霸的很庞大复杂的软件代码，导致实施起来比较困难。（他认为这个基本是事实。）但是另一个重要原因是，我们没有时间和人力去正确地整理分层这个大协议软件。一开始就只是开发，继续开发，然后就变成现在的样子。所以想询问大家，是否有必要花时间把网络协议结构化，模块化？Piper首先发言，他认为这本质没什么不同，只是代表着不同的说法，就像三个网络协议和一个网络协议的三个模块一样。Jason问到底是协议的规范要求做成大而全，还是我们没有时间去做模块化。Alexey认为这个问题背后隐藏的问题是我们是否需要一个超级英雄，知道所有的知识，知道所有的细节，愿意来负责维护支持以太坊网络协议，还是把协议模块化后，有一群开发者，负责自己擅长的那个方面的模块。

Martin表示模块化协议的一个困难是开发者如果只知道自己的一块内容，那么势必考虑的不那么全面了。Tim同意Martin的观点并说要做模块化并不是不可能，但是知识的学习需要时间，所以他认为模块化会很困难。Piper也表示同意，他认为新的开发者可以很高效的开发客户端，但是在没有熟悉所有的协议之前，不能建设性的提出关于提升协议开发和研究的意见。

Alexey回应说他经常在论坛，推特上面看见听见有类似超级英雄的开发者说早上四点起来干活，然后大家回复说太厉害了，太辛苦了，欠你人情之类的话。他认为这就是不健康的工作方式。我们真的就这么需要依靠超级英雄么？什么造成了超级英雄的现象？能否有机会避免，或者部分避免这种情况。Alexey重新表述他的问题，一个客户端会分配多少资源给模块化的开发者和超级英雄的开发者？一个团队不可能全是有能力改变协议的高级开发者，一定还有开发者需要去做开发客户端的事情。

Piper表示作为客户端团队的一员，他认为很多时候他们都去做客户端的开发和优化工作去了，并没有时间考虑协议本身。所以他认为在当前状态下，不是不能开发客户端，而是开发客户端需要很多工作，很难实现。Guillaume询问，我们有不同的客户端，但是否每个不同的客户端都需要重新编写每一部分的代码？有些代码能否复用？Tim说可能是因为商务许可的原因？Piper认为有些也是设计的原因，每个客户端都有自己的想法。不过如果能把客户端做成模块化，部分接口能够统一标准，复用是一个好的想法。Artem和Alex也表示同样的想法。

但Piper也认为在某些比较容易出问题的软件部分，模块化可能还不太容易实现，因为这部分的软件本身就是不稳定的，一直在修改和进化。模块化，能给各个客户端重复利用的软件代码应该在那些比较稳定的部分比较容易实现，类似Json RPC，或者说Json RPC的API。比较基础但是每个客户端都需要用到。

Alexey说到他们能做到把EVM1和EVM2都集成到主网上去，原本希望能够提高效果，但是他们碰到的问题是不同软件语言带来的。如果执行EVM C一次，那么费用很微小，但是在100个区块每秒的速度下执行EVM C，那么执行费用就变的比较大了。所以现在EVM C的效果就没有原始的Go的EVM效果好。他解释说他提到这个例子是说模块化软件需要考虑到一个地方：不能让不同模块化的接口不匹配影响到最终的结果。他说我们开始往这个方向走了，他希望大家都明确这个战略方向并开始尝试执行，而不是乱找方向。

Tomasz说他同意Alexey的说法，EVM C可能不是这么容易就能给每个客户端复用的，当时没有把接口部分的软件做成能够重复使用的。他同时认为随着时间的增加，协议软件有越来越多的优化的补丁打上去，优化措施会逐步损害到软件的分层化和模块化。但是他支持把客户端的软件做成模块化和复用。他认为现在每个客户端实现方法不同，每次有点软件的改动就需要写很多测试用例，花费很多时间来测试。

Piper还是认为不清楚现在的结论到底是什么，需要做什么。Alexey说经过讨论，他看到：首先，大家部分同意了部分软件可以开始做模块化。虽然每个客户端可能还是需要一两个超级英雄的存在，但是起码这个可以部分改变开发者的生活。同时他也发现优化代码会慢慢让软件代码结构化模糊。

Greg表示他从事高效能的内核软件开发很多年了，他感觉一个团队里面的每个成员都需要有自己特别擅长的一部分，那么整个团队才能开发出高效能的软件代码。同时团队成员也需要了解一些其它的部分以便能够互相交流。规范也需要定义清楚结构化，模块化。如果规范本身就不清楚，或者说没有定义好，那么代码实现起来就不可能模块化。Piper感觉听上去像全部重新构架软件，他认为要很仔细地来实施。他也认为抛弃掉旧的EVM的规则是很好的想法，能够降低开发新的客户端的难度。他觉得复用模块化的想法很好，但是他还是持有怀疑态度。他认为这个应该是自然形成的，而不是大家喊喊就能够出现的结果。

Piper继续说Trinity团队里面有人开发了很长时间的客户端软件的代码，但是却并不了解网络协议。这就是软件模块化造成的问题。所以他认为其实从某种程度说，我们已经开始做这方面的工作了，但是我们应该向着对以后有更加深远意义的、更加困难的改革前进。我们应该多花点资源在无状态以太坊以外的地方，比如同步和状态网络（state network），不管是在现在的协议上优化，或者开发新版本迭代。他说他也工作在历史数据链上，希望能把这个历史数据从节点上分离出去。Piper觉得这是他正在考虑的解决方案，也是我们真正可以做点什么的地方。

Martin表示支持去掉历史数据，同时也能想出新的办法来同步状态。Tim表示我们说的可能有点冲突。一个是让新的客户端开发变得更加便捷。第二个是让现在的小客户端获得更加多的市场份额。我们必须分清这两个的不同之处。Tomasz说模块化的软件结构在短期不是这么容易实现的，但从他的经验来看，跨客户端的测试方案是必不可少的。比如之前做了几个客户端Json RPC的测试就很好的摸清了不同客户端下的效果，这样很方便大家再做各自的调整达到一个统一的效果。

Artem说每个客户端都有自己的Json RPC的实现办法，但是不是每个客户端都能生成Json RPC的服务器。他建议这是我们可以去改进的地方，因为这个必然会降低客户端软件代码的复杂性。

Hudson说最后他想总结一下。他说我们再花一次会议讨论这个主题，应该侧重于可执行的下一步操作。如果有谁有什么想法，有谁愿意带头来做，可以在论坛里面提出来。Alexey总结说他从讨论里面看到了两点意见，一个是发现客户端团队是可以分成两类开发者，一类有经验可以全局把控，对网络协议提出更好的建议，另一类不需要知道所有的知识，但是专长在特有的一部分软件上。这个人员结构是可行的。第二点就是网络协议是有空间可以改成模块化的。首先要做的就是把规范先整理好，规划把软件结构划分的清楚，开发代码就能模块化，开发者也容易找到适合自己背景的软件模块。

James最后建议下一次可以多谈谈如何让客户端能够多样化。会议结束。

https://ethresear.ch/t/applying-the-five-whys-to-the-client-diversity-problem/7628

与会开发者：

Alex Vlasov

Alex Beregszaszi (axic)

Andrea Lanfranchi

Ansgar Dietrichs

Abdelhamid Bakhta

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

Vitalik

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

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

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

以太坊：

0x7Ba18D8d4B0E4EB06a720aF2BeC29603078c806b

Gitcoin:

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