区块链101：波卡共识

这是关于区块链的一系列文章的一部分。 如果这是你遇到的第一篇文章，我强烈建议从本系列文章的开头开始阅读。

上一集有点像热身，这样我们就可以开始沉浸在 Polkadot 的（深层）世界中。

到目前为止，我们一直在谈论 Rollups（或 Parachains），但我们说过这些缺乏我们期望从任何区块链中获得的一项关键功能：共识。 这是有意的，因为共识被委托给一个 父链，称为 Relay chain（中继链）。

所以今天，我们将开始讨论 Polkadot 基础设施中这个非常核心的组件，以及它作为这项技术核心的作用。

我们开始吧！

共识

从上一篇文章中，我们知道每个 Rollup 都有能力定义自己的状态转换规则，但它们本身无法发展自己的区块链 (Rollups)。 当然，它们会收到交易，甚至 提议区块，但共识将委托给 Relay chain。

所以一开始，我们似乎就陷入了困境：Relay chain 如何 验证 Rollup 的状态转换？

为了提供共识，它需要这样做，因为它需要确保 Rollup 的演变遵循其自身的规则！

我们的第一反应应该是 Relay chain 必须对 所有现有的 Runtime 有所了解。 没错：Runtime 必须在 Relay chain 中注册，整个机制才能工作。

但是……如果 Runtime 也存储在 Relay chain 上，那么它们与 智能合约 有什么不同？ 看来我们正朝着我们想要避免的方向发展！

那是什么呢？

Collators

关键的区别在于 状态 存在于哪里。 每个 Rollup 都跟踪自己的状态（和 Runtime），所以让我们从他们的角度看看会发生什么。

Rollup 中的区块生产如何运作？ 那么，某种 验证者（或至少是 区块生产者）需要生成一个包含有效交易的区块，然后它需要以某种方式告诉 Relay chain 类似这样的内容：

这是一个区块——我需要你验证它，并在你认为可以让我把它添加到我的区块链后告诉我

但问题是：Relay chain 对 Rollup 的状态知之甚少。 然而，我们的生产者 确实 拥有这些信息。 因此，通过一些密码学魔法，他们所做的是提供 足够的信息，让 Relay chain 完成其工作。

负责生成区块并提供此信息的节点称为 Collators，他们提供的信息是一个称为 Proof of Validity（简称 PoV）的简短证明。

但这些简短的证明到底包含什么呢？

构建证明

理论上，有 多种方式 可以证明计算执行正确。 因为这就是我们正在做的事情：Runtime 实际上只不过是 一个函数，它接受 当前状态 和 交易（在 Polkadot 术语中也称为 extrinsic），并产生 新状态。 像这样：

其中 sigma 代表状态，T 代表交易。 而 Y 函数是 Runtime！

这样的函数通常被称为 state transition function（状态转换函数）。

所以，是的，我们的目标可以重新定位为证明对于给定的输入集，函数的输出是 正确 计算 的。

有各种证明系统允许我们这样做，即：

• 零知识证明（如 SNARKs 或 STARKs）证明计算的正确性，可以选择不泄露某些信息。
• 欺诈证明，假设计算是正确的，除非有人能证明它是错误的。
• 基于见证的证明，提供足够的数据供其他人验证计算。

Polkadot 选择第三种方法：基于见证的证明，建立在 Merkle trees 之上。

原因是 Rollup 状态，以与 Ethereum 非常相似的方式，存储为 modified Patricia Merkle trie（修改后的 Patricia Merkle 树）。

作为参考，请参阅 这里！

主要思想实际上很简单：仅共享已更改的部分，加上足够的信息来重建 状态根。 是的……也许一个例子会有所帮助。

假设 Alice 想要将一些 Token 转给 Bob。 此操作的结果是他们的余额发生变化——但其余状态 几乎没有改变。 现在，他们的余额都将代表 trie 中的一个叶子——如下所示：

这当然是完整 trie 的 精简视图：紫色中的哈希可能隐藏了冗长的子 trie。 这正是此数据结构的优点：你只需要几个中间哈希即可从 Alice 和 Bob 的余额重建状态根（它是 整个 trie 的指纹）。

当然，你通常需要更多紫色哈希，因为我们实际上使用的是 radix-16 trie。

在更改目标余额后，这是新的情况：

因此，只有之前 精简的 trie、更新后的余额和新根，我们才能 拥有验证状态转换所需的一切！

总结一下，我们说这些 Proofs of Validity（有效性证明）只是 Rollup 状态的基于见证的证明。

有了这个，我们几乎完成了 Collators 在这个故事中的角色。 我们的下一站将是了解 Relay chain 如何获取这些 PoV 并验证它们。 这里的挑战是以 高效 的方式做到这一点，因为我们的基础层必须处理几个不同 Runtime 的验证。

