跟踪L2交易的最终性时间

特别感谢 Jon Charbonneau 和 Conor McMenamin 对本文的审阅。

到目前为止，我们都应该知道 确认规则具有安全性，而不是 rollups 本身。当我们说 rollups 继承“以太坊安全性”或它们是“信任最小化”的时候，我们实际的意思是，在 rollups 上可以使用与以太坊确认规则具有相近安全性的确认规则。然而，区块浏览器通常关心的是显示一个绿色徽章，而不深入讨论他们所指的确认规则或其提供的安全属性。

在 L2BEAT，我们希望解决这个问题，并让每个人都能理解。特别是，我们想要关注最终性，这是针对双重花费攻击的最强确认规则。

确认规则：一致性与可用性

确认规则是算法，在特定假设下，指示一个区块何时被确认并不太可能被重组。一旦一个区块被确认，相关交易的操作可以进行。例如，这可能涉及把咖啡递给顾客或将汽车交付给买家。

不同的确认规则为用户提供不同的安全保障。确认规则的安全性由一致性和可用性组成，并且严重依赖于底层共识算法：

• 一致性（安全性）：在网络分区下，任何两个节点的视图都是一致的。
• 可用性（活性）：即使在大部分节点停止参与协定后，交易仍会在一定时间限制内被包含到账本中。

CＡＰ定理告诉我们，不可能设计出一种在网络分区下既保持一致性又具备可用性的共识算法：如果发生严重的网络分区，节点要么决定继续生成区块而失去一致性，要么停止并失去可用性。节点无法区分其他节点是简单离线（动态参与）还是活跃但无法访问（网络分区），因此不可能采取不同的行动。

Eve 无法确定 Bob 是简单离线还是在不同的网络分区中。

像比特币这样的区块链，利用类似 Nakamoto 的共识，更倾向于保持活性，这意味着在网络分裂期间，双方都将继续生成区块，并在分裂被解决时最终进行重组，而其他诸如 Cosmos 链的区块链，使用 PBFT 类似的共识，在网络分区期间暂停以保持一致性。

以太坊上的确认规则

以太坊在网络分区下优先考虑可用性，使用 LMD GHOST 算法。这种方法意味着诚实的节点可能对链的顶端有不同的看法，并可能会为同一高度确认不同的区块，潜在导致重组。

在有利的网络条件下，以太坊也旨在通过最终性提供一致性保障，使用 Casper FFG 协议。最终性是可能的最强确认规则，节点有一个硬编码规则以绝不会重组已最终确定的区块。

已最终确定的账本（绿色）总是活动账本（蓝色）的前缀。

如果两个冲突的区块被最终确定，最终性保障将受到损害，这种事件可能发生在超过 1/3 的验证者采取恶意行为的情况下。然而，在以太坊上，这种行为面临的重大惩罚是 失去他们的权益。

用户可以选择使用 Casper FFG 作为最安全的确认规则，或者更倾向于通过依赖 LMD GHOST 达到更高的活性。LMD GHOST 的确认规则与 比特币中的 k 确认规则 类似，可以比单纯查看交易是否包含在账本中更复杂，如 安全区块确认规则 所规定的。

Rollups 上的确认规则

Rollups 理论上可以使用以太坊上可用的相同确认规则。如果你在 rollup 上发送了一笔交易，随后看到相同的交易已在 L1 的一个最终确定的区块中发布，你可能还想将 L2 交易视为最终。然而，这个过程要复杂得多。

交易数据 rollups

在以太坊上，区块包括交易列表和区块头中的提议状态根。如果交易的执行未导致状态与根表示的一致，整个区块将被丢弃，包括可以在不同顺序中后来添加到其他区块的交易。

在 rollups 上，由于发布数据和根的行为是解耦的，因此交易的有效性不必依赖于对应状态根的有效性。这种分离使得检查交易是否已最终确定即可，而不必等待状态根的最终确定，绕过诸如乐观 rollups 中的 7 天挑战期等附加延迟。

Twitter Embed
Twitter Widget Iframe

状态差异 rollup

状态差异是状态转换函数的输出，要验证它们的有效性，需要等待 ZK 证明。ZK 证明的生成需要时间，此外，还存在延迟的动机，以便在一个证明中包含更多交易，从而更好地摊销证明生成和验证的成本。

证明聚合技术提供了一种解决确认时间和成本摊销之间权衡的解决方案：即使 rollup 的活动最小，它仍然可以通过在同一个证明中包含来自更活跃 rollups 的交易来获益。此方法的示例是 Starkware 的 SHARP，目前从 Starknet、Paradex 和 StarkEx rollups（如 dYdX 甚至 Validiums）中聚合证明。

事情变得复杂的地方

Rollup 导出规范

如果 rollup 不是 基于的，批次的推导顺序可以由 rollup 序列化器定义，这可能在 L1 上以不同的顺序发布它们。

举个例子，OP Stack 链在 L1 上发布的批次使用前一个批次的哈希链接。这些批次无需按时间顺序发布，导致一个 12 小时的 序列窗口，期间节点等待可能丢失的交易。仅仅因为某个批次在 L1 上发布，交易不应被视为已包含：如果一个批次尚未连接到规范区块链，存在构建具有不同排序或交易集合的替代分叉的风险。

在 OP Stack 链上，区块时间为 2 秒，每个以太坊区块中产生 6 个区块。以太坊区块间的这 6 个区块的组合被称为“纪元”。通过 L1 提交的 L1 到 L2 消息被包含在对应 L1 区块的第一块的第一部分中。虽然这些交易可以在等待序列窗口结束之前被视为已确认，因为它们在生成时在 L2 账本中的顺序是已知的，但必须注意的是，如果前一个批次丢失，节点将不会开始计算包含这些消息的区块。因为没有完整的序列，就无法计算状态，因此状态根也不会在 L1 上发布。

