代理合约

什么是代理合约？

代理合约是一种智能合约，可接收用户调用，并将其转发至另一个包含实际业务逻辑的合约。

在加密领域，代理合约主要用于让智能合约系统支持升级，同时保留相同的公开合约地址和已存储状态。

用户实际交互的合约通常称为代理合约。

包含当前逻辑的合约通常称为实现合约、逻辑合约或主副本。

OpenZeppelin 代理升级模式说明，基于代理的可升级机制通过将合约存储与合约逻辑分离来实现。

这种分离很重要，因为智能合约部署后通常很难或无法更改。

如果项目部署普通合约后发现漏洞，团队可能需要在新地址部署新合约。

代理合约可以解决这一问题：在升级获批后，代理地址保持不变，只需将其指向新的实现合约。

用户、钱包和应用继续与代理地址交互，而该地址背后的逻辑则可以更改。

理解代理合约最简单的方式是：它是固定不变的正门，而实现合约则是门后可以替换的引擎。

代理合约为何存在？

代理合约之所以存在，是因为区块链的不可篡改性既带来安全性，也造成了不便。

不可篡改性很有用，因为用户可以相信，已部署的代码不会像普通网站软件那样被暗中修改。

不过，当开发者需要修复漏洞、添加功能、应对安全问题、提升性能或支持新标准时，不可篡改性就会成为问题。

没有代理合约时，升级智能合约往往意味着部署新合约，并要求用户迁移资产或权限。

这种迁移可能成本高昂、容易造成困惑和风险，也可能干扰用户操作。

代理合约可以让面向用户的地址保持稳定。

这对 DeFi 协议、NFT 项目、DAO、代币合约、跨链桥、质押系统、游戏资产和账户抽象钱包都很重要。

它可以减少用户操作障碍，因为每次逻辑变更时，集成方都不必更换合约地址。

它还可能提升安全性，因为紧急修复可以更容易地部署。

不过，可升级性也引入了信任假设，因为必须由某个主体或治理流程获得更改实现合约的权限。

代理合约的工作原理

代理合约通过存储状态并将函数调用转发给实现合约来运行。

用户调用代理合约时，代理通常不会自行执行主要应用逻辑。

相反，代理会使用

等底层 EVM 操作将调用转发给实现合约。

执行的是实现合约的代码，但发生变更的是代理合约的存储空间。

这是可升级代理系统得以实现的关键。

代理合约保存余额、设置、所有权变量、代币供应量、用户仓位和其他状态。

实现合约提供用于读取和更新这些状态的代码。

系统升级时，会部署一个包含新逻辑的新实现合约。

随后，代理合约会将实现合约指针更新为新合约。

用户访问的地址和已存储数据仍由代理保留，之后的调用则会使用新逻辑。

代理合约与 Delegatecall

是许多代理合约赖以运行的底层机制。

在普通外部调用中，一个合约调用另一个合约，而被调用合约使用自己的存储空间。

使用

时，被调用合约的代码会在调用方合约的存储上下文中运行。

对代理合约而言，这意味着实现合约的代码可以修改代理合约的存储。

这种机制功能强大，因为代理可以保留状态，同时更换所使用的实现代码。

它也很危险，因为实现代码必须考虑代理的存储布局。

如果实现合约写入错误的存储槽，就可能破坏关键数据。

如果代理将调用委托给恶意实现合约，恶意逻辑就可能转走资产或更改权限。

SWC-112 关于 delegatecall 的警告建议开发者谨慎使用

，并避免调用不可信合约。

在代理系统中，

不只是一个技术细节，而是安全模型的核心。

代理合约与实现合约

代理合约和实现合约承担不同职责。

代理合约保留用户调用的地址，通常也存储系统状态。

实现合约包含决定如何更改状态的函数和规则。

例如，代币代理可以在代理存储中保存余额，而实现合约则定义转账、授权、铸造、销毁或访问控制逻辑。

需要添加新功能时，开发者会部署新的实现合约。

随后，代理会升级并指向该新实现。

代理地址保持不变，因此用户和集成方无需切换到新地址。

