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

会议日期：2020年8月7日

会议时长：1.5小时

会议视频链接：

https://www.youtube.com/watch?v=Riu-PqrJVH4

会议议程：

1.以太经典链的分离

2.YOLO/YOLOv2和柏林测试更新

3.EIP讨论

3a:EIP-2046的后续工作和EIP-2666预编译器重新定价以及给384比特模块的实验讨论

3b:EIP-2780:减少交易固有的gas成本

4.交易选择在客户端是如何发生的

5.再生计划

6.更改ACD聊天的软件

会议主要内容：

1.会议开始，主持人Hudson欢迎大家的到来。他开始第一个议题，以太经典链的分裂。

他请Wei从技术层面来解释以太经典链的分离和51%攻击。Wei说他主要集中在技术层面的分析。51%攻击发生了两次。因为开放以太坊（OE）和Geth有个分裂,所以第一次攻击部分被捕捉到了。但开始的时候ETC团队以为是个程序错误，于是叫所有人都切换到Geth客户端上去。随后就发现这是一次攻击。这时候就有了一个攻击链和普通的矿工链。OE有比较低的重组（reorg）值，所以他们拒绝了攻击链，而相反的Geth节点马上重组了攻击链。因为攻击链有一个比较高的困难度，所以导致ETC节点有一个小的拆分。Wei表示如果网络最大重组值降低，那么攻击会发生的完全不同，同时攻击的奖励也会丢失。

第二次51%攻击发生在ETC团队叫大家移除OE矿工，然后大家立刻照做的时候。接着ETC团队企图为大家做一个白名单去忽略攻击链，但是因为重组已经发生了，已经没有机会去做这个措施，于是两次攻击都成功地实施了。

Wei认为值得讨论一下是否需要统一不同数值的最大重组值。因为可以用一个比较低的最大重组值来抵抗简单的51%攻击，从而忽略攻击链。James问道是否需要设置一个最大的重组值和一个标准的重组值？Wei回答说从这次的攻击看出来，我们应该给大部分的客户端设置一个默认的最大重组标准。

Peter表示在Geth里面标准的值是3个时段（epoch），就是9万个区块。原因是3个时段是大约两周时间。根据过去的经验，两周的时间可以解决掉因为链重组出现的问题。Martin表示还要注意的是，如果客户端开始引入短的重组值，但如果这个不改变客户端去做一个往后的同步动作和选择难度最大的节点，这样也会同步到错误的链上面去。如果这个不实施，那后面就会很乱，尤其是当客户端再次同步时候，会乱的一塌糊涂。

Wei说这个主要是看攻击的场景中是否所有的节点都能快速反应。如果最大重组值低，那么短期会有一个时段让矿工无法上难度最大的链，而在攻击结束后正常链会马上恢复链的难度，最后超过攻击链成为难度最大的链。所以还是一个如何保持平衡的问题。Alexey说还可能存在一个问题，他举例说在Bitcoin Cash尝试过增加检查点的机制。大概是每十个区块加入一个检查点。但是随后的安全性分析表明这种增加检查点的链在防止重组机会的同时，也会造成另一次攻击的机会，最后可能导致攻击者获得不同的节点和不同的区块的检查点，等到攻击过去后就无法再同步了。Wei澄清道51%攻击是无法被修复的，只能讨论如何减少发生的可能性和做到损失的最小化。

Peter表示攻击本质上还是ETC的安全性被破坏，攻击者可以要求矿工在比正常链难度高的链上面挖矿。我们现在讨论的是如何减少损失和破坏，但最本质的破坏还是攻击者能够随时选择在哪一个链上发动攻击并一直存在于网络中。对于这个本质问题，我们能够做点什么？

Tim表示赞同，并认为这个不是在客户端能够解决的事情。如何防止攻击再次发生看上去比实施何种客户端更加重要。Hudson询问是否有人认为这是需要在客户端层面解决的？大家默许认为这不是客户端层面能够完全解决的。James提议是否就延迟63个时间段的区块达成一致？随后Hudson，Alexey和Tim等又有一些讨论，他们认为不应该如此匆忙的下结论，还是需要在不同的情况下做了实验，拿到一点数据后才能定论。

Martin补充说上层应用受影响最多的就是交易所了，大多数的DeFi协议等。但是不能只依靠于底层稳固，不会重组这个前提，上层也需要健全自己的系统，最好能多到即便底层重组了也能够上层稳定。所以他认为Layer2需要更稳定。Peter表示赞同，同时也从用户体验的角度提出问题。在现在的分布式交易系统中，整个交易的体验太慢。用户希望在几分钟内完成一个交易，但是现在重组极限是200到500个区块，对应着是以小时计算的时间间隔。

