Rollups 大全(2) 架构篇
2022-11-28 19:16
CFG Labs
2022-11-28 19:16
订阅此专栏
收藏此文章

总览


架构设计,和其他设计一样,比如建筑设计,美术设计,艺术设计,讲究极高的审美,独特创新,以及可实用性。聪明的人很多,但是不是谁都能设计出 world class 的工程作品。那么如果没有这种天赋,一条可行的路就是学习优美的设计,临摹大师的画,学习不同作家的写作风格,最后变成自己独树一帜的风格。就像从写的第一篇文章开始,并不是为了吸引流量,搞粉丝,更多是帮助自己梳理逻辑,养成定期输出的好习惯,顺便吸引志同道合的小伙伴。


以太坊的执行层创新完全没有止步,从最新 Optimism 发布的(OP stack)就可以看出端倪(具体我们会再下一篇介绍),当然还有包括 zkSync, StarkNet, Scroll 等,如果开发者能够设计一个开发平台,实现聚合功能,也是一个不错的方向,这意味着用户无需再在不同的执行层做选择,提供一个真正意义上的开发者基础设施服务,提供更契合应用端(比如交易,游戏,社交)的 API,合约开发工具,链的可定制化,甚至实现链和链之间的轻松通信,让以太坊的应用开发者也可以享有 Cosmos 的 App chain Thesis 的功能和主权,那么何乐而不为呢。不过想要拉拢以太坊上应用的工程设计早就有 cevmos 这样的结算层,不过进展并不大。Cevmos 是采用了 Celestia, Cosmos, Evmos 等模块化架构方便以太坊应用开发的开发者平台,通过 Rollmint (用于 Cosmos 生态内的 Rollups SDK 工具,降低 Rollups 启动门槛), 部署 Evmos based chain (Cosmos SDK 链内置了 EVM) 作为 Celestia 上的 Rollup。可以理解为限制性,仅为 Rollups 设计的结算层,功能仅包括提交证明,Rollups 之间转账等。而相较于以太坊这种通用性的结算层(Rollups 或者 non-rollup 的应用),号称可以更为高效的,精准的服务一篮子 Rollups,避免了不必要的与智能合约应用进行的区块竞争。当然最核心的叙事还是能够吸引像 Optimism, Arbitrum 等这种自带众多核心 dapp 的执行层(mono rollups)迁移。尽管 cevmos 也一再强调能够提供 frictionless 的开发者迁移体验,让用户可以重新在 Celestia 的 app-specific (recursive) rollups 环境中实现合约 / 软件部署,但从 monorollups 角度思考, 迁移本身对于其的价值有多大? 乌托邦理想国的设计似乎也需要从人性出发,换位思考,可能设计出的东西可用性更强。所以 To B 的生意,核心还是要和这些执行层,或者 dapp 生态弄好关系,如何为别人赋能,甚至让他愿意与你分一杯羹,这就是创始人的水平了,难度肯定不小。毕竟在一个人才济济,高竞争的赛道,想要拔尖对团队的素质 / 能力 / 韧性要求很高。


以太坊架构


智能合约 rollups 的架构比较简单,本质上就是在以太坊上部署了一个争议解决的智能合约,形成双向最小信任的(trust minimized)桥,这里双向指两方面 (1)以太坊上桥合约负责让链上轻节点监督 rollup 的进展,比如接收区块头,处理欺诈或者有效性的证明,交易状态(轻节点接收部分数据,而全节点接收全部数据)2)而 rollups 本身也帮助验证以太坊。( 这里和 Celestia 不太一样,目前鼓励 rollups 全节点 / 轻节点在 Celestia 上弄个轻节点,而且还要连接一个诚实节点。但是 Celestia 并没有运行反向轻节点观察 rollups,如果这样,那就是 IBC 的双向桥方案。当然目前这样做的思考是 Celestia 觉得如果你的排序器作怪,那么 rollups 肯定没有人用,如果是明显作恶,那么通过社会共识,直接惩罚你在 Celestia 上的抵押就行了,无需再弄个自动的东西,比如合约。在他们看来,社会共识大于 code, 大于 token, 大于节点,人是核心。这也和我们的理念非常契合。当然我们下文会讨论 Celestia 团队的双向桥设计方案思考,不过目前还比较早期,因为双向桥的设计会增大 Celestia 的设计难度,以及节点的 overhead cost)。这里的设计也结合了 cryptoeconomic 的惩罚,如果 operator 没有提交正确的交易,那么他质押的钱就会被 slash 掉 (或者 staking 等方案),本质上还是提高了作恶成本。链上智能合约解决欺诈证明这里有个问题,尽管提交和仲裁过程很快,但是 L1 合约收到证明需要过程,而且也很可能会遇到 L1 的审查。这里就需要引入社会共识。而这个问题在 sovereign rollups (Celestia 的环境中)并不普遍存在,因为欺诈证明是通过 P2P 流言协议传播,因此在避免了 L1 的审查风险的同时,也可以大大缩减这个挑战期限,使得轻节点可以完成快速的确认。


