本文内容主要来自Arbitrum官方文档,时间:2023.12 大部分东西都跟OP差不多,类似的东西就不赘述了
<!--StartFragment-->
本文内容主要来自Arbitrum官方文档,时间:2023.12
大部分东西都跟OP差不多,不赘述。
现在L2上有部署两条Arbitrum rollup:
一条 Arbitrum Rollup 链,称为“Arbitrum One”,一条 AnyTrust 链,称为“Nova”
AnyTrust与rollup的区别是,anytrust上的交易详情不会放到L1上,也就是不提供DA。所以它更便宜。当有fraud proof挑战时,需要有至少2个诚实的委员会成员把相关数据提交到L1。
Arbitrum One现在也叫Arbitrum Classic。而最新的技术叫Nitro. Nitro和Classic的差别:跟OP上的OVM V1和Cannon的差别几乎是一样的。Classic的虚拟机叫AVM (Arbitrum Virtual Machine)。Nitro上用的是Wasm。
在Classic中,Solidity、Vyper 等语言写的合约会编译为 EVM 字节码(就好像它要部署在以太坊上一样)。ArbOS 将这个字节码转换为其相应的 AVM 指令;该 AVM 字节码既可以作为运行 L2 VM 的指令,也可以用于欺诈证明;在交互式欺诈证明中,两个验证器在L1的EVM中运行一段 AVM 字节码,直到证明谁对谁错。
Nitro中,geth的 Go 代码被编译成 WebAssembly (Wasm),Nitro 本质上是 EVM,定期生成以太坊式区块;我们可以将这些块视为 L2 状态更新的断言中的状态检查点。因此将交互式欺诈证明戏分为两个阶段:首先,两个争议方将他们的分歧缩小到一个区块;然后(并且只有那时)他们才会将块编译为 Wasm,从而继续将争议缩小到一条 Wasm 指令。然后针对该wasm指令完成争议的裁决。这跟Cannon的原理是一样的。
交易流程:
跟OP基本一样,Arbitrum每1-2分钟往L1提交一次。
在L2上,Sequencer收到交易后,会立即执行并返回结果给调用者,调用者此时可以自己决定信任或不信任Sequencer,因为毕竟还没发布到L1。
对付审查:用户可以在L1延迟收件箱里添加交易,在经过一段时间延迟(当前24h)后,强制在L2包含此交易。
在Arbitrum上,交易被发布到L1后,在L1上有stake的validator可以对当前的发布进行评论,即同意或争议。如果发生争议,就按照Nitro定义的流程进行交互式争议解决。
同样,提款需在7天争议期结束后方可完成。
Deposit交易一般在延迟一段时间(一般10分钟)后,才会被包含在L2交易里,这样做是为了减少L1重组对L2带来影响。
如果Sequencer出问题,此时可以使用特殊路径。在L1上的延迟收件箱里的交易,当过了规定时间(24h)后还没被纳入L2的话,任何人都可以调用SequencerInbox里的forceInclusion,把交易传入核心收件箱,这样这笔交易就被L2确认了。但这样会影响L2上未确认的交易的状态,因此规定的延迟时间是比较长的,用来保证只有特殊情况下才会这样做。另外这样还会导致交易排序问题。
跟OP差不多,包括L1的发布费用和L2的执行费用。给定 Arbitrum 链上的 L2 Gas 价格有一个设定的下限,可以通过ArbGasInfo.getMinimumGasPrice
查询。(目前 Arbitrum One 上为 0.1 gwei,Nova 上为 0.01 gwei)。
AnyTrust 依赖外部DA委员会来存储数据并按需提供数据。该委员会有 N 名成员,假定其中至少有两名是诚实的。
KeySet指定委员会成员的公钥以及DA证书有效所需的签名数量。KeySet使委员会成员的变更成为可能,并为委员会成员提供了更改其密钥的能力。
KeySet包括委员会数量,委员会签名门限,以及BLS公钥。L1 KeysetManager 合约维护当前有效KeySet的列表。L2 链的所有者可以在此列表中添加或删除KeySet。KeySet以hash的方式呈现。
AnyTrust 的核心概念是DACert(即DA证书)。DACert 包含:
数据块的hash
到期时间
N-1 委员会成员已签署(哈希值、过期时间)的证明,其中包括\
\
由于 2-of-N 信任假设,DACert 构成了区块数据(即 DACert 中哈希的原像)可从至少一名诚实的委员会成员处,至少在到期时间之前可获得的证据。
AnyTrust 为Sequencer提供了两种在 L1 上发布数据块的方法:它可以在L1用calldata发布完整数据,也可以发布 DACert 证明数据的可用性。L1 收件箱合约将拒绝任何使用无效密钥集的 DACert。
从收件箱读取数据的 L2 代码会像普通 Nitro 中一样读取完整数据块。如果它看到 DACert,则会参考 DACert 指定的KeySet(由于 L1 收件箱验证了该KeySet,因此已知该KeySet有效)来检查 DACert 的有效性。L2代码验证了
如果 DACert 无效,L2 代码将丢弃 DACert 并移至下一个数据块。如果 DACert 有效,则 L2 代码读取数据块,因为 DACert 有效,所以保证该数据块可用。
数据可用性实现:
委员会成员运行数据可用性服务器 (DAS) 软件。DAS 提供两个 API:
DAS 软件根据配置选项,可以将其数据存储在本地文件中、Badger 数据库中、Amazon S3 上,或者跨多个后备存储进行冗余存储。该软件还支持可选的内存缓存(使用 Bigcache)或 Redis 实例。
当 Arbitrum Sequencer生成要发布的数据批次时,它会通过 RPC 并行将该批次的数据以及到期时间(通常为未来三周)发送给所有委员会成员。每个委员会成员将数据存储在其后备存储中,并按数据的哈希值进行索引。然后,成员使用其 BLS 密钥对(哈希值、过期时间)对进行签名,并将带有成功指示符的签名返回给Sequencer。
一旦 Sequencer 收集了足够的签名,它就可以聚合签名并为(哈希、过期时间)对创建有效的 DACert。然后,Sequencer 将该 DACert 发布到 L1 收件箱合约中,使其可供 L2 上的 AnyTrust 链软件使用。
如果Sequencer未能在几分钟内收集到足够的签名,它将放弃使用委员会的尝试,并通过将完整数据直接发布到 L1 链来“回退到汇总”。
Arbitrum的工作原理:
\
\
EOA和合约将消息放入收件箱。该链一次读取一条消息,并处理每一条消息。这会更新链的状态并产生一些输出。
执行是确定性的——这意味着链的行为是由其收件箱的内容唯一确定的。因此,一旦您的交易被放入收件箱,您的交易结果就可以得知。任何 Arbitrum 节点都可以告诉您结果。所以一旦您的交易被处理,您就可以相信它(即使还没被发布到L1。当然你也可以等待发布到L1才认为交易被确认)。
为了理解Arbitrum,需要考虑如下问题:
Nitro的设计遵循四大理念:
\
\
有两种方式发布:
L1发布交易时,以brotli算法进行压缩,使用最高压缩比。
\
\
Nitro 节点可以被认为是由三个主要层构建的,如上所示:
由于顶层和底层严重依赖 geth ,因此这种结构被称为“geth 三明治”。
状态转换函数(STF)由底部的 Geth 层和中间 ArbOS 层的一部分组成。特别地,STF是源代码中的指定函数,并且隐式地包括由该函数调用的所有代码。STF 将收件箱中收到的交易字节作为输入,并可以访问以太坊状态树的可修改副本。执行 STF 可能会修改状态,最后将发出一个新块的标头(以以太坊的块标头格式),该标头将被附加到 Nitro 链上。
设计RollUp的挑战之一是希望系统在普通执行中表现良好与能够可靠地证明执行结果之间的关系。Nitro 通过使用相同的源代码来执行和证明,但针对两种情况将其编译为不同的target,从而解决了这个问题。
在编译执行Nitro节点软件时,使用普通的Go编译器,生成目标。(节点软件以源代码形式分发,并作为 Docker 映像分发。)
另外,为了证明,状态转换函数的代码部分由 Go 编译器编译为 WebAssembly (wasm)。然后,wasm 代码会经过简单的转换,转换为 WAVM 的格式,当存在争议时,在L1上用WAVM解决。
WAVM与wasm不是完全一样的,Nitro为它做了些适合当前场景的修改:
最有意思的扩展指令是ReadPreImage,它输入一个哈希值H和一个偏移量I,输出H的原文在I处的内容(以及输出内容的长度。如果I已经在末尾,则是0).这个指令在特定的Context下使用:PreImage已知,且其大小小于110kb。
例如,Nitro 链的状态以以太坊的状态树格式维护,该格式被组织为 Merkle 树。树的节点存储在数据库中,通过节点的 Merkle 哈希进行索引。在 Nitro 中,状态树保存在状态转换函数的存储之外,STF 只知道树的根哈希。给定根节点的哈希值,STF 可以使用ReadPreImage
来恢复特定节点的内容,这依赖于树的完整内容是公开的,并且以太坊状态树中的节点将始终小于限定大小。通过这种方式,STF 能够在只存储其根哈希的情况下任意读取和写入状态树的节点。
ReadPreImage的
其他用途是在给定header hash的情况下获取最近的 L2 块头的内容。这是安全的,因为块头是公开的并且具有有限的大小。
跟Cannon几乎一样。先通过二分法找到要挑战的块,然后是要挑战的交易,然后要挑战的opcode,然后挑战。有一些优化,核心思路一样。
这部分的文档描写的很详细,比OP详细多了。可以看下:
https://docs.arbitrum.io/inside-arbitrum-nitro/#the-rollup-chain
OP RollUp在L1上可以有验证者,验证者可以抵押ETH,就有提案权限。
在原理设计上这是可以有一定去中心化的,包括对L1上的链的块的提案,投票,验证,从而得到canonical chain,即rollup chain。这个rollup chain跟L2的链不一定完全一样,因为上面可能有invalid块等。
实际运行中,sequencer当前是官方中心化运行的。
其他不赘述了,可以看下上面的文档。
https://docs.arbitrum.io/arbos/l1-to-l2-messaging
https://docs.arbitrum.io/arbos/l2-to-l1-messaging
L1到L2是可重试的,每笔消息可以有ticket用来重试。
Arbitrum Orbit 允许您创建自己的专用链,该链适用于 :Arbitrum One、Arbitrum Nova或Arbitrum Goerli。
您拥有您的 Orbit 链,并且可以自定义其隐私、权限、费用代币、治理等。
这解锁的可能性示例:\
\
Orbit目前是公共预览版,还没有提供稳定版,所以功能可能会快速迭代。
Orbit是L3,它必须以Arbitrum One, Nova,或Goerli为L2。可以自定义其隐私、权限、费用代币、治理等。可以做到:
\
\
<!--EndFragment-->
如果觉得我的文章对您有用,请随意打赏。你的支持将鼓励我继续创作!