引言

今天，我们已经看到一些项目开始在其应用程序链中尝试使用 Madara，例如Pragma、Kakarot、Mangata Finance 和 Dojo 等。只要我们相信多链的未来和 zk 扩展的力量，我们将来只会看到更多这样的项目出现。然而，随着应用链数量的增长，也有一些问题浮现。例如：

1. 去中心化
2. 可组合性
3. 开发经验

在这篇文章中，我将尝试探讨因大量应用链出现而带来的问题，并提出一个我认为对 Madara 和 Starknet 问题来说合理且最佳的可能解决方案。如果您已熟知应用程序链和共享排序，请直接阅读“瞧瞧，这只是 Polkadot 的重演”部分。

当有100个应用链时会发生什么？

假设我们现在有100个不同的应用链定居在以太坊上，我们尝试解决这将导致的所有问题。

碎片化的去中心化

每个应用链都需要自行解决去中心化问题。现在应用链的去中心化并不像第1层协议那样是必要的，主要是因为我们依赖第1层协议来确保安全。然而，我们仍需要去中心化来确保活力、抗审查性并避免垄断优势（例如高额费用）。但还需要注意的是，如果每个应用链继续以自己的方式解决去中心化问题，这将很快使验证者集碎片化。每个应用链都必须制定经济激励措施用于加入新的验证者。此外，验证者需要选择他们愿意运行的客户端。更不用提的是，这为开发人员推出自己的应用链（相对于部署只是一笔交易的智能合约）造成了巨大的进入壁垒。

可组合性

本质上，可组合性意味着跨应用程序交互。在以太坊或 Starknet 上，这仅意味着调用另一个合约，其他一切都由协议本身处理。然而，对于应用链，这变得更加困难。不同的应用链有自己的区块和共识机制。每次您尝试与另一个应用链进行交互时，您都需要仔细检查共识算法和终局性保证，并相应地建立跨链桥（直接连接到链或通过第1层协议连接）。如果您想与10个具有不同设计的应用链进行交互，您需要执行10次不同的操作。

开发经验

解决去中心化和桥接问题并不容易。如果这是每个应用链的要求，那么普通智能合约开发人员将很难构建自己的应用链。此外，由于每个应用链都试图以自己的方式解决这些问题，我们很快就会看到不同的链遵循不同的标准，这使得加入生态系统变得更加困难。

共享排序器可解决此问题

现在，如果您关注应用链领域，您可能听说过“共享排序器”这个术语。这是为所有链提供一组通用的验证者的想法，旨在解决以上提到的问题。这就是它的工作原理。

共享去中心化

共享排序器的本质是，您不需要为每个应用链或第2层协议拥有一组不同的验证者。相反，您可以拥有一组真正高效且去中心化的验证者，对所有链的区块进行排序！想象一下包含来自100个不同应用链的交易的区块。您可能会认为这会让排序器变得非常臃肿，因为您需要能够处理每个应用链的执行引擎。

但是你没有这样做！

由于如今几乎每个排序器都是中心化的，因此排序器被视为是一个单一的应用程序，用于收集交易、对交易进行排序、执行交易并将结果发布到第1层协议上。但是，这些作业可以分为多个模块化组件。为了便于解释，我将它们分为两部分。

1. 订单引擎：负责按特定顺序对交易进行排序。一旦订单引擎决定了该订单，就必须遵循它。这是通过在第1层协议上提交此顺序并强制第1层协议验证者检查事务是否按所需顺序执行来强制执行的。
2. Rollup 引擎：Rollup 引擎基本上负责 Rollup 所做的所有其他事情 - 收集用户的交易、执行它们、创建证明并更新第1层协议上的状态。理想情况下，可以将其分解为更多组件，但在本文中我们不做此阐述。

这里的排序引擎是共享排序器，而rollup引擎基本上是所有rollup逻辑。所以交易生命周期看起来像如下图中所示：

基本上，共享排序器对rollup中的事务进行排序并将其提交到第1层协议。因此，通过将共享定序器集去中心化，您基本上可以将链接到该定序器集的所有rollup去中心化！要更详细地了解共享排序器的工作原理，您还可以参考 Espresso 的这篇精彩文章 17

可组合性

可组合性的主要问题之一是了解交易何时在另一个应用链上完成，并相应地在您的链上采取行动。但对于共享定序器，两个可组合汇总彼此共享区块。因此，如果事务在rollup B 上重新计算，则整个区块都会重新计算，这会恢复 rollup A 上的事务。

听起来这确实是说起来容易做起来难。为此，rollup之间的通信需要高效且可扩展。共享排序器需要就 Rollup 如何通信、跨链消息应该是什么样子、如何处理 Rollup 升级等提出适当的标准。虽然这些都是可以解决的问题，但它们很复杂且不容易解决。

开发者经验

