Sui 软件包中的 upgrade_cap 是一个特殊对象，用于控制升级已发布的 Move 包的权限. 当您在 Sui 上发布软件包时，系统会创建一个链接到该包的 upgrade_cap 对象. 此对象由发布者或指定机构持有，需要在将来对软件包代码进行任何升级或修改. 如果没有 upgrade_cap，软件包将不可变，这意味着你无法更改或替换其模块. 这种设计强制执行安全、受控的升级，并防止未经授权的更改，这对于维持已部署的智能合约的信任和稳定性至关重要.

从 CLI 的角度来看，当您使用 sui 客户端发布发布包时，您会收到软件包 ID 和 upgrade_cap 对象 ID. 要升级，您必须签署引用当前 upgrade_cap 的交易，然后系统会发布新版本的软件包以及新的 upgrade_cap 对象. 在 Move 代码中，你不能直接操作 upgrade_cap，但你的部署脚本或链下逻辑必须安全地处理它.

在架构上，upgrade_cap 体现了软件包生命周期管理的所有权和权限控制，将 Sui 的包模型与以太坊的不可变合约或代理区分开来. 最佳做法是将upgrade_cap 安全地存储在离线状态下或存储在多重签名钱包中，以防止泄露. 此外，升级之前需要仔细的版本管理和测试，因为这会影响依赖软件包的所有用户.

典型的错误包括丢失 upgrade_cap，使您无法升级，或者权限管理不当导致安全风险. 使用 Sui CLI，您可以查询当前 upgrade_cap 以获取软件包，也可以提交使用和补发该软件包的升级交易.

总而言之，upgrade_cap 是在 Sui 上进行软件包进化的加密密钥，可在保持去中心化和安全性的同时实现受控的、许可的升级. 正确管理它对于生产就绪的 Sui 智能合约开发和部署工作流程至关重要.

在 Sui 中，upgrade_cap用于管理智能合约的可升级性，允许开发人员在不丢失数据的情况下更新合约. 它授予执行合同升级的权限，通常归可信地址所有.

关键点：

*控制升级：upgrade_cap确保只有授权地址才能触发升级. *移动代码：在移动模块中用于处理升级. *CLI 示例：

 sui client publish --upgrade --package <package-id> --capability <upgrade-cap-id>

最佳实践：

• 在本地网络/测试网络上测试升级.
• 保护upgrade_cap以防止未经授权的访问.

在 Sui 网络upgrade_cap中的作用

目的：控制谁可以升级智能合约或模块.

*它的作用：向特定地址（通常是管理员）授予升级权限. 它确保只有授权实体才能修改已部署的合同.

关键概念：

*移动语言：在 M upgrade_capove 中实现，用于安全合同管理. *部署：在合约部署期间指定，仅允许将来通过授权地址进行升级.

CLI 示例：

sui client publish --gas-budget 10000 --upgrade-cap <upgrade-cap-id>

示例移动代码：

public fun grant_upgrade_cap() {
    let upgrade_cap = UpgradeCap::new();
    // Assign cap to authorized address
}

常见问题：

*权限错误：未经授权的地址正在尝试升级. *缺少功能：确保在部署期间设置upgrade_cap正确.

最佳实践：

*限制 upgrade_cap：限制对可信地址的访问. *在本地网络/测试网中测试：在部署到主网之前，请确保行为正确.

upgrade_capSui 中的****用作软件包升级的授权机制，充当赋予其持有者升级权的独特能力对象. 与合约不可变的 EVM 链不同，Sui 的升级系统要求该对象修改已发布的软件包，在保持安全性的同时提供受控的可变性. 持有者upgrade_cap可以通过 sui client upgradeCLI 命令授权升级，也可以通过 Move 的package::authorize_upgrade功能以编程方式授权升级. 最佳做法包括安全地存储upgrade_cap（通常在Versioned或AdminCap包装器中）和实施适当的所有权控制，因为丢失它会永久锁定可升级性，同时暴露在未经授权的修改风险中.

在 Sui 网络中，在upgrade_cap实现 Move 软件包在初始部署后对其进行安全和受控升级方面起着至关重要的作用. 当您在 Sui 上发布包时，会UpgradeCap创建并返回一个类型为的对象. 该对象是允许将来升级软件包的唯一权限，实际上是授予更改其代码权限的密钥.

