原标题：Possible futures of the Ethereum protocol, part 1: The Merge
最初，“合并”（The Merge）指的是以太坊协议自推出以来最重要的事件：期待已久、来之不易的从工PoW证明到PoS的过渡。如今，以太坊已经稳定运行了近两年，并且这种PoS在稳定性、性能和避免中心化风险方面表现非常出色。然而，PoS仍有一些重要领域需要改进。
我在2023年绘制的路线图将其分为几部分：改进技术特性，例如稳定性、性能和对小型验证者的可访问性，以及经济学变革以应对中心化风险。前者成为“The Merge”部分，而后者成为“the Scourge”的一部分。
这篇文章将重点关注“The Merge”部分：权益证明（PoS）的技术设计还有哪些可以改进，以及实现这些改进的途径有哪些？
这并不是一份可以对权PoS做的事情的详尽清单；相反，这是一份正在积极考虑的想法清单。
单Slot最终确定性（Single Slot Finality，SSF）和质押民主化
我们正在解决什么问题？
目前，以太坊需要 2-3 个 epoch（约 15 分钟）才能最终确定一个区块，并且需要 32 ETH 才能成为质押者。
这最初是为了在下面三个目标之间取得平衡而做出的妥协：
最大化参与质押的验证者数量（这直接意味着最小化质押所需的最小 ETH数量）
最小化最终确定时间
最小化运行节点的开销
这三个目标是相互冲突的：为了实现“经济上的最终确定性”（economic finality，即攻击者需要销毁大量 ETH 才能恢复最终确定的区块），每次最终确定时，每个验证者都需要签署两条消息。因此，如果你有许多验证者，要么需要很长时间来处理所有签名，要么需要非常强大的节点来同时处理所有签名。
请注意，这一切都取决于以太坊的一个关键目标：确保即使成功的攻击也会对攻击者造成高昂的成本。这就是“经济上的最终确定性”一词的含义。如果我们没有这个目标，那么我们可以通过随机选择一个委员会（例如Algorand 所做的）来最终确定每个slot来解决这个问题。但这种方法的问题在于，如果攻击者确实控制了 51% 的验证者，那么他们可以以非常低的成本进行攻击（撤销最终确定的区块、审查或延迟最终确定）：只有委员会中的那部分节点可以被检测为参与攻击并受到惩罚，无论是通过slash还是少数派软分叉。这意味着攻击者可以多次反复攻击该链。因此，如果我们想要经济上的最终确定性，那么简单的基于委员会的方法是行不通的，乍一看，我们确实需要验证者全集体参与。
理想情况下，我们希望保留经济上的最终确定性，同时在两个领域改善现状：
1、在一个 slot 内完成区块（理想情况下，保持甚至减少当前 12 秒的长度），而不是 15 分钟
2、允许验证者质押 1 ETH（原先为 32 ETH）
第一个目标的合理性来自两个目标，这两个目标都可以看作是“使以太坊的属性与（更中心化的）注重性能的 L1 链的属性保持一致”。
首先，它确保所有以太坊用户都能从通过最终确定机制实现的更高级别的安全保证中受益。如今，大多数用户都无法享受这种保障，因为他们不愿意等待 15 分钟；而使用单slot最终确定机制，用户几乎可以在确认交易后立即看到交易最终确定。其次，如果用户和应用程序不必担心链回滚的可能性（除非出现相对罕见的不活动泄漏-inactivity leak），那么它就简化了协议和围绕它的基础设施。
第二个目标是出于支持solo质押者的愿望。一次又一次的民意调查反复表明，阻止更多人solo质押的主要因素是 32 ETH 的最低限额。将最低限额降低到 1 ETH 将解决这个问题，以至于其他问题成为限制solo质押的主要因素。
存在一个挑战：更快的确定性和更民主化的质押目标都与最小化开销的目标相冲突。事实上，这个事实就是我们一开始不采用单slot最终确定性的全部原因。然而，最近的研究提出了一些解决这个问题的可能方法。
SSF是什么以及它是如何工作的？
单slot最终确定性涉及使用在一个slot内最终确定区块的共识算法。这本身并不是一个难以实现的目标：许多算法（例如Tendermint 共识）已经以最佳属性实现了这一点。以太坊独有的一项理想属性是“不活动泄漏inactivity leak”，Tendermint 不支持该属性，即使超过 1/3 的验证者离线，该属性也允许链继续运行并最终恢复。幸运的是，这个愿望已经得到解决：已经有提案修改 Tendermint 式共识以适应inactivity leak。
领先的单slot最终确定性提案
问题最难的部分是弄清楚如何使单slot最终确定性在验证者数量非常高的情况下发挥作用，而不会导致极高的节点运营商开销。为此，有几种领先的解决方案：
选项 1：蛮力——努力实现更好的签名聚合协议，可能使用 ZK-SNARKs，这实际上允许我们在每个slot中处理来自数百万个验证者的签名。
Horn，为更好的聚合协议而提出的设计之一。
选项 2：Orbit 委员会- 一种新机制，允许随机选择的中型委员会负责完成链，但以保留我们所寻求的攻击成本特性的方式。思考 Orbit SSF 的一种方式是，它开辟了一个妥协选项空间，范围从 x=0（Algorand 风格的委员会，没有经济是哪个的最终确定性）到 x=1（以太坊现状），开辟了中间点，在这些点上以太坊仍然具有足够的经济上的最终确定性以确保极其安全，但同时我们获得了只需要中等规模的验证者随机样本参与每个slot的效率优势。
Orbit 利用验证者存款规模中预先存在的异质性来获得尽可能多的经济上的最终确定性，同时仍将给予solo验证者相应的角色。此外，Orbit 使用缓慢的委员会轮换来确保相邻法定人数之间的高度重叠，从而确保其经济上的最终确定性仍然适用于委员会轮换边界。
选项 3：两层质押- 一种机制，其中质押者分为两类，一类的存款要求较高，另一类的存款要求较低。只有存款要求较高的层级会直接参与提供经济上的最终确定性。有各种提案（例如，参见Rainbow质押文章）来具体说明存款要求较低的层级拥有哪些权利和责任。常见想法包括：
将委托质押的权利给更高层级的质押者
随机抽取较低层级的质押者来证明并最终确定每个区块
生成包含名单（inclusion lists）的权利
与现有研究有哪些联系？
实现单slot最终确定性的途径（2022 年）：https://notes.ethereum.org/@vbuterin/single_slot_finality
以太坊单slot最终确定性协议的具体提案（2023 年）：https://eprint.iacr.org/2023/280
Orbit SSF：https://ethresear.ch/t/orbit-ssf-solo-staking-friendly-validator-set-management-for-ssf/19928
对 Orbit 风格机制的进一步分析：https://notes.ethereum.org/@anderselowsson/Vorbit_SSF
Horn，签名聚合协议（2022 年）：https://ethresear.ch/t/horn-collecting-signatures-for-faster-finality/14219
大规模共识的签名合并（2023 年）：https://ethresear.ch/t/signature-merging-for-large-scale-consensus/17386?u=asn
Khovratovich等人提出的签名聚合协议：https://hackmd.io/@7dpNYqjKQGeYC7wMlPxHtQ/BykM3ggu0#/
基于 STARK 的签名聚合（2022 年）：https://hackmd.io/@vbuterin/stark_aggregation
Rainbow质押：https://ethresear.ch/t/unbundling-staking-towards-rainbow-staking/18683
还剩下什么要做？需要权衡什么？
有四种主要的可能路径可供选择（我们也可以采取混合路径）：
1、维持现状
2、Orbit SSF
3、蛮力SSF
4、具有两层质押机制的 SSF
1意味着不做任何工作并保持原样，但这会使以太坊的安全体验和质押中心化属性变得比本来应该的更糟糕。
2避免“高科技”，通过巧妙地重新思考协议假设来解决问题：我们放宽了“经济上的最终确定性”的要求，这样我们就要求攻击是昂贵的，但攻击成本可能比现在低 10 倍（例如，攻击成本为 25 亿美元，而不是 250 亿美元）。人们普遍认为，以太坊如今的经济上的最终确定性远远超出了它所需要的水平，它的主要安全风险在其他地方，所以可以说这是可以接受的牺牲。
主要工作是验证 Orbit 机制是否安全并具有我们想要的属性，然后对其进行完全形式化和实施。此外，EIP-7251（增加最大有效余额）允许自愿验证者余额合并，这会立即减少链验证开销，并作为 Orbit 推出的有效初始阶段。
3避免巧妙的重新思考，而是用高科技强行解决问题。要做到这一点需要在很短的时间内（5-10 秒）收集大量签名（100 万以上）。
4避免了巧妙的重新思考和高科技，但它确实创造了一个两层的质押系统，仍然具有中心化风险。风险在很大程度上取决于较低质押层获得的特定权利。例如：
如果低层级质押者需要将其证明权委托给高级质押者，那么委托可能会中心化化，最终我们会得到两个高度集中的质押层级。
如果需要对较低层进行随机抽样来批准每个区块，那么攻击者只需花费极少量的 ETH 即可阻止最终确定性。
如果较低级别的质押者只能制作包含列表，那么证明层可能会保持中心化，此时对证明层的 51% 攻击可以审查包含列表本身。
可以组合多种策略，例如：
1 + 2：添加 Orbit，但不执行单slot最终性
1 + 3：使用强力技术减少最小存款额，而无需进行单slot最终确定。所需的聚合量比纯 (3) 情况少 64 倍，因此问题变得更容易。
2 + 3：使用保守参数执行 Orbit SSF（例如，128k 验证者委员会而不是 8k 或 32k），并使用蛮力技术使其超高效。
1 + 4：添加Rainbow质押，但不进行单slot最终确认
SSF如何与路线图的其他部分互动？
除了其他好处之外，单slot最终确定性还降低了某些类型的多块 MEV 攻击的风险。此外，在单slot最终确定性世界中，证明者-提议者分离设计和其他协议内块生产管道需要以不同的方式设计。
蛮力策略的弱点在于它们使得减少slot时间变得更加困难。
单一秘密领导人选举（Single secret leader election，SSLE）
我们正在解决什么问题？
如今，哪个验证者将提出下一个区块是可以提前知道的。这会产生一个安全漏洞：攻击者可以监视网络，确定哪些验证者对应哪些 IP 地址，并在验证者即将提出区块时对其发起 DoS 攻击。
SSLE是什么以及它是如何工作的？
解决 DoS 问题的最佳方法是隐藏哪个验证者将生成下一个区块的信息，至少在区块实际生成之前。请注意，如果我们删除“单一”要求，这很容易：一种解决方案是让任何人都可以创建下一个区块，但要求randao 揭示小于 2256/ N。平均而言，只有一个验证者能够满足此要求 - 但有时会有两个或更多，有时会没有。将“秘密”要求与“单一”要求结合起来一直是一个难题。
单一秘密领导者选举协议通过使用一些加密技术为每个验证者创建一个“盲”验证者 ID，然后让许多提议者有机会对盲 ID 池进行改组和重新盲化（这类似于mixnet的工作方式），从而解决了这个问题。在每个时段内，都会选择一个随机的盲 ID。只有该盲 ID 的所有者才能生成有效的证明来提议区块，但没有人知道该盲 ID 对应的是哪个验证者。
Whisk SSLE 协议
与现有研究有哪些联系？
Dan Boneh 的论文（2020）：https://eprint.iacr.org/2020/025.pdf
Whisk（以太坊具体提案，2022 年）：https://ethresear.ch/t/whisk-a-practical-shuffle-based-ssle-protocol-for-ethereum/11763
ethresear.ch 上的单一秘密领导人选举标签：https://ethresear.ch/tag/single-secret-leader-election
使用环签名的简化 SSLE：https://ethresear.ch/t/simplified-ssle/12315
还剩下什么要做？需要权衡什么？
实际上，剩下的就是找到并实现一个足够简单的协议，以便我们可以轻松地在主网上实现它。我们非常重视以太坊是一个相当简单的协议，我们不希望复杂性进一步增加。我们看到的 SSLE 实现增加了数百行规范代码，并在复杂的加密中引入了新的假设。找出一个足够有效的抗量子 SSLE 实现也是一个悬而未决的问题。
最终可能会出现这样的情况：只有当我们出于其他原因（例如状态树、ZK-EVM）大胆尝试并在 L1 的以太坊协议中引入执行通用零知识证明的机制时，SSLE 的“边际额外复杂性”才会下降到足够低的水平。
另一种选择是根本不理会 SSLE，而是使用协议外缓解措施（例如在 p2p 层）来解决 DoS 问题。
它如何与路线图的其他部分互动？
如果我们添加证明者-提议者分离 (attester-proposer separation，APS) 机制，例如执行票（execution tickets），那么执行区块（即包含以太坊交易的区块）将不需要 SSLE，因为我们可以依赖专门的区块构建者。但是，对于共识区块（即包含协议消息例如证明、可能包含列表的部分等的区块），我们仍将受益于 SSLE。
更快的交易确认
我们正在解决什么问题？
以太坊的交易确认时间进一步缩短是有价值的，从 12 秒缩短到 4 秒。这样做将显著改善 L1 和基于 rollups 的用户体验，同时使DeFi协议更加高效。它还将使 L2 更容易去中心化，因为它将允许大量 L2 应用程序在基于 rollups上工作，从而减少 L2 构建自己的基于委员会的去中心化排序的需求。
更快的交易确认是什么以及它是如何工作的？
这里大致有两种技术：
1、减少slot时间，例如减少到8 秒或 4 秒。这并不一定意味着 4 秒的最终确定性：最终确定性本身需要三轮通信，因此我们可以将每轮通信设为一个单独的区块，这将在 4 秒后至少获得初步确认。
2、允许提议者在 slot 期间发布预确认。在极端情况下，提议者可以实时将他们看到的交易包含在其区块，并立即为每笔交易发布预确认消息（“我的第一笔交易是 0×1234...”、“我的第二笔交易是 0×5678...”）。提议者发布两个相互冲突的确认的情况可以通过两种方式处理：（i）惩罚提议者，或（ii）使用见证者投票决定哪一个更早。
与现有研究有哪些联系？
基于预先确认：https ://ethresear.ch/t/based-preconfirmations/17353
协议强制提议者承诺 (PEPC)：https://ethresear.ch/t/unbundling-pbs-towards-protocol-enforced-proposer-commitments-pepc/13879
并行链上的交错周期（2018 年实现低延迟的想法）：https://ethresear.ch/t/staggered-periods/1793
还剩下什么要做？需要权衡什么？
目前还不清楚缩短slot时间的可行性。即使在今天，世界上许多地区的质押者也很难以足够快的速度获得证明。尝试 4 秒的slot时间存在使验证者集中心化的风险，并且由于延迟，在少数特权地区之外成为验证者是不切实际的。
提议者预先确认方法的弱点在于它可以大大改善平均情况的包含时间，但不能改善最坏情况：如果当前提议者运行良好，你的交易将在 0.5 秒内得到预先确认，而不是（平均）6 秒内被包含，但如果当前提议者离线或运行不佳，你仍然需要等待整整 12 秒才能开始下一个时段并提供新的提议者。
此外，还有一个悬而未决的问题，即如何激励预确认。提议者有动机尽可能长时间地最大化他们的可选性。如果见证人签署预确认的及时性，那么交易发送者可以将部分费用以立即预确认为条件，但这会给见证人带来额外的负担，并可能使见证人更难继续充当中立的“哑管道（dumb pipe）”。
另一方面，如果我们不尝试这样做，并将最终确定时间保持在 12 秒（或更长时间），生态系统将更加重视 2 层的预先确认机制，并且跨 2 层的交互将需要更长的时间。
它如何与路线图的其他部分互动？
基于提议者的预确认实际上依赖于证明者-提议者分离 (APS) 机制，例如执行票。否则，对于常规验证者来说，提供实时预确认的压力可能过于集中。
其他研究领域
51%攻击恢复
人们通常认为，如果发生 51% 攻击（包括无法通过加密证明的攻击，例如审查制度），社区将齐心协力实施少数派软分叉，确保好人获胜，坏人则inactivity-leaked或被削减。然而，这种程度的过度依赖社交层可以说是不健康的。我们可以尝试通过使恢复过程尽可能自动化来减少对社交层的依赖。
完全自动化是不可能的，因为如果完全自动化，那就相当于一个容错率 >50% 的共识算法，而且我们已经知道这类算法的（非常严格的）数学可证明的局限性。但我们可以实现部分自动化：例如，如果客户端审查了它已经看到很长时间的交易，它就可以自动拒绝接受一条链作为最终确定的甚至拒绝接受它作为分叉选择的头部。一个关键目标是确保攻击者至少不能快速获得彻底的胜利。
提高Quorum门槛
如今，只要有67%的质押者支持（译者注：Quorum机制是一种分布式系统中常用的用来保证数据冗余和最终一致性的投票算法），区块就会最终确定。有人认为这种做法过于激进。在以太坊的整个历史上，只有一次（非常短暂的）最终确定性失败。如果将这一比例提高到80%，那么增加的非最终确定性时期数量将相对较低，但以太坊将获得安全性：特别是，许多更具争议的情况将导致最终确定性的暂时停止。这似乎是一种比“错误的一方”立即获胜更健康的情况，无论是错误的一方是攻击者，还是客户端有错误。
这也回答了“单独质押者的意义何在”这个问题。如今，大多数质押者已经通过质押池进行质押，让单独质押者质押 ETH 达到 51% 的可能性似乎很小。但是，如果我们努力的话，让单独质押者达到quorum-blocking minority，特别是如果Quorum为80%（因此quorum-blocking minority只需要 21%）似乎是有可能实现的。只要单独质押者不参与 51% 攻击（无论是最终确定性逆转还是审查制度），这种攻击就不会获得“干净利落的胜利”，并且单独质押者会有动力帮助组织少数派软分叉。
抗量子性
Metaculus目前认为，尽管误差很大，但量子计算机可能会在 2030 年代的某个时候开始破解密码学：
量子计算专家，例如 Scott Aaronson，最近也开始更加认真地考虑量子计算机在中期内实际工作的可能性。这将对整个以太坊路线图产生影响：这意味着目前依赖于椭圆曲线的每个以太坊协议部分都需要某种基于哈希或其他抗量子性的替代方案。这特别意味着我们不能假设我们将能够永远依靠BLS 聚合的优异性能来处理来自大型验证者集的签名。这证明了在权益证明设计性能假设方面的保守性是合理的，也是更积极地开发抗量子替代方案的原因。
特别感谢Justin Drake、Hsiao-wei Wang、@antonttc和Francesco的反馈和审查。