与其考虑 “Relay chain” 验证这些区块，不如从 个人参与者 和这些区块提交后立即发生的整个过程的角度来处理下一节，这将很有用—— 这种协议被称为 ELVES。

有趣的事实：最初的论文说 ELVES 代表 Endorsing Light Validity Evaluator System（认可轻量有效性评估器系统），而官方文档 确定它意味着 Economic Last Validation Enforcement System（经济最终验证执行系统）。

我想在我们看到它在行动后，你可以决定哪个更合适！

ELVES 协议

一般来说，共识协议只有几个目标，其中包括确保存在 单个 共享历史，并且该历史中的每个步骤（区块）都是 有效 的。

相反，这意味着无效的区块永远不应被接受——它们应在 Relay chain 验证者检查后被 丢弃。 但是应该有多少验证者执行此审计？ 多少才 足够安全？

一般来说，我们不能让每个验证者节点检查每个 Rollup 区块，因为这会使 扩展 几乎不可能。

这是大多数区块链面临的现实，也是我们需要复杂的共识机制的原因。

Polkadot 通过 ELVES 解决了这个问题，它总共包含四个阶段或步骤。

Backing（支持）

第一步称为 backing（支持）。

当 Collator 提交 Rollup 区块（及其 PoV）时，一小群专门分配给该 Rollup 的 Relay chain 验证者（称为 backers（支持者））会收到该区块，并执行 初始验证。

Backers 本质上是在做繁重的工作：他们执行 Rollup 的状态转换函数（Runtime），并验证 PoV 是否正确。

如果一切正常，他们会通过所谓的 candidate receipt 来证明这一点，并在新区块上盖上他们的批准印章。

他们 支持 新区块的有效性，因此得名！

Availability（可用性）

第二阶段称为 availability phase（可用性阶段）。

Backers 声称新区块有效……但是我们可以相信他们吗？ 他们可能错误地评估了区块的有效性，甚至可能在撒谎！ 我们如何确保情况并非如此？

很简单：让其他验证者进行 第二轮 区块验证。

为此，backers 需要让他们的对等方可以使用该区块。 听起来很简单，但围绕着我们 如何 分发这些区块存在一些相关的问题：

• 如果 backers 将每个区块发送给每个其他对等方，那么节点很快就不得不在内存中存储大量区块，其中大部分他们永远不会检查。 不理想！
• 如果 backers 在分发区块之前等待挑战的到来，那么整个过程的延迟会增加，从而减慢共识的速度。 同样不理想。

那么，中间解决方案呢？ 幸运的是，存在这样一种技术，称为 erasure coding（纠删码）。

我已经在之前的文章中对此进行了广泛的讨论，因此如果你想获得完整的解释，请查看该文章！

它的工作原理如下：该区块被分成 chunks（块），并且只有一小部分块预先分发给其他节点。 当对等方想要检查该区块时，它可以向对等方询问其他小块，并重建原始区块。 有趣的是，他们不需要 所有碎片——只需要一小部分即可。

这很棒，因为通信很精简，并且节点不需要存储那么多信息！

实际上，分发与支持阶段同时发生，而不是纯粹按顺序发生。

一旦有足够的验证者证明已经收到了他们各自的块，那么协议就会进入下一阶段。

是的，术语绝对准确。

Approval（批准）

现在到了协议中最有趣的部分（在我看来）：approvals phase（批准阶段），这是第二轮修订发生的地方。

在你的收件箱中获取 Frank Mangone 的故事

免费加入 Medium 以获取这位作者的更新。

该协议会随机选择一个 小型委员会 的验证者来审核支持的区块。 重要的是，委员会是在上一个阶段分发区块 之后 选择的。 随机选择由 Verifiable Random Functions (VRF) 提供支持。

为什么这很重要？ 因为如果 backers 提前知道谁将成为委员会的成员，他们可能会 胁迫他们 批准该区块！

通过按此顺序执行操作，我们可以使不诚实的节点难以沉迷于腐败行为！

如果所有委员会成员都批准了一个区块，那么该区块将被接受，并且 Rollup 可以将其附加到其链上。 但是一些审计员可能会声称某个区块无效，或者他们可能没有及时响应（称为 no-shows（未出现））。 在这种情况下，需要另一个步骤。

Escalation and Disputes（升级和争议）

No-shows（无法出现）很容易处理：ELVES 选择额外的随机验证者来提供他们的批准。

实际上，这非常聪明：如果由于验证者受到 攻击 而导致无法出现，那么委员会会不断扩大，直到攻击者无法实际跟上为止！

