一文读懂Arbitrum Rollup的工作原理


一文读懂Arbitrum Rollup的工作原理
本文插图
【一文读懂Arbitrum Rollup的工作原理】
免责声明:本文旨在传递更多市场信息 , 不构成任何投资建议 。 文章仅代表作者观点 , 不代表火星财经官方立场 。
小编:记得关注哦
来源:以太坊爱好者
最近我发表了一篇博文比较 Arbitrum Rollup 和相互竞争的其他 rollup 系统(中文译本) 。 不过 , 那篇文章里面没有详细介绍 Arbitrum Rollup 的工作原理 , 所以这一篇文章的任务就是填补这个空白 。
一句话 , Arbitrum Rollup 是一个由以太坊链上合约管理的链下协议 。 为使自己的应用能够在 Arbitrum Rollup 上运行 , dApp 的开发者需要用 Solidity 编写一组合约 , 然后将这些合约编译成可以在 Arbitrum 虚拟机上运行的可执行代码 。 运行速度会更快 , 你我期待的就是这个 。
Rollup 基础知识
先从基础知识说起 。 我们使用默克尔树(Merkle Tree)来组织虚拟机的状态 , 因而可以算出虚拟机状态的密码学哈希值 。 我们把这个哈希值存储在链上 , 因此在协议的任何一个时间点 , 都会有一些虚拟机的状态(通过链上共识)被完全确认和最终敲定 。 这些已经获得终局性的状态的哈希值 , 就存在链上 。
协议的参与者 , 通过提出一个争议断言(Disputable Assertion , DA)来推进该虚拟机的状态;该断言声明 , 从某些状态哈希开始 , 基于一些技术前提 , 虚拟机将会执行特定数量的计算步骤 , 生成新的状态哈希 , 并在执行期间完成相关的支付 , 生成相关的日志事件 。 争议断言可能是有效的(即可信的) , 也可能是无效的 。 参与者在提出争议断言时需要为保证断言的有效性而赌上一笔押金 。 (更多关于押注及其工作原理的内容将在后面介绍 。 )

一文读懂Arbitrum Rollup的工作原理
本文插图
- 争议断言会使协议产生一个决策点 -
如上图所示 , 提出一个争议断言就会产生一个协议最终必须要解决的逻辑决策点 。 如果争议断言是有效的 , 则系统将进入图中右上角的新状态 , 包括由争议断言生成的新状态哈希值 , 以及其他附带效果(产生相应的支付和日志) 。 若争议断言是无效的 , 则进入右下角的分支 , 争议断言被系统拒绝 , 原来的状态不会发生变化 。
旧的 Arbitrum 协议
最开始的 Arbitrum 协议每次只处理一个争议断言 。 当某些参与者提出一个争议断言后 , 会有一个挑战期 , 在此期间任何人都可以挑战这个争议断言 。 如果没有被挑战 , 则该争议断言将被系统接受;否则就会执行纠纷解决协议 , 撤销争议断言(这是为了防止提议者和挑战者合谋炮制争议结果) 。
这样做很简单 , 但是有两个缺点 。 首先 , 因为每次只处理一个争议断言 , 所以虚拟机的处理速度很受限 。 在每个挑战期内 , 正常的处理流程基本上都将停滞 。 第二 , 恶意参与者通过故意挑战所有的争议断言可以彻底冻结虚拟机 。 攻击者需要付出一些押金作为代价 , 但是只要他们愿意 , 他们至少可以在某些特定场景下通过这种攻击长时间延误系统(而获利) 。
新的改进版本
在我这篇文章中介绍的新的 Arbitrum Rollup 协议解决了上述的两个缺点 。 通过 “流水线化” 处理多个争议断言 , 验证节点模拟虚拟机的运算速度有多快 , 虚拟机的处理速度就有多快 。 第二 , 我们后面将会解释 , 恶意参与者无法延阻系统 , 他们只能暂时延误对最终结果的链上确认 , 但这些结果对诚实节点来说早已 “无需信任地被敲定了” 。
所以 , 到底怎么做到呢?那就要讲得再深一点了……
每个状态后面最多可以接一个争议断言 。 如果一个状态后面没有争议断言 , 那么任何人都可以生成一个争议断言接在后面 , 作为一个新的分叉点 。 结果就是产生了一棵平行未来之树 。