upgrade_cap в пакетах Sui — это специальный объект, который контролирует полномочия на обновление опубликованного пакета Move. Когда вы публикуете пакет на Sui, система создает объект upgrade_cap, связанный с этим пакетом. Этот объект находится в распоряжении издателя или уполномоченного органа и необходим для будущих обновлений или модификаций кода пакета. Без upgrade_cap пакет становится неизменяемым, то есть вы не сможете изменить или заменить его модули. Такая конструкция обеспечивает безопасные контролируемые обновления и предотвращает несанкционированные изменения, что крайне важно для поддержания доверия и стабильности развернутых смарт-контрактов.

С точки зрения интерфейса командной строки, когда вы публикуете пакет с помощью sui client publish, вы получаете идентификатор пакета и идентификатор объекта upgrade_cap. Для обновления необходимо подписать транзакцию со ссылкой на текущий файл upgrade_cap, после чего система выпустит новую версию пакета вместе с новым объектом upgrade_cap. В коде Move вы не можете напрямую манипулировать upgrade_cap, но ваши сценарии развертывания или логика вне сети должны обрабатывать его безопасно.

Архитектурно upgrade_cap предусматривает контроль прав собственности и разрешений на управление жизненным циклом пакетов, что позволяет отличить пакетную модель Sui от неизменных контрактов или прокси-серверов Ethereum. Рекомендуется безопасно хранить upgrade_cap в автономном режиме или в кошельке с несколькими подписями, чтобы избежать взлома. Кроме того, перед обновлением необходимо тщательно управлять версиями и тестировать их, поскольку оно затрагивает всех пользователей в зависимости от пакета.

Типичные ошибки включают потерю файла upgrade_cap, из-за которого вы не можете обновляться, или неправильное управление полномочиями, что создает угрозу безопасности. Используя интерфейс командной строки Sui, вы можете запросить текущий пакет upgrade_cap или отправить транзакции по обновлению, которые будут использованы и перевыпущены.

Таким образом, upgrade_cap — это криптографический ключ к эволюции пакетов в Sui, позволяющий выполнять контролируемые и разрешенные обновления при сохранении децентрализации и безопасности. Правильное управление им необходимо для рабочих процессов разработки и развертывания готовых к использованию смарт-контрактов Sui.

In Sui upgrade_capиспользуется для управления возможностью обновления смарт-контрактов, позволяя разработчикам обновлять контракты без потери данных. Она предоставляет разрешение на обновление контрактов и обычно принадлежит доверенному адресу.

Ключевые моменты:

*Control Upgrade: upgrade_capгарантирует, что обновления могут запускать только авторизованные адреса. *Код перемещения: используется в модулях Move для обработки обновлений. *Пример CLI:

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

Лучшие практики:

• Тестовые обновления в локальной сети/тестовой сети.
• Защитите их, upgrade_capчтобы предотвратить несанкционированный доступ.

Роль upgrade_capв сети Sui

Назначение: определяет, кто может обновить смарт-контракт или модуль.

*Что оно делает: предоставляет разрешения на обновление определенным адресам (обычно это администраторы). Это гарантирует, что только уполномоченные организации могут изменять развернутые контракты.

Ключевые концепции:

*Язык перемещения: upgrade_capреализован в Move для безопасного управления контрактами. *Развертывание: указано при развертывании контракта, чтобы будущие обновления можно было использовать только по авторизованным адресам.

Пример интерфейса командной строки:

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Ограничение: ограничьте доступ к доверенным адресам. *Протестируйте в Localnet/Testnet: убедитесь в правильном поведении перед развертыванием в основной сети.

