区块链 101：Polkadot

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

对我来说，这是一篇非常特别的文章。

我自己也是前 Polkadot Blockchain Academy 的校友。 我参加学院的时候，它还是完全在线下的，而且当时还存在一些粗糙的地方。

中间那个头发乱糟糟的人就是我，还有我的战友 Emiliano 和 Ernesto

那是一段不可思议的时光。 我记得当时被这项技术迷住了。 即使那是我一生中最艰难的经历之一，但挑战过程确实令人愉快。

我全心全意地推荐任何想要学习或巩固区块链知识的人都去报名！

一些学生在学院毕业后继续在 Polkadot 生态系统中工作，但我没有。 最初，我当时正在开发的产品本应加入 Polkadot，但最终在商业上没有成功。 因此，随着时间的推移，我学到的细节开始从我的记忆中消退。 此外，Polkadot 本身也在不断发展，而我当时根本无法跟上。

但现在我可以了。 因此，这些文章既是为了你，亲爱的读者，也是为了我自己：这是我努力赶上进度，同时告诉你关于这个奇妙的区块链的一切。

Polkadot 是一个庞然大物。 要想全面地介绍它，单单靠一篇文章是不够的，因此我们将从介绍这个区块链所提供的酷炫功能开始。

说了这么多介绍！ 让我们不要再浪费你宝贵的时间了，直接进入正题吧！

回顾 Rollups

不久前，我们探讨了 Rollups 的定义，Rollups 也被称为 layer 2s 或 L2s。 简单来说，Rollup 是一种分布式账本技术，它将共识工作负载委派给父区块链，通常称为 layer 1 (L1)。

正如我之前提到过的，这通常被表述为 L2 继承了 L1 的安全性。

也许只是我个人感觉，我觉得大多数人会立即将 Rollups 的概念与 Ethereum 生态系统 联系起来。 我的意思是，考虑到 Ethereum 中 Rollups 的列表相当长，这样的假设并没有错。

然而，Rollup 实际上是一个更通用的概念。 Bitcoin 甚至有一些 L2 解决方案，如 Rootstock 或 Lightning Network，而且我不久前还读到一些 L2 系统 也开始在 Solana 生态系统中涌现。

现在看来，区块链社区普遍认为 L2 是一种很有用的解决方案……但情况并非总是如此。

你看，到目前为止，我提到的任何一种 L1 技术都不是考虑到 Rollups 而设计的。 它们最初被认为是独立的、一站式解决方案系统。 这也没什么问题——这个想法在它们最初创建时根本就不存在。

这导致了一些复杂情况，其中最重要的是所谓的 状态碎片化 。 简而言之，这意味着一个生态系统中所有 L2 的 全局状态 是 分散的，每个 L2 都有其自己独立的状态。

更重要的是，将资产从一个 L2 转移到另一个 L2 是一个相当大的问题。 这就是我们通常所说的 互操作性——允许不同的系统相互理解，并在彼此之间转移资产。 但由于大多数 Rollups 也被认为是独立的系统，因此互操作性根本不在计划之内，因此，状态碎片化仍然是一个问题。

我知道 人们正在努力 实现这种互操作性，这确实值得称赞。 尽管如此，我还是忍不住要问：如果我们早就知道 Rollups 在今天会如此重要，难道我们不应该创建一个旨在从一开始就 完全支持它们 的区块链，并提供完整的互操作性以及所有其他功能吗？

幸运的是，这个问题 确实有答案。 Gavin Wood，Ethereum 的创始人之一，早在区块链发展的早期就具有同样的远见卓识，并决定离开原来的团队，去追求他关于如何构建一个能够完全支持这些卫星 Rollups 的系统，并为它们提供实现无缝互操作所需的基础设施的想法。

而这些想法最终变成了 Polkadot。

从头开始

那么，我们如何从头开始设计这个系统呢？

首先，最重要的是：我们希望 Rollups 成为 主角。 我们将构建一个基础层，但这并非直接面向用户。 我们的目的是让 Rollups 成为这个基础层的消费者，而用户则使用 Rollups。 因此，这个基础层专注于解决 共识 问题，以便 Rollups 可以实现自定义逻辑。

换言之：

基础层不需要支持智能合约

是的，我知道——这听起来有点令人望而却步。 创建程序的能力使 Ethereum 具有革命性意义，而现在我却告诉你 Polkadot 的基础 故意避免了它们。 但这正是重点：我们不会完全放弃定义自定义逻辑的能力——我们只是将它放在其他地方。

有点像 Ethereum 不支持智能合约，而只有 Rollups 支持。

好吧，这是一个有趣的想法。 但是，它并没有解决另一个根本问题：状态碎片化。

