Rollup去中心化

1. 引言

前序博客有:

所有Rollup项目的目标应为:

  • 构建技术栈
  • 将运营和治理去中心化,并交给社区

从而可实现去中心化世界。“去中心化”一词激发了一种开放、无许可的理念,以及一大批具有更快乐哲学的参与者。

在这里插入图片描述

  • 大多数L1区块链系统都是从Honest Majority诚实的大多数(或supermajority绝大多数)活跃参与者那里获得真相的来源(source of truth)。最重要的是,appointment协议偏向于优先考虑诚实的参与者加入,诚实的参与者将始终超过敌对/不诚实的参与者。
  • Rollup依赖于一种根本不同的信任假设来寻找真相的来源。真相不是由诚实的多数决定的,而是由可信的第三方(TTP)决定的。在Rollup中,TTP是位于以太坊等安全的L1区块链之上的 validating bridge智能合约

因此,Rollup的去中心化与L1链的去中心化有所不同,Rollup去中心化关注于:

  • Aid decision making— The goal is not to make sure the right decision is collectively agreed upon by an honest majority, but to ensure all potential decisions can be delivered and presented to the smart contract bridge in a timely manner。

Rollup系统仅需要one honest party来step up at the right time and deliver all messages(potential decisions) to the bridge合约——由合约来代表所有参与者进行最终决策。

因此,Rollup去中心化的目的不是引入10万个活跃Validators,而是恰恰相反:

  • 需确保1 honest party 总是有机会step up at the right time,并将所有potential decisions发送给bridge合约。由合约而不是参与的大多数来做最终决策。

Honest Majority1 honest party

  • Rollup将决策权从validators/system operators中,转移给了 智能合约。

因此,Rollup去中心化应专注于:

  • appointment协议可确保某honest party必要时可参与并single-handedly assist the bridge smart contract and protect the entire system when it is under attack by an all powerful adversary。就像甘道夫站在一座桥上捍卫友谊对抗巴尔罗格一样,巴尔罗格最终在齐拉齐吉尔的顶峰被击败。

2. Rollup:中心化前端+去中心化后端

Rollup为一种不同于CEX的链下系统,使得系统由“Won’t be evil” 转为 “Can’t be evil”。
Rollup具有中心化前端+去中心化后端:
在这里插入图片描述

  • On-chain bridge:维护链下系统的所有资产
  • Off-chain database:记录链下系统的债务往来

bridge需信服链下系统准确反应了所有债务,且在用户提款前,资产可覆盖所有的债务。为解决该问题,Rollup引入了3种actor:

  • On-chain bridge:为自动化智能合约,可验证数据库所有更新的完整性。
  • Sequencer:某运营者,取一组pending交易,对交易进行排序后供Executor执行。【为用户提供前端服务,以收集交易。对链下系统的安全性影响较小。】
  • Executor:某open-membership set of operators,从Sequencer那取得排序后的交易,对该交易进行执行,并attests to their execution with the bridge mart contract。【后端服务,处理并保护所有交易。】

Rollup与可信链下系统的主要区别在于:bridge是智能合约(而不是中心化CEX)。借助an open-membership group of executors,bridge可检查the integrity of all attested updates to the off-chain database before a customer withdrawal is processed。换句话说,Rollup为链下系统提供了去中心化后端,它使一大群网络大黄蜂能够处理和保护链外数据库的所有有效更新。

Patrick McCorry推荐将Rollup以SDK方式实现并开源,作为Web3软件栈供社区使用。

3. 如何为Rollup引入One Honest Party

在这里插入图片描述
Rollup协议中2个关键角色为:

  • Sequencer:某运营者,取一组pending交易,对交易进行排序后供Executor执行。【对链下系统的安全性影响较小。】
  • Executor:某open-membership set of operators,从Sequencer那取得排序后的交易,对该交易进行执行,并attests to their execution with the bridge mart contract。

3.1 Sequencer是可选的