upgrade_capКлавиша** в Sui служит механизмом авторизации обновлений пакетов и представляет собой уникальный объект возможностей, предоставляющий владельцу права на обновление. В отличие от цепочек EVM, где контракты неизменны, система обновлений Sui требует, чтобы этот объект модифицировал опубликованные пакеты, обеспечивая контролируемую изменчивость при сохранении безопасности. upgrade_capВладелец sui client upgradeможет авторизовать обновления с помощью package::authorize_upgradeкоманды CLI или программно с помощью функции Move. Передовой опыт заключается в безопасном хранении данных upgrade_cap(часто в бумажной упаковке Versionedили в AdminCapобертке) и внедрении надлежащих механизмов контроля за их владением, поскольку их потеря навсегда лишает возможности обновления, а возможность несанкционированных модификаций может быть подвержена риску несанкционированного внесения изменений.

В сети Sui оно upgrade_capиграет важную роль в обеспечении безопасного и контролируемого обновления пакетов Move после их первоначального развертывания. При публикации пакета на Sui UpgradeCapсоздается и возвращается объект соответствующего типа. Этот объект являетсяединственным органом, который позволяет обновлять пакет в будущем. Он фактически выступает в роли ключа, дающего разрешение на изменение кода пакета.

Вы должны сохранить за собой право собственности на этот upgrade_capпакет, если собираетесь обновить пакет позже. Если вы перенесете его на другой адрес или сожжете (например, отправив по адресу0x0), дальнейшие обновления невозможны. Этот дизайн обеспечивает неизменность, если это явно не предусмотрено создателем пакета.

Почему UpgradeCap так важен

Объектно-ориентированная модель Sui вводит эту концепцию, позволяющую отличать неизменяемые пакеты от обновляемых. upgrade_capПакеты, к которым нет доступа, считаются постоянно неизменными. Это отличается от цепочек EVM, где контракты можно изменять только в том случае, если delegatecallпрокси или обновляемые шаблоны создаются вручную.

Пример рабочего процесса обновления

При публикации пакета:

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

Результат включает в себя:

• Идентификатор пакета
• Идентификатор объекта UpgradeCap

Чтобы обновить его позже, выполните следующие действия:

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

Использование UpgradeCap в Move

В модулях Move вы можете защитить обновления или конфиденциальные переходы с помощью объекта capability:

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полномочиям на языке Суй.

Распространенные ошибки

*Отсутствует upgrade_capво время обновления→ Приводит к ошибкам «отказано в разрешении». *Случайный перенос в нулевое значение→ Ваш пакет блокируется навсегда. *Попытка вызвать обновление неизменяемых пакетов→ Система отклонит транзакцию.

Подробнее

• Документация: https://docs.sui.io/concepts/packages
• Примеры обновлений: https://docs.sui.io/build/upgrade
• Справочник по интерфейсу командной строки: https://docs.sui.io/reference/cli/client

В конечном счете, это upgrade_capсвидетельствует о приверженности Суй недвусмысленным полномочиям и тщательному контролю за развитием состояния и кода. Понимание того, как использовать, хранить и отзывать данные, является ключом к созданию безопасных и удобных в обслуживании смарт-контрактов в экосистеме Sui.

Роль в upgrade_capпакетах Sui

upgrade_capЭтообъект возможностей, который контролирует разрешения на обновление пакетов в объектно-ориентированной системе обновлений Sui. В отличие от цепочек EVM, использующих шаблоны прокси-серверов, Sui обрабатывает обновления на уровне пакетов с помощью этого специализированного объекта возможностей.

Базовая механика

При публикации пакета:

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

Транзакция возвращает:

1. Идентификатор пакета (неизменяемый идентификатор)
2. upgrade_capобъект (0x2: :пакет: :UpgradeCap)

Этот объект возможностей:

• Этопервоклассный объект Sui, которым можно владеть, передавать или делиться
• Должен быть включен в качестве входных данных в любую транзакцию по обновлению
• Содержит идентификатор пакета, для которого разрешено обновление

Ключевые технические сведения

1.Модель безопасности:

• upgrade_capОбновить пакет может только владелец
• Придерживается модели владения объектами Суи (без авторизации на основе подписи)
• Может управляться с помощью многозначных контрактов или таймлоков

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
      )
  }

