可升级合约

什么是可升级合约？

可升级合约是一种智能合约设计，允许区块链应用在部署后修改或扩展其逻辑，同时保持面向用户的地址、存储状态和余额不变。

在加密货币领域，可升级合约最常用于 DeFi 协议、代币系统、质押合约、跨链桥、借贷市场、智能账户、治理系统，以及其他可能随时间需要修复或新增功能的链上应用。

传统智能合约通常被称为不可变合约，因为其已部署代码一旦上链便无法直接编辑。

可升级合约通过将合约地址和存储数据与执行用户操作的业务逻辑分离，解决了这一限制。

构建可升级合约最常见的方法是代理模式（Proxy Pattern）：用户与代理合约交互，代理则将调用转发至独立的实现合约。

代理保持相同的公开地址，而在授权升级发生时，实现合约可替换为新版本。

这意味着，每当协议修复漏洞、增加功能或改进内部逻辑时，用户无需迁移至新的合约地址。

对加密用户而言，主要优势是连续性，因为代币余额、质押记录、投票权和协议仓位可保留在同一合约存储中。

对开发者而言，主要优势是灵活性，因为他们可改进协议，而无需强制全面迁移用户资金和数据。

对投资者和交易者而言，主要担忧是治理风险，因为在用户已经存入资产后，升级权限仍可能改变协议的行为方式。

可升级合约如何运作

可升级合约通常至少包含两个核心部分：代理合约和实现合约。

代理合约是用户、钱包、区块链浏览器和其他智能合约通常与之交互的地址。

实现合约包含实际逻辑，例如转账规则、质押计算、借款功能、奖励分配或访问控制检查。

当用户向代理发送交易时，代理会使用名为

的底层机制运行实现合约的代码。

使用

时，实现逻辑会像代理的一部分一样运行，但存储、地址和余额仍绑定于代理。

因此，代理可在升级期间变更实现地址，同时保留用户数据。

升级本身通常由获授权的管理员、多签钱包、治理合约或时间锁将代理的实现指针更改为新的实现合约来完成。

新的实现合约必须经过精心设计，以兼容代理的现有存储布局。

如果存储布局遭到破坏，升级后的合约可能错误读取余额、所有权记录、权限或其他关键数据。

这也是可升级合约比简单的不可升级合约需要更严格的工程设计、测试和审计的主要原因之一。

可升级合约为何对加密市场重要

可升级合约很重要，因为加密应用通常保障真实资产，且无法依赖传统软件更新方式。

在普通 Web 应用中，开发者可以修补后端代码、重新部署服务或修改数据库，而无需要求用户迁移资产。

在公共区块链上，已部署的合约代码通常是永久性的，因此如果合约不可升级，严重漏洞可能需要进行困难的迁移。

可升级设计允许对协议逻辑进行受控更新，从而缓解这一问题。

当项目需要修复漏洞、支持新的代币标准、添加风险控制、提高 Gas 效率或应对区块链生态变化时，这种设计会很有用。

不过，可升级性也会改变加密应用的信任模型。

如果单个地址能够立即升级合约，用户就必须信任该地址不会部署恶意或疏忽的逻辑。

如果升级由去中心化治理控制，用户就必须信任治理流程、投票规则、时间锁和投票者参与情况。

设计良好的可升级合约，应在灵活性与对升级者、升级时间及用户监控变更方式的严格限制之间取得平衡。

代理模式

代理模式是可升级合约中最广泛使用的架构。

在此模式下，代理合约存储状态并将函数调用转发至实现合约。

实现合约包含业务逻辑，但普通用户不应直接使用它。

当协议升级时，会部署新的实现合约，并更新代理以指向该新实现。

面向用户的地址保持不变，因此钱包、集成服务和其他合约可继续调用代理地址。

Ethereum 的智能合约升级文档对这一设计进行了详细说明。

代理模式功能强大，因为它避免了手动状态迁移；这种迁移可能成本高、风险大且会使用户感到困惑。

但当开发者不了解代理存储、函数选择器、初始化函数和管理员权限的工作原理时，它也会带来风险。

代理不会仅因可升级而自动安全。

该设计的安全性取决于实现质量、升级权限、测试、治理和监控。

实现合约

实现合约有时也称为逻辑合约，因为它包含定义应用如何运行的代码。

例如，在代币合约中，实现合约可以定义转账规则、授权、铸造限制、销毁逻辑和基于角色的权限。

在质押合约中，实现合约可以定义存入规则、提取规则、奖励公式、惩罚逻辑和紧急控制。

在借贷合约中，实现合约可以定义抵押品规则、利息计算、强制平仓逻辑和风险参数。

