观点

交互式欺诈证明:Arbitrum 的秘密武器

Ajian   |     |   1142 次阅读

Arbitrum One 已经在主网开放,我们计划推出一系列的文章,讲解 Arbitrum 的内部构件。本文摘自 Inside Arbitrum,该原文深入讲解了 Arbitrum 的工作原理

围绕 optimistic rollups,最主要的设计抉择是,如何解决争议。假设 Alice 断言 Rollup 会的运行会产生某个结果,而 Bob 不同意,那协议该如何定夺,选择谁提交的结果呢?

处理的方法基本可分两类:交互式证明,或者重执行交易。Arbitrum 选择了交互式证明,我们认为这种办法效率更高,也更灵活。Arbitrum 的其它设计也基本上遵循这个原则。

从 2014 年以来,我们一直在开发交互式欺诈证明(和 Arbitrum)。基本的机制我们写在了 2018 年出版的论文里,虽然现在我们又做了大量的升级。

交互式证明

交互式证明的思路是让 Alice 和 Bob 参与一个由 L1 合约引导的回合制协议,使用任何 L1 合约所需的最小开销来解决他们之间的分歧。

Arbitrum 的方法基于对争议的剖析。如果 Alice 的断言涉及了 N 个执行步骤,那就让她曝光出两个各涉及 N/2 个步骤的断言,然后让 Bob 选择一个来挑战。这样一来,争议的规模就缩小了一半。这个过程持续进行,每一回合都将争议的规模缩小一半,直到争议的范围变成一个执行步骤。注意,直到此时为止,L1 引导合约都不必考虑实际上执行了什么。仅当争议被缩小到单个执行步骤时,L1 引导合约才需要理解这一步要执行什么指令,以及 Alice 对该步的断言是否为真,以此解决争议。

交互式证明背后的关键原理是,如果 Alice 和 Bob 有所争议,Alice 和 Bob 应尽可能做链下的工作来解决争议,而不是让 L1 合约承担负担。

重执行交易

另一个方案是,让一个 Rollup 区块在区块内每一笔交易后附带一个状态哈希值断言。然后,在争议情形中,L1 引导合约将模拟一整笔交易的执行,看结果是否与 Alice 的断言一致。

为什么说交互式证明更好?

我们坚决认为,交互式证明是个更好的方法,理由如下。

在乐观情形下,交互式证明效率更高。因为交互式证明可以解决大于一笔交易的争议,因此,一个 rollup 区块可以仅包含一个断言,断言整条链在这一个区块的所有内容执行完之后的结果状态。相反,重执行方法需要区块内的每个交易后面都附带一个状态断言。如果一个 rollup 区块里面有成百上千笔交易,这两种方法在对 L1 区块的空间占用上将出现显著的区别 —— 而这种占用正是 rollup 成本的主要部分。

在悲观情形下,交互式证明的效率也更高:如果出现了争议,L1 引导合约只需检查 Alice 和 Bob 的操作 “在往正确的方向走”,比如 Alice 确实把 N 步骤的断言拆成了两个针对一半步骤的断言。(引导合约无需去计算 Alice 断言的正确性,Bob 会做,在链下做。)只需要重新执行一个指令。相反,在重执行交易模式下,L1 引导合约需要模拟一整笔交易的执行。

更高的交易级 gas limit:交互式证明可以摆脱以太坊对单笔交易 Gas Limit 的限制;即使一笔交易 gas 消耗量太大、无法放进以太坊区块内,也仍有可能可以放进 Arbitrum 的区块内。Rollup 的 Gas Limit 当然也不可能是无限的,但仍可以做到比以太坊主链所容许的大得多。就以太坊而言,大 gas 容量的 Arbitrum 交易的唯一缺点是它可能需要运行更多的交互步骤(这个也仅仅是在有所争议的情况下)。相反,重执行模式下的 rollup 交易,gas limit 必须小于以太坊的区块 Gas Limit,否则就没法在一笔以太坊交易内模拟执行完这笔交易了(而且模拟执行比起在以太坊中直接执行,gas 消耗量还要更大)。

合约大小没有限制:交互式证明无需为每一个 L2 合约创建一个以太坊合约,所以也不要求合约符合以太坊合约的限制。对于 Arbitrum 的争议合约来说,在 L2 上部署一个合约的操作也是一系列计算过程的组合,与别的操作没有区别。相反,重执行模式下,L2 合约的大小比以太坊主链上所能容许的还要小,因为要模拟一个合约的执行需要能够仿制(instrument)这个合约,而仿制的代码必须能够放进一个以太坊合约内。

更大的实现弹性。交互式证明允许实现上的更大灵活性,举个例子,加入 EVM 中还不存在的指令。必要的功能无非是能在以太坊上验证一个单步执行的证据。而重执行模式就严格受限于 EVM。

交互式证明方法是 Arbitrum 的设计核心

Arbitrum 的大部分设计都是由交互式证明方法所开启的机会驱动的。如果你在学习 Arbitrum 的特性时疑惑于为什么这种它们要存在,这里有两个简单的思考方向:“这个特性是用来支持交互式证明的吗?” 以及 “这个功能是是如何利用交互式证明得以实现的”?大部分关于 Arbitrum 的 “为什么” 都跟交互式证明有关。

想了解更多?看看 Inside Arbitrum

(完)


原文链接: https://medium.com/offchainlabs/interactive-fraud-proofs-arbitrums-secret-sauce-debc3b019418
作者: Offchain Labs
翻译: 阿剑


你可能还会喜欢:

Optimistic Rollup 为什么要这么设计?

Rollup 各方案异同简介

Arbitrum Rollup 的工作原理

 
0 人喜欢