Upgrade authority — це ключ, який дозволяє замінити байткод розгорнутої програми на Solana. Поки цей ключ існує, ваша програма технічно залишається мутабельною, а користувачі та інтегратори покладаються на вашу чесність та безпеку цього ключа. Цей довідник описує, як перевіряти стан authority, мінімізувати ризики та діяти в разі компрометації.

Що таке upgrade authority та які ризики

Коли ви розгортаєте програму через solana program deploy або anchor deploy, клієнт створює два акаунти: саму програму (Program Data) та Buffer акаунт. Upgrade authority записується в поле upgrade_authority акаунта Program Data. Власник цього ключа може в будь-який момент викликати інструкцію upgrade і замінити байткод програми.

Основні ризики пов'язані не з наявністю authority як такою, а з тим, хто ним контролює:

  • Компрометація одиночного ключа. Якщо authority зберігається на гарячому гаманці розробника або CI/CD-сервері без обмежень доступу, витік приватного ключа означає повний контроль зловмисника над програмою.
  • Соціальна інженерія. Навіть multisig не захищає, якщо підписанти схильні підписувати транзакції без перевірки інструкцій та байткоду.
  • Недостатня ізоляція. Використання одного ключа для authority, казначейства та адміністрування створює єдину точку відмови.
  • Невідповідність очікуванням користувачів. Деякі протоколи декларують «немодифікованість» програми, але не відмовляються від authority фактично. Це створює юридичний та репутаційний ризик.

Передача authority на multisig

Найпоширеніша міграція — перевести upgrade authority з одиночного ключа на multisig-акаунт (наприклад, Squads). Це не усуває authority, але розподіляє право підпису між кількома учасниками.

Передумови: розгорнута програма з відомим Program ID; встановлений CLI Solana (перевірено на версії 1.18+); створений multisig-акаунт із достатньою кількістю підписантів та порогом.

Кроки:

  1. Перевірте поточний authority програми: solana program show <programid></programid>
  2. Викличте інструкцію set_authority з типом UpgradeAuthority, де новим authority виступає адреса multisig-акаунта. У Squads це зазвичай робиться через створення пропозиції (proposal) з інструкцією setAuthority.
  3. Після досягнення порогу підписів та виконання пропозиції перевірте результат: solana program show <programid></programid> Очікуваний результат: поле Upgrade Authority містить адресу multisig-акаунта.

Обмеження: після передачі authority на multisig, будь-яке оновлення програми вимагатиме створення та виконання пропозиції. Це сповільнює розгортання, особливо в екстрених випадках. Продумайте поріг та склад підписантів заздалегідь.

Відкат: якщо multisig-акаунт створено коректно, зворотна передача на одиночний ключ технічно можлива через нову пропозицію setAuthority. Проте це суперечить меті міграції. Якщо ви помилилися з адресою multisig (наприклад, вказали неіснуючий акаунт), відкат неможливий — authority буде втрачено без можливості відновлення.

Відмова від authority (revoke)

Повна відмова від upgrade authority робить програму іммутабельною назавжди. Після виклику revoke жоден ключ у світі не зможе оновити байткод.

Команда:

solana program revoke <programid></programid>

Очікуваний результат: поле Upgrade Authority у виводі solana program show стає порожнім.

Коли це доречно: стабільні протоколи з фіксованою логікою (наприклад, стандартні токен-програми, фіналізовані бриджі), програми, що пройшли кілька аудитів і не планують змін, а також випадки, коли репутаційна цінність іммутабельності перевищує гнучкість оновлень.

Ризики: відкликання є незворотним. Будь-який баг, виявлений після revoke, не може бути виправлений на рівні байткоду. Єдиний шлях — розгортання нової програми з новим Program ID та міграція користувачів.

Перевірка перед revoke: переконайтеся, що програма розгорнута з правильним байткодом (звіріть хеш), усі необхідні акаунти ініціалізовано, а інтегратори поінформовані. Рекомендується мати принаймні один повний цикл роботи програми на mainnet-beta перед остаточним відкликанням.

Перевірка поточного власника authority

Регулярна перевірка — базова гігієна для інфраструктурних команд та аудиторів.

Середовище: CLI Solana 1.18+, доступ до RPC-вузла (може бути публічним для читання).

Команда:

solana program show <programid></programid>

Що аналізувати у виводі:

Поле Що перевіряти
Program Id Збігається з очікуваним Program ID протоколу
Upgrade Authority Адреса відповідає очікуваній (multisig, null, або конкретний ключ)
Authority Type Має бути UpgradeAuthority
Data Length Розмір байткоду в байтах — корисно для виявлення неочікуваних оновлень

Програмна перевірка: для автоматизованого моніторингу можна використовувати RPC-метод getAccountInfo з кодуванням base64 та десеріалізацією структури UpgradeableLoaderState. Поле upgradeAuthorityAddress містить опціональну Pubkey — None означає відкликання, Some(key) — активну authority.