当代理将调用委托给实现合约时，实现合约代码会使用代理的存储。

这意味着，实现合约应以其变量将存储于代理合约内部的方式编写。

开发者通常应防止用户直接初始化或错误使用实现合约。

他们还应确保任何新实现均兼容上一版本的存储布局。

错误修改存储的新增实现可能对链上数据造成永久性损害。

存储布局

存储布局是可升级合约安全中最重要的概念之一。

在 Solidity 中，状态变量会根据包括变量顺序和继承顺序在内的特定规则放入存储槽位。

合约升级时，新实现必须以与旧实现相同的方式解释代理现有存储。

开发者通常只会在现有变量之后添加新变量，而不会删除变量、重新排序变量或修改变量类型。

如果合约最初在某一槽位存储用户余额，新版本不得意外将同一槽位视为管理员地址或奖励变量。

存储冲突可能导致余额异常、权限丢失、错误记账或可被利用的合约行为。

Solidity 存储布局文档说明了 Solidity 如何在持久化存储中组织状态变量。

现代可升级合约库也提供工具和检查机制，帮助开发者在部署前发现不安全的存储变更。

即使使用工具，每次升级时仍应仔细审查存储布局。

ERC-1967 代理存储槽位

ERC-1967 是一项常见的 Ethereum 标准，为代理信息定义了特定存储槽位，包括实现地址、管理员地址和 Beacon 地址。

ERC-1967 的目的在于减少代理与实现合约之间的存储冲突。

它还帮助区块链浏览器和开发者工具识别代理背后的实现合约。

没有标准存储槽位，钱包、浏览器、审计人员和监控工具就更难了解代理正在使用哪一个逻辑合约。

ERC-1967 尤其重要，因为代理本身需要存储与升级相关的数据，而实现合约也预期使用代理的存储。

官方ERC-1967 规范定义了这些代理存储槽位约定。

对加密用户而言，ERC-1967 可使可升级合约更容易检查，因为许多工具可显示当前实现地址。

对开发者而言，ERC-1967 提供了更安全、更标准的代理元数据存储方式。

ERC-7201 命名空间存储

ERC-7201 是一项较新的智能合约命名空间存储布局标准。

命名空间存储将相关状态变量归入特定命名空间，以减少存储布局冲突，尤其适用于复杂的可升级系统。

当合约使用继承、模块、插件或多个可升级组件时，这种方式很有用。

OpenZeppelin Contracts 5.x 在其可升级变体中采用了包含 ERC-7201 风格存储命名空间的可升级合约模式。

官方ERC-7201 规范描述了一项用于在 Solidity 源代码中记录命名空间存储位置的约定。

对开发者而言，命名空间存储可使升级更易于推理，因为每个合约组件都可以保留各自的存储区域。

对用户而言，命名空间存储大多不可见，但若正确实施，可提高安全性。

它并不能免除审计、测试和仔细审查升级的需要。

使用初始化器而非构造函数

可升级合约通常使用初始化器函数，而非构造函数。

普通构造函数仅在合约部署时运行一次；但在代理设计中，代理使用实现合约代码时，不会为代理状态运行实现合约的构造函数。

因此，可升级合约通常将设置逻辑移至如

的函数中。

初始化器会设置代币名称、代币符号、所有者地址、管理员角色、手续费参数或初始配置等值。

初始化器必须受到保护，以确保每个代理只能运行一次。

如果初始化器可被多次调用，攻击者可能重置所有权、修改权限或控制合约。

OpenZeppelin 的可升级合约编写指南解释了为何基于代理的可升级合约使用初始化器函数替代构造函数。

当新版本增加新的设置要求时，良好的可升级合约也会谨慎使用重新初始化器函数。

每个初始化器和重新初始化器都应作为升级流程的一部分接受审查。

透明代理

透明代理是一种将管理员调用与用户调用分离的代理设计。

在此模型中，管理员可执行与升级相关的操作，而普通用户的调用会转发至实现合约。

透明代理模式有助于避免管理员意外通过代理触发实现函数的问题。

它还能降低代理管理员函数与实现函数之间发生函数选择器冲突的风险。

这一模式在生产系统中很常见，因为它为升级提供了清晰的管理员结构。

其代价是可能涉及额外的部署和管理组件，例如代理管理员合约。

对用户而言，重要的是识别谁控制代理管理员，以及升级是否被延迟、受治理或接受外部监控。

UUPS 代理

UUPS 是 Universal Upgradeable Proxy Standard 的缩写。

在 UUPS 设计中，升级逻辑通常放在实现合约中，而非完全由代理自身管理。

