Ethereum Core Devs Meeting #90 | 以太坊核心开发者会议第90期

最新推荐文章于 2024-11-08 21:37:06 发布

ETHPlanet

最新推荐文章于 2024-11-08 21:37:06 发布

阅读量359

点赞数 1

分类专栏：以太坊核心开发者大会文章标签：区块链

本文链接：https://blog.csdn.net/ethplanet/article/details/107662280

版权

以太坊核心开发者大会专栏收录该内容

5 篇文章 0 订阅

订阅专栏

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

会议日期: 2020年6月26日

会议时长：1.5小时

会议视频链接：

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

会议议程：

1.关于功能开发与网络维护的辩论

-如何在增加功能和保持网络健康之间保持平衡，避免让实施者们过于疲惫，同时又能促进实现方式的多样性等

2.柏林EIP - 集成更新

-Yolo测试网

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

-EIP-2537: BLS12-381曲线操作

3.符合条件的 (EFI) EIP回顾

-EIP 2718: 包含交易类型的交易格式

4.EIP-1559实施会议更新

5.测试网更新

-EIP-2046的基准

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

会议主要内容：

1.关于功能开发与网络维护的辩论

主持人 Hudson Jameson 欢迎大家来到第90次以太坊核心开发者会议，并开始第一个议题。Hudson表示这个议题最初由Alexey Akhunov发起，最近在推特、魔术师论坛等地方有很多关于功能开发VS网络维护的讨论，即我们如何在增加功能和保持网络健康之间保持平衡，避免让实施者们过于疲惫，同时又能促进实现方式的多样性等。Hudson首先让 Alexey 对此议题进行回顾。

Alexey Akhunov表示，事情的起源是因为社区里矿工投票，决定增加区块的Gas最大值限制，这个事情在各个地方引发了很多讨论。他觉得这些讨论很重要，所以应该在一个正式的场合提出来。他认为有两点意见需要明确。首先就是主持人提到的功能开发VS网络维护。这个主要是需要评估不断提出的新需求到底有多重要。他知道为了开发新的需求，有些开发者一直在工作，一直处于很紧张疲惫的状态。他认为这是很不健康的模式。其次是（客户端）实现方式的多样性，他强调多样性在2016年的DoS攻击中起到了很好的防护作用。现在多样性还需要考虑到底是增加彼此间竞争的多样性还是彼此间合作的多样性？最后他表示他只是抛砖引玉，更想听听大家的意见。

Geth客户端的Martin表示多样性是很好的东西，Geth团队从来不追求成为最大的客户端。因为有了多样性的客户端，他们晚上才可以睡踏实，不用担心万一Geth客户端出问题，整个网络都会完蛋。同时，对于互相之间的竞争关系，他们团队有一个约定就是不去和其它客户端互相比较。最后关于长期的开发功能与网络维护间的争论，或者说是如何维护核心问题，他认为之前做了很多类似的工作，并且取得了很好的进展，所以才有了现在的Eth 1.x无状态工作。他觉得可以改进的一点是1.x无状态工作小组并没有太多地参与核心开发者会议。

Alexey表示Martin的发言就是他想听到的。他认为核心开发者会议现在变得官僚主义了，变得只重视如何开发功能了，而没有去想一想为什么需要这些功能，是不是现在就需要开发等问题。他举例说类似BLS曲线操作，用于EVM的简单子程序等功能，到底真的是我们现在所需要的么？他们不是还有更加重要的问题需要解决么？每次参加会议都让他沮丧，让他失去热情和兴趣来参加核心开发者会议，这让他困惑不堪。

Peter接着继续回到客户端多样性的话题。他表示Geth客户端确实是一个占绝对优势的客户端，因此如果 Geth 中出现问题，那么这对整个网络来说将是一个大问题。他表示尽管很高兴看到大部分人在使用 Geth，但它确实有着自身的缺陷。因为很多人在用，所以Geth不能负担出一点小错误，因此这也反过来导致开发进度很慢。因此如果能够重新拾起客户端的多样性，这将是非常棒的，即便多样性要分掉Geth的“一块蛋糕”。