在这个架构中,以太坊扮演了共识和 DA 的双重角色,并且根据桥合约最终确认有效交易(桥合约会过滤无效交易)。Rollups 的全节点和轻节点并不能和其他 L1 一样,根据本地的节点决定 fork choice rule 或者交易有效性规则,还是需要依赖于以太坊轻节点的信息源。所以本质上主链的规则还是 L1 说了算。其实以太坊也可以运用类似 IBC 的双向节点的方式,不过他们没有采用也能理解。以太坊总有一种官方指导范式的感觉,对于其他的方式,不会主动去采用接纳,比如以太坊基金会没有给你背书,那么你的项目难度会很大 (Hongyi W3 hitchiker)。当然既然存在智能合约就会存在智能合约风险等部署风险,而 Celestia 就没有引入任何执行环境支持这类的运用智能合约的桥,不过未来是否会引入,通过什么方式引入,如何解决这些问题,我们会为大家一一解离。


除了智能合约 Rollups, Starkware 为代表的 L1-L3 的设计也成为了很多新项目的首选架构。比如 Solana VM 模块化项目 Eclipse, 除了解决争议的结算层以外的设计(L2), DA& 共识 (L1),其 L3 层引入包括独立费率市场,高 TPS,共享工具,开发者社区,可支持的代币标准等功能。而 StarkNet 本身的设计中,L3 的功能包括独立,隐私以及可扩展性。当然除了拥有自己的费率市场,完整的区块空间 (1% in Ethereum)以外,app specific rollup (recursive rollups, 或者叫 appchain whatever) 的最终普及还需要很多因素的助力,比如是否有可行互操作性协议(桥功能)实现 intra-cluster 以及 inter-cluster 之间的通讯,比如是否有足够的流行性共享支持等。


较于 Cevmos 的设计,StarkNet (L2) 的结算层并非加以限制,而是一个类似于以太坊更为通用性的平台。通用性,也就意味着有更多的设计空间,和可组合型。同时,Cevmos 更是严格意义上 Celestia 生态主打的 Sovereign Rollups,而 StarkNet 还是以太坊中 Smart Contract Rollups 中的变种。在 StarkNet 设计中,比较有趣的是 L2 的设计,L2 的验证合约可以将众多合约 L3 的有效性证明聚合为一个证明,验证这些交易,从而生成一个最终的交易,发布到以太坊的链上合约上。这种设计一方面提升了以太坊的验证效率(验证聚合 N 条 Proof 的时间,和之前验证单条 proof 的时间相当)同时也为 L3 带来了更多的设计优化空间(比如 DA 层的链下设计)。这里我们不妨与 zk bridging 的设计做些对比。zk briging 是一种终极解决方案,或许我们需要一种更为扁平化的设计方案。这里我们以 SR(soveregin rollups 有自己结算层的 rollups)来举例。如果 Rollup 1 想和其他 Rollups 搭建最小信任化桥,他可以怎么做?这种设计引入了所谓的聚合服务提供商的角色,相较于 SR1 提供结算层,并且在其他(n-1)Rollups 部署轻节点,接收(n-1)条证明的方式相比,聚合服务提供商大大减少 SR1 本身的工作压力。服务商不仅负责在其他 SR 上部署轻节点,同时负责接收 SR2-SRn 的证明,并且在链下实现多条证明的验证,并且聚合生成证明,并且最终发布到 SR1 链上。链下操作的操作又大大减少了成本,同时避免了像 Starkware 中高度依赖流动性结算层(L2)做验证,或者桥功能的问题,大大减少了延迟性问题。终极方案 enshrined  rollups 留着下次介绍。