但是，当审计员声称某个区块无效时，系统会进入 dispute phase（争议阶段）：批准区块的决定会立即升级到所有验证者，并且每个验证者都需要 检查区块 并 投票。

为了确保验证者 正确 投票，该协议会 削减少数派（是的，这是一个权益证明协议）。 我们对不当行为施加严重的后果，这增加了模型的安全性。 总而言之，试图破坏此系统非常复杂，因为你必须：

• 腐败最初的支持验证者
• 拥有足够的资源来使诚实的审计员在被随机选择时崩溃
• 如果被抓住，则面临大规模削减的风险！

并且在 正常 运行期间——你知道，生成有效的区块，并且节点可以执行其职责——只有一小部分验证者会主动检查任何特定的 Rollup 区块。

换句话说，此协议非常适合并行执行共识机制！

Interoperability（互操作性）

好的！ 我们已经介绍了 Rollup 如何生成区块，以及 Relay chain 如何通过 ELVES 验证它们。

现在，我们只缺少 Polkadot 架构的最后一个部分：这些不同的 Rollup 实际上是如何 相互通信 的？

The Interoperability Challenge（互操作性挑战）

我们已经知道大多数区块链 孤立存在。

将资产从一个区块链移动到另一个区块链通常需要 bridges（桥）——这些系统只是将你的资产保存在一条链上，同时在另一条链上铸造等效的表示。

至关重要的是，这些系统通常是 集中的。 因此，它们通常是跨链操作中 最薄弱的环节。 我已经 提到过 一句关于密码学的话：

一条链的强度不超过其最薄弱的环节

因此，这些桥梁经常成为漏洞利用的目标。

当然，这一切都源于一个简单的原因，即互操作性未被视为许多系统最初设计的一部分，因为没有人有水晶球。

来吧，告诉我该构建什么！！

与上一篇文章类似，让我们想象一下，我们即将构建一个新的区块链，该区块链支持 Rollup 之间的原生互操作性，而无需依赖中心化桥梁。 那甚至会如何运作？

假设 Alice 想要将存储在她 Rollup A 账户中的 100 个 Token 发送到 Bob 在 Rollup B 上的账户。这应该很简单：Rollup A burned（销毁） Alice 的 100 个 Token，Rollup B 为 Bob 铸造 100 个等效的 Token。

小菜一碟，对吧？

不完全是。 假设 Rollup A 成功销毁了 Token，但 Rollup B 未能铸造它们。 Alice 丢失了她的 Token，而 Bob 一无所获。 或者，如果 Rollup B 铸造了 Token 但 Rollup A 未能销毁它们，那么……我们现在基本上 duplicated the tokens（复制了 Token）。 当然，这两种情况都令人震惊，应不惜一切代价避免。

为了解决这个问题，两个 Rollup 都需要以某种方式 coordinate（协调）一个复杂的两阶段交易。

有点像 distributed database commit（分布式数据库提交）。

Rollup A 需要 prepare（准备）销毁 Token，Rollup B 需要 prepare（准备）铸造它们，并且只有当两者都准备好时，它们才会实际执行这些操作。

即使这增加了系统的复杂性（和延迟），但至少在理论上是可行的。 但是，这需要某种用于 Rollup 之间 direct communication（直接通信）的机制。

随着我们向生态系统添加更多 Rollup，我们必须确保这些单独的系统之间的通信 still works（仍然有效）。 如果每个 Rollup 都有自己的格式和怪癖，那么混乱将Swift发生。

几乎可以肯定的是，需要某种 标准。

Polkadot 试图从中吸取教训，并提出了自己的解决方案：一种原生的跨链通信机制，即 XCM。

XCM

Cross-Consensus Messaging format (或简称 XCM) 简直就是：一种 messaging format（消息传递格式）。

虽然 “simply”（简直） 低估了它的优雅。 XCM 更像是一种 universal language（通用语言），用于描述 actions（动作）。 XCM 没有让 Rollup 尝试直接协调复杂的交易，而是采取了不同的方法：它创建了一种描述 intentions（意图）的标准方式，这实现了两件事：

• 它允许 Relay chain 处理协调。
• 它允许每个 Rollup 实现用于处理消息的逻辑。

为了更好地理解这一点，让我们回顾一下前面的示例。 Alice 想要将 100 个 Token 从 Rollup A 发送到 Bob 在 Rollup B 上的账户。因此，XCM 消息将类似于以下内容：

从 Alice 的帐户中提取 100 个 Token，将它们 teleport（传送）到 Rollup B，然后将它们 deposit（存入）到 Bob 的帐户中。

该消息完美地描述了应该发生的事情，但没有描述应该 how（如何）发生。 每个 Rollup 都根据自己的规则和功能解释这些指令。 但这就引出了一个问题：我们如何确保 Rollup B 实际上 executes the message（执行该消息）？

