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

ETHPlanet

于 2020-08-25 14:22:59 发布

阅读量324

点赞数 1

本文链接：https://blog.csdn.net/ETHPlanet/article/details/108220350

版权

在这里插入图片描述

会议：以太坊核心开发者会议#92
会议日期: 2020年7月24日
会议时长：1.5小时
会议视频链接：
https://youtu.be/RWX9vkY7Oas
会议议程：
1.上次会议回顾
-是否需要继续深挖原因
-是否需要再讨论答案
-有没有可行的办法
2.EIP讨论
-EIP-2565
-EIP-2718

会议主要内容：

1.会议开始，主持人James欢迎大家的到来。他开始第一个议题，继续上次91号会议的主要议题讨论网络健全。James说首先请Alexey就上次的会议做个总结，然后Pooja给我们一个更新。
https://ethereum-magicians.org/t/coredevcalls-91-retrospective-how-did-we-do-with-five-why-s/4441

Alexey说他在魔术师论坛上写了基于他自己想法的总结，他把大意再说一次。上次会议是基于Piper的五个问题作为指导讨论的，深入讨论了三个层面的为什么，试图搞清楚真正的问题是什么。回到核心开发者身上，他也想搞清楚到底压力来自于哪里。关于为什么Geth是主流客户端，如果我们认为这个问题是真实存在的，那么就需要研究为什么存在这个问题。他听到过四种回答，第一个是说现在Geth的实施办法是被最多信任的办法。第二个是认为其它实施办法不能提供同样的功能。第三个是认为我们缺少标准，所以不太允许我们随意切换。第四个并行运行多个实施办法，那么成本上会划不来。还有些想法是这是一个有系统风险的问题，如果搞错了那么整个系统都有风险。所以最后就没有人来关心这个问题。

Alexey认为有几件事其实大家可以行动起来。首先就像他前面说的，先要搞清楚问题是否真实存在，那么首先要有数据来证明Geth实施办法是占主流份额的。然后需要有机制来评估在我们决定改变的情况下，改变措施的效果如何。还有一个需要注意就是我们需要很仔细的对待那些敏感的信息。

Pooja继续发言。她说CatHerder开始帮忙做一些调查，她贴出一个调查的链接，展示调查的内容。她说想通过调查得出一些数据。比如说调查问卷里面提到，如果需要一个备选的客户端，用户最希望是哪一个。反馈的数据显示Besu是最佳备胎。但是调查才发出去一周不到的时间，她们希望能得到更多的数据返回。

Alexey呼吁大家更多的参与，看看我们现在评估问题的方法有无不妥。Tim提了一个小建议。他知道我们有一个列表列出了交换内容，矿工池等，他建议大家可以过一遍这个列表，看看使用比例是如何的。Pooja说已经有这个单子并正在考虑。Martin表示赞同现在的评估方法，还建议可以使用发布在Eth Discovery的ENR数据。这个数据是之前爬虫信息取回，包括了多少客户端安装了ENR，ENR里面有没有具体的客户端的信息等。Alexey认为他更倾向于人工手动的办法。他认为自动化的调差能够得到数据，但是不能告诉你一个节点的重要性。我们不知道某一个节点到底有多关键，不知道一旦这个节点失败或者出现共识失败的问题，会带来多大的冲击。我们可以知道多少节点会不工作，但不知道不工作带来的后果。Martin询问Peter是否知道ENR信息是全功能模式还是轻客户端模式。Peter认为这个需要分情况不能一概而论。

Alexey强调我们在调查的时候也需要尊重用户的个人隐私，一方面这个很重要，另一方面也是为了避免用户担心隐私问题而给出不准确的回答。Pooja说现在信息都存在excel的表格中，她们不会和公众分享这些信息。同时考虑到个人隐私，有些问题已经被设计成可选的。Alexey询问隐私信息被泄漏的后果是什么，Hudson回答说他的理解是如果有矿工分享了硬件设施的信息，可能会导致DDoS针对性的攻击，尤其是用另一个客户端的竞争对手。他认为不一定会发生，是一种可能的情况。

Alexey表示关于调查数据，另一个他考虑的问题是能否定时发布调查结果，比如每月发布一次？因为他意识到有些运营者，一直认为Geth是主流，从未想过去改变什么。如果我们可以通过数据的展示告诉他们，其实你们应该做点什么来把现状变得更好。他们也可以从商业的层面来评估，是否能够投入多少资金，让系统变的更好，他们也能从中受益。希望几个月过后，我们从新的数据中能看出一些改变。Hudson表示赞同。