这种模式很有用，但用户应了解由谁控制升级。

如果代理管理员由单个私钥控制，该密钥可能对合约拥有极大的控制权。

如果升级由治理机制通过时间锁和投票流程控制，用户可能有更多时间在变更生效前审查内容。

代理合约与普通智能合约

普通智能合约通常在同一个合约中包含存储和逻辑。

部署后，普通合约的代码通常是固定的。

基于代理的系统至少将存储和逻辑拆分到两个合约中。

代理负责存储状态并转发调用。

实现合约负责提供逻辑，并可在升级机制允许的情况下替换。

因此，代理系统比普通合约更加灵活。

但它也更难审计，因为安全性取决于代理、实现合约、管理员控制、初始化流程、存储布局和升级历史。

普通合约对用户而言可能更简单，因为地址上的代码就是实际执行的代码。

使用代理合约时，用户和审计人员需要查看代理背后的当前实现。

因此，区块链浏览器通常会标记已验证的代理合约；如果能识别当前实现合约，也会显示其地址。

代理合约与可升级性

使用代理合约最常见的原因是实现可升级性。

可升级合约允许开发者在部署后更改逻辑，同时保留代理地址。

这对修复漏洞、添加功能、改进 Gas 效率、接入新集成、调整治理或升级协议都可能很有用。

不过，可升级性会改变信任模型。

可升级合约无法像不可升级合约那样完全不可篡改。

用户需要信任升级权限的持有者不会引入恶意或草率的变更。

升级权限可能由单一所有者、多重签名钱包、DAO、时间锁控制器或其他治理合约持有。

更安全的设计通常会让升级权限保持透明，并提高滥用权限的难度。

例如，时间锁可以在重大升级执行前给用户留出退出时间。

如果缺少强有力的控制措施，代理合约可能成为通往用户资金的隐蔽后门。

ERC-1967 代理标准

ERC-1967 是一种广泛使用的代理存储槽标准。

ERC-1967 标准为代理信息定义了特定存储槽，例如实现合约地址、管理员地址和信标地址。

其目标是避免代理与实现合约之间发生存储冲突。

当两个变量意外使用同一个存储槽时，就会发生存储冲突。

在代理系统中，由于代理存储和实现逻辑通过

交互，存储冲突尤其危险。

ERC-1967 还有助于区块链浏览器和开发者工具识别代理背后的当前实现。

这让代理系统更容易检查和审计。

许多常见的可升级代理模式都会使用 ERC-1967 存储槽。

采用已知标准并不会自动确保代理安全。

但它可以减少本可避免的混淆，并帮助工具识别关键代理数据的存储位置。

透明代理

透明代理是一种将管理员调用与用户调用分开的代理模式。

在这种模式下，普通用户调用代理后，调用会被转发给实现合约。

管理员可以执行与升级相关的操作，但通常不能通过代理误调用实现合约中的函数。

这种设计有助于避免代理管理员函数与实现合约函数之间发生函数选择器冲突。

OpenZeppelin 的代理文档将

列为一种内置管理员和升级接口的代理。

透明代理很常见，因为升级逻辑明确位于系统的代理一侧。

不过，与更精简的代理模式相比，它可能会产生稍高的开销。

此外，代理管理员也需要谨慎管理。

如果代理管理员遭到入侵，攻击者可能会将合约升级为恶意逻辑。

透明代理的安全性取决于其实现代码和管理员安全。

UUPS 代理

UUPS 是 Universal Upgradeable Proxy Standard 的缩写，即通用可升级代理标准。

ERC-1822 UUPS 标准介绍了一种通过实现合约逻辑管理升级兼容性的代理设计。

在 UUPS 设计中，升级函数位于实现合约，而不是复杂的代理管理员接口中，因此代理本身可以更加精简。

这可能降低部署成本和代理复杂性。

不过，开发者必须正确保护实现合约中的升级函数。

如果访问控制设置错误，攻击者可能有机会升级系统。

如果新实现移除了升级函数或破坏了该功能，代理之后可能难以甚至无法再次升级。