Alexey 表示，在我们实现多样性或性能 (或者两者兼而有之) 这一目标之前，我们不应该去实现什么大功能。这是大家要实现的目标，包括那些非核心开发者、普通的用户、DApp 开发者等，大家应该尝试使用不同的客户端。

Hudson 表示在推动客户端多样性这方面，的确需要包括核心开发者在内的所有人的推动。同时，也的确有一些具体的事情可以做，比如通过对话了解到矿工在什么条件下愿意使用除了Geth的其它客户端，比如通过对话和市场营销的层面来让大家了解如何运行Nethermind 、Besu 或 Parity (Open-ethereum) 等不同的客户端。还可以通过头脑风暴想出更多协作的方式，比如网上发表联合宣言，不达到多样性不增加新功能。

Alexey 回应道，实际上我们不能简单请求社区去使用哪个客户端，因为我们身处一个超级大的社区，在这个生态系统里面的人都是理性行事的，他们都想通过最少的付出收获最大的可能回报，因此简单的请求是无效的。他们知道其他人可能会选择哪个客户端，因此除非你将某些事情绑定在一起，否则你就无法得到想要的结果。这不仅是关于客户端多样性，其中存在一个二级效应，客户端采用的多样性需要一定的时间才能实现。Hudson表示这个观点说服了他。

Tim发言说到，现在不只是单个用户，也有很多公司的业务运行在以太坊的上面，如果只有一个客户端，那么所有公司的所有业务都依存在这个客户端上面。与此同时，如果要让他们转换客户端，或者说让这些公司的软件架构做成和客户端无关，即底层可以切换到任意客户端，是需要很大的工作量的。Tim表示这个也要考虑进去，而不只是考虑单个的用户。

Alex直接发言说到他认为客户端多样性是不会出现的。他认为人们总是选择最简单的东西去做。第二个理由是同时维护5-6个客户端，从工作量上面来说也不现实。Alexey回应说其实这不只是关于客户端的多样化问题，还有其它的效应。客户端的多样性绝对不是一朝一夕能做好的，但没有做就不知道是否能做成。就算花了一年的时间得出结论不能做到客户端多样性，那么他认为这一年后也会有更多的客户端出现，给人们更多的时间来理解现在的架构。他认为现在不断增加新功能的现状就像在追逐一辆一直在行驶的火车，时间太紧迫。

James表示还是应该先回到开发功能VS网络维护上来。他说人们喜欢新功能，但是并不知道核心开发者需要付出很多才能持续地增加这些新功能。Tomasz表示反对，他认为增加这些功能并不是非常耗费时间，如果我们暂停开发这些功能，那么反而可能会陷入糟糕的境地，因为所有客户端最终都会花时间优化现有产品以达到领先地位。现在我们在良性的互相竞争，促使大家开发出更好的产品出来。其次，他认为核心开发者之所以做这些事情，是因为热爱，是因为他们认为这些很重要，而不是被逼一直在做，辛苦到一刻都不能离开的程度。

Will也发表了自己的意见。他说很多在做的EIP还是很有意义的，这些EIP提升了效率，是值得做的。所以简单地讨论不开发新功能，不做EIP并不是一个好的答案。只有参与其中，参与到新功能的开发，才能更好地理解以太坊，从而想出有建设性的意见。Tim接着说，其实大部分的EIP都只是简单的改动，可能只占用了10%的核心开发者的时间，但是也不可否认总会有超大改动的EIP的出现，就比如最近的账户抽象，EIP-1559等等。这些超大改动的EIP不可能做到没有瑕疵，合并总会有错误产生。所以这个时候客户端具有一定的多样性就是好事情，能够分散风险。

Tomasz又补充说，也许我们应该把研究和核心开发分开一点。也许我们目前的模式就是不同的客户端追求不同的开发方式，并与其他人分享他们的成果，这也许就是一个很好的模式！

想发言的人太多了，Hudson表示按照在视频会议软件中举手的顺序来发言，这样能保持一些次序。（编者注：这种情况在以往的会议中从来没有出现过，可想而知这是一个多么重要和引起共鸣的议题！）