Преимущества, специфичные для Sui, по сравнению с EVM

-Шаблоны прокси-серверов: обновления происходят на уровне пакета, а не на уровне контракта -Обратная совместимость: существующие объекты остаются действительными после обновлений -Безопасность, основанная на возможностях: вместо ролей администраторов используется модель владения объектами Sui upgrade_cap-Прозрачное управление: их можно вкладывать в мультиподписи или в казначейские облигации DAO

Распространенные ошибки и способы их устранения

Лучшие практики

1. Для производства: перевод upgrade_capна кошелек с несколькими подписями
2. Для неизменяемых контрактов: сохраните возможность после публикации
3. Всегда подтверждайте владение мощностями: object::is_owner(&cap, tx_context::sender(ctx))
4. Выпускайте события при обновлениях: event::emit(UpgradeEvent { package_id, version })

В upgrade_capнем воплощена объектно-ориентированная модель безопасности Sui: разрешения на обновление рассматриваются как передаваемые активы, а не как жестко закодированные роли администраторов, что обеспечивает гибкие возможности управления при сохранении безопасности.

upgrade_cap в Sui — это специальный объект, который предоставляет право обновлять опубликованный пакет Move. При публикации пакета с помощью интерфейса командной строки Sui система автоматически создает объект upgrade_cap, связанный с этим пакетом. Этот объект контролирует возможность обновления или изменения пакета после его первоначального развертывания. Не удерживая кнопку upgrade_cap, никто не сможет обновить пакет, сделав его неизменным.

Например, при публикации пакета:

ваш клиент опубликует --gas-budget 10000 --path. /my_package

Выходные данные включают идентификатор объекта upgrade_cap. Этот объект необходимо включить в транзакции по обновлению, чтобы подтвердить полномочия. Чтобы обновить пакет, позвоните по телефону:

<upgrade_cap_object_id>обновление клиента --пакет --upgrade-cap --gas-budget <new_package_path>10000

Эта транзакция использует старый upgrade_cap и выдает новый для обновленного пакета. upgrade_cap обеспечивает строгий контроль разрешений на жизненный цикл пакета, гарантируя, что только уполномоченные стороны могут изменять код контракта.

С точки зрения Move, сам код пакета напрямую не влияет на upgrade_cap, поскольку он обрабатывается на уровне протокола. Однако разработчикам необходимо безопасно управлять этим объектом вне сети, обычно храня его в защищенных кошельках или системах с несколькими подписями, чтобы предотвратить несанкционированные обновления.

Утерянный upgrade_cap означает, что вы не сможете снова обновить пакет, в результате чего код будет заблокирован навсегда. Это подчеркивает важность безопасных методов управления ключами. Кроме того, обновление пакета затрагивает всех полагающихся на него пользователей, поэтому перед развертыванием обновления следует тщательно протестировать в тестовой сети или локальной сети.

Поскольку пакеты Sui имеют разные версии, upgrade_cap является ключом к переходу между версиями. Система гарантирует атомарные обновления, привязывая управление версиями пакетов к этой возможности.

Вы можете запросить upgrade_cap, связанный с пакетом, используя интерфейс командной строки Sui или SDK:

клиент sui get-package <package_id>

который возвращает сведения о пакете, включая текущее значение upgrade_cap. Безопасная обработка upgrade_cap является частью передовых практик в рабочих процессах разработки Sui, позволяющих избежать случайных или злонамеренных изменений кода.

В отличие от неизменных контрактов Ethereum или схем обновления прокси-серверов, upgrade_cap от Sui представляет собой явный сетевой объект, контролирующий обновления. Такой дизайн повышает прозрачность и безопасность, делая полномочия на обновление явным объектом в системе.

Разработчики должны включить управление upgrade_cap в свои конвейеры развертывания. Обычно в процессе обновления необходимо включить объект upgrade_cap и убедиться, что объект upgrade_cap подписан правильными ключами.

