Starknet与Madara应用链如何通过共享排序器提升区块链性能

引言

当前区块链领域已经涌现出一批积极探索Madara应用的项目，包括Pragma、Kakarot、Mangata Finance和Dojo等。随着我们对多链未来和zk扩展能力的信心不断增强，预计将有更多项目加入这一行列。不过，应用链数量的激增也带来了一系列值得关注的问题，包括去中心化程度不足、跨链互操作性挑战以及开发者体验的优化等。

本文将深入探讨应用链大规模部署可能引发的各类问题，并针对Madara和Starknet生态提出一个切实可行的解决方案。对于已经熟悉应用链和共享排序概念的读者，可以直接跳转至”这简直是Polkadot的翻版”部分获取核心观点。

百链齐发的挑战

设想一个由100条应用链组成的以太坊生态，我们需要直面由此产生的各种复杂问题。

去中心化的困境

每条应用链都需要独立解决去中心化问题。虽然目前应用链的去中心化程度不及底层协议那么关键——毕竟我们依赖底层协议来保障安全性——但适度的去中心化对于确保系统活力、抗审查性以及避免垄断定价等问题仍然至关重要。然而，如果每条链都采用不同的去中心化方案，很快就会导致验证者资源严重分散。每条链都需要设计专门的经济激励机制来吸引验证者，而验证者又必须谨慎选择支持的客户端。这种复杂性无疑为开发者自主构建应用链设置了极高的门槛，远非简单的智能合约部署可比。

互操作性难题

区块链的可组合性本质上是关于跨应用交互的能力。在以太坊或Starknet上，这通常意味着直接调用其他合约，底层协议会自动处理后续流程。但对于应用链而言，情况就复杂得多。每条链都有自己独特的区块结构和共识机制，每次跨链交互都需要仔细考量对方的共识算法和最终性保证，并建立相应的跨链桥接方案——无论是直接连接还是通过底层协议中转。如果需要与10条架构各异的应用链交互，就意味着要重复10次完全不同的对接流程。

开发者体验的痛点

解决去中心化和跨链桥接问题绝非易事。如果这些成为每条应用链的标配要求，普通智能合约开发者将很难独立构建应用链。更棘手的是，由于各链采用不同的解决方案标准，整个生态系统很快就会陷入标准混乱的局面，进一步加大新成员的加入难度。

共享排序器的破局之道

关注应用链发展的读者可能对”共享排序器”这个概念并不陌生。其核心思路是通过为所有链提供统一的验证者集合，来系统性地解决上述问题。

去中心化的共享方案

共享排序器的革命性在于，它消除了为每条应用链单独建立验证者集合的必要性。取而代之的是一组高效且去中心化的验证者，负责为所有链的交易排序！想象一个包含100条不同应用链交易的区块，你可能会担心排序器会因此变得臃肿不堪——毕竟它需要兼容每条链的执行引擎。

但实际上并非如此！

当前大多数排序器都是中心化运作，被视为单一应用，负责交易收集、排序、执行并将结果提交至底层协议。但这些功能完全可以拆分为模块化组件。为便于理解，我们将其分为两个核心部分：

排序引擎专门负责确定交易顺序，一旦顺序确定就必须严格执行。这种强制性通过在底层协议上提交排序结果，并要求协议验证者核查执行顺序来实现。Rollup引擎则负责其他所有功能——收集用户交易、执行交易、生成证明并更新底层协议状态。理论上这些功能可以进一步细分，但本文不做深入探讨。

在这种架构下，排序引擎就是共享排序器，而Rollup引擎则包含了所有Rollup逻辑。整个交易生命周期如下图所示：

简而言之，共享排序器负责对Rollup交易进行排序并提交至底层协议。因此，通过实现排序器集合的去中心化，实际上就实现了所有关联Rollup的去中心化！想更深入了解共享排序器工作原理的读者，可以参考Espresso团队撰写的这篇深度解析。

互操作性的提升