upgrade_cap如果您打算稍后升级软件包，则必须保留其所有权. 如果您将其转移到另一个地址或将其烧毁（例如，将其发送到0x0），则无法进行进一步升级. 除非包创建者明确选择加入，否则这种设计强制执行不变性.

为什么 upgradeCap 很重要

Sui 的以对象为中心的模型引入了这个概念，以区分不可变包和可升级的包. 没有访问权限的包upgrade_cap被视为永久不可变. 这与EVM链形成鲜明对比，在EVM链中，只有手动构建delegatecall代理或可升级模式，合约才是可变的.

升级工作流程示例

当你发布软件包时：

sui client publish --path . --gas-budget 100000000

输出包括：

• 包裹编号
• upgradeCap 对象 ID

要稍后升级：

sui client upgrade \
  --package <original_package_id> \
  --module-upgrade-path <new_module_path> \
  --upgrade-cap <upgrade_cap_id> \
  --gas-budget 100000000

在 Move 中使用 upgradeCap

在 Move 模块中，您可以使用功能对象保护升级或敏感过渡：

public entry fun secure_upgrade(upgrade_cap: &UpgradeCap, ctx: &mut TxContext) {
    // logic that uses upgrade_cap as proof of authority
}

或者，如果你想完成软件包，请将其销毁：

transfer::public_transfer(upgrade_cap, @0x0);

这将永久取消您更新软件包的能力.

最佳实践

*** upgrade_cap如果您计划将来升级，请将其存储在安全的钱包或治理模块中**. *** upgrade_cap如果你想让你的包裹不可改变，那就烧掉**，这在金融合约或 NFT 中很常见，可以建立用户信任. *将升级逻辑封装在治理中，这样 DAO 或多重签名批准升级，而不是单个私钥. *避免泄露upgrade_cap身份证，因为在 Sui 中，所有权等于权力.

常见错误

*** upgrade_cap升级期间丢失**→ 导致 “权限被拒绝” 错误. *意外转为空值→ 您的包裹将永久锁定. *尝试对不可变包进行升级→ 系统将拒绝交易.

了解更多

• 文档：https://docs.sui.io/concepts/packages
• 升级示例：https://docs.sui.io/build/upgrade
• CLI 参考：https://docs.sui.io/reference/cli/client

归根结底，upgrade_cap这代表了 Sui 对明确权限和对状态和代码演变的精细控制的承诺. 了解如何使用、存储和撤销它是在Sui生态系统中构建安全和可维护的智能合约的关键.

upgrade_cap在 Sui 包中的作用

upgrade_cap是一个能力对象，用于控制 Sui 以对象为中心的升级系统中的软件包升级权限. 与使用代理模式的 EVM 链不同，Sui 通过这个专用的功能对象处理包级别的升级.

核心机制

发布软件包时：

sui client publish --gas-budget 100000000 --path ./move_package

交易返回：

1. 包裹 ID（不可变标识符）
2. upgrade_cap对象 (0x2:: package:: upgradeCap)

此能力对象： -是一个一流 Sui 对象，可以拥有、转让或共享 -必须作为输入包含在任何升级交易中 -包含它授权升级的软件包 ID

关键技术细节

1. 安全模型： -只有所有者upgrade_cap才能升级软件包 -遵循 Sui 的对象所有权模型（没有基于签名者的授权） -可以在多重签名合约或时间锁中进行管理

2. 升级过程：

  sui client upgrade --package [PACKAGE_ID] \
                    --upgrade-cap [UPGRADE_CAP_ID] \
                    --gas-budget 200000000 \
                    --path ./updated_package

3.关键移动模式：

  // Storing upgrade_cap in a publisher struct
  struct Publisher has key {
      id: UID,
      upgrade_cap: package::UpgradeCap,
  }
  
  // Upgrading (must use &mut reference)
  public entry fun upgrade(
      publisher: &mut Publisher,
      new_package: vector<u8>,
      new_modules: vector<vector<u8>>,
      ctx: &mut TxContext
  ) {
      package::upgrade_package(
          &mut publisher.upgrade_cap,
          new_package,
          new_modules,
          ctx
      )
  }

与 EVM 相比 Sui 的特定优势