James提出异议，他认为从他在自己的经验来说，他感觉从节点运营者那边取得正确的信息是很困难的。而且就算我们拿到了正确的数据，也很难改变节点那边的状态。Alexey觉得现在整个系统没有人做协调工作，每个人都从自己的立场出发考虑问题，或者说从自身的商业模式的最大化考虑问题。Tim提出一个意见，他认为如果我们需要让客户端多元化，我们应该通过调查找出愿意使用不同客户端用户或者节点运营商的共同点，然后把这些共同点总结出来，广而传播。

Alexey说如果关于调查和调查数据没有多余的意见后，他还想说另一个问题。最初他想到这个问题的时候，他就认为Cat Herders能够帮上忙。他设想他们手上有一个相关人士的列表，使用访谈类而不是调查的形式，比如通过电话的形式，这样可以更快更高效的获得大家的想法。 Tim表示这是对调查的一个很好的补充。Alexey继续表示，如果大家都同意调查的形式，那么就需要一个协调者来确保大家思想统一，同时要确保正确的信息能被传播到生态圈里面的每一个角落。

Alexey询问Go Ethereum团队他们最大的恐惧是什么？比如说是代码的正确性，或者是某种缺陷带给生态圈的影响。Martin说在上一次的Devcon他阐述过这个问题。他当时着重指出主要是共识问题，服务问题等这类问题会把70%左右的网络都弄瘫痪。Alexey说在过去两三年这种压力越来越大是否因为用户数量越来月多？Martin说是的。Alexey认为这就让我们现在讨论的议题更加重要了。

Alexey接着问系统的gas极限在哪里？大家有没有设想过如果提高gas极限到一个不安全的数值，比如2000万，会发生什么，会触发什么严重的问题，谁又会被受影响最厉害？Peter说这样会导致30秒就能产生一个区块，这样让我们再次进入Shanghai DoS的情形。我们怎么解决这种突然出现的区块？但Peter也表示他更关注极限情况是如何，会发生什么极限问题。

于是Alexey提出一个假设性的问题，他问我们能否创造出这么一个条件，Martin马上问是不是有意的模仿网络受到攻击？Alexey认为在社区和核心开发者中间有一些理解上的偏差。社区用户想的比较简单，他们认为提高gas极限就能解决问题。Peter又建议说可以创造一个表格，里面设置一些影响网络的变量，输入不同的数值，看看网络在1，3，5年的时间内会变成什么样子。

Vitalik发言认为问题是对于EIP-1559，没有一个清楚的答案。Tim也强调说，只要增加gas极限的要求增长速度比网络容量增长速度快，那么就始终存在这个问题，EIP-1559就不会被解决。有人曾说要增加区块容量20%，这也不能根本解决问题。我们需要一个更加广泛的解决方法。Vitalik认为Rollups是个解决办法，同时他之前提议的精简gas成本的办法也可能解决这个问题，理论上比较简单，也比较容易实现。

Vitalik说其实这里有两个问题，一个是短期问题，谁来攻击网络，一个是长期问题，网络状态大小不断增加。Peter他反对推高gas极限。他说我们如果让网络不断扩大会引发一个严重问题。从上次上海DoS攻击的经验来看，攻击者是先让网络膨胀，让以太坊网络不断增大，然后通过各种办法攻击节点。当时解决办法有两个，第一是推高成本，让攻击者无法负担让网络膨胀增大的成本，第二个解决办法就是直接暴力的删除增大的网络部分。如果我们现在决定提高gas极限，那么网络大小就会慢慢增大，如果增大到一种危险的极限状态，我们没有东西可以删除，我们就束手无策了。这是我们需要真正担心的事情。另外同步的角度看也会有问题。如果网络大小翻倍了，系统同步的时间并不是同步翻倍增加，而会增加更多。James询问Peter是不是有点解决办法可以考虑？

Alexey表示现在可能还太早去给出一个完成的解决办法，现在也没有足够的时间来充分的考虑任何解决办法的提议。他说其实上次会议有一点小分歧，有些人认为很难写出一个完整功能的以太坊客户端，所以我们才提出了why。然后有四个回答被记录下来。其中有一个是协议太复杂导致很难把代码分层模块化。但Alexey反而认为其实是我们一开始没有很好的设计代码。通过大量的工作是可以把现在的软件模块化的，从而容易实现不同的人维护不同的软件模块。但是他怀疑是不是大家都有这个想法，都愿意去这么做，有没有这么多资源愿意投入去做，还是等到Eth2.0的到来？