跨链互操作的主要难点在于确认对方链上交易完成状态，并据此在本链执行相应操作。但在共享排序器架构下，两个可组合的Rollup实际上共享同一个区块。如果Rollup B上的交易需要回滚，整个区块都会回滚，连带Rollup A上的交易也会撤销。

当然，实现这一愿景并非易事。Rollup间的通信必须高效且可扩展，共享排序器需要制定完善的跨链通信标准，包括消息格式、Rollup升级处理机制等。虽然这些都是可以解决的问题，但其复杂性不容小觑。

开发者体验的优化

尽管共享排序器抽象了去中心化环节并简化了跨链通信，但每条链仍需遵循特定标准才能与排序器兼容。例如，所有Rollup交易都需要转换为排序器能够理解的通用格式，同时需要从排序器区块中筛选出相关交易。为解决这些问题，预计共享排序器将提供专门的Rollup框架或SDK，帮助开发者聚焦业务逻辑而无需关心底层细节。

下图展示了应用链与共享排序器的典型架构：

这简直是Polkadot的翻版

Polkadot实际上早于以太坊就开始探索多链未来的发展路径。经过五年多的深入研究，熟悉Polkadot的读者可能已经发现，上述设计方案在很大程度上复用了Polkadot的现有架构！

中继链的启示

中继链本质上对应着前文提到的排序引擎加底层协议。它主要实现两大功能：为所有平行链(即Rollup)的交易排序，以及验证交易执行的正确性(与zk验证不同，它通过重新执行Rollup代码来验证状态变更)。

不难发现，中继链实际上就是我们讨论的共享排序器。区别在于中继链还需要验证执行结果(因为Polkadot是底层协议)，而我们把这个职责留给了以太坊。

XCM与XCMP协议

前文提到，如果每条链都自定义跨链交互方式，很快就会导致标准混乱。开发者需要跟踪每条交互链的不同格式，还要考虑链上升级等复杂情况。这些问题都可以通过制定统一的跨链标准得到完美解决。

正如你所料，Polkadot已经实现了这一点。XCM是标准的消息格式，而XCMP则是底层链相互通信的协议标准。本文不展开详细说明，有兴趣的读者可以参考官方文档。

Substrate与Cumulus框架

Substrate是Parity开发的区块链构建框架。虽然Polkadot上的所有平行链都使用Substrate，但该框架本身设计为链无关的。它抽象了区块链的通用功能，让开发者可以专注于业务逻辑。值得注意的是，Madara正是基于Substrate构建的，Polkadot、Polygon Avail等众多项目也是如此。Cumulus则是构建在Substrate之上的中间件，专门用于将链接入Polkadot网络。

延续我们的类比，Substrate和Cumulus可以视为Rollup框架的替代方案，用于构建应用链并接入共享排序器。

共享排序器 → 中继链

跨链互操作 → XCM和XCMP

Rollup框架 → Substrate和Cumulus

这几乎就是Polkadot架构的翻版！除此之外，Polkadot和Parity拥有业内经验最丰富、资金最充足的开发团队，持续为Substrate和Polkadot添加新功能并提升可扩展性。这项技术已经过多年实战检验，并提供了大量开箱即用的开发工具。

以太坊上的Polkadot？

虽然Polkadot在多链探索上先行一步，但不可否认当前以太坊仍是去中心化程度最高、应用和流动性最集中的区块链。那么，有没有可能将Polkadot的技术优势引入以太坊生态呢？

答案是肯定的！实际上，我们已经在通过Madara推进这项工作。Madara使用Substrate框架，允许开发者在以太坊上构建支持zk证明的二层/三层解决方案。接下来我们需要的就是以共享排序器形式存在的Polkadot中继链。具体来说，如果我们能够复用Polkadot中继链，同时做出以下调整：移除验证环节(通过zk证明在底层协议完成)、将交易顺序提交至底层协议、优化节点和共识算法以支持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生态系统限制的情况下构建区块链。这也是我们为Madara选择Substrate的重要原因。当然，我对Cosmos的了解有限，很期待听取更有经验的观察者的见解！更多对比信息可以参考官方比较文档。