OpenZeppelin 的 UUPS 工具包含一些保护措施，以减少意外失去升级能力的情况，但开发者仍需仔细审查。

UUPS 代理功能强大，因为它兼具灵活性和效率。

如果团队不了解升级权限的实际归属位置，UUPS 代理也会带来风险。

信标代理

信标代理从独立的信标合约获取实现合约地址。

许多代理可以指向同一个信标，而无需各自存储实现合约地址。

信标升级后，所有使用该信标的代理都可以开始使用新的实现合约。

当项目需要部署许多逻辑相同、且希望能够一起升级的合约时，这种设计很有用。

例如，工厂合约可以创建许多采用相同逻辑的用户金库、资金池、账户或 NFT 相关合约。

信标代理可以简化批量升级。

但它也可能增加风险，因为一次信标升级就可能同时影响多个代理实例。

必须妥善保护信标管理员。

用户应了解自己的合约是否依赖信标，因为信标变更可能改变许多合约的行为。

信标代理适合管理大量合约，但会将升级权集中在信标上。

最小代理与 ERC-1167

最小代理是一种非常精简的代理合约，旨在以较低部署成本复制另一个实现合约的行为。

ERC-1167 最小代理标准定义了一种精简的字节码模式，可低成本创建合约克隆，并将调用转发给固定的实现合约。

最小代理通常也称为克隆合约。

如果项目需要部署许多逻辑相同的合约，例如钱包、金库、资金池、账户或市场实例，最小代理就很有用。

每个克隆合约都有独立地址和状态，但会复用实现合约的逻辑。

由于无需重复部署完整实现代码，这种方式可以节省 Gas。

并非所有最小代理都可升级。

许多 ERC-1167 克隆会指向固定实现，除非在其他地方添加额外升级逻辑，否则无法更改目标合约。

这一区别很重要：最小代理着眼于低成本克隆，而可升级代理着眼于替换逻辑。

有些系统会结合使用这两种思路，但不应将它们混为一谈。

代理合约中的存储布局

存储布局是代理合约设计中最重要的主题之一。

由于代理存储状态而实现合约提供逻辑，实现合约必须按照正确顺序读取和写入存储。

如果新实现不正确地更改变量顺序，就可能把旧存储内容识别为错误的数据类型。

例如，余额映射可能会被误当成所有者变量，或者配置值可能被新变量覆盖。

这可能导致合约失效或产生安全漏洞。

可升级合约框架通常要求开发者追加新变量，而不是重排或删除旧变量。

有时会使用存储间隔为未来变量预留空间。

存储布局检查可以在部署前发现许多升级错误。

开发者应将存储布局视为合约公开安全模型的一部分。

如果可升级项目没有说明升级时如何检查存储布局，用户应保持谨慎。

代理合约的初始化

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

构造函数只会在实现合约部署时运行。

但在代理系统中，用户与代理交互，因此需要初始化的是代理的存储空间。

这意味着通常要通过代理调用初始化函数来执行设置逻辑。

初始化可能会设置所有者、代币名称、金库地址、管理员角色、供应量、手续费设置或治理参数。

如果忘记初始化，代理可能处于未受保护状态。

如果攻击者抢先调用初始化函数，就可能成为所有者或管理员。

如果初始化函数可以重复调用，关键设置就可能被覆盖。

因此，可升级合约需要使用初始化保护机制，防止重复初始化。

初始化漏洞是可升级合约中最常见、也最危险的错误之一。

代理管理员与升级权限

代理管理员是有权升级代理实现合约的账户或合约。

这一角色可能由单个钱包、多重签名钱包、DAO 投票、时间锁或治理合约控制。

管理员角色极为重要，因为它可以更改控制用户资产的代码。

即使先前的实现安全，如果管理员升级为恶意逻辑，用户仍可能损失资金。

如果管理员密钥被盗，攻击者可能会替换实现合约。

如果管理员响应过慢或权力分散过度，紧急修复可能难以落实。

良好的代理治理需要平衡安全性、响应速度、透明性和用户退出权。