Peter继续发言，他表示他反对之前Tomasz说的观点。他认为有时候看上去好像新的EIP只需要一周的时间来整合，其实背后可能已经花费了好几周的时间来开发和测试。每个EIP的实现都会伴随着开发的风险，他举了几个之前已经完成的EIP，他说虽然每个EIP出现的问题都没有严重到对主网有致命性的打击，但是这些问题还是花费了大量的时间来测试、定位和修改。所以对于主要的客户端Geth来说，其必须花时间确保新功能在客户端上是正确无误的，因为他们承担不起这个后果。所以他认为“EIP只需要花少量时间就能完成”这个说法是不公平的。

关于客户端多样性，他认为每个客户端都有自己的办法和思路，这之间的竞争是好事情，能够促进大家想出更好的解决方案。但是需要一个全球的、各个客户端之间的统一的共识是很困难的事情。

Martin说Peter说了很多他想说的，的确大量工作并不是耗费在整合阶段，而是在前期的准备工作上。Artem接着表示他不知道完全暂停新功能开发是不是一个好计划。他觉得大的客户端和小的客户端的目标是不同的。小客户端敢于去尝试更多的东西，因为就算错了也不会影响到主网，而大客户端如果出错了会让整个网络都挂掉。所以一个完美的目标应该是很多个小客户端，在确定了开发目标之后，新功能的实验就能够很快的进行。

Peter又说，对小客户端来说，可能比较有帮助的一件事是关于简化协议的某些内容，使小客户端更容易实现。比如Trinity团队最近增加了一个EIP来向网络添加请求ID，Geth花了很久的时间才实现了不需要请求ID，但是新增一个请求ID的话，会让其它小客户端的开发更加方便。

Tomasz继续发言，他反对之前Martin和Peter说的“很多时间都花费在测试工作中”的说法。他表示，其实做安全性考虑、测试、实验研究以及在Geth上实现等工作的都是同一群人。AlexV也表示同意Tomasz的观点，同时他也说，即便暂停了新功能开发，用户也不太可能切换其所使用的客户端。

Tim继续补充关于测试方面的事情，他表示赞同Tomasz的观点并认为有更多的人能够参与进来是好事情。他也表示对于测试，事先是不知道会碰到什么问题的，也不知道确切的工作量。

Alexey表示希望再次强调一下多样化的实现。他说现状就是只有一个主流的客户端Geth，这种情况看似不可避免，但他并不同意这个观点，并且认为大家至少要尝试去改变现状。他认为这需要改变大家的共识而不是简单的游说。其次，他反问如果真的实现了多样性，又能够为大家带来什么？他表示，如果只有一个客户端，而且这个客户端只有三个人维护，那么当某个用户需要支持的时候，他可能无法得到响应。得不到响应的原因可能有很多，但主要还是因为那三个人很可能太忙了。而一旦实现了多样性，理想状态中至少会有十个客户端，那么用户就可以做选择，起码可以有机会选一个不那么忙的客户端。

Peter又说对于Geth团队来说，做大量测试并不是一种享受，反而很痛苦，但他们觉得这是他们的责任，尤其是现在这么多用户在使用的情况下。作为Geth客户端的开发者，他们愿意去做测试。但是无论多大多小的客户端，都要明白测试工作是很辛苦的，并且不会是一帆风顺的。

Greg表态说他认为Geth客户端独大是不可避免了。之前提到的整合的问题，或者暂停新功能开发的提议，都不能解决现在的问题。现在Geth团队的问题就是人手不够。另外其它的客户端从技术上是很难和Geth竞争，只有在其它方面去争取去覆盖Geth没有覆盖到的区域，而这又变成了一个市场问题了。

James说前面有很多关于多样性的讨论，但对于EIP–1559，如果非要设定一个多样性的门限指标的话，那么我们需要很多用户使用大量小客户端来进行对比。Martin又说对于测试这个工作，很多人认为是简单的入门级的工作，其实正好相反，这项工作需要足够的功力去确认做什么样的测试是有效的、如何写测试脚本、如何评估测试结果等等。他又举了几个例子，并且总结说其实只有客户端实现的开发者们才有这种专业知识来做这样的工作。