随后大家又有一些讨论，结论是现在可以充分讨论，但是不能做任何决定。Peter建议让Etherscan把一些数据，比如掉的区块个数，掉链次数和链长度等，加入到他们的表格中，先记录下来。

2.Hudson开始第二个议题，YOLO/YOLOv2和柏林测试更新。James表示整个7月都暂停了，他希望每个团队都能更新一下。Martin说他没有更新，但是他认同应该有YOLOv2. Tim询问YOLOv2是否会有新的EIP，还是用和v1一样的？Hudson说先用一样的，如果有需要再增加，以后他猜想是否还会有v3。

Martin表示如果用一样的EIP，那么还是应该叫v1. Tim说他这么问是因为他记得之前有会议提到有一组gas成本数据是需要再后续的YOLO中使用的。Hudson说这个应该是EIP-2046里面的，正好在下一个议题可以讨论。

3.Hudson开始第三个EIP讨论的议题。

首先是EIP-2046的后续工作和EIP-2666预编译器重新定价。Alex首先发言，他说之前柏林的研发有个停顿，这正好给了一个时间窗口来测试具体的EIP-2046和部分EIP-2666的数据。他想知道客户端开发者有没有基准测试或者一些数据？Martin询问Alex提供过部分预编译器的基准测试数据，但不是全部的，现在是否有全部的数据了？

Alex回答说没有包括Modex的预编译器，但基本上每个价格可能不准确的预编译器都测试了。他看见Nethermind做了基准测试，但还没有看到具体数字。他说他也知道Geth和Besu都想提高性能，但可能还没有机会执行运算。总之他最感兴趣的还是测试得到的数字。比如，Alex说到，在EIP-2666里面就需要把数字再提高一些去匹配所有客户端的性能。现在只匹配了Geth和OE，而且还是他自己独立完成的。EIP-2666是一个超级大的汇总，还包括了预编译器不同的错误应对方式。这个主题其实应该是一个单独的，可以放在后续讨论的主题。但是要推动EIP-2046和一些预编译器的价格调整，他仍然需要客户端开发者提供数据。Martin表示困惑，他认为Alex只需要知道重要客户端开发者表示赞同或者不赞同就好了。

Alex说是否他就把所有价格先调高比方说25%来应对所有的客户端，然后让每个客户端再针对自己的性能进行优化？Martin说Geth现在性能不错，但是实际预编译器的价格基准比较还没有进行。Alex也说他不担心Geth和OE，但是他对其他客户端没有经验。Tim说Besu团队为2046做了基准测试，价格100比较合适，40稍微低了点，但是并没有做EIP-2666的基准测试。

Alex表示现在最重要的还是要拿到数据。因为一个潜在的问题是预编译器的价格里面可能包含一个大的固定成本，并且这个成本现在被静态调用的价格给遮挡住了。如果是这样会极大的影响到现在的价格设置。所以Alex需要基准测试数据来判断，然后下一次会议时候就可以为EIP-2046给出推荐的预编译器成本数值或者另外准备一个EIP单独来调整所有预编译器的价格。Hudson问是否确定下一次就可以给出数值？Alex认为这取决于拿到基准测试数据的情况。Besu表示下次会议肯定可以提供。Nethermind的数据Alex自己会在查询下。

Hudson开始下一个关于EIP-2780，即减少交易固有的gas成本的讨论。Uri介绍说Matt创建了EIP-2780，他们希望这个EIP至少做到把交易的gas成本从21k下降到7k，因为他们认为现在转移以太币的成本比较高，在面对DeFi带来的时间敏感和大额交易量的交易竞争时候没有优势。现在很多有价值的交易在区块链上发生，这个是很好的结果，因为这就是他们设计的原因之一。但如果能够允许更多交易发生在链上，又不让成本增加太多，这样就更好。所以Uri表示他想认真审查一遍这些想法的实施，看看哪些地方会有问题，哪些是核心开发者可以帮助改进的。

现在主要的顾虑是在区块链的状态大小的影响上，这其实已经是一个问题了。一方面如果我们继续允许状态大小继续增加，这就会产生问题。另一方面如果继续允许gas来更多的操控价格，包括Vitalik提出的叔块率，也会产生问题。Martin提出在EIP里面，提到每创建一个账户会在链状态上增加20比特大小，这是非常错误的。Uri解释说这是一个错误，应该是大约20KB左右。Martin还提出在EIP里面把交易的次数算的不太准确，这样导致低估了安全性和外接延展性的考虑。

