为什么 Polkadot 无需硬分叉即可实现升级

大多数区块链将重大升级视为一场危机。节点运营商必须手动协调，社区就升级时机争论不休，有时甚至导致链分裂为两个竞争版本。Polkadot 的运行时（Runtime）升级机制则完全不同。

Polkadot 不强迫每个验证者手动更换软件，而是将自身的规则库存储在链上，并通过治理机制进行更新。没有网络分裂，没有仓促的协调，也不存在“双重真相”。

这一点至关重要，因为 Polkadot 持续推出有意义的协议变更，从治理改革到扩展性改进。本文将深入解析什么是运行时、升级过程如何运作，以及它为何能完全避免硬分叉。

什么是 Polkadot 运行时？

运行时是定义链核心规则的部分。你可以将其理解为管理网络运行的规则手册，包括交易验证方式、奖励计算逻辑以及治理提案的执行机制。

从技术角度来看，运行时被编译为 WebAssembly（简称 Wasm），并直接存储在链的状态中。这一细节使得后续的一切成为可能。由于规则库存在于链内而非独立的节点软件中，更改它就像更新账户余额一样，仅仅是另一种状态更新。

这种设计位于 DOT 投资者兴趣日益增长的核心位置，因为网络在保持连续性的同时不断添加新功能。

Polkadot 运行时升级是如何工作的？

运行时升级在触及实时网络之前就已经开始了。开发者编写并测试新版本的代码，然后将其编译为 Wasm 二进制文件。

该二进制文件会在链上提出提案，经过 Polkadot 的公投系统处理，或者对于某些平行链而言，通过更简单的授权来源流程。一旦获得批准，新的 Wasm 块就会替换存储中的旧块。

验证者无需提前安装新软件。节点客户端已经知道如何运行存储在状态中的任何 Wasm 代码，因此一旦新运行时写入链中，网络将在下一个区块开始按照新规则执行。

为什么 Polkadot 不需要硬分叉？

当区块链的规则发生非向后兼容的变化时，就会发生硬分叉。未升级的节点操作者将被留在不兼容的链上。这是大多数较老网络处理协议变更的方式，通常意味着巨大的协调风险。

Polkadot 在结构上避免了这一问题。因为运行时是存储在链上的数据，而不是嵌入在独立节点二进制文件中的逻辑，所以升级不会创建两个不兼容的网络版本。只有一个链、一个状态，以及在变更生效后大家共同遵循的一套新规则。

这种无分叉设计在 Polkadot 官方运行时升级指南中有详细记录，其中指出运行时升级是一种无需硬分叉即可更改链逻辑的方法。

Polkadot 链上治理与升级

运行时升级并非由命令强制执行。它们通过 Polkadot 的链上治理系统 OpenGov 进行，DOT 持有者利用轨道和公投系统对提案进行投票。

每个轨道都有基于变更重要性的审批阈值。次要参数调整与主要协议升级遵循不同的投票规则，这确保了低风险提案的快速通过，同时对高影响力提案进行充分审查。

一旦公投通过，执行就是自动的。不存在团队手动切换开关的单独步骤。

运行时升级期间发生了什么？

将过程分解为阶段有助于理解：

代码准备：开发者编写并测试新运行时，然后编译为 Wasm。提案提交：升级作为链上提案提交，通常通过 Fellowship 或治理轨道进行。治理投票：DOT 持有者以及针对技术变更的 Polkadot 技术 Fellowship 通过公投发表意见。批准与确认：提案必须在决策期内达到其轨道的批准和支持阈值。链上存储：批准后，新的 Wasm 运行时被写入链的状态。网络过渡：验证者立即开始按照新规则执行区块，无需手动重新安装。

整个周期可能需要几小时到几周不等，具体取决于提案使用的治理轨道。

无分叉运行时升级的优势

这种方法为 Polkadot 提供了相对于依赖手动协调升级的网络的几个实际优势：

升级期间无链分裂风险协议改进的部署速度更快以治理驱动变更，而非中心化决策数千个验证者之间的协调负担更低更容易在平行链间部署新功能

敏捷核心时间（Agile Coretime）区块空间模型以及近期其他几个网络变更都是通过这种方式推出的，无需在变更生效前要求验证者手动更新客户端。

Polkadot 运行时升级示例

自启动以来，Polkadot 的运行时已经经历了多次版本发布，每一次都通过相同的无分叉流程执行。这些变更包括用 OpenGov 取代旧理事会系统的治理 overhaul、与异步支持相关的扩展性工作，以及与网络核心时间模型相关的持续平行链级变更。

展望未来，即将到来的 JAM 升级被视为更重大的架构转变，但它仍将遵循此前每次运行时变更所使用的相同链上、无分叉执行模式。

运行时升级 vs. 硬分叉

特性 运行时升级 硬分叉

链分裂风险

通常避免

可能发生

审批流程

链上治理

因网络而异

验证者协调

低，自动化

通常高，手动

升级机制

链上 Wasm 替换

新的不兼容客户端软件

典型时间线

几小时至几周

数周至数月

该表格展示了区分两者的重要性。硬分叉要求每个节点操作者采取行动，而运行时升级要求链本身进行更新，从而消除了大部分人为协调问题。

Polkadot 运行时升级是否完全无风险？

无分叉并不意味着无风险。未经充分测试的运行时可能会在上线后引入错误，由于变更一次性应用于整个网络，错误可能会同时影响所有人。

代码错误：未经测试的逻辑可能在执行后导致意外行为。治理风险：低投票率可能导致提案在审查有限的情况下通过。兼容性问题：依赖中继链行为的平行链需要密切关注变更。测试差距：在主网提案前跳过测试网试验会增加出现问题几率。

对于超出常规参数变更的任何内容，审计、测试网试验和 Fellowship 审查仍然是流程的一部分。

结论

Polkadot 运行时升级允许网络更改自身规则，而无需分裂成相互竞争的链。运行时作为 Wasm 代码存在于链上，提案通过 OpenGov 的公投轨道进行，一旦获得批准，新逻辑便自动激活。这消除了其他地方导致大多数硬分叉的手动协调负担，同时 DOT 质押奖励让验证者在每次过渡中保持参与，确保护网安全。

权衡之处在于，治理质量和代码测试变得更为重要，因为有缺陷的升级会一次性影响整个网络。关注 Polkadot 发展的读者应留意活跃的公投和即将进行的 Fellowship 审查，以了解接下来会出现哪些变更。