Alexey表示听到了大家很多的意见，但是他想提醒的是，我们现在讨论的任何方法都是依赖于核心开发者的。但是在整个生态系统里面，核心开发者只是较小的一部分。所以还是需要来自于其它部分的帮助才能促成这个改动。

Hudson表示今天大家畅所欲言很多，但是因为时间关系肯定是不够的，会后在GitHub和魔术师论坛上可以继续讨论。他询问AlexV和Vitalik有没有什么经验可以从Eth2.0传递过来的。Vitalik表示Eth2.0之前并没有太多的考虑客户端多样性的问题，这对于一个新项目是好的建议，对于现有的项目并不是太友好。所以暂时他也没有更好的办法。

Martin说是不是应该在7月暂停一下柏林的升级，以便大家有时间集中在此事上面？Hudson表示同意，并询问大家的意见。James也表示同意，并说正好BLS曲线操作也很复杂，需要更多时间去完成。

Hudson说他接下来邀请Matt来介绍他提议的EIP-2718。因为会议时间不太够了，所以日程上其它的议题可以推迟到下一次会议再讨论。同时关于功能开发与网络维护的讨论还可以在线下——比如魔术师论坛的聊天室或者是其它任何大家觉得适合讨论的地方——进行，也期待大家讨论出更好的实际的可行的办法出来。

CatHerder的Pooja发言，她说她认为这里面可能会需要进行大量的协调工作。她表示虽然每个客户端是独立的，也不需要向谁汇报，因为大家都在Github上工作，但是有时候还是有重要的信息没有被传达。CatHerder做过很多协调的工作，但是在客户端这边她感觉没有起到很好的帮助作用。她建议可以让CatHerder的同事多参与进来，帮助客户端分享以及发布信息，比如可以帮助传递Martin前面说的需要很多资源来做测试的信息，她认为这将会很有帮助。Hudson表示赞同，并询问讨论的发起人Alexey最后有什么想要表达或者总结的？

Alexey说非常感谢大家的热烈讨论，这是一件值得做的事情。

https://gitter.im/ethereum/AllCoreDevs?at=5ef4f6e13a0d3931fab39894

2. 符合条件的 (EFI) EIP回顾

终于来到了下一个议题，新EIP-2718的讨论。Matt介绍说这个和Vitalik在2017年提出的EIP-232类似。他想引入一种新的交易类型。这之前有不少的EIP都想引入新的交易格式。现在最好的办法是通过RLP编码来确认交易格式，就像EIP-155一样需要把CHAIN_ID加入到RLP编码内部去。但是这会在交易格式需要改变时，或者引入新的交易格式时产生新的问题。所以这个EIP和EIP-232一样，重新规划了交易类型的RLP。先辨认RLP里的第一个变量，决定是什么类型的交易以及后续如何解码。Matt认为这么做会让以后引入新的交易类型更加方便。同时只要设定第一个标量表示已知的交易类型的哈希算法不改变，那么也能做到向后兼容。Matt表示这是这个EIP的大概内容，并询问大家的意见。Vitalik表示赞同这个EIP。

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

https://ethereum-magicians.org/t/eip-2718-typed-transaction-envelope/4355

3. 前次会议决定和行动的回顾

下一个议题是前次会议决定和行动的回顾。首先是EIP-2046，因为James上周去度假了，所以推迟到下一次会议来讨论。其次是EIP-2565，James确认进入了EFI。第三个是Hudson需要再关注一下ETH 2.0的保证金代理合约的安全性审计工作。最后是需要Kelly给出上次会议他提到的测试报告。

这次会议需要的行动是首先确认柏林分支的工作在7月暂停。其次是持续讨论今天第一项议题。Hudson宣布会议结束。

与会开发者：

Alex Vlasov

Alex Beregszaszi (axic)

Andrea Lanfranchi

Ansgar Dietrichs

Abdelhamid Bakhta

Artem Vorotnikov

Daniel Ellison

Daniel Weaver

David Mechler

Dimitry