特别感谢 Jon Charbonneau 和 Conor McMenamin 审核了这篇文章。

此时我们都应该知道确认规则具有安全性，而不是Rollup本身。当我们说 Rollup 继承了“以太坊安全性”或者它们是“信任最小化”时，我们实际上是指在Rollup上可以使用具有与以太坊确认规则大致相同安全性的确认规则。然而，大多数区块链浏览器更多的是关注显示一个绿色徽章，而不去详细说明他们所指的是哪个确认规则，或者它们提供了什么安全属性。

在 L2BEAT，我们希望解决这个问题并让每个人都可以使用它。特别是，我们希望关注最终确定性——这是对抗双重支付攻击的最强确认规则。

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

确认规则是在特定假设下，指示何时一个区块被确认并且不太可能被重组（reorg）的算法。一旦一个区块被确认，就可以进行与其交易相关的行动。例如，这可能涉及将一杯咖啡交给顾客或将一辆车交付给买家。

不同的确认规则给用户不同的安全保障。确认规则的安全性包括一致性和可用性，很大程度上取决于底层的共识算法：

• 一致性（安全性）：在网络分区下，任何两个节点的视图都是一致的。
• 即使大量节点停止参与协议，交易仍然会在一定时间内继续被纳入账本。

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

伊芙不知道鲍勃是简单地离线还是在不同的网络分区。

像比特币这样的区块链，利用类似中本聪的共识，有利于活跃性，这意味着在网络分裂期间，双方将继续产生区块，并且如果分区解决，最终将重组，而像 Cosmos 链这样的区块链则使用类似 PBFT 的共识，在网络分区下停止以保持一致性。

以太坊上的确认规则

以太坊在网络分区的情况下，优先选择保持可用性，并采用了LMD GHOST算法。这意味着，诚实的节点可能对链的最新状态有不同的理解，并可能对同一高度的不同区块给予确认，这可能导致区块的重新组织（重组）。在网络条件良好时，以太坊还通过Casper FFG协议，试图提供更强的一致性保障。最终确定性是一种强大的确认规则，它通过硬编码的规则，确保一旦一个区块被确认，就不会再被重组。

已经确定的账本（绿色）始终是实时账本（蓝色）的前缀。

如果两个冲突的区块被同时确认，那么最终确定性的保障就会受到威胁。这种情况可能在超过三分之一的验证者存在恶意行为时发生。不过，在以太坊上，这种行为将导致验证者的抵押损失，因此风险很大。用户可以选择使用Casper FFG作为最安全的确认规则，或者依赖于LMD GHOST以获取更快的确认。LMD GHOST的确认规则类似于比特币中的k-确认规则，但可能比单纯检查交易是否被记录在账本上更复杂，正如Safe Block确认规则所示。

Rollup 的确认规则

理论上，Rollup可以使用与以太坊相同的确认规则。如果你在Rollup上发送了一个交易，并且稍后在以太坊主链（L1）中看到这个交易被记录在一个已经确定的区块中，那么你可能会认为这个L2的交易也是最终确定的。但实际情况比这更为复杂。

交易数据Rollup

在以太坊中，一个区块包含了交易列表和这些交易提出的状态根，这些信息都记录在区块头中。如果交易执行的结果与状态根不符，整个区块将被丢弃，包括那些可能会在其他区块中以不同顺序添加的交易。在Rollup中，由于发布数据和提交状态根是两个独立的过程，因此即使状态根无效，交易也不必被丢弃。考虑到这种分离，我们只需检查交易是否已被确定，而不需要等待状态根的最终确定，这样可以避免额外的延迟，例如在Optimistic Rollup中的七天挑战期。

状态差异Rollup

状态差异是状态转换函数的输出。为了验证它们是否有效，需要等待一个零知识证明（ZK证明）。生成ZK证明需要时间，而且还有进一步的延迟，因为存在将更多交易包含在单个证明中的激励，以此来更好地分摊证明生成和验证的成本。证明聚合技术提供了一个解决方案，平衡了确认时间和成本分摊之间的权衡：即使某个Rollup的活动较少，它仍然可以从将更活跃的Rollup中的交易包含在同一证明中的成本分摊中受益。一个例子是Starkware目前的SHARP系统，目前正在聚合 Starknet、Paradex 和 StarkEx Rollup（如 dYdX 甚至 Validiums）的证明。

事情变得复杂的地方

Rollup 派生规范

如果 rollup 不基于固定顺序，批次的处理顺序可以由 rollup 排序器决定，这可能会导致在 L1 上以不同的顺序发布它们。例如，OP Stack 链在 L1 上发布的批次是使用前一个批次的哈希链接的。这些批次不需要按时间顺序发布，导致了一个 12 小时的排序窗口，在此期间节点等待可能遗漏的交易。仅因为它们在 L1 上发布，并不意味着交易被认为已包含在内：如果一个批次尚未连接到批次的规范链，存在构建具有不同排序或交易集的另一个分支的风险。

