近期,已有一些项目开始尝试使用Madara为其应用链进行实验,例如Pragma、Kakarot、Mangata Finance和Dojo等。只要我们坚信多链未来以及zk扩展的潜力,未来将会有更多此类项目浮现。然而,应用链数量的增加也带来了一些问题
原文标题:Shared sequencers for Starknet and Madara app chains
原文作者:apoorvsadana
原文来源:Starknet
编译:MarsBit,MK
介绍
近期,已有一些项目开始尝试使用Madara为其应用链进行实验,例如Pragma、Kakarot、Mangata Finance和Dojo等。只要我们坚信多链未来以及zk扩展的潜力,未来将会有更多此类项目浮现。然而,应用链数量的增加也带来了一些问题,主要包括:
• 去中心化
• 可组合性
• 开发体验
在本文中,我将尝试阐述因拥有大量应用链而引发的问题,并提出一种我认为对Madara和Starknet来说优雅且最佳的可能解决方案。如果你对应用链和共享序列化非常熟悉,可直接跳至“等等,这不就是Polkadot重演吗?”部分。
100个应用链会发生什么?
假设我们处于一个现实场景,有100个不同的应用链在以太坊上结算。我们来探讨这会导致的所有问题。
去中心化的碎片化
每个应用链都需要独立解决去中心化的问题。目前,应用链的去中心化并非像L1那样必需,主要是因为我们依赖L1以确保安全性。然而,我们仍需去中心化以保证活跃性、抵抗审查以及避免垄断优势(例如高费用)。然而,如果每个应用链都以自身的方式解决去中心化问题,很快会导致验证者集的碎片化。每个应用链都必须制定经济激励措施以吸引新的验证者。此外,验证者还需要选择他们愿意运行的客户端。更不用说,这为开发者启动自己的应用链(与部署智能合约相比,后者仅是一笔交易)设置了很高的门槛。
可组合性
可组合性基本上意味着跨应用交互。在以太坊或Starknet上,这只意味着调用另一个合约,剩下的所有事务都由协议本身处理。然而,对于应用链来说,这变得更为困难。不同的应用链具有自身的区块和共识机制。每次你尝试与另一个应用链交互时,都需要仔细检查共识算法和最终性保证,并相应地设置跨链桥梁(直接连接到链或通过L1)。如果你想与10个设计不同的应用链交互,你需要做10次不同的设置。
开发体验
解决去中心化和桥接问题并非易事。如果这是每个应用链的要求,那将使通常的智能合约开发者难以构建自己的应用链。此外,随着每个应用链试图以自己的方式解决这些问题,我们很快就会看到不同的链遵循不同的标准,这使得加入生态系统变得更加困难。
共享序列器可以解决这个问题
现在,如果你一直在关注应用链领域,你可能已经听说过“共享序列器”这个术语。它指的是为所有链拥有一组公共验证者的概念,以解决上述问题。以下是它的工作原理。
共享去中心化
共享序列器的本质是你不需要为每个应用链或L2拥有不同的验证者集。相反,你可以拥有一个非常高效且去中心化的验证者集,为所有链排序区块!想象一个包含来自100个不同应用链交易的区块。你可能会认为,由于需要处理每个应用链的执行引擎,这实际上会使序列器变得非常臃肿。
其实不是这样!
由于目前几乎每个序列器都是中心化的,序列器被视为一个收集交易、对其进行排序、执行它们并将结果发布到L1的单一应用程序。然而,这些任务可以分成多个模块化组件。为了解释,我将它们分为两个部分。
• 排序引擎:负责按特定顺序排列交易。一旦排序引擎确定了这个顺序,就必须遵守它。通过在L1上提交此顺序并强制L1验证者检查交易是否按照所需顺序执行来实施这一点。
• Rollup引擎:Rollup引擎基本上负责Rollup的所有其他操作 - 从用户处收集交易,执行它们,创建证明并在L1上更新状态。理想情况下,这可以分解为更多的组件,但是我们在这篇文章中会避免这样做。
在这里,排序引擎是共享序列器,而Rollup引擎基本上是所有Rollup逻辑。所以交易的生命周期看起来是这样的:
共享序列器基本上负责为Rollups跨区块排序交易并将它们提交给L1。因此,通过去中心化共享序列器集,你基本上是在去中心化与该序列器集相关联的所有Rollups!为了更详细地了解共享序列器的工作原理,你也可以参考Espresso的这篇精彩文章。
可组合性
可组合性的主要问题之一是理解交易在另一个应用链上何时最终确定,并在你的链上相应采取行动。然而,借助共享序列器,两个可组合的Rollups可以相互分享区块。因此,如果Rollup B上的交易回滚,整个区块都会回滚,这会导致Rollup A上的交易也回滚。
现在,这确实听起来比实际操作要简单。为了实现Rollups之间的通信,需要有效且可扩展的解决方案。共享序列器需要制定适当的标准,以确定Rollups如何通信,跨链消息应该是什么样的,如何处理Rollup升级等。虽然这些问题是可以解决的,但它们很复杂且不容易解决。
开发者体验
虽然共享序列器确实抽象了去中心化方面,并使得跨链消息传递更为简单,但每个链仍然需要遵循一些标准以保持与共享序列器的兼容性。例如,所有Rollup交易都需要转换为序列器理解的通用格式。同样,需要从序列器中过滤区块以获取相关交易。为了解决这个问题,我想共享序列器会提供Rollup框架或SDK,以抽象掉样板代码,并只向应用链开发者展示业务逻辑部分。
下面是一张带有共享序列器的应用链的示意图:
等等,这不就是Polkadot重演吗?
Polkadot在以太坊之前就开始着手于多链未来的工作。事实上,他们已经投身于这项工作超过5年了,如果你熟悉Polkadot,你可能已经注意到上面的设计基本上是在重新发明Polkadot已经完成的很多事情!
中继链(共享去中心化)
中继链基本上是上述序列图中的排序引擎+L1。中继链:
• 跨所有平行链(Rollups)排序交易
• 它验证交易是否正确执行(而不是通过zk验证,它实际上重新运行了Rollup的执行代码以验证状态差异)
你可能已经意识到,中继链基本上是我们上面讨论的共享序列器。除了中继链还需要验证执行(因为Polkadot是L1),而我们将其留给以太坊来处理。
XCM和XCMP
我们在上一节中提到,如果每个链都构建自己与其他链互操作的方法,我们很快就会在所有链上看到不同的标准和格式。你需要跟踪与你交互的每个链的所有这些格式。此外,你还需要回答例如链升级时会发生什么的问题。然而,通过引入所有链必须遵循的标准,可以优雅地解决这些问题。
正如你可能已经猜到的,Polkadot已经完成了这个任务。XCM是消息格式,XCMP是所有基于底质的链可以用来相互通信的消息协议。我不会深入探讨它,但你可以在这里阅读有关它的信息。
底质和Cumulus
底质是由Parity开发的可以用来构建区块链的框架。虽然Polkadot上的所有平行链都使用底质,但底质实际上是以与链无关的方式构建的。该框架抽象了区块链的所有常见方面,使你可以专注于你的应用逻辑。正如我们所知,Madara是基于底质构建的,Polkadot、Polygon Avail和许多其他项目也是如此。此外,Cumulus是基于底质之上的中间件,允许你将你的链连接到Polkadot。
因此,延续我们之前的类比,底质和Cumulus可以被视为替代Rollup框架的解决方案,允许你构建应用链并将它们连接到共享序列器。
共享序列器 → 中继链
可组合性 → XCM和XCMP
Rollup框架/栈 → 底质和Cumulus
是的,这实际上完全是Polkadot的重演!除此之外,Polkadot和Parity拥有一些最有经验和资金雄厚的团队,他们继续构建Substrate和Polkadot,增加更多功能并使其更具可扩展性。这项技术已经经过多年的战斗测试,并且已经拥有大量的开发工具。
在以太坊上置用Polkadot?
虽然确实Polkadot在以太坊之前就开始构建多链未来,但不可否认的是,截至目前,以太坊仍然是最去中心化的区块链,并且是大多数应用和流动性所在的地方。然而,如果有一种方法可以将所有的Polkadot技术引入以太坊生态系统,那会怎样呢?
确实有这种可能!实际上,我们已经通过Madara开始了这个过程。Madara使用Substrate框架,允许任何人在以太坊之上构建自己的zk-powered L2/L3解决方案。接下来我们需要的是以共享序列器形式的Polkadot中继链。所以基本上,如果我们能重用Polkadot中继链,但是
• 删除验证部分,因为这发生在L1上通过zk证明
• 将交易顺序提交给L1
• 优化节点和共识算法以支持Tendermint/HotStuff
我们就可以得到之前提到的共享序列器。显然,这比说起来容易做起来难。然而,我相信这条路径比从头开始重建序列器、标准和框架更为务实。Polkadot已经以一种与链无关的方式解决了很多问题,我们可以借鉴给以太坊。作为副产品,我们得到了
• 一个继续构建和教育世界有关Substrate的积极开发者集合
• 一个积极的开发者工具集和强大的社区
• 许多活跃的平行链可以选择在以太坊上结算,如果他们愿意的话(我们最近看到Astar通过Polygon CDK做了同样的事情)
结论
我写这篇文章的主要想法是在Starknet和以太坊的更广泛生态系统中开展讨论。我觉得共享序列模型在Starknet的去中心化以及所有考虑在其上构建的应用链中将发挥重要作用。只要我们对应用链的论文和zk扩展充满信心,对共享序列模型的深入分析就是不可避免的。此外,由于Madara正在向生产迈进,Starknet已经开始着手去中心化工作,我认为现在是解决这个问题的重要时刻。因此,我请求所有阅读此文的人提供您对此话题的任何反馈/建议。期待阅读您的想法!
附录
Polkadot与Cosmos
与Polkadot相似,Cosmos已经为多链未来解决了很多年。因此,它通过Cosmos SDK和IBC做了很多开发,我们也看到了很多应用链正在构建在Cosmos生态系统之上。因此,考虑Cosmos对此方法也是公平的。我个人对此话题的看法是,Polkadot更为相关,因为它解决了共享序列器问题,而Cosmos要求每个应用链构建自己的验证者集。此外,Substrate一直以无关链的方式构建,以允许开发者构建区块链,而不需要对共识算法或Polkadot生态系统做任何假设。这也是我们选择Substrate为Madara的原因。然而,话虽如此,我在Cosmos上的经验有限,我很愿意从更有经验的人那里听到更多关于这个话题的信息!您还可以在这里找到关于这两个网络比较的更多信息。