跨区块链的可升级性模式分析 – ImmuneBytes

2026年3月2日

引言

智能合约曾因其不可变性而备受赞誉。代码一旦部署就无法更改的理念既是其特点也是其缺陷。随着协议的成熟和用户需求的演变，开发者们意识到了冻结逻辑的局限性。可升级性成为了解决方案。但它也带来了代价。每种升级机制都引入了新的复杂性层、新一类错误以及新的攻击面。

在过去的几年里，我们对以太坊、Solana、Cosmos 和其他生态系统中的智能合约进行了审计。一个反复出现的主题是开发者们尝试使他们的合约更具灵活性的创造性——有时是危险的——方式。这篇博客深入探讨了现有的不同可升级性模式、它们在底层是如何实现的以及它们可能出现问题的地方。

权衡：灵活性与最终性

不可变性在理论上听起来很完美。但无论你的智能合约写得多么好，错误总会发生。业务逻辑会演变。治理会改变。如果无法升级，不可变合约中的一个错误可能会永远锁定数百万美元。另一方面，升级能力可能会破坏对去中心化的信任，并为 rug pulls、backdoors 或意外的 bricking 打开大门。

找到正确的平衡至关重要。但要做到这一点，你需要理解可升级性的设计空间。

EVM 链中的可升级性

基于代理的模式 (Proxy-Based Patterns)

在以太坊和其他 EVM 链中，最广泛采用的方法是 proxy delegation。在这里，用户与一个 proxy contract 交互，该合约使用 delegatecall 将逻辑执行转发到一个独立的 implementation contract。

有几种常见的变体：

透明代理 (Transparent Proxy)

使用 admin 账户授权升级。只有 admin 可以调用升级函数；其他调用则转发到 logic contract。最大的风险是意外地向公众暴露升级函数或搞乱 storage slots。

UUPS (Universal Upgradeable Proxy Standard)

UUPS（通用可升级代理标准）不依赖于外部 admin proxy，而是由 implementation contract 包含升级逻辑。它更 gas-efficient 且模块化，但如果升级授权逻辑没有得到适当保护，风险也更高。

信标代理 (Beacon Proxy)

Beacon Proxy 专为多个 proxy 共享相同 implementation 逻辑的扩展用例而设计。beacon contract 存储当前 logic contract 的地址。当它更新时，所有 proxy 都会自动指向新的 implementation。由于共享逻辑的风险，这种模式更难安全管理。

存储布局陷阱 (Storage Layout Gotchas)

EVM 环境中的可升级合约需要对 storage layout 进行精确控制。proxy 和 logic contract 变量之间的任何不匹配都可能导致灾难性的 corruption。Solidity 不强制执行 layout 一致性，因此一个放错位置的变量可能会悄无声息地破坏一切。

Solana：通过程序权限进行升级

Solana 智能合约（称为 programs）被编译为 BPF 字节码，并以指定的“upgrade authority”部署到链上。此账户如果持有必要的 key，则可以随时部署新版本的 program。

虽然 Solana 的升级模型在某些方面更简单，但它带来了中心化风险。如果 upgrade authority 是一个单一的 hot wallet，那么整个合约都可以被任何妥协它的攻击者替换掉。我们看到一些项目将去中心化推迟太久，有些甚至从未撤销其 authority。这违背了使用 Solana 安全、高性能的 runtime 的全部目的。

Solana 还引入了与 program-derived addresses (PDAs) 相关的风险。一些开发者在不同升级中错误或不一致地使用 bumps，导致状态冲突或关键数据账户访问丢失。

Cosmos 和 CosmWasm：治理驱动的迁移

使用 CosmWasm 构建的 Cosmos 合约允许通过 migrate entry point 进行显式迁移。这种模式的优点是升级逻辑是合约本身的一部分。当通过 on-chain governance 提出并批准升级时，新的 WASM 字节码被上传，执行继续。

由于状态自动保存且迁移逻辑明确定义，storage mismatch 的风险较低。然而，不正确的 migration code 或 governance layer 中的权限错误仍然可能导致问题。

我们见过的一个常见问题是 migration logic 中缺乏验证；合约通常假定存储中存在某些值而不进行检查，导致升级后出现 panics 或 broken invariants。

Substrate/Polkadot：运行时级别升级

在 Polkadot 和其他基于 Substrate 的链中，整个 runtime 可以通过 governance proposal 进行交换。这允许进行强大、协调的升级，但引入了复杂性。你升级的不是单个合约，而是整个链逻辑。

对于用 Ink!（Substrate 的智能合约语言）编写的合约，升级并非原生支持。你通常会部署一个新合约并手动迁移状态，除非你已经构建了一个自定义的升级机制。这赋予了开发者灵活性，但安全性的重担完全落在了他们身上。

跨生态系统的安全隐患

无论底层链是什么，风险都归结为几个关键点：

• 不当的访问控制： 升级功能暴露给未经授权的用户是一个常见的关键问题。无论是以太坊中泄露的 admin key 还是 Solana 上未撤销的 authority，控制就是一切。
• 状态损坏 (State Corruption)： 在 EVM 中，这发生在 storage layout 不匹配的情况下。在 CosmWasm 中，这通常是不安全 migration logic 导致的结果。在 Substrate 中，这通常是由于开发者定义的 migration bugs 引起的。
• 合约失效 (Bricking the Contract)： 失败的升级可能会使合约处于不可用的状态。例如，一个错误地禁用了升级功能的 UUPS 合约将永远无法再次升级。或者在 Solana 中，在上传正确的 binary 之前意外撤销 upgrade authority 可能会冻结系统。
• 治理漏洞 (Governance Loopholes)： 在允许 governance-controlled upgrades 的链上，糟糕的 quorum 阈值或投票操纵可能允许恶意行为者强制进行用户不希望的升级。

真实案例和经验教训

• 2022 年，一个主要的以太坊 DeFi 协议推送了一次升级，无意中覆盖了关键的 storage variables，冻结了数十亿美元的 TVL，直到部署了 hotfix。

• 一个基于 Solana 的项目由于在不同版本中错误计算了 bumps，导致失去了对其 PDA vault 的访问权限。

• 在 Cosmos 中，配置错误的 migration logic 导致一些用户在升级后余额清零，迫使链停止并进行手动恢复。

每个生态系统都有其故事。共同的主题始终是：可升级性功能强大，但默认情况下很少是安全的。

设计更安全的升级

作为安全研究人员，我们倾向于将可升级性视为一项特权且危险的操作。如果你必须使用它，我们建议如下：

• 将升级访问权限锁定在 multisig 或 timelock 合约之后。
• 始终在 forked mainnet 环境中模拟你的升级。
• 明确验证版本之间的 storage layouts。
• 记录每个升级路径，包括预期结果和失败场景。
• 如果你的生态系统支持 governance 升级，请执行严格的 quorum 和投票期。

最重要的是：制定回滚计划。即使你认为升级是万无一失的。

总结

可升级性并非区块链系统中的缺陷。它是许多生产协议中的必需品。但它也是合约可能拥有的最危险的功能之一。无论你是在以太坊中使用 delegatecall，在 Solana 中升级 authorities，还是在 Cosmos 中迁移 hooks，有一点始终不变：你正在用不可变性换取责任。

这不仅仅是关于编写可升级合约。这是关于设计不损害用户信任、去中心化或安全的升级路径。

在这方面，真正的模式不仅仅是代码，更是谨慎。

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