这个难题的第二个关键点是，我们应该设计某种方式，让 Rollups 能够 原生 地相互通信。 也就是说，应该存在某种 协议，该协议可以被基础层和 Rollups 理解，并允许事物从一个 Rollup 转移到另一个 Rollup。

我们不会在我们的思想实验中走得更远，因为我们已经为我们的设计提供了一些重要的指导方针（而且我们没有时间在这篇文章中发明一个区块链！），即：

• 最小化的基础层
• 原生跨链（或跨 rollup）通信

剩下的就是看看 Polkadot 如何将这些想法变为现实。

区块链的区块链

在 Polkadot 中，我们一直在讨论的基础层被称为 Relay chain（中继链）。

它正如你所期望的那样：有意地最小化，仅专注于 共识 和 协调。 它不支持智能合约或复杂的应用程序逻辑——只有保持整个网络安全和同步的要素。

我们将在下一篇文章中讨论 Relay chain。 现在，让我们只关注其他组件：Rollups，逻辑存在的地方。

我们可以将它们分为两类：

• 系统链，提供基本功能。
• 以及其他 自定义的 Rollups，最初称为 Parachains（平行链）。

顺便说一句，Polkadot 社区正在慢慢地用简单的 Rollup 来代替 Parachain 这个术语。 这样做是有原因的，但一旦我们在未来的文章中讨论 JAM，它就会更有意义。

这里必须讨论两个关键方面：首先，我们需要了解逻辑是如何 表达的。 其次——同样重要的是——我们还需要了解 Relay chain 如何为这些 Rollups 提供共识。

让我们一次回答一个问题。 本文的剩余部分将专门讨论前一个问题，我们将用 完整的交付 来回答后一个问题。

Rollups 中的逻辑

通常，我们会以 智能合约 或类似的构件——例如 Solana 中的程序，或 Cardano 中的验证脚本——来思考逻辑。 这里有一个清晰的模式：用户可以定义任何自定义逻辑，而区块链则准备好解释和执行这些指令。

是的，最准确的描述

但是我们很少停下来思考其中的含义。 如果你还记得我们之前对 Ethereum 中 存储 和 合约 的简要介绍，我们不得不提出很多小工具，以允许事情被整齐地存储，并通过一系列指令（操作码）进行处理。 毫无疑问，这套机制令人印象深刻，但是它的 设计目的是为了追求通用性。

现在我仔细想想，这有点自相矛盾。

想想看。 这意味着 EVM 或 SVM 网络中的每个节点都需要说它们各自的虚拟机的语言——它必须完美地执行每个可能的指令，管理虚拟堆栈，处理任意的内存布局，并处理任何人可能部署的代码不可预测的资源消耗。

而所有这些通用性 都是有代价的。 这两个系统都因为执行速度较慢且成本较高而受到影响，因为它们必须 为任何情况做好准备，而这通常会导致效率低下。

但在某些情况下，这可能没有必要。 让我们想象一下，我们要设计一个区块链，你只能创建和转移同质化代币（coins的更专业的说法）。

类似于比特币的东西，但具有多代币支持。

你不需要执行 任何 类型指令的能力——只需 一些简单的功能 就可以完成任务。 你不需要与通用的 sendTransaction 调用进行通信——相反，像 mintTokens 这样的简单指令可以专注于特定的任务。

再说一次，这是一个既陌生又奇妙的想法。 但是我们该怎么做呢？

运行时

在 Polkadot 中，你不是将单个智能合约或程序部署到通用的 VM，而是将 整个区块链逻辑 定义为一个单独的程序，称为 Runtime（运行时）。

Runtime 定义了你的区块链应该遵循的 每一条规则。 它指定了允许的操作、如何处理它们、如何管理帐户、如何计算费用——所有的一切。 因此，它本质上是你的 整个状态转换逻辑！

当然，你可能会想知道如何才能 开始 编写那种代码。

不用担心，你不需要从头开始——有一整套工具可以做到这一点，称为 Polkadot SDK（以前称为 Substrate）。 在那里，你会找到称为 pallets（模块）的模块化构建块——预先构建的、精心制作和优化的（但带有特定倾向的）组件，可以在你的区块链逻辑中使用。

例如，有一个用于帐户管理的 pallet。 还有一个用于多重签名的 pallet。 如果你想构建更复杂的东西，比如 DEX，你只需要组合几个现有的 pallets，并在其上添加一些自定义逻辑——通过一组称为 FRAME（用于运行时聚合模块化实体的框架）的实用程序。

有趣的是，有一些 pallets 可以将 智能合约功能 添加到 Rollup 中。 尽管起初看起来有些违反直觉，但其想法是，如果开发者希望这样做，他们可以 选择加入 该行为。

曾经有一种基于 Rust 的新智能合约语言 Ink! 的推动，它只需要添加 pallet-contracts。 尽管 Ink! 仍在积极开发中，但我相信最近社区的关注点已经转移到 PolkaVM，它承诺通过一些其他专门的 pallets 带来更流畅的体验。 别担心，我们稍后会讨论这个问题！