-无需代理模式：升级发生在套餐级别，而不是合同级别 -向后兼容性：现有对象在升级后仍然有效 -基于能力的安全性：使用 Sui 的对象所有权模型而不是管理员角色 -透明治理：upgrade_cap可以存入 multisigs 或 DAO 国库

常见错误和解决方案

| 错误 | 原因 | 修复 | | --------------| -----| | UpgradeCap not found| 缺少能力对象 | 验证你使用的是正确的 upgrade_cap ID | | Package ID mismatch| 使用错误的 upgrade_cap | 检查软件包:: id (&cap) 是否与目标包匹配 | | Insufficient gas| 升级需要更多汽油 | 增加汽油预算（升级成本 2-3 倍常规税）| | Module compatibility error| 新版本中的重大更改 | 确保结构布局保持兼容 |

最佳实践

1. 用于生产：转移upgrade_cap到多重签名钱包
2. 对于不可变合约：发布后烧掉该能力 3.务必验证权能所有权：object::is_owner(&cap, tx_context::sender(ctx))
3. 升级时发出事件：event::emit(UpgradeEvent { package_id, version })

它upgrade_cap体现了 Sui 面向对象的安全模型——升级权限被视为可转让资产，而不是硬编码的管理员角色，在保持安全的同时提供了灵活的治理选项.

Sui 中的 upgrade_cap 是一个特殊对象，表示升级已发布的 Move 包的权限. 当您使用 Sui CLI 发布软件包时，系统会自动创建与该软件包关联的 upgrade_cap 对象. 此对象控制软件包在初始部署后升级或修改软件包的能力. 如果不持有 upgrade_cap，任何人都无法升级软件包，使其不可变.

例如，发布软件包时：

sui 客户发布--gas-budget 10000--path. /my_package

输出包括 upgrade_cap 对象 ID. 此对象必须包含在升级交易中才能证明权威. 要升级软件包，请致电：

<upgrade_cap_object_id>sui 客户端升级--packagrade-ca <new_package_path>p--gas-budget 10000

此交易消耗了旧的 upgrade_cap，并为升级后的软件包发行了新的 upgrade_cap. upgrade_cap 对软件包生命周期实施严格的权限控制，确保只有授权方才能修改合约代码.

从 Move 的角度来看，软件包代码本身并不能直接操作 upgrade_cap，因为它是在协议级别上处理的. 但是，开发人员需要在链下安全地管理该对象，通常将其存储在安全钱包或多重签名设置中，以防止未经授权的升级.

丢失 upgrade_cap 意味着你无法再次升级软件包，实际上是永久锁定了代码. 这凸显了安全密钥管理做法的重要性. 此外，升级软件包会影响所有依赖它的用户，因此在部署之前，应在测试网或本地网络上对升级进行全面测试.

由于 Sui 软件包是版本控制的，所以 upgrade_cap 是在版本之间移动的关键. 系统通过将软件包版本控制与该功能绑定来保证原子升级.

你可以使用 Sui CLI 或 SDK 查询与软件包关联的 upgrade_cap：

sui 客户端获取软件包 <package_id>

它返回包裹的详细信息，包括当前的upgrade_cap. 安全地处理 upgrade_cap 是 Sui 开发工作流程最佳实践的一部分，以避免意外或恶意的代码更改.

与以太坊的不可变合约或代理升级模式相比，Sui 的 upgrade_cap 是一个明确的控制升级的链上能力对象. 这种设计通过使升级权限成为系统中的明确对象来增强透明度和安全性.

开发人员必须将 upgrade_cap 管理整合到他们的部署管道中，通常是编写升级过程脚本以包含 upgrade_cap 对象，并确保该对象由正确的密钥签名.

upgrade_capin Sui 软件包是一种特殊对象，它赋予其所有者升级已发布的 Move 包的专有权利. 当你在 Sui 网络上部署包时，Sui 会生成一个与UpgradeCap你的账户关联的对象. 此功能充当安全访问密钥——没有它，任何人（包括你）将来都无法升级该软件包的代码.

在upgrade_cap调用 upgradeSui 的系统模块提供的函数时使用. CLI 允许您执行如下升级：

sui client upgrade \
  --package-path /path/to/your/package \
  --upgrade-capability <upgrade_cap_object_id> \
  --gas-budget 100000000