upgrade_capПакеты in Sui — это специальный объект, предоставляющий владельцу эксклюзивное право обновлять опубликованный пакет Move. Когда вы развертываете пакет в сети Sui, Sui создает UpgradeCapобъект, привязанный к вашей учетной записи. Эта возможность служит ключом безопасного доступа — без нее никто (включая вас) не сможет обновить код этого пакета в будущем.

Вы используете его upgrade_capпри вызове upgradeфункции, предоставляемой системным модулем Sui. Интерфейс командной строки позволяет выполнять следующие обновления:

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

Для UpgradeCapавторизации транзакции обновления необходимо передать идентификатор объекта. Если вы потеряете UpgradeCapили перенесете его на недоступный адрес (например0x0), пакет станет неизменяемым, поскольку никто не сможет начать обновление.

Если вы хотите намеренно отключить будущие обновления, вы можете включить в свой пакет такую функцию, как:

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

Вызов этой функции удаляет возможность и навсегда блокирует код. Это рекомендуется для пакетов, которым не следует доверять или которые регулируются извне.

Рекомендация: всегда защищайте свои файлы UpgradeCapи попробуйте перенести их в DAO или мультиподпись, если вы работаете над инфраструктурой для совместной работы или публичной инфраструктурой.

upgrade_cap###Роль комплекта комплектов Это upgrade_capфункциональный объект, который предоставляет разрешение на обновление пакета Move на Sui. Это уникальная функция Sui, которая обеспечиваетконтролируемую изменчивостьпубликуемых пакетов, в отличие от неизменяемых контрактов в цепочках EVM.

###Ключевые концепции 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_capin Sui — этоключевой объект, который контролирует обновление пакетов.

###Ключевые моменты: 1.Права администратора— upgrade_capобновлять пакет может только владелец. 2.Безопасность— предотвращает несанкционированные изменения (в отличие от неизменяемых контрактов Ethereum). 3. sui client upgradeИспользование интерфейса командной строки— требуется для.

###Пример перемещения:

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. Стратегия тестирования ####Пробный запуск локальной сети

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

В Sui upgrade_capэто специальный объект, который дает вам право обновить опубликованный пакет Move. Когда вы развертываете пакет с помощью--upgradeable, вы автоматически получаете UpgradeCapсвязанный с ним объект. Этот объект действует как пропуск разрешений — без него вы не сможете обновлять этот пакет. Этот объект необходимо сохранить и подписать в любое время, когда вы захотите обновить код. Это делает его мощным механизмом контроля доступа при разработке в блокчейне.

Такой дизайн отличает Sui от цепочек EVM, где логика обновлений часто решается с помощью контрактов на использование прокси-серверов и отдельных ролей администраторов. В Sui разрешение на обновление встроено в объектную систему. Если вы создаете коллекцию NFT, контракт DeFi или любую другую систему, нуждающуюся в будущих обновлениях, вы UpgradeCapгарантируете, что внесение изменений сможет внести только доверенный разработчик (или компания с несколькими подписями) с таким ограничением, что снизит вероятность несанкционированных обновлений.

Чтобы создать обновляемый пакет, используйте интерфейс командной строки Sui:

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

Убедитесь, что идентификатор объекта --upgrade-capabilityсовпадает с идентификатором, полученным при первой публикации. Если вы потеряете этот объект или забудете защитить его (например, переведя его в кошелек с несколькими подписями), любой, кто его получит, сможет изменить ваш контракт.

К распространенным ошибкам относятся забывание сохранить файлupgrade_cap, использование недействительного дайджеста или попытка обновить пакет, не подлежащий обновлению. Лучше всего хранить данные в upgrade_capбезопасном хранилище, особенно в рабочей среде, и тщательно отслеживать их во время аудитов.

Подробнее об upgrade_capобновлениях пакетов и обеспечении их безопасности вы можете прочитать в официальной документации Sui: https://docs.sui.io/build/package-upgrades