Message Execution（消息执行）

答案可能比你预期的更为细致。

XCM 遵循 fire and forget（发射后不管）模型——当 Rollup A 发送消息时，它没有收到 Rollup B 已执行该消息的确认。 但是，让我们花一点时间来分析一条消息的生命周期，看看我们能从中了解到什么：

• 首先，Rollup A 制作 XCM 消息并将其 “up”（发送）到 Relay chain。
• 然后，Relay chain 将消息 stores（存储）在其自己的存储中，并将其路由到 Rollup B 中的 message queue（消息队列）。
• 当 Rollup B 的 Collator 构建他们的下一个区块时，他们 expected（应该）处理他们各自队列中的消息。
• Relay chain 验证者根据收到的消息的处理情况，验证新生成的区块是否有效。

请注意，此机制称为 Horizontal Relay-routed Message Passing (HRMP)，预计将被更轻量级的 Cross-Chain Message Passing protocol (XCMP) 取代。

主要区别在于，目前，所有消息都存储在 Relay chain 中。 XCMP 旨在将消息直接存储在 Rollup 上，并使存储在 Relay chain 中的信息非常轻量。

好的，这里有几件事要说。 首先也是最明显的是，no absolute guarantee（不能绝对保证）每个消息都将由目标 Rollup 处理。

但是，并非一切都丢失了——无论是在 HRMP 还是 XCMP 中，Relay chain 都以消息队列的形式维护有关每个 Rollup 应执行哪些 XCM 消息的信息。 感谢这一点，Relay chain 验证者有足够的上下文来检查（并且他们 will check（将会检查））Collator 是否确实在处理消息，并按预期的顺序进行处理。 如果他们没有这样做，那么他们的区块最终将被视为无效，并且他们的区块生产将被停止。

失败的执行会怎样？ 好吧，XCM 包括 asset trapping 之类的机制——资产不会消失，它们会被 trapped（捕获），然后可以通过单独的流程恢复。 当然，围绕这一点存在更多的复杂性，因为 XCM 消息可用于表示各种动作，而不仅仅是 Token transfer。

总的来说，XCM 是朝着正确方向迈出的一步。 它具有巨大的潜力，但其成功取决于其使用和实施方式。

我想我们必须拭目以待！

Summary（总结）

今天我们已经介绍了很多内容！ 让我们快速回顾一下：

• 我们看到了 Collators（收集人） 如何是专门的节点，它们不仅生产区块，还生产其状态转换有效性的简短证明，以 Proofs of Validity（有效性证明）的形式。
• 然后，这些区块由 ELVES 共识协议审核，该协议以其可扩展性、效率和安全性而著称。
• 最后，XCM 实现了 Rollup 之间的本机互操作性。 它已经在 Polkadot 生态系统中大量使用，并允许非常丰富的交互。

当然，我们还没有涵盖所有内容（例如，我没有提到 async backing，这本身就是一个非常有趣的功能）——但这应该足以很好地掌握 Polkadot 中的共识如何运作。

作为额外的奖励练习，我们可以利用我们新获得的知识，并尝试用它来理解互联网上流传的关于 Polkadot 架构的图像之一。 让我们看看我们是否可以识别所有组件：

每个 “停靠” 在圆圈上的小东西都是一组 collators（粉红色点），它们为 parachain（灰色正方形）生产区块，并由一些验证者（那些长而圆润的粉红色图形）支持。

Relay chain 是中间的大灰色圆圈，而穿插在其中的粉红色连接是 XCM 消息。

最后，似乎连接到多个 collators 的验证者 “pools”（池）可能与 on-demand coretime（按需核心时间）有关——我们Soon将探索的概念。

Polkadot 真正独特之处不仅在于单一的创新，而在于这些不同的部分如何协同工作。 它确实是少数几个让我印象深刻的例子之一，它试图构建的不仅仅是一个区块链，而且是 solid infrastructure（坚实的基础设施），用于互连区块链的生态系统。

当然，另一个主要的候选者是以太坊生态系统，我们将在本系列结束之前重新审视它！

时间会证明这个愿景的成功程度。 如果有什么意义的话，我们讨论过的惊人的技术创新推动了整个行业的发展，它们绝对值得学习。

说到技术创新，Polkadot 仍然有一些惊喜。 例如，我们尚未回答 Rollup 如何 gain access（获得访问权限）到 Relay chain 的验证能力。 我的意思是，验证者不应该 for free（免费）工作，因此必须存在某种激励措施，对吗？

我不想在这里破坏剧情，所以你必须等待下一篇文章才能找到答案！

再见！

• 原文链接： medium.com/@francomangon...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～