Sequencer不是必须的,而是可选的,因为:

  • 用户可跳过Sequencer,将其交易直接提交给bridge合约。【Sequencers are not essential as a user can bypass them and forcefully order their transaction for execution via the bridge contract.】
    在这里插入图片描述

由2条路径了提交交易:

  • fast path:通过Sequencer来包含用户交易。
  • slow path:用户跳过所有Sequencers,直接将其交易提交给bridge合约for ordering。这也称为forced inclusion safeguard,只有实现了该功能的Rollup,才可认为其是安全的。【所有Rollup必须提供slow path。】
    • Rollup与sidechain侧链的核心区别就在于:用户是否可forcefully order a transaction for execution。
    • forced inclusion safeguard用于确保在最后情况下用户退出的安全性。

不过若只考虑average-case,则非常需要an honest party to participate as the Sequencer:

  • Prevent or fairly extract MEV
  • Guaranteed inclusion of time sensitive transactions (liquidations)
  • Reliable user experience (no dropped transactions, up to date info, etc)

有趣的是,对去中心化Sequencer追求可能会对基于用户体验需求的Rollup的长期架构和路线图产生重大影响,本文不展开讨论。
但是,正如这里所讨论的,这是完全没有必要的,因为用户可以绕过所有Sequencer并单独order其交易执行。

3.2 An Honest Executor

在这里插入图片描述
Only one honest execution is needed to assist the bridge smart contract and protect the off-chain database。

Executors构成了Rollup的后端,负责更新off-chain database。
Executor的主要任务包括:

  • 获取排序后的用户交易list
  • 基于database,执行排序后的用户交易list
  • 提交新的database update给bridge合约

Executor位于on-chain bridge和off-chain database之间,负责将链下世界的消息发送到链上合约。
为此,需要one honest executor来强化如下属性:

  • Liveness属性:已排序的和pending的交易最终都将会被Executors执行。
  • Safety属性:有信服的证据来证明,每个提交的database update都是有效的。

取决于俄所采用的信服的证据是fraud proof还是validity proof,从而会影响honest executor的执行规则:

  • Optimistic Rollup:an honest executor 需同时保护safety和liveness。
  • Validity Rollup:an honest executor 仅保护liveness。

3.2.1 Honest Executor for Safety

在这里插入图片描述
An honest party is only needed in an optimistic rollup as they monitor and ready to challenge all posted attestations.

Adversary的目标为:

  • Convincing the bridge smart contract of a database update that has a single invalid state transition (i.e., steals all funds).

为此:

  • Validity proof → cryptography:A cryptographic proof replaces the need for an honest party to protect the database update’s integrity. An adversary needs to break the underlying cryptography before they can produce a fake proof — which is no small feat(这是一个不小的壮举,伪造证明的难度较高).
  • Fraud proof → honest executor:When an executor attests to a database update via the bridge, all other executors have an opportunity to review the attestation and potentially issue a challenge for it.

为此,仅需要关注fraud proof情况下,honest executor如何保证safety:

  • 1)Break safety:没有可用的honest executor,bridge信服了an invalid update。
    • Fraud proof机制下,其安全性要求存在某honest executor,可发起a challenge against all adversarial executors。只要有某executor是honest的,则可保证win every challenge against the adversary。
  • 2)Delay attacks:故意没收抵押资金,目的是延迟已执行交易的最终性。【代表的是对liveness的攻击,而不是对safety的攻击。】
    • delay attacks是欺诈证明这种游戏挑战机制的副作用。游戏挑战机制的根本问题在于:不是证明某attestation是invalid的,而是某player lost the game。对手可以利用这一限制,将挑战游戏延长到分配的全部时间(约1周),并在前一个挑战游戏结束之前发布新的无效证明。通过重复这两个步骤,它可以防止诚实attestation的最终确定。
    • 每一场挑战赛都会要求对手没收赌注资产,因此这是一次昂贵的攻击。在执行延迟攻击的财务成本和这样做的好处之间存在权衡。
      延迟攻击代表了对liveness的攻击,而不是对safety的攻击。