这可以使代理更小且部署成本更低，但也意味着实现合约必须正确包含并保护升级函数。

如果升级授权逻辑存在错误，合约可能容易遭受未授权升级。

如果未来实现中删除或破坏升级函数，代理可能变得难以或无法再次升级。

UUPS 代理很受欢迎，但需要仔细的访问控制和测试。

用户应检查 UUPS 合约是否具有明确的升级权限、时间锁和公开的升级历史。

Beacon 代理

Beacon 代理是一种设计，其中多个代理合约从共享的 Beacon 合约读取其实现地址。

通过变更 Beacon 中存储的实现地址，该设计允许一次性升级多个代理实例。

当协议部署许多类似合约，例如金库、池、账户或代币化仓位时，Beacon 代理可能很有用。

主要优势是运营效率，因为一次 Beacon 升级可以更新多个代理。

主要风险是集中性，因为一次错误的 Beacon 升级可能同时影响多个合约。

Beacon 所有权和升级权限应通过强有力的治理和监控进行保护。

钻石模式

钻石模式是一种升级架构，其中一个代理可以将不同函数调用路由到不同的实现合约，通常称为 Facet。

它允许将大型智能合约系统拆分为更小的模块。

钻石设计可升级系统的某一部分，而无需一次性替换每个函数。

对于需要在一个地址下提供众多功能的复杂加密协议，这种方式可能很有用。

其代价是复杂性，因为开发者必须非常谨慎地管理函数选择器、Facet 存储、访问控制和升级规则。

钻石模式系统功能强大，但普通用户可能比检查简单代理结构更难检查它们。

可升级合约的优势

可升级合约的第一项优势是修复漏洞。

如果发现严重问题，开发者可能能够修补逻辑，而无需强制用户手动迁移资金。

第二项优势是功能扩展。

协议可在保持相同合约地址的同时，增加新的抵押品类型、奖励规则、模块或安全控制。

第三项优势是集成稳定性。

升级后，钱包、分析平台、聚合器和其他智能合约仍可指向同一代理地址。

第四项优势是用户体验。

用户在每次协议更新时可能无需授权、提取、重新存入或手动迁移仓位。

第五项优势是紧急响应。

治理良好的升级流程可帮助协议比完整迁移流程更快地应对实时风险。

可升级合约的风险

可升级合约最大的风险是管理员滥用。

如果升级权限由薄弱的私钥、疏忽的团队或遭破坏的治理流程控制，合约可能以有害方式被修改。

恶意升级可能盗取资金、阻止提币、修改手续费、改变余额或移除用户保护措施。

另一项重大风险是存储损坏。

设计不当的实现升级可能破坏旧数据与新逻辑之间的关系。

第三项风险是隐藏的复杂性。

用户可能以为自己正与一个合约交互，但实际行为取决于当前实现地址和升级权限。

第四项风险是监控不足。

如果用户和集成服务不跟踪升级，可能错过协议行为的重要变化。

第五项风险是治理被控制。

如果投票权过于集中，少数群体可能批准有利于自身却损害其他用户的升级。

用户如何评估可升级合约

用户应首先检查合约是否为代理，以及其当前使用哪个实现合约。

当合约遵循 ERC-1967 等常见代理标准时，许多区块链浏览器会显示代理信息。

用户还应检查谁拥有升级合约的权限。

由单一外部拥有账户控制的升级，通常比由多签、时间锁或透明治理流程控制的升级风险更高。

用户应查看项目是否在升级发生前公布相关信息。

还应检查合约是否经过审计、审计报告是否覆盖升级逻辑，以及此前升级是否安全执行。

对于大额存入，用户应关注时间锁期限、紧急暂停权限、管理员角色变化和升级事件历史。

即使合约在技术上编写良好，如果升级权限过度中心化或监控不足，仍可能存在风险。

开发者最佳实践

除非拥有丰富的安全经验，开发者应使用经过充分审查的升级框架，而不是从零编写代理逻辑。

开发者应通过多签所有权、基于角色的权限、时间锁或链上治理等强访问控制来保护升级函数。

开发者应为初始部署和每条升级路径编写自动化测试。

开发者应在升级前后比较存储布局，以检测不安全的变化。

开发者应使用初始化器保护，并避免未受保护的设置函数。

除非确有必要且经过全面审查，否则应避免危险的底层模式。

开发者应公开实现合约源代码，并使代理关系易于检查。

升级发生时应触发清晰事件，以便监控系统检测变更。

开发者应记录变更内容、变更原因以及所考虑的风险。

开发者应规划紧急响应，同时避免赋予单一参与者无限权力。

可升级合约与不可变合约