升级公告发布后，时间锁可以延迟升级执行，从而提升用户信任。

多重签名可以通过要求多位签署者共同批准来降低单一密钥风险。

公开升级提案和审计报告有助于用户了解变更内容。

代理合约与区块链浏览器

区块链浏览器通常可以帮助用户检查代理合约。

较好的区块链浏览器可能会标明某个地址是代理合约，并识别当前实现地址。

如果代理遵循 ERC-1967 等已知标准，浏览器还可能显示代理管理员信息。

这有助于用户和审计人员查看实际执行的代码。

如果浏览器无法识别代理，用户可能只查看代理字节码而忽略实现逻辑。

这可能造成虚假的安全感，因为代理中可能几乎没有可见的应用代码。

用户应检查实现合约的源代码是否已验证。

用户还应查看实现合约是否曾发生变更。

如果代理已升级为新逻辑，旧审计报告可能不再适用。

对于高价值交互，审查代理、实现合约、管理员和升级历史，比只检查可见地址更稳妥。

代理合约与代币合约

许多代币合约会使用代理，以支持未来升级。

可升级代币可以保留相同的代币地址，同时更改转账规则、手续费规则、铸造逻辑、销毁逻辑、跨链逻辑、合规规则或治理功能。

当代币需要随着时间调整时，这种设计可能很有用。

但它也可能带来风险，因为用户购买或收到代币后，所依赖的规则仍可能发生变化。

例如，升级可能新增转账限制、更改手续费行为、增加暂停权限或修改访问控制。

在认定代币规则永久不变之前，用户应检查其合约是否可升级。

用户还应查看谁控制升级，以及治理流程是否会延迟变更。

使用代理的代币并不一定不安全。

这只是意味着它的信任模型与完全不可篡改的代币合约不同。

关键在于升级权限是否透明且受到妥善保护。

代理合约与 DeFi 协议

DeFi 协议经常使用代理合约，因为金融应用需要维护。

借贷协议、自动做市商、衍生品系统、质押金库或收益策略，可能需要在审计、市场变化、预言机改进或发现漏洞后进行升级。

代理合约让这些系统可以改进，而无需强制每位用户迁移仓位。

这很方便，因为 DeFi 仓位可能较为复杂，也可能与许多协议相互关联。

不过，可升级性也会带来系统性风险。

广泛使用的 DeFi 合约如果进行不当升级，可能会同时影响许多用户和集成方。

可升级的 DeFi 协议应具备严格的测试、审计、监控、治理控制和应急流程。

用户不应只关注协议是否经过审计。

用户还应确认当前实现是否经过审计，以及未来升级是否需要公开审查。

在 DeFi 领域，代理合约提升了可维护性，但也使治理变得更加重要。

代理合约与 NFT

NFT 项目可能使用代理合约来支持可升级的元数据逻辑、铸造逻辑、市场集成、版税逻辑、质押系统或游戏机制。

NFT 代理可以让项目在上线后增加功能。

如果实现合约控制代币 URI 逻辑，代理还可能允许更改元数据行为。

当项目从简单收藏品发展为游戏、会员权益或数字身份系统时，这可能很有帮助。

但如果收藏者期望规则固定或元数据永久不变，这种设计也可能引发争议。

NFT 买家应检查 NFT 合约是否可升级，以及元数据是否可以更改。

买家还应查看谁控制升级管理员。

完全不可篡改的 NFT 和可升级 NFT 都可能是合理设计，但它们提供的保障不同。

收藏者应了解自己购买的是规则固定的 NFT，还是参与一个可能持续演变的项目。

代理合约让 NFT 开发更加灵活，但也要求用户信任项目的升级流程。

代理合约与 DAO

DAO 可能使用代理合约升级治理模块、金库工具、投票系统、质押合约或协议参数。

与由单一管理员控制的代理相比，由 DAO 控制的代理可能更加透明，因为升级或许需要提案和投票。

不过，DAO 治理并不会自动让升级变得安全。

投票参与率低、买票、治理攻击、仓促的提案或不清晰的代码变更仍可能带来风险。