Uri继续表示他大体上同意Martin的看法。当我们说大小增加时，是指它们变得字节数增大，而且预估的增加三倍的交易会带来什么样的影响，所有这些都需要看清楚。另一个需要补充的方面是使用量与潜在攻击的问题。如果使用量因此更改而增加，那么这会造成怎样的影响。例如，I/O负载，然后还有一个问题，即是否可以利用此更改进行攻击。关于这次攻击，Uri的主要论点是今天能发动这次袭击吗？它可能是一年前推出的吗？进行这样的攻击会付出什么代价？EIP本身应进一步概述这一点。

Uri说如果有人利用这个新的向量，用许多小的交易攻击块，那么现在使用DeFi会花费多少钱，以及它以前的成本是多少？我想我和Peter在Twitter上有一些分歧，是否应该只考虑攻击向量是否可能，或者是否应该将其成本也纳入讨论。最后Uri询问大家这逻辑是否成立？

Alexey说我们也许可以在不同的时间讨论这个特别的提议的特殊性，但我们本质上都有这个危机时刻，有很多与核心基础设施有关的外部扩展，我将把网络视为核心和边界。边界定义就是交易的来源，它们就是DeFi网站所在的地方。核心实质上是传输事务的节点。边界是创造和获取价值的地方，核心是为边界服务的东西。

但不幸的是，Alexey继续说到，我们已经创建了一个系统，在这个系统中，边界将其成本外部化到核心，这也是它能够捕获价值的原因之一。我们需要解决这一问题，努力降低外部扩展性，使边界参与者承担更高的成本，核心基础设施成本更低。如果我们降低成本，可能会带来更多用户，但也会使危机恶化，以至于我们将被这些外部性所削弱。我们知道网络容易受到各种DOS攻击，所以我的意见是我们需要暂时退一步。在我们没有明确的解决办法之前，我们不应让它变得更糟。

James表示我们有时候还不清楚一个改动发生之后可能带来的后果，这些改动都没有回退键，所以他个人的意见还是偏保守一些。

Uri表示他完全同意James，Alexey等提出的想法，所以他才说确实想讨论状态大小、gas代币和叔块率。Uri认为如果我们这样做，将降低3倍交易的成本，并且状态大小是一个无论如何都需要解决的主要问题。但是即使我们这样做了，真的降低了交易的成本，结果表明它将使增长率提高约1%。所以假设如果我们在2020年1月这样做的话，在过去的8个月里，状态大小将增加0.5%。

但是Peter质疑EIP里面数字的准确度。Uri也承认数字有缺陷并会再次检查。后面又有一些关于数字和动机的讨论。最后Hudson总结说时间关系不能继续争论下去了，但他建议首先需要把EIP中使用的数字确认好，其次是关于改变后风险的把控。Uri感谢大家的意见。

https://ethereum-magicians.org/t/eip-2780-reduce-intrinsic-cost-of-transactions/4413

4.Hudson开始下一个议题，讨论交易选择在客户端是如何发生的。Peter发言说，讨论这个的动机是为了减少主网上的堵塞。他介绍在Geth他们按照先进先出的原则，如果多个交易有相同的价钱，那么它们会按照到达的时间顺序排列。Geth很快就会发布这个新版本，然后就测试，想知道到底能不能帮助减轻主网负担。

Hudson问到是否剩下的客户端有计划实施这个方案？Artem表示他们没有这个计划，Alexey说OE已经实施了这个逻辑在代码里面。Besu的Tim表示暂时没有计划，也想看看Geth实施后的结果。Paul询问是否共识就是如果多个交易价格相同，是否就按照FIFO的顺序排列？

Peter回应说其实只要能够确定顺序，用任何办法都可以。之前还有两种排序方法的提议。一种是按照交易的哈希值，一种是按照账户哈希值或者地址。后者有可能会给矿工来挖账户。Peter表示他个人认为这两种方法不好，所以Geth还是选择了FIFO。

James询问Geth下周发布后哪里可以看到效果？Peter说他也不清楚，但是长期来看，只有当多次发送交易请求没有意义的时候，或者说只有当用户认为只要发送一次交易，多发送交易反而会亏钱的时候，这个交易次数才会下降，从而导致gas价格的下降。所以长期如果有效果，应该能看到gas价格的下降。