Celestia 的主权 Rollup


刚才上文提到,相较于智能合约 rollups,主权 rollup 有自己的客户端结算层,而无需通过以太坊上的轻节点决策主链。本质上你可以理解为就是一条 L1,全节点和轻节点通过 P2P 流言网络下载区块数据,同时他们在 Celestia 上的轻节点也用于追踪数据的有效性和排序。而 L1 的 fork choice rule 以及交易规则等也取决于本地验证节点。


这里欺诈证明和有效性证明的传播方式也是通过 P2P,而非智能合约的链上确认。轻节点确认状态转换,而共识节点确认有效性。好处,上文也提到了,轻节点的快速确认,不必要的挑战期,以及 P2P 网络中更为优化的同步延迟性。


另外, 目前 Rollups 与 Celestia 并没有通过双方最小信任桥连接。原因上文已经提到过。其实我很喜欢主权 Rollup,但是深挖之后,发现过于理想化,因为不认同不可变更的 L1 代码 / 合约 100% 解决问题的能力,所以希望更多的通过社会共识 / 硬分叉解决问题,比如交易的有效性法则,比如分叉规则等,理解起来非常抽象。以往,硬分叉 (ETC 和以太坊之间的分叉)被认为很稀奇,未来会不会成为一个 feature, 而非 bug。当然理念归理念,这种情况下如果要在最小信任桥的基础上实现起来的工程复杂度非常困难,如果一个链硬分叉,那么另一条链也需要硬分叉,那么上面的应用怎么去应付这些?当然这只是一种桥设计,这里也带来更多桥设计的空间,比如可更新桥的设计。有兴趣的同学可以再去深入研究下https://blog.celestia.org/sovereign-rollup-chains/。 


这里我想重点讲的是动态和静态桥以及基于他们衍生出的可升级桥。Sovereign Rollup/ 链的升级通常可以通过多签,链上治理,或者 SR 中强调的硬分叉来实现。而不同链之间如果要实现互操作性,那么肯定需要引入桥(不管是信任桥,最小化信任桥,IBC,甚至是内置桥等,当然未来在原子互换的基础上,甚至不需要桥),比如可以解读双方的状态机器,以及欺诈或者有效性证明。一般情况下,如果两条链都属于 EVM, MOVEVM, 等智能合约,那么双方之间的状态机器代码可以直接添加(当然可能会用到解析智能合约比如 SR1 是 evm chain, 想了解 move 或者 sealevel SR, 那么就需要引入 move 和 sealevel 解析器 )。这种无需引入社会共识和治理等的桥接过程,我们称为动态桥。通过解析智能合约就可以实现。


但是如果 Rollup A 是基于 Cosmos SDK 开发的,而非智能合约环境,那么 A 和 B 的桥的搭建就需要引入硬性升级了 (比如 Celesita 中的 EVM Rollups 和 Cosmos Hub)。这种桥也可以通过 IBC 轻客户端的方式实现。那么上述的桥如何实现升级呢?


假设 RollupA 现在需要硬分叉了,那么 B 也需要更新节点 (比如谁来更新,除了通过轻节点 (P2P settlement),也可以有其他实现形式,比如硬分叉,或者链上智能合约 (onchain settlement)


在动态桥情况下,1)A 链的节点可以帮助更新 B 链上的轻节点,因为桥的交易是通过一个社群 / 团队控制的,我们称为是信任桥。2)当然 B 链也可以自主更新。这取决于相关的治理和经济安全性,可信任桥 3)最小信任桥的设计中,智能合约可以解析 rollup 状态,并且验证有效性。类似于以太坊中的智能合约 Rollup。而对于静态桥,由于他们是内置的合约关系(上文提到的那种情况),那么 B 链也需要硬分叉,不可行。对这块有深度研究的同学欢迎一起讨论。