虽然共享定序器确实抽象了去中心化方面并使跨链消息传递更容易，但每个链仍然需要遵循一些标准才能与共享排序器兼容。例如，所有rollup事务都需要转换为排序器可以理解的通用格式。类似地，需要过滤来自排序器的区块以获取相关交易。为了解决这个问题，我假设共享排序器会提供rollup框架或 SDK，用于抽象样板代码并仅向应用链开发人员公开业务逻辑部分。

下图为应用链与共享排序器的外观图

瞧瞧，这只是 Polkadot 的重演

Polkadot 早在以太坊之前就开始研究多链的未来发展。事实上，他们已经为此研究了5年多，如果您熟悉 Polkadot，您可能已经注意到，上述设计基本上是重新发明了 Polkadot 已做过的很多事情！

中继链（共享去中心化）

中继链基本上是以上序列图中的排序引擎 + 第1层协议。中继链

1. 对所有平行链上的交易进行排序（rollups）
2. 它验证交易是否正确执行（而不是使用 zk 验证，它实际上重新运行 rollup 的执行代码来验证状态差异）

您可能已经意识到中继基本上是我们上面讨论的共享定序器。除了中继链还需要验证执行情况（因为 Polkadot 是第1层协议），而我们将其留给以太坊。

XCM 和 XCMP

我们在上一节中提到，如果每个链都构建自己的方法来与其他链互操作，那么我们很快就会因为所有链上的不同标准和格式而感到体验的臃肿性。您需要跟踪您与之交互的每个链的所有这些格式。此外，您还需要回答诸如如果链升级会发生什么？然而，这些问题可通过引入所有链都必须遵循的标准来很好地予以解决。

正如您可能已猜到的那样，Polkadot 已经做到了这一点。 XCM 是消息传递格式，XCMP 是所有底层链都能用来相互通信的消息传递协议。本文不做详细解释，请访问此链接做进一步了解。

Substrate 和 Cumulus

Substrate 是 Parity 开发的一个可用于构建区块链的框架。虽然 Polkadot 上的所有平行链都使用substrate，但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 支持的第2层/第3层解决方案。接下来我们需要的是共享排序器形式的 Polkadot 中继链。所以基本上，如果我们可以重用 Polkadot 中继链，但是

1. 删除验证部分，就像通过 zk 证明在第1层协议上发生的那样
2. 将交易顺序提交给第1层协议
3. 优化节点和共识算法以支持Tendermint/HotStuff

我们可获得前面提到的共享排序器。显然，这说起来容易做起来难。然而，我相信这种方法比从零开始重建排序器、标准和框架更务实。Polkadot 通过与各种链兼容的方式，已解决了很多问题，我们可以借用以太坊的经验。作为副产品，我们得到

1. 一群活跃的开发人员，他们能继续构建并向行业传授有关 Substrate 的知识
2. 活跃的开发人员工具集和强大的社区
3. 许多活跃的平行链如果愿意的话也可选择在以太坊上结算（我们最近看到 Astar 通过 Polygon CDK 做了类似的动作）

结语

我写这篇文章，主要是想在 Starknet 和以太坊更广泛的生态系统之间展开讨论。我认为共享排序模型不仅会在 Starknet 的去中心化中发挥重要作用，而且也会在所有考虑在其之上构建的应用链的去中心化中发挥重要作用。只要我们对应用链理论和 zk 扩展充满信心，对共享排序模型的彻底分析是必然要做的事情。此外，随着 Madara 正在走向生产，Starknet 已开始去中心化工作，我觉得这个话题现在很重要。因此，我希望每位读者在阅读本文时留下与该主题相关的任何反馈/建议。期待您提供的阅读想法！

附录

波卡与 Cosmos

Cosmos 与 Polkadot 类似，多年来一直在解决多链未来的问题。因此，它在 Cosmos SDK 和 IBC 方面取得了很多进展，我们也看到很多应用链构建在 Cosmos 生态系统之上。因此，也考虑 Cosmos 作为一种方法是公平的。我个人对此主题的看法是，Polkadot 更具有相关性，因为它解决了共享排序器问题，而 Cosmos 要求每个应用程序链构建自己的验证器集。此外，Substrate 始终以与链无关的方式构建，允许开发人员在不假设共识算法或 Polkadot 生态系统的情况下构建区块链。这也是我们为 Madara 选择 Substrate 的原因。然而，话虽如此，我在 Cosmos 方面的经验是有限的，很想从更有经验的人那里听取更多关于这方面的信息！您还可以在此处找到两个网络相比较的更多信息。

声明：

1. 本文转载自[starknet]，著作权归属原作者[apoorvsadana]，如对转载有异议，请联系Gate Learn团队，团队会根据相关流程尽速处理。
2. 免责声明：本文所表达的观点和意见仅代表作者个人观点，不构成任何投资建议。
3. 文章其他语言版本由Gate Learn团队翻译， 在未提及Gate.io的情况下不得复制、传播或抄袭经翻译文章。