不可变合约在部署后无法更改其已部署代码。

这为用户提供了强可预测性，因为除非合约本身已经包含可配置参数，否则规则是固定的。

可升级合约可通过既定的升级机制修改其逻辑。

这为开发者提供了灵活性，但要求用户信任升级流程。

不可变合约通常更适合简单资产、最小化协议或固定规则比未来灵活性更重要的系统。

可升级合约通常更适合可能需要修补、风险控制、集成和长期维护的复杂协议。

两种设计并非总有一种更好。

正确选择取决于受保障的价值、应用复杂性、预期升级需求和治理强度。

为何可升级性影响代币和协议风险

可升级合约会直接影响代币持有者，因为合约逻辑可能定义铸造、销毁、转账限制、手续费或治理权利。

如果升级改变代币规则，可能影响市场信心和代币用途。

可升级质押合约可能影响奖励率、锁定期、惩罚和提取行为。

可升级借贷合约可能影响抵押率、强制平仓阈值、利率和市场风险控制。

可升级跨链桥可能影响资产托管、消息验证和提取逻辑。

因此，交易者和长期投资者应将升级权限作为协议基本面分析的一部分。

代币在市场层面可能看似去中心化，但仍可能依赖一个可由少数群体升级的合约。

了解可升级性有助于用户判断协议规则是真正固定，还是仍可能发生变化。

常见误解

一种常见误解是，可升级合约意味着原始合约代码会在链上被编辑。

在大多数代理设计中，原始代理代码不会被编辑，而是将代理指向不同的实现合约。

另一种误解是可升级性总是不好。

当可升级性透明、受限、经过审计且得到负责任治理时，它可能很有用。

第三种误解是审计能够消除升级风险。

审计可以审查当前代码和升级流程，但未来实现可能引入新的风险。

第四种误解是用户只需检查代币合约地址。

对于可升级系统，用户还应检查实现合约、管理员角色和升级事件。

第五种误解是去中心化会自动防止不良升级。

如果投票权集中、参与度低或提案难以审查，治理仍可能失败。

FAQ

加密领域中的可升级合约是什么？

可升级合约是一种智能合约设计，允许协议在部署后修改逻辑，同时保留相同地址和存储数据。

为何加密项目使用可升级合约？

加密项目使用可升级合约来修复漏洞、增加功能、改进安全控制、降低迁移成本，并长期维持集成。

可升级合约安全吗？

当可升级合约采用强访问控制、谨慎的存储管理、审计、监控和透明治理时，可能是安全的。

可升级合约的主要风险是什么？

主要风险是获授权的升级者可能部署有害或存在缺陷的逻辑，从而改变协议行为或使用户资金面临风险。

什么是代理合约？

代理合约是面向用户的合约，负责存储数据并将调用转发给包含当前逻辑的实现合约。

什么是实现合约？

实现合约是逻辑合约，定义代理将调用委托给它时函数的行为方式。

为什么可升级合约使用初始化器？

可升级合约使用初始化器，是因为构造函数逻辑不会像普通合约部署那样初始化代理的存储。

什么是存储冲突？

当新合约逻辑以与旧布局冲突的方式读取或写入存储槽位时，就会发生存储冲突。

什么是 ERC-1967？

ERC-1967 是一项标准，定义了实现地址、管理员地址和 Beacon 地址等代理信息的存储槽位。

什么是 ERC-7201？

ERC-7201 是一项命名空间存储布局标准，有助于组织状态变量并减少复杂可升级合约中的存储冲突。

可升级合约之后能变为不可变合约吗？

可以，部分项目可以放弃或禁用升级权限，但用户应在链上验证，而不应只依赖公告。

用户如何检查合约是否可升级？

用户可以在区块链浏览器中检查合约、寻找代理信息、查看实现地址，并检查管理员或治理权限。

结论

可升级合约是一种强大的智能合约设计，使加密协议能够在保留地址、状态和余额的同时改进逻辑。

最常见的设计使用代理合约存储数据，并将执行委托给可替换的实现合约。

这种模式可使漏洞修复、功能升级和长期协议维护更容易。

但如果升级权限过度中心化、存储布局处理不当或治理薄弱，它也可能引入严重风险。

ERC-1967 代理存储槽位、ERC-7201 命名空间存储、初始化器函数、审计、时间锁和透明管理员控制等重要标准和实践，可降低这些风险。

对于加密用户而言，可升级性应始终是风险分析的一部分，因为它决定协议规则是固定的还是仍可能改变。

对于开发者而言，可升级合约应被视为安全关键型基础设施，从首次部署开始便需要谨慎设计、测试、监控和治理。