主权结算层 +recursive rollups


本质也是主权 rollups 的细分。这种设计是我觉得相对可行的方案。zk-bridging 主宰的 SR 世界很酷,不过有很大风险不会成为现实,或者我们说很难在短期成为现实,那么短期可实现的方案就是通过叙事 rollups as the service 的新一代结算层,来摒弃以太坊这个老古董。和 Cevmos 的设计理念类似,这种主权结算层上搭建的是各类 app-specific rollups,这部分 rollups 更强调 feature, 而非主权,没必要单独弄个主权链出来。但是相比于智能合约应用,拥有独立的费率市场,区块空间,而相比于 Cosmos App 链,也不需要一开始大费周章的去搞自己的节点生态,那可有钱有势力的金融家玩的丛林游戏,我们做好产品,吸引用户,没必要分散太多精力。当然高性能,低 gas 费率,聚合功能,灵活开发等是千百年不变的真理。没有这些,你怎么去吸引 dapp 开发者?这里的设计简单,可实现,避免了冗余复杂的桥设计。


目前比较桥的主流方案认为可以归为四种,从安全程度低到高分别介绍:


1)社区主导的桥,这种一般是多签的设计,比如委员会成员有 10 个人,那么 6 个人签名代表交易通过。如果 5 个人勾结打算停止签名交易,那么就停掉了。如果六个月要偷钱,那么资金也没了,当然你可以引入一系列惩罚机制。但是不可否认这并不是终极解决方案。因为少数人存在很强的作恶可能性。这也是为什么 rollup 更新目前 you 少数控制私钥引发的社区持续激烈的讨论。


2)轻客户节点

有种观念, IBC 也是社区主导的桥,当然这个社区更大了,更有威信了,都是拥有大量质押资产,质押比例的大节点,当然人数也更多了,Tendermint 100-150 个节点,但还是那么一帮人,取决于桥连接的两条链的安全,而这个安全由链的大多数诚实验证节点给到我们。所以不可否认 IBC 的安全还是这些节点掌控者,但是你可以通过提高足够的质押分配比例来减少勾结问题,你可以通过质押足够多的币来保证网络的经济安全。当然从某种意义上讲这比第一种方案要安全。


3)第三种可能更适用于 rollup 的环境,考虑到 rollups 并不会考虑引入大量的节点集,那么第三方的桥服务商可能很乐于提供这种服务。比如说类似于 Axelar 或者 Polymer 的 App chain 节点可以参与进来,通过跟踪结算层 rollup 的状态,通过结算层上部署的桥合约(多签或者阈值加密合约)实现资产的从结算层到这个 hub 的流转。


4)第四种最小信任桥,这种类似于以太坊的智能合约 Rollups,验证状态转换的欺诈 / 有效性证明以及 DA。当然还是会有智能合约的部署风险。上文也提到 Celestia 并不支持这种智能合约环境,但是如果将 Rollup 以及桥的设计嵌入在 Celestia 中,是可以实现这种 two way 最小信任桥的。对于 Celestia 来说,也会引来额外的工程难度,也给共识节点和非共识节点带来了额外工作量,尽管在 fraud/validity provable 结算层的环境中,这种工作量也是最小化的。当然你还需要下载额外的结算层数据。相比于以太坊的 state root 等效的 zkevm rollup, Celestia 这种方案或许也是一个不错的技术突破点,甚至可以解决其价值捕获,资产流转的根本性问题。


https://forum.celestia.org/t/an-open-modular-stack-for-evm-based-applications-using-celestia-evmos-and-cosmos/89


https://blog.celestia.org/sovereign-rollup-chains/


The Complete Guide to rollups Delphi Digital


https://forum.celestia.org/t/considerations-for-a-two-way-bridge-to-celestia/355

相关Wiki

【免责声明】市场有风险,投资需谨慎。本文不构成投资建议,用户应考虑本文中的任何意见、观点或结论是否符合其特定状况。据此投资,责任自负。

CFG Labs
数据请求中
查看更多

推荐专栏

数据请求中
在 App 打开