因此，单纯检查链上数据不足以追踪 L1 确认时间。还需要了解如何通过检查 rollup 节点软件本身，从 L1 数据导出 L2 区块。

有权限的功能

Scroll 是一个 ZK rollup，发布交易数据，这意味着原则上不需要等待 ZK 证明即可认为他们的交易是最终的。如果他们没有实现删除尚未证明的批次的功能，这是真的。

https://etherscan.io/address/0x2e07f0fba71709bb5e1f045b02152e45b451d75f#code#F1#L260

对于发布状态差异的 rollups 同样适用：zkSync Era 和 zkSync Lite 采用三步流程发布状态差异：首先，他们在没有任何证明的情况下提交数据，然后提供它们的证明，然后在 24 小时延迟后，状态根变得可用于处理取款。理论上，在提供证明时，交易的顺序已固定，因此不需要等待执行延迟通过。然而，zkSync 可以撤销这些区块：

https://etherscan.io/address/0x7Ed066718Dfb1b2B04D94780Eca92b67ECF3330b#code#F10#L425

虽然 zkSync Era 上从未撤销过区块，但在 zkSync Lite 上已经发生过 8 次。

最终性可观察性

由于发布状态差异的 rollup 不发布交易数据，我们如何追踪交易是否真的被包含？是的，我们可以跟踪影响，比如账户序号，但一般情况下情况会变得复杂。

每日难题：

假设我想通过状态差异 rollup 把我的车以 5 ETH 的价格出售。在一段时间后，我注意到状态差异显示我的余额增加了 5 ETH 或更多？ 我该把我的车卖给谁？

虽然这样做有效，但这意味着使用状态差异的技术决策渗透到应用逻辑中，这意味着即使一个 rollup 是 EVM 兼容的，项目也必须调整其合约以考虑这一点。

一个部分解决方案是发布交易根并在 ZK 证明内部验证其有效性。即使在这种情况下，仍然必须依赖排序器来获得必要的 Merkle 路径，这在知名中心化排序器下可能是合理的，但在无权限设置下就变得棘手了。

活跃性指标

作为跟踪 rollup 交易最终性时间的第一步，在 L2BEAT 上我们开始跟踪活跃性指标，特别是事务批次之间的间隔（如适用）和状态根。其理由是，如果一个 rollup 例如每月只与 L1 交互一次，用户不能期望最终性时间在几分钟内。活跃性指标可以被认为是最终性时间的一个下限指标：如果一个交易数据 rollup 每两分钟发布一次批次，并且假设 L2 事务的分布是均匀的，预期的最终性时间不会低于一分钟。

以下是我们为 zkSync Era（状态更新）和 OP Mainnet（交易批次）跟踪的一些数据示例：

zkSync Era 在九月份的活跃性指标。

OP Mainnet 在九月份的活跃性指标。

正如预测的那样，由于 ZK 证明需要时间生成，并且有把更多交易包含在单个证明中的激励，zkSync Era 的活跃性指标比 OP Mainnet 较差。需要牢记的是，正如我们在前面的部分中讨论的，活跃性指标并不直接转化为最终性考虑：在最坏的情况下，OP Mainnet 实际上具有更高的最终性时间，因为它的排序窗口。

你现在可以在 L2BEAT 上探索大多数 rollup 的活跃性指标：

跟踪活跃性的局限性

虽然活跃性可以被视为最终性的下限指标，但有时它是一个非常糟糕的指标。想象一下一个块时间为 4 秒的 rollup，这意味着每个以太坊块有 3 个 rollup 块。如果 rollup 操作员在每个 L1 块只发布两个 L2 块，即使从以太坊的角度来看，这个 rollup 仍然非常活跃，它也将越来越落后于 L2 的软确认，最终性的时间将越来越糟糕。虽然这是一种极端情况，但 rollup 需要考虑这一点。

一个实际的例子是 Starknet：尽管我们观察到状态更新之间的平均时间为 32 秒，但最终性时间实际上接近 6 小时：

来源：starkscan.co

这是因为 Starknet 为每个 L2 块发布一个状态根更新到 L1。然而，要做到这一点，他们必须引用一个 SHARP 证明，通常大约每 30 分钟 发布一次。此外， 这些证明在 L2 的软确认链顶端大约有 6 小时的延迟。

软确认

软确认是用于在 L2 上实现更短确认时间而牺牲安全保证的确认规则。目前，在所有情况下，软确认意味着信任中心化的操作员不会在 L1 上发布不同的交易。错误的软确认是可追溯的故障，因此可以实施离线或链上淘汰机制来跟踪排序器的声誉。与 Nethermind 合作，我们计划估计这些安全属性，并跟踪任何给定时刻的风险价值。

左：如果 Starknet 持有由淘汰机制保障的软确认，所提供的经济保障。右：随着时间推移，被重新组织的总风险价值。

向前发展

跟踪最终性时间是一项复杂的任务。我们的第一步是监控 ZK rollup 证明提交的时间间隔，这为最终性时间施加了比状态根提交间隔更高的下限。接下来，我们计划引入每个项目的历史数据图表。随后，我们的研究将集中于所有其他需要考虑的机制，以最终实现实时的最终性时间指标。敬请关注！

• 原文链接： medium.com/l2beat/tracki...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～