Vitalik:Rollup 二层网络的三个阶段
人民干脆面
发表于 2022-12-1 09:55:34
130
0
0
L2beat的风险分析页面,显示了有关各种rollup项目的大量统计信息,包括它们的辅助轮状态:% G' h$ a: d1 D2 `' X1 y& Q+ c
/ I9 z) l4 n: n/ ^/ S6 }% B. _. Z
然而,截至今天,这些信息还没有很好地被标准化,这使得用户很难理解特定rollup所使用的特定信任模型。Rollup团队甚至可能有动力对他们当前的信任模型保持沉默,而是将讨论重点放在完全无需信任的未来。
这篇文章提出了一个简单的基于里程碑的模式,来帮助我们将Rollup分为三个不同的阶段(具体取决于它们对辅助轮的依赖程度),这样做是为了实现以下几个目标:
让用户更容易识别特定Rollup在多大程度上依赖于“对特定人群的信任”以及“对代码的信任”;
2 J5 X9 B" x4 I8 V. s
激励Rollup项目方改进他们的信任模型,降低信任最小化被取消优先级的风险;6 z6 r/ m( ]$ m Z/ ^: L& U7 M
3 g: ~6 W# V! K2 H1 A
给生态一些精确的里程碑来协调和庆祝,让我们说“TheSurge”何时完成一半或完全完成,这与“TheMerge”是类似的。此模式并非旨在暗示一种道德判断,即尽快实现代码信任最大化是唯一正确的行动方案。Rollup绝对应该有一个明确的摘掉辅助轮的路线图,但只有在准备好后才应该摘掉辅助轮。
图片来源:由无界版图AI工具生成。8 k/ t& h& E! y) A! i
& z& `9 G: u% r. M
概要阶段0:完整的辅助轮要求:
6 o/ w7 q# x* J; j
该项目应该称自己为Rollup。
+ b/ i) `2 n: P5 g$ w3 E
所有Rollup交易都应该上链。
应该存在一个“rollup全节点”:一个可独立运行的软件包,它可读取L1链,提取和rollup链,并计算rollup链的当前状态。如果它不同意发布到合约中的Rollup状态根,它应该发出警报。
应该有一种机制允许用户发布Rollup交易,或者至少确保在没有运营商合作的情况下提取他们的资产。即运营商不能通过对用户的审查来冻结或窃取用户的资产;他们这样做的唯一可能工具,必须是发布虚假状态根。9 B# y& A9 N' X, h7 t
. j& _; _$ ~: ^& O! f2 O/ R- `
如果发布新状态根的链上机制只是一个多重签名,其中没有任何有效的欺诈证明或有效性证明,那也没关系。阶段1:有限的辅助轮要求:9 v- y0 Z9 ]7 X+ m8 S
: p e3 Z2 l* @: B, x
必须有一个正在运行的欺诈证明或有效性证明方案,它具有接受或拒绝哪些状态根被Rollup合约接受的实际权限。
可以存在基于多重签名的覆盖机制(“安全委员会”),它可以覆盖欺诈证明或有效性证明系统的输出并发布状态根,以防万一证明系统代码被利用。然而:(1)多重签名必须是6of8或更严格的(即>=8个参与者并且签名阈值>=75%)4 p! h# c* Q& s' l; z% q1 L; i, @
(2)至少有一个仲裁阻止组(即有足够多的参与者来阻止多重签名)必须在运行Rollup的组织之外。$ B( l) a" w) Z+ n: w/ L
. c. b. k; b$ C- r% [; D
可以存在一种升级机制,但如果其阈值低于多重签名,则升级必须具有至少7天的强制激活延迟或防欺诈游戏的最长时长(以较长者为准)。这条规则的目标是确保升级机制不能被用来介入实时纠纷。第2阶段:摘除辅助轮要求:. M/ m% W6 i* ?' B5 N- `5 N
如果代码没有漏洞,则不得有任何一组参与者(甚至是集体)可发布除代码输出之外的状态根。/ X) l' k- W: s7 h
这样做(“如果代码没有错误,那么没有人可以覆盖它”)的目的,是摆脱对安全委员会的过度依赖,后者只有在发生明显错误的情况下才能使用,例如:/ d- ?6 s; k; G$ b, h" o
Rollup使用其状态转换功能的两个或多个独立实现(例如,两个不同的欺诈证明者,两个不同的有效性证明者,或每一个),只有当他们不同意时,安全理事会才能做出裁决——这只会在有一个漏洞时发生。2 F) v L0 {7 O2 ^
g, b2 y# |; U, v1 G6 U
如果有人在处理相同的数据后,提交包含两个不同状态根的两个有效证明的交易或一系列交易(即“证明者不同意自己”),控制权暂时移交给安全理事会。
: a2 X' h/ F& _9 D# W1 x
如果>=7天没有提交有效证明(即“证明者被卡住”),控制权暂时移交给安全理事会。
允许升级,但必须延迟>=30天。
成为第一个吐槽的人