3.2.2 Honest Executor for Liveness

在这里插入图片描述
一个诚实的executor可以独自一人强行推进并执行所有ordered和pending的交易。

由某 honest executor 来“pick up the slack” 并强制执行所有ordered交易。最终的成功取决于honest executor在合适的时机切入,以及adversary如何阻止。

adversary攻击Rollup liveness的目的在于:

  • 阻止用户所生成交易的执行

在几乎所有的汇总设计中,当前选择诚实执行人的任命(appointment)协议依赖于先到先得的原则,这基本上取决于谁能先发布证明。
先到先得的方法存在微妙的竞争条件问题,adversary可以利用这种方法无限期地阻止诚实的一方参与。例如,如果两个或两个以上的executor同时提交一个建议的数据库更新,那么adversary可以简单地以最少的数据库更新front-run诚实的executor。

乍一看,显而易见的解决方案是为一个诚实的executor和所有executor提供一个专用的时间段,用于提出数据库更新,并完全消除潜在的竞争条件。专用时段的有效性取决于诚实的一方需要多长时间才能获得该时段。需防范的最重要的威胁是adversary填满所有时段,再次延迟诚实的executor参与的机会。
另一个需要考虑的方面是数据库更新内容。可想象一个appointment协议,它会对未能按时提出数据库更新建议的executor进行抨击和驱逐。在这种情况下,可能希望防止adversary发布空数据库更新,并通过拒绝执行这些更新来有效地停止执行这些交易。

Arbitrum避免liveness攻击的解决方案为:

  • 强制每个数据库更新的最小计算量。
  • 系统运营商无法篡改的确定性交易费用。

强制最小执行进度,因为执行者必须提出有意义的数据库更新。此外,这使得adversary用“垃圾”填充有序交易队列的成本很高。

4. 展望

总之,须确保:

  • 诚实的executor具有guaranteed slot来提交数据库更新
  • 诚实的一方将及时获得一个slot
  • 对adversary来说,用垃圾执行来填充汇总是非常昂贵的。

上述目标提供了一些经验法则,有助于为executor设计新的任命协议,并确保一名诚实的executor能够在正确的时间挺身而出。然而,尽管经验法则很好,但目前仍缺乏可供Rollup项目采用的明确的任命协议。

除此之外,整个讨论假设一个executor将执行所有的工作以生成一个数据库更新,并且整个executors彼此不合作。这很可能是Optimistic Rollup的情况,但ZK-Rollup的情况并非如此。

附加任务:在ZK-Rollup中,executor需要重放所有交易,并生成交易执行正确的有效性证明,相比于Optimistic Rollup中的executor这是额外的任务。

众所周知,证明生成可以在多个Provers之间进行外包和并行化,但仍然缺乏能够公平地分割交易负载、使开放成员身份的Provers能够一起工作并最终将所有独立证明聚合为一个链上发布的单个证明的appointment协议。
例如,一个executor将证明交易1至1000,而下一个executor将证明交易1001至2000。最后,所有子任务证明都可以聚合/递归地组合成单个证明。

已有一个值得信赖的第三方——bridge智能合约——它可以用来将交易分段分配给特定的executor,并在他们未能按时完成任务时追究他们的责任(削减/驱逐)。因此,有所有的材料可供使用,但它仍然是一个大部分未开发的研究和设计空间,以利用bridge的额外力量。

希望有人会提出一个appointment协议,99.9%的时间可以让一组open-membership的Provers协同工作,但在最坏的情况下,一个诚实的executor可以为所有参与者强行取得进展。

参考资料

[1] What Does It Mean to Decentralise a Rollup?
[2] Where Is the One Honest Party for a Rollup?
[3] Rollups: Centralised front-end, decentralised back-end

猜你喜欢

转载自blog.csdn.net/mutourend/article/details/129120935