详情
技术|第二层溶液Arbitrium Rollup的工作原理

出处:链外实验室作者:埃德·费尔滕此前我发过一篇文章比较 Arbitrum Rollup 和其他 rollup 解决方法。但没细说 Arbitrum Rollup 的工作原理,所以本文将详细介绍 Arbitrum。Arbitrum Rollup 是一个由 ETH 链上合约管理的链下协议。一个 dApp 开发者用 Solipty 写了一组合约,将这类合约撰写进 Arbitrum 虚拟机 中,然后就可以在 Arbitrum Rollup 中运行合约了。如此运行速度可以快些。让大家从基础说起。虚拟机的状况以默克尔树的形式组织,因此就可以计算出该虚拟机状况的加密哈希。在协议的任意时间点,都有一些虚拟机状况被完全确认和敲定。这类虚拟机状况的哈希是储存在链上的。协议参与者可以提出一个“争议断言” 。该断言声称,虚拟机从某些状况哈希开始,基于一些技术首要条件可以实行特定数目的计算步骤,从而生成新的状况哈希。并在计算期间完成特定的支付与生成特定的日志事件。该“争议断言”可能有效,可能无效。提出“争议断言”的一方需要基于断言的有效性质押一笔保证金。图:一个争议断言在协议中产生了一个决策点如上图左边所示,一个争议断言产生了一个协议最后需要解决的逻辑决策点。假如该断言有效,系统会进入一个新状况 ,依据特定的断言产生新的状况哈希和其他诸如支付和日志的附带成效。不然就会进入另一个分支 ,该断言就会被拒绝,状况维持不变。最开始的 Arbitrum 协议每次处置一个“争议断言”。当某方提出一个断言时,挑战期便开始,在此期间其他人都可以对该断言发起挑战。假如没人发起挑战,该断言就会被确认;不然争议协议就会运行以取消争议断言 。这个设计非常简单,但有两个缺点。第一,因为每次仅处置一个争议断言,致使虚拟机的处置速率有限。因此,每一个挑战期期间,处置进程基本上停滞下来。第二,作恶者可以通过对某虚拟机所有些争议断言发起挑战来冻结该虚拟机。攻击者会为此付出肯定的代价 ,但假如他们不在意这类损失,至少在一些场景下他们可以导致系统的处置进程延误非常长一段时间。新版 Arbitrum Rollup 协议解决了上面两个问题。将多个争议断言按流水线式排布,如此设计下,虚拟机处置速度就可以和验证节点模拟虚拟机运算的速度一样快了。第二,正如下图所示,作恶者没办法延缓进程,他们只能暂时延误对结果的链上确认,而对于诚实节点来讲,这类结果已经是“不需要信赖地被敲定了”。其工作原理是什么?我需要更进一步地介绍这个新的协议….每一个状况最多有一个争议断言跟在其后。假如某个状况后没争议断言,那样其他人都可以在其后创建一个争议断言,作为一个新的分支点。从而产生一颗多种可能的将来之树。图:一颗多种可能的将来之树Arbitrum 的另一个要紧部分就是质押 。其他人都可以往那颗树中的方框里质押肯定金额。通过质押,用户则押注了某个方框最后将被协议确认。换句话说,该用户觉得其押注的方框是目前状况的正确分支。假如用户押错注了,其押金便会遭到罚没。质押行为不能撤销。用户可以将押金向右移动 ,但不能向左移动,由于这等于用户撤销其此前的质押操作。提出争议断言的一方需要押注其提出的争议断言有效。一般情况下他们都可以满足这一需要 —— 将其现存的押金往右移动并押注在需要的方框上。关于质押还有一个细节:假如用户押注的方框被确认且被记录在协议上了,用户可以选择取回押金。这意味着,用户假如押对注了,便可以选择不再移动押金,留在原处直到被系统追上,然后就可以取回其押金了。图:愈加典的状况树 — 由一系列正确的断言组成在这一点上大伙或许会担忧那颗充满各种可能的树会变得很庞大、枝繁叶茂。这在实践中不太可能发生,由于这需要多方对不同的结果押注。其中仅有一方是正确的,别的人则会损失押金。那样结果最大概是如此的:这是一颗由“有效的争议断言”所组成的链,一个接一个,所有质押者都具备同样结果的分支上。大家需要系统尽量快地对每一个争议断言做出决定。所以当新的争议断言被添加上链且出现一个分支点时,就会产生一个与该争议断言有关联的期限。这个期限足够长以至于其他人都可以在期限内判断该争议断言是不是有效,然后需要在期限之前选择是不是押注。 一旦期限满了,所有参与决定争议断言的押注都将可知。假如 Alice 和 Bob 在不一样的方框上进行押注,会有两种状况发生:要么其中一位向右移动到另一个人的押注上 ;要么找不到如此的路径。假如 Alice 和 Bob 之间没一条可以连接他们的向右的路径,则他们一定相矛盾。那样在他们之间肯定可以找到一个唯一的分叉点—— 这一点将他们两个分叉,各押注了相矛盾的分支方框。图:Alice 和 Bob 之间存在争议当两方之间出现争议时,系统会在他们之间启动一个交互式的争议解决协议。可惜在本文中我没足够的篇幅来描述该争议解决协议 —— 这是一个二分法交互协议 ,像我之前在其他 Arbitrum 文档中的描述。该协议带来的结果是,其中一方会被证实错误的。其押金会被罚没,且押注册会计师从方框中移除。而这类押注的部分会给争议的另一方,剩余的会被销毁。多个争议可以同时存在,但每一个质押者每次最多只能选择一个争议。由于错误的押注册会计师被删除,每一次争议的出现都会降低系统中的分歧数目。损失押金的质押者可以选择第三押注,但新的押注不可以再影响期限已过的争议断言。这样带来的影响是,一个争议断言的质押期限过了之后,关于怎么样处置该争议断言的争议都会被消除。当某个争议断言的质押期限到期之后,并且所有在期限内存入的押注在该断言的同一个分支上,系统就可以确认该争议断言的结果。它会被确认或拒绝,目前状况会向右移动到正确的方框上。假如该断言被正式有效,其附带成效 也会被记录上链。虚拟机状况就是如此向前移动的。通常情况下,为了不损失我们的押金,参与者都将诚实押注。只有有效的争议断言会被提出,没人将在争议断言的无效分支上押注,从而形成一条单一的链。在这样的情况下,每一个争议断言都能在质押期限过后立即被确认。Arbitrum Rollup 的一个重要程度质就是不需要信赖 —— 单个诚实参与者就可以确保虚拟机状况正确推进。为何?假设 Alice 一直对每一个争议断言的正确分支进行押注,并且当树不再产生分支了,她就建议一个争议断言。由于 Alice 在正确的分支上押注,所以每一次争议她都是胜利方。假如其他人与 Alice 相矛盾,他们将 在一个不有关的争议中损失他们的质押金, 最后进入 Alice 所在的争议中,其押金将输给 Alice。不管什么方法,任何反对 Alice 的一方最后都会被罚没。只有与 Alice 相符合的押注才会胜利到最后,所以 Alice 所在的分支会成为唯一一个准时收到押注的路径 —— 该路径会被确认。图:只须 Alice 是诚实的,无论别的人如何做,绿色方框最后都会被确认因为在这种方法上系统是不需要信赖的,假如 Alice 在一个方框上押注并且她了解该方框的路径是正确的,那样她可以确认其所在的方框上将最后被确认。对于 Alice 来讲,该路径就像被敲定了一样。即便用户没在某条路径上押注,但假如用户看到其他一些用户押注该路径,并且相信该路径上至少一个人是诚实的,那样其就可以确认该路径将最后被确认 —— 对该用户来讲,这条路径就像被敲定了一样。结果最后确定性的不需要信赖为何这样要紧?那篇对于其他 rollup 协议的讨论中举出了一个经典的例子。假设一个虚拟机计划向 Alice 支付一笔买卖。该支付事件坐落于正确的路径上,但这笔买卖还需等待一段时间,直到这笔出货交易平台在的方框在链上被确认。最后确定性不需要信赖让 Alice 可以即时收到汇款。假如 Bob 手上有闲钱,他可以立即给 Alice 钱,作为交换,Alice 把将来马上被确认的支付款项转给 Bob 。Bob 只有确定该支付买卖必然会发生才会想这么做。Bob 可以通过押注诚实结果来确保这一点 —— 那样他就可以对这笔支付必然会发生抱有不需要信赖的信心。不只 Bob 可以如此做,其他人都可以以这种方法把钱借给 Alice 或其他像她那样的人。这类人还可以通过提供更少的手续费以角逐。重要是,这种市场机制的可行性取决于不需要信赖的最后确定性。假如“每一个人”都已经了解该事件将最后被确认,那样链上确认的延迟就不会带来不便。不只支付这个案例,对于虚拟机所做的其他事情也是这样。假如虚拟机计划生成一个日志项来广播发生了的事件,不需要信赖的最后确定性意味着其他人都可以确信该日志将被链上承认。由于系统是不需要信赖的,作恶者没办法强行生成一个错误的结果。他们可以做的只有延缓系统处置过程。但如此会牺牲他们的押金,假如质押数额非常大的话本钱将会特别高。想象一下假如有人想要发起延迟攻击,且想牺牲他们的押金。他们可以带来最大的破坏是什么?第一,作恶者不可以阻止诚实验证者继续在树上构建他们的诚实分支。他们也不可以妨碍诚实验证者相信诚实分支的最后确认具备不需要信赖性。攻击者可以做的只有在错误分支上质押,以延缓对诚实路径的链上确认。他们的每笔押注都会给诚实质押者创造多一个争议,在这个过程中诚实验证者都会分走一大半攻击者的押金。当攻击者的押金都被分走时,链上工作便继续进行。那假如攻击者在多个错误结果上质押呢?那样,那些押金就会在一次次的争议里被分走。假如有多人在诚实结果上质押,他们可以进入有攻击者的争议里,与攻击者并行工作,然后把质押者的押金分走。而当大家注意到这一点,大伙都了解在发生啥事了,就会有不少人加入到在正确结果上做质押,如此他们就能分走制造争议的攻击者的押金。假如有 K 个人在诚实结果上做质押,攻击者就要花费 K 份押金来一次争议期的延迟。假如攻击者花费更多的押金,这或许会吸引更多的诚实质押者。对攻击者来讲状况只能愈加坏。有不少优化策略可以推行,以降低运行协议必需的链上记账数据量、降低链上 gas 消耗、与让延迟攻击所带来的分食狂欢更容易发生。笔者在这里就不对优化详细展开了,这篇文章已经够长了。

版权保护: 本文由 T12区块链 原创,转载请保留链接: http://www.egfi.cn//baike/1789.html