Vitalik 新作：如何缩短以太坊的交易确认时间？

原文作者：Vitalik Buterin，以太坊联合创始人

原文编译：Luffy，Foresight News

区块链良好用户体验的一个必不可少的特性是快速的交易确认时间。如今的以太坊与五年前相比已经有了很大的进步，这得益于 EIP -1559 和 PoS 合并之后稳定的出块时间，用户在 L1 上发送的交易可以在 5-20 秒内得到可靠的确认，已经接近信用卡支付的使用体验。然而，以太坊的用户体验仍需要进一步的改善，因为有些应用程序确实需要数百毫秒甚至更短的交易延迟。这篇文章将介绍加快以太坊交易确认时间的一些实用方案。

现有的想法和技术概述

单 slot 最终性

现在以太坊的 Gasper共识采用 slot 和 epoch 架构。每隔 12 秒（单个 slot 的时长），验证者子集会在区块链的最新区块上发布投票，在 32 个 slot（6.4 分钟，一个 epoch 包含 32 个 slot）内，所有验证者都有机会投票一次。然后，这些投票被重新解释为类似于 PBFT 的共识算法中的消息，该算法在两个 epoch（12.8 分钟）后提供非常严格的经济保证，这就是最终性。

过去几年，我们对这种方法越来越不满意。主要原因是：（i）它很复杂，逐个 slot 投票机制和逐个 epoch 最终性机制之间存在许多交互错误；（ii）12.8 分钟太长了，没人愿意等那么久。

单 slot 最终性（single slot finality，SSF）用一种与 Tendermint 共识相似的机制取代了这种架构，在该机制中，区块 N 在区块 N+1 生成之前已经完成。与 Tendermint 的主要不同之处在于我们保留了「非活跃泄漏（inactivity leak）」机制，这种机制允许区块链在超过 1/3 的验证者离线时继续运行并恢复。

SSF 的主要挑战在于，它似乎暗示者每个以太坊质押者都需要每 12 秒发布两条消息，这对区块链来说是一个很大的负担。有一些巧妙的想法可以缓解这种情况，包括最近的 Orbit SSF 提案（https://ethresear.ch/t/orbit-ssf-solo-staking-friendly-validator-set-management-for-ssf/19928）。即便如此，这种方案通过加快「最终确定性」能显著改善用户体验，但它并没有缩短用户需要等待 5-20 秒的这个时间。

Rollup 预确认

在过去的几年中，以太坊一直遵循着以 Rollup 为中心的路线图，围绕支持数据可用性和其他功能设计以太坊基础层（L1）。这些功能被 Rollup（还有 Validiums 和 Plasmas ）等 L2 协议使用，L2 协议可以为用户提供与以太坊相同级别的安全性，但它们的交易规模比 L1 要大得多。

这使得以太坊生态系统中产生了一种关注点分离：以太坊 L1 可以专注于抗审查、可靠、稳定以及维护和改进某些核心基础功能，而 L2 可以通过不同的文化和技术权衡专注于用户体验。但如果你沿着这条路走下去，就会出现一个不可避免的问题：L2 专注于为那些希望在 5-20 秒内获得更快确认的用户提供服务。

到目前为止，创建自己的「去中心化排序」网络已经成为 L2 不可推卸的责任。可能每隔几百毫秒，一小部分验证者会签署区块，他们会将自己的代币质押在这些区块中。最终，这些 L2 区块的区块头会发布到 L1 上。

L2 验证者集可以作弊：他们可以先签署区块 B1，然后再签署与 B1 有冲突的区块 B2，并在 B1 之前将其提交到链上。但如果他们这样做，就会面临惩罚而失去他们的押金。在实践中，我们已经看到了这种做法的中心化版本，但是 Rollup 在开发去中心化排序网络方面进展缓慢。你可以说要求 L2 都进行去中心化排序是一项不公平的交易：这相当于要求 Rollup 做与创建一个全新的 L1 相同的工作。出于一些原因，以太坊基金会研究员 Justin Drake 一直在推广一种让所有 L2（以及 L1）访问共享的以太坊预确认机制的方法：based preconfirmations（）。

Based preconfirmations（Based 预确认）

Based preconfirmations 的方法假设以太坊提议者将因 MEV 相关原因而成为高度复杂的参与者（请参阅此处了解我对 MEV 的解释，另请参阅提案）。Based preconfirmations 的方法利用这种复杂性，激励这些成熟的提议者提供预确认服务。

基本思想是创建一个标准化协议，通过该协议，用户可以提供额外的费用，以换即时取保证自身交易被纳入下一个区块，并获得有关执行该交易结果的声明。如果提议者违反了对任何用户做出的承诺，他们就会受到惩罚。