Обмеження: публічні RPC-вузли можуть повертати кешовані дані. Для критичних перевірок використовуйте власний валідатор або перевіреного провайдера з гарантіями свіжості даних.

План дій при компрометації authority

Якщо є підстави вважати, що приватний ключ upgrade authority витік, дійте швидко, але без паніки. Часове вікно між витоком та реакцією — це період максимального ризику.

Крок 1. Оцінка масштабу. Визначте, який саме ключ скомпрометовано: одиночний гаманець, ключ від CI/CD, чи один із підписантів multisig. Від цього залежить подальша стратегія.

Крок 2. Якщо authority на одиночному ключі:

  1. Негайно перевірте, чи програма вже оновлена невідомим байткодом: solana program show <programid></programid> — порівняйте Data Length з відомим значенням.
  2. Якщо байткод не змінено, негайно передайте authority на новий multisig або відкличте (revoke), залежно від стратегії протоколу. Використовуйте ключ, який ще під вашим контролем.
  3. Якщо байткод уже змінено, програма скомпрометована. Перейдіть до кроку 4.

Крок 3. Якщо скомпрометовано один підписант multisig:

  1. Перевірте історію транзакцій multisig-акаунта — чи не було створено пропозицій щодо оновлення програми.
  2. Якщо пропозицій немає, видаліть скомпрометований підписант з multisig (якщо механізм дозволяє) або створіть новий multisig без нього та переведіть authority.
  3. Тимчасово підвищте поріг підписів, якщо це можливо в рамках вашого multisig-рішення.

Крок 4. Якщо програма вже оновлена зловмисним байткодом:

  • Не намагайтеся «відкотити» через оновлення — це створить гонку з зловмисником, який досі має authority.
  • Якщо authority досі під вашим контролем — негайно відкличте її (revoke), щоб заморозити зловмисний байткод і запобігти подальшим змінам.
  • Розгорніть нову програму з новим Program ID та випустіть оновлення для користувачів та інтеграторів.
  • Якщо authority вже не під вашим контролем — програма повністю втрачена. Розгортайте нову з нуля.

Крок 5. Комунікація. Повідомте інтеграторів, користувачів та, за необхідності, аудитора протоколу. Чим прозоріше ви поясните ситуацію та дії, тим менший репутаційний збиток.

Обмеження плану: він не захищає від сценарію, де зловмисник отримав authority та одночасно відкликав її у свій власний неконтрольований акаунт. У такому випадку ніхто, включно з оригінальною командою, не зможе оновити програму — але й зловмисник також не зможе змінити її заново.

Типові помилки при роботі з authority

Нижче наведено фактичні причини помилок, з якими стикаються команди при роботі з upgrade authority.

Збереження authority на CI/CD-ключі. Фактична причина: ключі, що генеруються в CI/середовищах (GitHub Secrets, CI-variables), часто мають ширший доступ, ніж потрібно, і логуються в plaintext-логах або передаються через незахищені канали. Наслідок — витік ключа разом із повним контролем над програмою. Рішення: CI/CD повинен лише підписувати транзакції, але не володіти authority. Використовуйте ключі з мінімальними привілеями або зовнішні сервіси підпису.

Передача authority на неправильну адресу. Фактична причина: копіпаста адреси multisig-акаунта з іншого протоколу або мережі (devnet замість mainnet-beta). Наслідок: authority втрачено без можливості відновлення. Рішення: завжди верифікуйте адресу повністю, включно з префіксом мережі, та перевіряйте результат командою solana program show одразу після виконання.

Revoke замість transfer через непорозуміння. Фактична причина: розробник плутає solana program revoke з передачею authority і випадково відкликає її, очікуючи побачити нову адресу. Наслідок: програма стає іммутабельною назавжди. Рішення: чітко розрізняйте інструкції set_authority (передача) та revoke (відкликання). Ніколи не виконуйте ці команди на production без попередньої перевірки на devnet.

Ігнорування Data Length при аудиті. Фактична причина: аудитори перевіряють лише адресу authority, але не розмір байткоду. Наслідок: несанкціоноване оновлення може залишитися непоміченим, якщо зловмисник зберіг той самий розмір. Рішення: фіксуйте хеш байткоду (наприклад, SHA-256 від serialized Program Data) і верифікуйте його при кожному аудиті.

Використання одного ключа для кількох програм. Фактична причина: зручність розгортання з одного гаманця. Наслідок: компрометація одного ключа означає втрату control над усіма програмами одночасно. Рішення: ізолюйте upgrade authority для кожної програми окремо, навіть якщо вони належать одному протоколу.

Відсутність плану дій до інциденту. Фактична причина: команди налаштовують authority, але не документують, хто має доступ, як швидко можна зібрати підписи multisig, і яку послідовність дій виконувати. Наслідок: у момент інциденту команда витрачає час на обговорення замість реакції. Рішення: задокументуйте план (подібний до наведеного вище) до розгортання на mainnet-beta.

Джерела