良好的 DAO 升级流程应包括易读的摘要、技术差异说明、审计链接、风险分析、投票时限和时间锁延迟。

DAO 成员应了解哪些合约可以升级，以及治理拥有何种权限。

如果治理可以升级金库合约、代币合约或核心协议逻辑，投票者就需要对重大的安全决策负责。

代理合约可以帮助 DAO 随时间调整。

它们也可能赋予治理更改用户原以为稳定不变的规则的权力。

DAO 的可升级性应保持可见、有文档记录并受到谨慎控制。

代理合约的优势

代理合约的第一个优势是可升级性。

项目可以修复漏洞、增加功能并改进逻辑，同时无需更改主要合约地址。

第二个优势是状态连续性。

实现逻辑发生变化时，用户余额、仓位、权限和设置仍可保存在代理中。

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

钱包、dApp、索引器和其他合约可以继续使用同一个地址。

第四个优势是减少迁移障碍。

每次升级后，用户可能都无需手动将资产迁移到新合约。

第五个优势是克隆模式下的 Gas 效率。

与每次都部署完整代码相比，最小代理可以更低成本地部署许多相似合约。

第六个优势是模块化架构。

团队可以更清晰地分离存储、逻辑、升级控制和部署模式。

只有在代理合约经过谨慎设计、审计、治理和监控时，这些优势才有价值。

代理合约的风险

第一项风险是恶意升级。

如果升级权限遭到入侵或被不诚实地行使，安全逻辑可能会被恶意逻辑替换。

第二项风险是存储冲突。

如果存储布局错误，升级可能会破坏重要合约状态。

第三项风险是初始化失败。

未初始化的代理或实现合约可能让攻击者取得控制权。

第四项风险是函数选择器冲突。

如果设计不当，代理管理员函数可能与实现合约函数冲突。

第五项风险是审计与当前代码不匹配。

合约过去可能经过审计，但当前实现可能已经不同。

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

用户可能没有意识到自己交互的是代理，而不是简单的不可升级合约。

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

攻击者可能通过投票权、管理员权限或社会工程影响升级流程。

第八项风险是工具识别错误。

如果代理采用自定义或非标准设计，区块链浏览器、钱包和索引器可能无法正确显示代理详情。

交互前如何检查代理合约

用户应首先在区块链浏览器上检查该合约地址是否被标记为代理。

用户应查找当前实现合约地址。

用户应确认实现合约源代码是否已发布并通过验证。

用户应检查实现合约近期是否发生变化。

用户应了解由谁控制代理管理员或升级权限。

用户应检查升级是否通过多重签名、DAO、时间锁或单个私钥进行。

用户应对照实现合约的部署时间，检查审计报告的日期。

用户应阅读官方文档，了解合约是否有意设计为可升级。

即使代理地址没有变化，用户也不应因此认定合约不可升级。

对于大额存款，用户应将代理审查视为常规尽职调查的一部分。

开发者最佳实践

开发者应使用经过充分审查的代理框架，不要在未经专家审查的情况下自行编写代理逻辑。

在适当情况下，开发者应遵循 ERC-1967 等标准，以便工具检查代理状态。

开发者应使用强有力的访问控制保护升级函数。

对于价值较高的升级权限，开发者应使用多重签名钱包、时间锁或治理合约。

开发者应谨慎编写初始化函数，并防止重复初始化。

每次升级前，开发者都应测试存储布局。

不了解后果时，开发者绝不能重排、删除或更改现有存储变量。

开发者应在区块链浏览器上验证实现合约。

进行重大变更前，开发者应发布升级公告、审计报告和技术说明。

开发者应监控升级事件，并在升级失败时做好迅速响应的准备。

用户最佳实践

用户应了解，可升级代理与完全不可篡改的智能合约并不相同。

存入大量资金前，用户应检查由谁升级代理合约。

用户应检查升级是否会受到时间锁延迟。

用户应确认最新实现是否已验证并经过审计。

如果代理管理员由一个身份不明的钱包控制，用户应保持谨慎。

对于持有大量仓位的协议，用户应关注升级事件。