在 OP Stack 链上，区块时间为 2 秒，每个以太坊区块内有 6 个区块。这 6 个区块间的分组被称为一个“时代”。通过 L1 提交的 L1 至 L2 消息包含在给定 L1 区块的对应时代的第一个区块的第一部分中。虽然这些交易可以在不等待排序窗口过去的情况下被认为是已确认的，因为它们在 L2 账本上的排序已知，但重要的是要注意，如果缺少前一个批次，节点将不会开始计算包含这些消息的区块。这是因为在没有完整序列的情况下，无法计算状态，因此，状态根也不会在 L1 上发布。

其结果是，仅检查链上数据不足以追踪 L1 确认时间。还需要通过检查 rollup 节点软件本身来了解 L2 区块如何从 L1 数据衍生出来。

许可功能

Scroll 是一种发布交易数据的 ZK Rollup，这意味着原则上不需要等待 ZK 证明即可将其交易视为最终交易。如果他们没有实现删除尚未经过验证的批次的功能，情况就会是这样。

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

这同样适用于发布状态差异的Rollup：zkSync Era 和 zkSync Lite 有一个三步过程来发布状态差异：首先，它们在没有任何证明的情况下提交数据，然后为它们提供证明，然后在 24 小时延迟后，根可以执行来处理提款。理论上，当证明被提供时，交易的排序是固定的，所以人们不需要等待执行延迟过去。除此之外，zkSync 可以撤销这些区块：

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

虽然在 zkSync Era 中没有区块被恢复，但在 zkSync Lite 上却发生了这种情况8次。

最终确定性可观察性

由于发布状态差异的 rollup 并不发布交易数据，我们如何追踪确保交易已经被包括在内？是的，我们可以追踪效果，比如账户随机数，但一般情况下会变得复杂。一个月前我提出了以下问题：

这是一个解决方案，如果排序器愿意回应你并且你信任它，这种方法是有效的。但如果它不愿意呢？或者它愿意但你不信任它呢？你如何验证这个说法是正确的？
这是我最喜欢的回答。这里建议了一个实际有效的解决方案：

虽然这个方法有效，但它意味着使用状态差异的技术决策会渗透到应用逻辑中，这意味着即使一个rollup与以太坊虚拟机EVM等价，项目也必须调整其智能合约以适应这种情况。部分解决方案是发布交易根并在ZK证明中验证其有效性。即便如此，仍然需要依赖排序器获取必要的Merkle路径，这在有声誉的中心化排序器中可能是合理的，但在无权限的情况下会更加复杂。

活跃度指标

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

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

zkSync Era 9 月份的活跃度指标。

9 月份 OP 主网活跃度指标。

正如预测的那样，由于ZK证明需要时间生成，并且有动力在单个证明中包含更多交易，zkSync Era的活跃度指标比OP Mainnet差。需要注意的是，正如我们在前面的章节中讨论的那样，活跃度指标并不能直接转化为最终确定时间的考虑因素：在最坏的情况下，由于其排序窗口，OP Mainnet实际上具有更长的最终确定时间。

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

跟踪活跃度的局限性

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

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

来源：starkscan

一个实际的例子是Starknet：尽管我们观察到状态更新之间平均需要32秒，但最终确定时间实际上接近6小时。这是因为Starknet为每个L2区块在L1上发布状态根更新。然而，为了做到这一点，他们必须引用SHARP证明，通常每30分钟左右发布一次。此外，这些证明通常落后于L2软确认链的最新块约6小时。

软确认

软确认是用于在L2上实现更短的确认时间而牺牲安全保障的确认规则。目前，在所有情况下，软确认意味着信任中心化的操作员不会在L1上发布不同的交易。不正确的软确认可以归因于操作失误，因此可以实施机制来跟踪排序器的声誉，无论是链下还是链上的惩罚。与Nethermind合作，我们计划估算这些安全属性，并跟踪在任何特定时刻处于风险中的价值量。

左：Starknet 上的经济保证，前提是他们有通过削减机制获得的软确认。右：随着时间的推移，面临重组风险的总价值。

向前走

时展望未来，跟踪最终确定时间是一项复杂的任务。我们的第一步是监控ZK rollups提交证明的间隔，这对最终确定时间的下限产生了更高的限制，相对于状态根提交之间的间隔。随后，我们计划引入显示每个项目历史数据的图表。接下来，我们的研究将关注所有需要考虑的额外机制，以最终实现最终确定时间的实时度量。请继续关注！

声明：

1. 本文转载自[medium]，著作权归属原作者[Luca Donno]，如对转载有异议，请联系Gate Learn团队，团队会根据相关流程尽速处理。
2. 免责声明：本文所表达的观点和意见仅代表作者个人观点，不构成任何投资建议。
3. 文章其他语言版本由Gate Learn团队翻译， 在未提及Gate.io的情况下不得复制、传播或抄袭经翻译文章。