如上所述，based preconfirmations 机制为 L1 交易提供了保障。如果 Rollup 是「Based Rollup」（注：Based Rollup 由 Justin Drake 于 2023 年 3 月提出，是一种排序完全由 L1 完成的 Rollup），那么所有 L2 区块都是 L1 交易，因此可以使用相同的机制为任何 L2 提供预确认。

我们实际上看到的是什么？

假设我们实现单 slot 最终性。我们使用类似 Orbit 的技术来减少每个 slot 签名的验证者数量，这样我们也可以在减少 32 ETH 最低质押数量，可谓是一举两得。结果，slot 时间可能会逐渐增加到 16 秒。然后我们使用 Rollup 预确认或 Based preconfirmations 来为用户提供更快的保证。我们现在得到了什么？一个 epoch-and-slot 架构。

「它们是同一张图」这个 meme 已经被过度使用了，所以我只会将我几年前绘制的一张旧图表与 L2 预确认图表放在一起，以描述 Gasper 的 slot-and-epoch 架构，我希望我能够解释清楚。

有一个深刻的哲学原因可以解释为什么人们总是不可避免地使用 epoch-and-slot 架构：就某件事达成近似的一致本质上比就某件事达成最大程度的「经济最终性」一致需要更少的时间。

一个简单的原因是节点数量。虽然由于超优化的 BLS 聚合和不久的将来的 ZK-STARK，旧的渐进式去中心化 / 最终确定时间 / 开销权衡现在看起来更加温和，但从根本上来说，以下观点仍然是正确的：

• 「近似一致」仅需要少量节点，而经济最终性则需要所有节点中的相当一部分。
• 一旦节点数量超过一定规模，你就需要花费更多时间来收集签名。

在当前的以太坊中，12 秒的 slot 被划分为三个 sub-slots，用于 (i) 区块发布和分发、(ii) 证明 (iii) 证明聚合。如果证明者数量少得多，我们可以将其减少到两个 sub-slots，并拥有 8 秒的 slot 时间。另一个实际上更重要的因素是节点的「质量」。如果我们还可以依靠专业化的节点子集来达成近似协议（并且仍然使用完整的验证器集来实现最终性），我们可以合理地将其缩短到约 2 秒。

因此，我认为 (i) slot-and-epoch 架构显然是正确的，但 (ii) 并非所有 slot-and-epoch 架构都是一样的，我们需要更充分地探索设计空间。特别是，那些不像 Gasper 那样紧密交织的方案值得探索。

L2 应该做些什么？

在我看来，目前 L2 可以采取三种合理的策略：

• 无论是技术层面还是精神层面，都要「based」。也就是说，L2 是以太坊基础层技术属性及其价值（高度去中心化、抗审查等）更优秀的传递渠道。用最简单的形式来理解，你可以将这些 Rollup 视为「品牌分片」，但它们也可以更加雄心勃勃，并且它们对新的虚拟机设计和其他技术改进进行了大量实验。
• 成为「具有区块链脚手架的服务器」，并充分利用它。如果你从服务器开始，然后添加（i）STARK 有效性证明以确保服务器遵守规则，（ii）保证用户退出或强制交易的权利，以及可能的（iii）集体选择的自由，无论是通过协调的大规模退出还是通过投票更改排序器的能力，那么你已经获得了很多链上的好处，同时保留了服务器的大部分效率。
• 折衷方案：一条拥有 100 个节点的快速区块链，依靠以太坊提供额外的互操作性和安全性。这是许多 L2 项目事实上的当前路线图。

对于某些应用程序（例如 ENS、keystores 以及一些支付场景），12 秒的区块时间就足够了。对于需要更短确认时间的应用程序，唯一的解决方案是 slot-and-epoch 架构。在这三种情况下，「epoch」都是以太坊的 SSF（也许我们可以将该首字母缩略词重新定义为「single slot」以外的其他含义，例如，它可以是「Secure Speedy Finality」）。但在上述三种情况下，「slot」是不同的：

• 以太坊原生的 slot-and-epoch 架构
• 服务器预确认
• 委员会预确认

一个关键问题是，我们能把第 (1) 类中的某样东西做得有多好？特别是，如果它变得非常好，那么第 (3) 类似乎就意义不大了。第 (2) 类将永远存在，因为任何「based」的东西都不适用于链下数据 L2，例如 Plasma 和 Validium。但如果以太坊原生的 slot-and-epoch 架构可以缩短到 1 秒的「slot」（即预确认）时间，那么第 (3) 类的空间就会变得小得多。

今天，我们距离得到这些问题的最终答案还很遥远。区块提议者将变得多么复杂？这个关键问题的答案仍然存在相当多不确定性。像 Orbit SSF 这样的设计非常新颖，因此类似 Orbit SSF 的 slot-and-epoch 方案的设计空间还需要更多的探索。我们拥有的选择越多，我们就能为 L1 和 L2 上的用户做得更好，我们也能简化 L2 开发人员的工作。