最后，这个 Runtime 会被编译成二进制代码。 传统上，编译目标是 WebAssembly，尽管为了获得更好的性能，该生态系统正在慢慢地向 RISC-V 架构演进。

但我们甚至还没完成 一半。 假设我们已经成功地为我们的区块链制作了二进制文件。 酷毙了。 但故事该如何继续呢？ 谁来执行这些代码，又该如何执行呢？

节点架构

我们已经很清楚，区块链是由理解状态转换逻辑的 节点 组成的。 因此，解释和执行 Runtime 代码将是我们的平行链（或 Rollup）节点的工作！

平行链节点由一个 客户端（或 主机）组成，该客户端可以与 Runtime 通信并执行 Runtime。 它本质上是我们的编译后的二进制文件的执行环境——如果愿意，你可以称它为一个 迷你 VM。

换句话说，它处理所有的 基础设施，而 Runtime 则负责 逻辑。 它管理着诸如：

• 一个用于存储的 数据库
• 与其他节点进行的 网络连接
• 交易池

你懂的，标准的节点功能。

但是，这些节点没有你在其他区块链中中可以找到的静态的执行逻辑，而是有一种 插槽，可以在其中插入 任何 Runtime。 通过 Runtime APIs（运行时 API），主机可以调用 Runtime 函数，并且通过 host functions（主机函数），Runtime 可以与主机通信以使用其某些功能，例如访问数据库存储。

这是一个很棒的概念，因为它允许我们为各种各样的 Runtime 重用节点。 说到这里……Runtime 存储在哪里？

存储 Runtime

原则上，Runtime 可以存储在任何地方。 一个简单的解决方案是将其与节点的源代码一起分发。 对于每个平行链，你只需说“嘿，使用标准的客户端代码，并使用这个特定的 Runtime”。

但是 Polkadot 的人们还有另一个隐藏的技巧——一个非常聪明的技巧：将 Runtime 直接存储在区块链上 怎么样？

别告诉我你的第一个想法不是“我到底为什么要这么做”？

是的，这是一个奇怪的想法，但是有充分的理由：无需分叉的更新。

这到底是什么鬼？

你看，正如我们之前提到的，逻辑传统上是直接构建到节点软件中的。 这意味着，当你想要升级交易的处理方式时，你需要一个 硬分叉 或 软分叉 ——一个复杂而危险的过程，需要每个节点运营商 手动升级 他们正在运行的软件。

现在，由于 Polkadot SDK 中节点架构的设计方式，我们可以做一些非常了不起的事情，坦率地说，这件事情具有颠覆性：我们可以更新 Runtime 代码 而无需更改节点的架构。

不过，我们仍然需要确保每个人都 同时 切换到正确版本的 Runtime，因为否则我们仍然可能会遇到分叉的情况。 但是，通过将整个 Runtime 代码 直接存储在区块链的状态中（在保留的位置），每个人都可以简单地使用当前版本的 Runtime，并且不会形成分叉——一个 无需分叉的更新！

太棒了！

无需协调！

但是——总是 有但是——它也存在一些风险。 例如，我们有一个也困扰着其他区块链的问题：如果我们没有彻底测试新的 Runtime，我们可能会将漏洞或错误引入到 整个区块链 中。

除此之外，还会出现其他 新的 问题。 如果新的 Runtime 与 旧状态 不兼容怎么办？ 在这种情况下，我们需要执行某种迁移——但这可能根本不是一件简单的事情！ 它需要广泛的模拟和测试，以便我们 100% 确定在执行时一切都会顺利进行。

除了潜在的问题之外，这无疑是一个有趣的概念。 我想时间会证明这到底是一个天才的架构决策还是一个运营上的噩梦，但至少这种可能性是存在的！

总结

我认为现在停下来是个不错的地方。

在我们最初的问题之后，事情进展得非常顺利。 我们介绍了如何在 Polkadot Rollups 中处理 逻辑 的大部分内容，其中节点的运作方式就像那些带有游戏卡插槽的老式游戏机一样，我们可以在其中插入我们自定义的 Runtime。

啊……美好的旧时光

这当然很多……但信不信由你，我们 只是触及了皮毛。 这只是热身！

而且我甚至没有把节点架构背后的所有细节都算进去。 不过话说回来……我想对于我介绍过的大多数区块链来说，这都是真的！

许多问题仍然没有解答。 特别是我们还没有谈到 Relay chain 的作用。 我们之前说过它提供 共识——但它是如何做到的呢？ Rollups 和 Relay chain 之间需要进行什么样的通信？ 需要共享什么信息？

我将在我们的下一次相遇中尝试回答这些问题以及更多问题。 很快再见！

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