Exchange Ranking
Top Exchanges
24h Volume Ranking
Popularity Ranking
Exchange BTC Balance
Proof of Reserves
Decentralized Exchanges
Funding Rate
Funding Heatmap
Liquidation Data
Max Pain
Long/Short Ratio
Whale L/S Ratio
Binance/Okex/Huobi L/S
Bitfinex Margin L/S
ETF Tracker
Solana ETF
XRP ETF
Hong Kong ETF
Bitcoin Treasuries
Crypto Reversal
Ethereum Reserves
HyperLiquid Wallet Analysis
Hyperliquid Whale Watch
Large Transactions
On-chain Movement
Bitcoin ROI
Stablecoin Market Cap
Options Analysis
News
Articles
Economic Calendar
Features
Wallet
Contract Calculator
Security
Collections
Watchlist
Following
DOT 为什么 Polkadot 无需硬分叉即可实现升级
大多数区块链将重大升级视为一场危机。节点运营商必须手动协调，社区就升级时机争论不休，有时甚至导致链分裂为两个竞争版本。Polkadot 的运行时（Runtime）升级机制则完全不同。
Polkadot 不强迫每个验证者手动更换软件，而是将自身的规则库存储在链上，并通过治理机制进行更新。没有网络分裂，没有仓促的协调，也不存在“双重真相”。
这一点至关重要，因为 Polkadot 持续推出有意义的协议变更，从治理改革到扩展性改进。本文将深入解析什么是运行时、升级过程如何运作，以及它为何能完全避免硬分叉。
什么是 Polkadot 运行时？
运行时是定义链核心规则的部分。你可以将其理解为管理网络运行的规则手册，包括交易验证方式、奖励计算逻辑以及治理提案的执行机制。
从技术角度来看，运行时被编译为 WebAssembly（简称 Wasm），并直接存储在链的状态中。这一细节使得后续的一切成为可能。由于规则库存在于链内而非独立的节点软件中，更改它就像更新账户余额一样，仅仅是另一种状态更新。
这种设计位于 DOT 投资者兴趣日益增长的核心位置，因为网络在保持连续性的同时不断添加新功能。
How does Polkadot runtime upgrade work?
Runtime upgrades started before they touched the real-time network. Developers write and test the new version of the code, and then compile it into a Wasm binary.
This binary file will be proposed on-chain, processed through Polkadot's referendum system, or, for some parallel chains, through a simpler authorization-source process. Once approved, the new Wasm block replaces the old block in storage.
Verifiers do not need to install new software in advance. The node client already knows how to run any Wasm code stored in state, so once the new runtime is written to the chain, the network will start executing according to the new rules in the next block.
Why doesn't Polkadot need a hard fork?
A hard fork occurs when the rules of the blockchain change that is not backward compatible. Node operators that are not upgraded will be left on incompatible chains. This is how protocol changes are handled in most older networks, and often means huge coordination risks.
Polkadot structurally avoids this problem. Because the runtime is data stored on the chain, rather than logic embedded in separate node binaries, upgrades do not create two incompatible network versions. There is only one chain, one state, and a new set of rules that everyone will follow after the changes take effect.
这种无分叉设计在 Polkadot 官方运行时升级指南中有详细记录，其中指出运行时升级是一种无需硬分叉即可更改链逻辑的方法。
Polkadot 链上治理与升级
运行时升级并非由命令强制执行。它们通过 Polkadot 的链上治理系统 OpenGov 进行，DOT 持有者利用轨道和公投系统对提案进行投票。
每个轨道都有基于变更重要性的审批阈值。次要参数调整与主要协议升级遵循不同的投票规则，这确保了低风险提案的快速通过，同时对高影响力提案进行充分审查。
一旦公投通过，执行就是自动的。不存在团队手动切换开关的单独步骤。
运行时升级期间发生了什么？
将过程分解为阶段有助于理解：
- 代码准备：开发者编写并测试新运行时，然后编译为 Wasm。
- 提案提交：升级作为链上提案提交，通常通过 Fellowship 或治理轨道进行。
- 治理投票：DOT 持有者以及针对技术变更的 Polkadot 技术 Fellowship 通过公投发表意见。
- 批准与确认：提案必须在决策期内达到其轨道的批准和支持阈值。
- 链上存储：批准后，新的 Wasm 运行时被写入链的状态。
- 网络过渡：验证者立即开始按照新规则执行区块，无需手动重新安装。
整个周期可能需要几小时到几周不等，具体取决于提案使用的治理轨道。
无分叉运行时升级的优势
这种方法为 Polkadot 提供了相对于依赖手动协调升级的网络的几个实际优势：
- 升级期间无链分裂风险
- 协议改进的部署速度更快
- 以治理驱动变更，而非中心化决策
- 数千个验证者之间的协调负担更低
- 更容易在平行链间部署新功能
敏捷核心时间（Agile Coretime）区块空间模型以及近期其他几个网络变更都是通过这种方式推出的，无需在变更生效前要求验证者手动更新客户端。
Polkadot 运行时升级示例
自启动以来，Polkadot 的运行时已经经历了多次版本发布，每一次都通过相同的无分叉流程执行。这些变更包括用 OpenGov 取代旧理事会系统的治理 overhaul、与异步支持相关的扩展性工作，以及与网络核心时间模型相关的持续平行链级变更。
展望未来，即将到来的 JAM 升级被视为更重大的架构转变，但它仍将遵循此前每次运行时变更所使用的相同链上、无分叉执行模式。
运行时升级 vs. 硬分叉
该表格展示了区分两者的重要性。硬分叉要求每个节点操作者采取行动，而运行时升级要求链本身进行更新，从而消除了大部分人为协调问题。
Polkadot 运行时升级是否完全无风险？
无分叉并不意味着无风险。未经充分测试的运行时可能会在上线后引入错误，由于变更一次性应用于整个网络，错误可能会同时影响所有人。
- 代码错误：未经测试的逻辑可能在执行后导致意外行为。
- 治理风险：低投票率可能导致提案在审查有限的情况下通过。
- 兼容性问题：依赖中继链行为的平行链需要密切关注变更。
- 测试差距：在主网提案前跳过测试网试验会增加出现问题几率。
对于超出常规参数变更的任何内容，审计、测试网试验和 Fellowship 审查仍然是流程的一部分。
结论
Polkadot 运行时升级允许网络更改自身规则，而无需分裂成相互竞争的链。运行时作为 Wasm 代码存在于链上，提案通过 OpenGov 的公投轨道进行，一旦获得批准，新逻辑便自动激活。这消除了其他地方导致大多数硬分叉的手动协调负担，同时 DOT 质押奖励让验证者在每次过渡中保持参与，确保护网安全。
权衡之处在于，治理质量和代码测试变得更为重要，因为有缺陷的升级会一次性影响整个网络。关注 Polkadot 发展的读者应留意活跃的公投和即将进行的 Fellowship 审查，以了解接下来会出现哪些变更。
