Ключ авторизации в Aptos: почему адрес остаётся прежним после смены ключа

Адрес аккаунта, ключ и обратная запись отвечают на разные вопросы

При создании обычного аккаунта адрес выводится из первого публичного ключа и схемы подписи. Затем он становится постоянным адресом аккаунта, где лежат его ресурсы. Ротация меняет `authentication_key`, но не переносит баланс, модули и данные. Поэтому новый публичный ключ не должен подменять адрес отправителя в следующей транзакции.

Получите аккаунт на фиксированной версии реестра и сохраните адрес, `authentication_key` и `sequence_number`. Функция чтения (view) `0x1::account::get_authentication_key` возвращает тот же ключ без изменения состояния. Номер последовательности нужен для доказательства ротации и следующей транзакции. Как работают последовательные номера, разобрано в отдельном гайде.

Сначала выясните, какой путь вызвал кошелёк

Основной `rotate_authentication_key` строит структуру `RotationProofChallenge`. Её подписывают текущий и новый ключи. Вызов проверяет обе подписи, обновляет поле аккаунта, записывает новый ключ в `OriginatingAddress` и выпускает событие. Номер последовательности внутри структуры защищает доказательства от повторного применения.

Функция `rotate_authentication_key_with_rotation_capability` использует делегированное право `RotationCapability`. Она также требует доказательство владения новым ключом и обновляет обратную запись. Этот путь отличается тем, кто вправе начать операцию. Перед подписью полезно разобрать отображаемый вызов и адрес получателя права.

`rotate_authentication_key_call` принимает готовые 32 байта и не доказывает владение соответствующим секретом. Поэтому он меняет ключ, но не `OriginatingAddress`. `rotate_authentication_key_from_public_key` выводит ключ из публичного ключа и выпускает событие с неподтверждённой битовой маской; обратный индекс он тоже не обновляет.

В исходнике остаётся `set_originating_address`, но текущая реализация сразу завершает вызов ошибкой `ESET_ORIGINATING_ADDRESS_DISABLED`. Комментарий о последующем исправлении индекса не является работающей процедурой. Это намеренная защита от подмены обратного сопоставления в моделях абстракции аккаунта.

Что сохранить до следующей подписи

Ротация завершена, когда неизменный адрес хранит ожидаемый новый ключ, а транзакция имеет `success: true`. Для пути с доказательствами добавьте совпадающую обратную запись. После этого кошелёк должен строить следующую транзакцию от старого адреса, но подписывать её новым ключом. Проверять старый ключ реальной отправкой не нужно.

Если новый ключ в состоянии есть, а кошелёк показывает новый адрес, ошибка возникла при локальном восстановлении или в индексе. Сначала проверьте прежний адрес по публичным данным. Затем обновите или заново добавьте этот аккаунт в кошельке по инструкции разработчика. Хранение seed-фразы и резервных копий — отдельный слой, который ротация автоматически не чинит.

Ищите ошибку в той записи, которая не совпала

Старый ключ в ресурсе означает, что ротация не применилась. Проверьте результат и поле ошибки `vm_status`, затем обновите `sequence_number` перед пересборкой. Новый ключ при пустом OriginatingAddress может быть штатным результатом упрощённого пути. Не повторяйте ротацию только ради индекса: следующий вызов потребует уже новый ключ и может окончательно запутать кошелёк.

Публичный и приватный ключ выполняют разные роли. Перед любой ручной ротацией полезно ещё раз сверить эту границу: в статье и заявке поддержки достаточно адреса, хеша и публичных ключей.