Peter解释说很多人的确认为Eth2.0是一个解决方案，但是他想澄清的是，Eth2.0的确提高了吞吐量，但是并没有解决这个问题，所以Eth2.0不是解决方案，只是延长了这个问题被暴露的时间。Alexey表示他说的重点不是技术问题，是架构和组织问题。是否能成立一个软件架构小组，这个小组能否在Eth2.0的团队里面开始工作。如果不行，Eth2.0是不是也会失去模块化软件的机会？Peter说Eth2.0的确有机会能解决一些Eth1.0不能解决的问题，比如状态租赁（State Rent）不能引入Eth1.0，但是可以引入到Eth2.0。我们还可以想办法引入更多的新规则，这样就更可能解决网络规模化的问题。我们还可以规划一下，看看关于软件架构有哪些是在Eth1.0上想做但是没有做成的，在Eth2.0上可以做起来。比如说可能63分片化能提供极好的性能。

James认为有些事情不花资源也能做做看，比如发动用户，遛猫者等所有生态系统的参与者朝一个目标前进。核心开发者可以宣布在网络节点没有去中心化之前不会再次硬分叉，这样能反过来逼着所有人思考如何去中心化，而不是现在非要核心开发者来思考解决办法并引导。Alexey表示怀疑这个效果，因为他认为整个生态圈有两类人，我们核心开发者是一类，社区的用户是另一类。屁股决定脑袋，社区用户有些只想要新功能，并不关心在什么客户端上。

Tim也表示社区有时候只要新的功能，更极端的是社区是要在Geth上实现新功能，不需要Besu，那样就更让客户端集中化了。Alexey补充说这样可能还会促使社区用户在填写调查表时候故意填写有倾向性的信息而不是真实的信息。Pooja表示回到刚才的话题如果我们怀疑调差数据的真实性，我们是否可以把一些信息做成必填项，类似实名制，这样能让数据更加可靠。Alexey认为只有当人们真心愿意分享这个数据时才能保证数据的可靠性，其它限制类的办法纵总有人能想出办法规避。Peter也表示很容易用其它身份来提供数据。

James表示技术上来说每个客户端都为柏林准备好了，大家都测试了，都集成了，都认为可以上线了。但是真的要上线的时候他能感受到来自客户端的压力。他希望我们能工作在一起短期内解决这个问题。Tim说最早的时候讨论过这个问题，当时说让Martin主持客户端的模糊测试，他认为这个计划仍然很好。Martin立刻说其实昨天他才送出测试邀请，这个计划正在进行中，只是刚开始。Alexey表示回到之前的问题，如果我们认为这是一个长期的目标，那么我们就需要有长期的计划，但我们还没有找出任何技术上可行的解决方法。Piper打断了Alexey的说话，他说他个人觉得可行的办法还是在网络层面，我们需要不同类型的客户端对应不同类型的软件模块。我们应该知道具体怎么做，就需要把资源分配上去，然后落实。James提醒大家时间有限，只能再说两分钟，就需要进行下一个议题了。Alexey说如果大家有兴趣，可以会后再讨论，无论什么形式，也不一定要两周一次，因为他真的很想搞清楚什么解决办法能让开发者舒适，也不会把事情变得更糟糕。

2.James开始下一个议题，EIP的更新。他先请Kelly来更新EIP-2565。Kelly先简单回顾了一下，他说这个EIP是三月开始引入的，一个月之前通过了EFI。现在根据之前收集的反馈再做收尾工作，也在开放以太坊的客户端做优化的工作。

下一个是EIP-2718。James说我们还没有机会深入讨论这个EIP，这次轻客户端的人也没有参加这次会议，所以也没有人来回答关于这个EIP的技术问题。但Piper说他可以帮助回答。Peter回答说对于这个EIP,他担忧的和上次的抽象账户的EIP一样。如果有好的理由，他同意有多种类型的交易。但他希望先引入一个新的交易，再引入一种交易形式，这样避免只引入抽象概念，而不知道如何去实际操作。Piper说EIP-2718实际是从EIP-2711分离出来的，之前已经实现了EIP-2718建议的的三种新交易类型的一种，赠与交易类型。
https://eips.ethereum.org/EIPS/eip-2718
https://eips.ethereum.org/EIPS/eip-2711

对于EIP-2718进入EIP，James询问每个客户端有没有反对意见？大家都表示赞同，James正式宣布EIP-2718进入EFI。

Alex说希望在探讨一下上次会议的提到的一个问题。他说Alexey前面提到矿工需要40ms来组装一个区块才能保持盈利。同时对于EIP-2537，他花了挺多时间来做状态测试，但是他发现这个状态测试的工具很难用。所以能否讨论一下这个工具。 Martin说非常同意，这个工具难用已经有一段时间了，但是我们并没有很好的应对。但同时我们也一直在修改这个测试工具了，我们希望找到一个人能够来负责这个事情。James提到他本人和Martin都说了一年了还没进展。因为时间关系，Alex最后和Martin决定会后继续讨论下测试工具的完善优化问题。

James宣布会议结束。

与会开发者：
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