必须传递UpgradeCap对象的 ID 才能授权升级交易. 如果您丢失UpgradeCap或将其转移到无法访问的地址（例如0x0），则该软件包将不可变，因为没有人可以启动升级.

如果你想故意禁用未来的升级，你可以在你的软件包中加入一个功能，比如：

public entry fun burn_cap(cap: UpgradeCap) {
    sui::package::delete_upgrade_cap(cap);
}

调用此函数会删除该功能并永久锁定代码. 对于必须不可信或受外部管理的软件包，建议使用此方法.

最佳实践：UpgradeCap如果您正在开发协作或公共基础设施，请务必保护您的安全，并考虑将其转移到 DAO 或多重签名.

upgrade_cap###在 Sui 包中的作用 upgrade_cap是一个能力对象，可授予在 Sui 上升级 Move 包的权限. 与 EVM 链上的不可变合约不同，它是一项独特的 Sui 功能，可为已发布的包实现受控的可变性.

###关键概念

1. 它能做什么： -保存Publisher和UpgradePolicy（例如、immutable、compatible、arbitrary）.
   -需要授权软件包升级（例如，错误修复、新功能）.

2. 为什么 Sui 独一无二： upgrade_cap-部署后，EVM 合约不可变；Sui 允许通过治理进行升级（通过）.
   -升级省油（仅重新发布修改后的模块）.

3.安全影响： -无论谁持有，upgrade_cap都可以改变包裹的逻辑.
-最佳实践：部署后将其转移到多重签名或 DAO.

###移动代码结构 ####**1. upgrade_cap在 init**中定义

module my_pkg::my_module {
  use sui::package;
  use sui::transfer;

  // Called once during package publish
  fun init(otw: &mut TxContext) {
    let (upgrade_cap, publisher) = package::claim(otw);
    transfer::transfer(upgrade_cap, tx_context::sender(otw)); // Give cap to deployer
  }
}

####2. 升级软件包

module my_pkg::upgrader {
  use sui::package;

  // Requires the UpgradeCap
  public entry fun upgrade(
    upgrade_cap: &mut UpgradeCap,
    new_package: vector<u8>,
    otw: &mut TxContext
  ) {
    package::upgrade(upgrade_cap, new_package, otw);
  }
}

upgrade_cap在 Sui 中是一个控制软件包升级的关键对象.

###要点：

1. 管理员权限— 只有upgrade_cap持有者才能升级套餐.
2. 安全— 防止未经授权的更改（与以太坊的不可变合约不同）.
   3.sui client upgradeCLI 用法— 必填项.

###移动示例：

struct UpgradeCap has key, store { id: UID }  

###最佳实践： ✔ 安全存储（例如，多重签名）.
✔ localnet首先测试升级.

为何独一无二： Sui 允许升级（与 EVM 不变性相比）.

（失败 upgrade_cap= 不再升级！）

###1. 核心概念 upgrade_cap是一个特权对象，用于控制 Sui 中的软件包升级. 与合约不可变的 EVM 链不同，Sui 允许通过这种基于能力的系统进行受控的可变性.

###2. 主要特性

###2. 移动实施 ####基本结构

module my_pkg::admin {
    use sui::package;
    use sui::transfer;
    use sui::tx_context;

    // Generated during initial publish
    struct UpgradeCap has key, store { 
        id: UID 
    }

    // Initialize and transfer cap
    public fun init(ctx: &mut tx_context::TxContext) {
        let (upgrade_cap, publisher) = package::claim_upgrade_cap(ctx);
        transfer::transfer(upgrade_cap, tx_context::sender(ctx));
    }
}

####升级流程

module my_pkg::upgrader {
    use sui::package;
    use sui::upgrade_cap;

    public entry fun upgrade(
        cap: &mut upgrade_cap::UpgradeCap,
        policy: u8,
        digest: vector<u8>,
        ctx: &mut tx_context::TxContext
    ) {
        package::authorize_upgrade(cap, policy, digest);
        let new_pkg = package::make_upgrade_ticket(cap, policy, digest);
        // ... complete upgrade
    }
}

###3. CLI 工作流程 ####首次发布

sui client publish --gas-budget 1000000000
# Output includes UpgradeCap object ID

