szhbsd 前言：
一句话，Arbitrum Rollup 是一个由以太坊链上合约管理的链下协议。为使自己的应用能够在 Arbitrum Rollup 上运行，dApp 的开发者需要用 Solidity 编写一组合约，然后将这些合约编译成可以在 Arbitrum 虚拟机上运行的可执行代码。运行速度会更快，你我期待的就是这个。
Rollup 基础知识
先从基础知识说起。我们使用默克尔树（Merkle Tree）来组织虚拟机的状态，因而可以算出虚拟机状态的密码学哈希值。我们把这个哈希值存储在链上，因此在协议的任何一个时间点，都会有一些虚拟机的状态（通过链上共识）被完全确认和最终敲定。这些已经获得终局性的状态的哈希值，就存在链上。
协议的参与者，通过提出一个争议断言（Disputable Assertion，DA）来推进该虚拟机的状态；该断言声明，从某些状态哈希开始，基于一些技术前提，虚拟机将会执行特定数量的计算步骤，生成新的状态哈希，并在执行期间完成相关的支付，生成相关的日志事件。争议断言可能是有效的（即可信的），也可能是无效的。参与者在提出争议断言时需要为保证断言的有效性而赌上一笔押金。(更多关于押注及其工作原理的内容将在后面介绍。)
– 争议断言会使协议产生一个决策点 –
如上图所示，提出一个争议断言就会产生一个协议最终必须要解决的逻辑决策点。如果争议断言是有效的，则系统将进入图中右上角的新状态，包括由争议断言生成的新状态哈希值，以及其他附带效果（产生相应的支付和日志）。若争议断言是无效的，则进入右下角的分支，争议断言被系统拒绝，原来的状态不会发生变化。
旧的 Arbitrum 协议
最开始的 Arbitrum 协议每次只处理一个争议断言。当某些参与者提出一个争议断言后，会有一个挑战期，在此期间任何人都可以挑战这个争议断言。如果没有被挑战，则该争议断言将被系统接受；否则就会执行纠纷解决协议，撤销争议断言（这是为了防止提议者和挑战者合谋炮制争议结果）。
这样做很简单，但是有两个缺点。首先，因为每次只处理一个争议断言，所以虚拟机的处理速度很受限。在每个挑战期内，正常的处理流程基本上都将停滞。第二，恶意参与者通过故意挑战所有的争议断言可以彻底冻结虚拟机。攻击者需要付出一些押金作为代价，但是只要他们愿意，他们至少可以在某些特定场景下通过这种攻击长时间延误系统（而获利）。
新的改进版本
在我这篇文章中介绍的新的 Arbitrum Rollup 协议解决了上述的两个缺点。通过 “流水线化” 处理多个争议断言，验证节点模拟虚拟机的运算速度有多快，虚拟机的处理速度就有多快。第二，我们后面将会解释，恶意参与者无法延阻系统，他们只能暂时延误对最终结果的链上确认，但这些结果对诚实节点来说早已 “无需信任地被敲定了”。
所以，到底怎么做到呢？那就要讲得再深一点了……
每个状态后面最多可以接一个争议断言。如果一个状态后面没有争议断言，那么任何人都可以生成一个争议断言接在后面，作为一个新的分叉点。结果就是产生了一棵平行未来之树。
– 平行未来之树 –
押注
协议的另外一个重要的部分是押注。任何人都可以在树上的某个方框（状态）后面下注。对某个方框押注，意味着你在断言该方框最终将被协议确认。换句话说，你在断言从当前状态到你押注的方框所在的这条分支是正确的分支。如果你错了，可以想见你的押金将被罚没。
押注行为不能被撤销。你可以将你的押注向右移动——可以在分叉点后向上或向下选择分支——但你不能向左移动押注，因为这相当于撤销你之前作出的押注承诺。
提出争议断言的参与者要在 “认可其断言有效” 的继任方框上押注。通常他们可以向右移动已存在的押注到满足条件的方框上。（在极少数情况下（译者注：比如他们的断言是无效的，被成功挑战）他们不能这样做，他们可以额外再押一注到需要的方框上。但是注意，他们将在相冲突的两条路径上押注，因此最终他们会损失至少一笔押金——通常自相矛盾不是明智的移动选择）。
关于押注还有一个细节：如果你押注的方框被确认成为被接受的历史的一部分，你可以选择收回押金。这意味着，如果你是正确的，你可以停止移动你的押注，直到系统 “追上” 你，然后你就可以收回你的押金。
– 一棵更标准的状态树 —— 由一连串的有效断言组成 –
在这一点上，你可能会担心，平行未来之树会变得非常大，而且枝繁叶茂。这在现实中是不可能发生的，因为这需要多方押注不一致的结果。只要他们中有一个是诚实的，其他所有人都会损失他们的押金。更有可能的是，这棵树实际上是一个由有效 DA 串成的链，一个接一个，所有的押注都在同一条分支上。
押注期限
我们需要系统在尽可能短的时间内对每个争议断言做出决定。所以当一个争议断言被添加上链、产生一个分叉点的时候，会有一个期限与之关联。这个期限足够长，任何人如果愿意，都有足够的时间检查这个争议断言是否有效，以及产生一笔押注交易上链。任何要押注的人都必须在期限结束之前完成操作（过期的押注仍然可以上链，但它们不能决定那个争议断言的有效性）。一旦期满，所有可以决定争议断言的押注都将可知。
纠纷
如果 Alice 和 Bob 押注不同的方框，那么以下两件事件中，必有一件为真。要么其中一个押注可以向右移动到另一个 —— 意味着他们的断言是一致的 —— 要么找不到这样的路径。如果没有一条向右移动的路径可以连接 Alice 和 Bob 的方框，则他们必然有分歧。他们之间一定可以找到一个唯一的分叉点 —— 一个唯一的争议断言，某个人押注这个断言是有效的，而另一个押注其无效。
– Alice 和 Bob 之间存在争议 –
当两个参与者之间出现纠纷时，系统可以启动一个交互式纠纷解决协议。我在这里没有足够的篇幅来描述这个纠纷解决协议 —— 我只想说，这是一个类似我们在其他 Arbitrum 文档中描述过的二分法交互协议。
纠纷解决协议的结果是一个参与者将被发现是错误的。这个参与者的押金会被罚没。押注会从所在的方框上删除。部分押金会给到纠纷的另一方，剩下的被烧掉。
多个纠纷可以同时解决，但是每个押注者一次最多只能参与一个纠纷。因为输家的押注将被删除，每解决一个纠纷都会减少整个系统的分歧数量。损失押金的参与者可以继续押注，但是新的押注无法影响押注期限已过的争议断言。这样做的效果是，一个争议断言的押注窗口结束后，一切有关如何处理该断言的分歧都将被消除。
结果确认
某个争议断言的押注期限到期后，如果所有及时提交（且尚未被删除）的押注，都存在于从该断言产生的同一条分支上，那么系统就可以肯定该断言的结果为真。争议断言要么被接受要么被拒绝，当前状态会移动到争议断言右边正确的方框上。如果争议断言被确认有效，则其附带效果，如支付等，也会在链上生效。虚拟机的状态就是这样向前移动的。
一般情况下，参与者都会诚实守矩，谁也不想因为押注错误而损失押金。只有有效的争议断言会被（其他参与者）断言，构成一条链，没有人会在任何争议断言的无效分支上押注。在这种情况下，所有的争议断言都会在押注期限一过后立即被确认。
何以无需信任（Trustless）
Arbitrum Rollup 的一个重要性质就是无需信任 —— 只要有一个诚实参与者就可以确保虚拟机状态正确向前推进。为什么呢，想象一下 Alice 总是在正确的分支上押注，如果没有争议断言，她就自己断言。
因为 Alice 总是在正确的分支上押注，所以她会赢下每一次纠纷。如果有任何人不同意 Alice，他们要么 (a) 与一个无关的第三方产生纠纷并损失押金，或者 (b) 最终和 Alice 产生纠纷并输给 Alice 押金。无论哪种情况，所有与 Alice 不一致的人都将失去押金。只有同意 Alice 的押注才能存活下去，所以 Alice 在树上的路径最终会成为唯一一个有及时押注的分支 —— 并且 Alice 的路径会被确认。
– 只要 Alice 是诚实的，无论别人怎么做，绿色方框都会得到确认 –
因为按这种方式系统是无需信任的，如果 Alice 押注某个方框，她一定知道到这个方框的路径是可信的，Alice 可以确定这个方框最终一定会被确认。对于 Alice 来说，这条路径就跟被敲定了一样。
即使你没有押注某条路径，如果你看到有好几个人对它押注，只要你相信其中至少有一个诚实的人，你就可以肯定这条路径最终一定会被确认——对你来说，这条路径就跟被敲定了一样。
无需信任的终局性（Finality）的好处
为什么说无需信任的终局性有价值？经典的例子来自于之前对其他 rollup 协议的讨论。假设一个虚拟机要向 Alice 进行支付。支付事件发生在诚实的路径上，但是包含这笔支付的方框还需要等待一些时间被链上确认。
无需信任的终局性让 Alice 可以立即拿到钱。如果 Bob 有余钱，可以立即付给 Alice，以交换 Alice 尚未被确定的收款（加上支付给 Bob 一点小费）。Bob 只有在他能确定 Alice 的这笔收款一定会发生，才会想和 Alice 交易。Bob 可以通过押注诚实的结果来确保这一点——这样他对这笔支付最终一定会发生抱有无需信任的信心。不仅仅是 Bob 可以这样做。任何有点钱的人，都可以用这样的方式借钱给 Alice 或者有她这样需求的人，这些人通过提供更低的费用相互竞争，使 Alice 立即拿到钱的成本大大降低。
关键是，这种市场机制的可行性取决于无需信任的终局性。如果 “每个人” 都知道这件事最终会被确认，那么链上确认的延迟就不会带来那么多的不便。
不仅对于支付，虚拟机能做的其他事情也是如此。如果虚拟机要生成一个日志事件记录发生了什么事情，无需信任的终局性意味着任何人都可以肯定地采取行动，因为这个日志事件最终一定会被链上承认。
延迟攻击
因为这个系统是无需信任的，坏人无法强行制造错误的结果。他们能做的只能是延缓系统。这样做需要他们付出押金，如果押金数额巨大，则代价高昂。
想象一下，如果有人宁愿付出押金也要发动延迟攻击，他们能造成的最坏的情况是怎样的？
首先要注意的是，坏人无法阻止好人继续构筑诚实的分支。而且他们也无法阻止好人获得对 “诚实的分支终将被确认” 的无需信任的信心。
攻击者能做的只是在错误的分支上押注，以延迟诚实路径的链上确认。他们每次的押注都会产生一起和诚实参与者的纠纷，而诚实的参与者会从纠纷中拿走攻击者的一大部分押金。等到攻击者的全部押金被拿走了，链上确认还会继续向前推进。
如果攻击者多笔押注错误的结果会怎样？那么这些押金会在一个接一个的纠纷中被拿走。如果有多人押注诚实的结果，这些人都可以进入纠纷解决，并行拿走攻击者的押金。而且需要注意，所有人都很清楚发生了什么，很多人都想加入进来分一杯羹，押注正确的结果从攻击者手上抢夺押金。如果诚实方有 K 个人押注，则在一次纠纷延迟期内，就要消耗攻击者 K 份押金。如果攻击者下更多的押注，那很可能会吸引更多的诚实押注者。这对攻击者来说是个灾难。
优化
还可以做很多优化来降低操作协议所需的链上记账数据量，降低链上的 gas 消耗，让攻击者延迟攻击引发的喂养狂潮更容易上演。我不会再这里详述这些优化 —— 这篇文章已经足够长了。