5.Hudson开始第五个议题，再生计划。Alexey介绍说他最近写了《再生计划》，这是一个关于我们如何实现这一目标的更详细的计划。本质上，我们逻辑上把状态分成两个不相交的部分，我们称之为一个活动状态和另一个非活动状态。我们没有改变状态的默克尔树计算方式，所以我们保留了现有的状态计算方法，只是引入了这种逻辑区别。然后我们介绍了再生事件的概念，它们会定期发生，可能是预先安排的时间，也可能是由人工决定的，例如，一百万个区块，大约六个月时间，接着发生的是，活动状态被重置为只有哈希计算的状态，其余的东西都变为非活动状态。在这两个再生事件之间，或者在这个例子中的六个月期间，游戏规则以四种不同的方式改变。交易转换需要一个额外的属性，一个证明，实质上它是一个包含一些默克尔多重证明的字节串。

Alexey说他不打算详细介绍它是如何工作的，但他已经仔细考虑过了。当交易执行时，我们会找到证明的任何有效部分，并激活证明中显示的那些部分，并使它们成为活动状态的一部分。接着需要一个很小的区块见证者，它被介绍给矿工来证明他们的货币基础（coinbase），它被附加到区块上，否则他们就得不到奖励。如果货币基础还没有处于活动状态，他们应该将它包含在见证中，并且在任何事务之前，这个块见证需要被添加到活动状态。

Alexey继续说我们在硬分叉版本中收费，我们需要硬分叉的唯一一件事就是将这个交易证明作为收费数据包含进来。之前只能收数据费，现在还能收证人费。好在与无状态的以太坊设计相比，我们不必知道如何在多个发送者之间分摊费用，因为它只由一个发送者发送。

Alexey说还有一个建议，改变链ID，这样在再生之后，任何不使它失败的东西都不会失败，但需要重新提交。这个提议的好处是，如果我们适当地调节再生事件，比如说我们以一个活动状态大小为目标，那么现代的机器可以以非常低的延迟存储在RAM或设备中，这样就可以很容易地获得它，这意味着所有的状态访问操作，如sload平衡和sload 哈希都只是从RAM读取的，而不必一直调整它们的成本。

Alexey继续介绍到，对于交易发送者来说，这意味着他们需要获取状态的快照，而不是活动状态，获取最新的再生事件的快照，这应该足以生成有效的交易，但是如果他们想最小化证明，则需要一个更新的快照，费用由他们承担。这是这种再生的一个更具哲理性的考虑，它将成本从核心推到边界，与现状的主要区别在于，优化失败不再成为这一系统性问题。目前，几乎所有的优化都必须在核心进行，如果我们不能持续优化，就会带来系统性风险，网络可能会失败。再生优化必须发生在边界上，因为边界更为多样，周围有更多的资金，因此不存在相同的系统性风险，如果一个运营商落后，会造成伤害，但不会损害整个网络。

Alexey说我不打算详细讨论我们如何推出它，那将是一个非常技术性的讨论，我想邀请大家参加Eth研发Discord，有一个特别的再生频道。同时我在Twitter上发布了一个关于我们如何可能过渡到这个东西的HTML文件，所以Alexey邀请大家阅读，以便大家可以获得更多的技术讨论。

Hudson说很多讨论在Discord上进行。Martin询问这次的交易是否需要之前再生数据？Alexey回答说不需要，只需要上一次的再生时间的数据。随后James，Paul还有Alexey还有一些技术上的讨论，James最后总结说他们会在Eth1.0无状态会议中详细讨论这个事情，会把结论放到核心开发者聊天室去。

https://ledgerwatch.github.io/regenesis_plan.html

6.Hudson开始下一个议题，更改ACD软件的讨论。Hudson说之前在Core Devs聊天室活跃的用户现在在Eth R&D Discord活跃。他考虑叫人们从Gitter转移到Discord频道上去聊天，这样我们就有两个渠道可以聊天。所以想询问大家意见如何转移？接着James，Martin等有一些Gitter和Discord聊天工具功能上的讨论，比如查看历史记录，比如删除消息，比如如何在频道外分享已经聊天的内容等。Wei又介绍到Matrix的用户体验也很流畅，建议大家体验。Hudson最后表示他会和Discord询问一下有关聊天工具的功能提供，下次会议时再和大家交流。

7.Hudson感谢大家的参与，他宣布会议结束。

与会开发者：

Alex (axic)

Alex Vlasov

Alexey Akhunov

Artem Vorotnikov

Hudson Jameson

James Hancock

Karim Taam

lightclient

Martin Holst Swende

Peter Szilagyi

Pawel Bylica

Pooja Ranjan

Rai

Tim Beiko

Uri Klarman

Vie Yang

Wei Tang

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

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

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

以太坊：

0x7Ba18D8d4B0E4EB06a720aF2BeC29603078c806b

Gitcoin:

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