####授权升级

sui client call \
  --package <UPGRADE_CAP_PKG> \
  --module admin \
  --function authorize_upgrade \
  --args <UPGRADE_CAP_ID> 1 0x<COMPILED_PACKAGE_DIGEST> \
  --gas-budget 1000000000

####执行升级

sui client upgrade --upgrade-capability <UPGRADE_CAP_ID> \
  --gas-budget 1000000000

###4. 安全模式 ###能力嵌套

struct AdminCap has key {
    id: UID,
    upgrade_cap: UpgradeCap  // Delegatable
}

####限时升级

module my_pkg::timelock {
    struct TimedUpgradeCap has key {
        cap: UpgradeCap,
        unlock_epoch: u64
    }

    public fun upgrade_when_ready(
        cap: &mut TimedUpgradeCap,
        ctx: &mut TxContext
    ) {
        assert!(tx_context::epoch(ctx) >= cap.unlock_epoch, ELOCKED);
        package::authorize_upgrade(&mut cap.cap, ...);
    }
}

###5. 常见陷阱

###6. 升级政策

// Bitflags determining upgrade flexibility
const POLICY_COMPATIBLE: u8 = 0x1;  // Backwards-compatible
const POLICY_ADDITIVE: u8  = 0x2;   // New functions only
const POLICY_BREAKING: u8 = 0x4;    // Full changes

###7. 测试策略 ####Localnet 试运行

sui client publish --upgrade-policy 7 --dry-run

####升级模拟

#[test_only]
module test {
    fun test_upgrade() {
        let (cap, _) = package::test_upgrade_cap();
        package::authorize_upgrade(&mut cap, ...);
        assert!(package::test_is_authorized(cap), 0);
    }
}

###建筑影响

1. 去中心化治理： -DAO 可以设置升级上限 shared-通过对象进行多重签名方案

2. 企业就绪： -带有政策标志的分阶段推出 -紧急撤销功能

3.DevEx 优势： -修复部署后的错误 -节能型存储迁移

对于生产系统： -存UpgradeCap放在冷库中 -实施升级投票机制 -通过 [Sui Explorer 的升级选项卡] 进行监控 (https://explorer.sui.io/upgrades)

在 Sui 中，upgrade_cap是一个特殊对象，它赋予你升级已发布的 Move 包的权利. 当您使用部署包时--upgradeable，您会自动获得一个与UpgradeCap之链接的对象. 这个对象就像权限单一样——没有它，你就无法推送对该软件包的升级. 每当你想升级代码时，你都需要持有这个对象并用它签名，这使其成为链上开发的强大访问控制机制.

这种设计使得 Sui 与 EVM 链不同，后者的升级逻辑通常通过代理合同和单独的管理员角色来处理. 在 Sui 中，升级权限被嵌入到对象系统中. 如果您正在构建NFT集合、DeFi合约或任何需要未来更新的系统，则可以UpgradeCap确保只有具有该上限的可信开发人员（或多重签名）才能推动这些更改，从而减少未经授权升级的机会.

要创建可升级的软件包，请使用 Sui CLI：

sui client publish --path . --gas-budget 100000000 --with-unpublished-dependencies --upgradeable

发布后，您将在upgrade_cap输出中看到如下所示：

"createdObjects": [
  {
    "objectType": "0x2::package::UpgradeCap",
    "objectId": "0xabc123...",
    ...
  }
]

要稍后升级软件包，请将其编译为.json摘要并运行：

sui client upgrade --package-id <PACKAGE_ID> --module <PATH_TO_COMPILED_MODULE> --upgrade-capability <CAP_OBJECT_ID> --gas-budget 100000000

确保中的对象 ID 与--upgrade-capability您首次发布时获得的 ID 相匹配. 如果你丢失了这个对象或者忘记保护它（比如转移到多重签名钱包），任何获得它的人都可以修改你的合约.

常见的错误包括忘记存储upgrade_cap、使用无效的摘要或尝试升级不可升级的软件包. 最佳做法是upgrade_cap安全地保管，尤其是在生产中，并在审计期间对其进行密切监控.

你可以在 Su upgrade_capi 的官方文档中阅读更多关于软件包升级和安全升级的信息： https://docs.sui.io/build/package-upgrades