除非了解相关风险，否则用户应避免向可升级合约授予无限代币额度。

使用协议后，用户应撤销不必要的授权。

用户应记住，即使过去的行为看起来安全，升级仍可能改变未来的行为。

用户应将代理合约视为需要持续评估信任程度的灵活系统。

关于代理合约的常见误解

一种误解是代理合约必然不安全。

如果采用成熟模式、完善的访问控制、可靠的治理、审计和透明的升级流程，代理合约也可以安全运行。

另一种误解是使用了知名框架的代理合约就必然安全。

即使是标准代理，如果实现合约有恶意逻辑或管理员遭到入侵，也可能非常危险。

另一种误解是代理地址包含了用户需要审查的全部逻辑。

实际上，关键应用逻辑通常位于实现合约中。

还有一种误解是审计报告始终涵盖当前代码。

如果代理已经升级，旧审计报告可能没有审查新的实现合约。

另一种误解是最小代理都可以升级。

许多最小代理只是将调用转发给固定逻辑的低成本克隆合约。

常见问题

代理合约是什么意思？

代理合约是一种将调用转发给另一个合约的智能合约，通常用于在更改实现逻辑时保留相同地址和存储状态。

加密项目为什么使用代理合约？

项目使用代理合约来支持升级、修复漏洞、增加功能、减少迁移障碍、保持地址稳定，并高效部署多个相似合约。

代理合约可以升级吗？

许多代理合约可以升级，但并非所有代理都可升级，因为有些最小代理指向固定逻辑。

什么是实现合约？

实现合约包含代理通过转发或

执行的逻辑。

代理合约中的 delegatecall 是什么？

是一种 EVM 操作，允许代理在使用自身存储上下文的同时执行实现合约的代码。

什么是 ERC-1967？

ERC-1967 是一种为代理数据定义特定存储槽的标准，代理数据包括实现合约、管理员和信标地址等。

什么是透明代理？

透明代理是一种可升级代理模式，它将管理员升级调用与普通用户调用分开，以降低函数冲突风险。

什么是 UUPS 代理？

UUPS 代理是一种可升级代理模式，其升级逻辑由实现合约处理，而不是主要由代理合约处理。

什么是信标代理？

信标代理从信标合约获取实现合约地址，因此只需更改信标，就能同时升级多个代理。

什么是最小代理？

最小代理是一种精简的克隆合约，通常基于 ERC-1167 构建，可将调用转发至共享实现逻辑，以降低部署成本。

代理合约有风险吗？

有。如果升级权限管理薄弱、存储布局错误、初始化不安全，或用户不了解逻辑可能发生变化，代理合约就可能存在风险。

如何检查一个合约是否为代理合约？

可以在区块链浏览器中查看代理标记、实现地址、ERC-1967 存储槽、已验证的源代码和升级事件。

结语

代理合约是一种智能合约设计模式，它将面向用户的地址和存储状态，与执行合约行为的逻辑分开。

这种模式在加密领域得到广泛使用，因为它允许智能合约升级，而无需用户和集成方迁移到新地址。

代理接收调用、保存存储状态，并将执行转发给实现合约，通常通过

完成。

ERC-1967、ERC-1822 和 ERC-1167 等标准有助于规范常见代理设计，包括透明代理、UUPS 代理、信标代理和最小代理。

代理合约带来诸多优势，包括可升级性、状态连续性、集成稳定性和更低成本的克隆部署。

它们也会带来严重风险，包括恶意升级、存储冲突、未初始化合约、管理员密钥遭入侵、治理不明确和审计过时。

对开发者而言，代理合约应被视为高风险架构组件，需要谨慎设计、测试、实施访问控制并公开相关文档。

对用户而言，代理合约的审查方式应不同于普通不可升级合约，因为代理背后的逻辑可能随时间改变。

理解代理合约最简单的方式是：它可以在受控条件下替换某个链上地址背后的代码，同时保留相同的链上地址。

这种灵活性可以让加密系统更安全、更易维护，但前提是升级权限透明、受限并受到妥善治理。