Loader owner выбирает правильный decoder

Первый проход по Program account

  1. 1
    Закрепить program ID и cluster

    Возьмите адрес из фактической инструкции приложения, а не из названия проекта. Запросите getAccountInfo с finalized commitment.

  2. 2
    Проверить executable

    Executable=true подтверждает вызываемый program account. Обычный data account с похожим адресом не является программой.

  3. 3
    Прочитать owner

    Owner — loader program. Только точный BPF Upgradeable Loader открывает loader-v3 ветку с ProgramData.

  4. 4
    Сохранить raw data и slot

    Parsed view удобен, но raw bytes, encoding и context slot позволяют независимо повторить декодирование.

Owner определяет, где искать authority
Program ownerState modelЧто нельзя делать
BPF Upgradeable Loader (loader-v3)Program → отдельный ProgramDataЧитать authority из Program account balance или metadata dApp
Legacy/deprecated BPF loaderДругая immutable deployment modelПридумывать отсутствующий ProgramData
Loader-v4Отдельный loader и собственное account stateДекодировать байты как UpgradeableLoaderState::ProgramData
Native/builtin ownerRuntime-provided program boundaryПрименять CLI loader-v3 authority вывод
Owner определяет, где искать authority
Program owner
BPF Upgradeable Loader (loader-v3)
State model
Program → отдельный ProgramData
Что нельзя делать
Читать authority из Program account balance или metadata dApp
Program owner
Legacy/deprecated BPF loader
State model
Другая immutable deployment model
Что нельзя делать
Придумывать отсутствующий ProgramData
Program owner
Loader-v4
State model
Отдельный loader и собственное account state
Что нельзя делать
Декодировать байты как UpgradeableLoaderState::ProgramData
Program owner
Native/builtin owner
State model
Runtime-provided program boundary
Что нельзя делать
Применять CLI loader-v3 authority вывод

Похожая задача у EVM proxy требует чтения implementation/admin slots, но архитектура другая. Solana ProgramData — не прокси и не implementation address: это loader-v3 account с executable bytes и metadata deployment.

ProgramData связывает bytecode, slot и authority

Loader-v3 Program account хранит ProgramData address. Прочитайте этот address на том же cluster и finalized context. ProgramData state содержит slot последней loader-v3 операции, которая обновила это поле, и optional upgrade_authority_address. В текущей реализации slot записывают deploy, upgrade и ExtendProgram; последняя операция может расширить account без изменения исполняемых байтов. SetAuthority и SetAuthorityChecked сохраняют прежний slot. За metadata следуют executable bytes. CLI solana program show показывает те же ключевые поля, но для аудита сохраните raw accounts и независимо подтвердите pointer.

Минимальный evidence record
ПолеЧто доказываетЧего не доказывает
Program ownerКакой loader управляет accountКто контролирует frontend или protocol state
ProgramData addressГде loader-v3 хранит bytes/metadataЧто source code соответствует bytes
Loader operation slotКогда loader-v3 последний раз обновил slot через deploy, upgrade или ExtendProgramМенялись ли исполняемые байты или authority; нужна точная instruction
Upgrade authority Some(pubkey)Кто может подписать loader-v3 upgrade/close по текущим правиламЧто ключ у одного человека или будет использован
Upgrade authority NoneLoader-v3 authority отозвана для этой ProgramDataОтсутствие багов, админов в самой программе или смены program ID
Минимальный evidence record
Поле
Program owner
Что доказывает
Какой loader управляет account
Чего не доказывает
Кто контролирует frontend или protocol state
Поле
ProgramData address
Что доказывает
Где loader-v3 хранит bytes/metadata
Чего не доказывает
Что source code соответствует bytes
Поле
Loader operation slot
Что доказывает
Когда loader-v3 последний раз обновил slot через deploy, upgrade или ExtendProgram
Чего не доказывает
Менялись ли исполняемые байты или authority; нужна точная instruction
Поле
Upgrade authority Some(pubkey)
Что доказывает
Кто может подписать loader-v3 upgrade/close по текущим правилам
Чего не доказывает
Что ключ у одного человека или будет использован
Поле
Upgrade authority None
Что доказывает
Loader-v3 authority отозвана для этой ProgramData
Чего не доказывает
Отсутствие багов, админов в самой программе или смены program ID

Authority может быть обычным ключом, PDA или адресом multisig/governance workflow, но pubkey сам по себе не раскрывает порог, участников и delay. Эти свойства проверяют по программе-контроллеру и реальным инструкциям. Нельзя назвать контроль децентрализованным только по красивому имени authority account.

Slot указывает на loader-операцию, а не объясняет её

Связать onchain state с проверенным кодом

  1. 1
    Зафиксировать slot и bytecode hash

    Скачайте ProgramData bytes из двух RPC на finalized state и посчитайте hash исполняемой части с описанным offset/decoder.

  2. 2
    Найти и классифицировать loader transaction

    Проверьте транзакцию на ProgramData slot и декодируйте точную instruction: deploy, upgrade или ExtendProgram. Program ID, ProgramData, authority signatures и result должны совпасть; один slot не доказывает запись новых исполняемых байтов.

  3. 3
    Отдельно восстановить authority history

    Ищите SetAuthority/SetAuthorityChecked и текущего подписанта в истории account. Более поздняя смена authority не обязана менять ProgramData slot.

  4. 4
    Сопоставить build artifact

    Verified source полезен только при воспроизводимой сборке и совпадении deployed bytes. Название репозитория не является связью.

  5. 5
    Проверить application routing

    Декодируйте фактическую instruction: frontend/router может начать вызывать другой program ID, даже если старый immutable.

  6. 6
    Повторить на новом slot

    Для mutable программы заключение живёт до следующего upgrade или authority change. Сохраните checkedAt и recheck trigger.

Аудит отвечает только за заявленную версию и scope. Как проверить commit, compiler settings и deployed bytecode, разобрано отдельно; ProgramData evidence дополняет, а не заменяет этот процесс.

Расхождение двух RPC — причина остановиться

Stop и recovery
СигналВероятная причинаДействие
Program account отсутствуетНеверный cluster/ID или закрытый accountНе подписывать; восстановить адрес из instruction
Owner не loader-v3Выбран неверный decoderПерейти к документации точного loader
ProgramData pointer не совпадаетRPC/parser/cache ошибка или другой programСверить raw bytes на finalized slot
Slot/authority различаются между RPCРазная commitment/lag или недавний deploy, upgrade либо ExtendProgramДождаться finalized и повторить
Authority изменилась после аудитаControl plane обновилсяПерепроверить bytecode, history и governance
Authority=NoneLoader-v3 immutable stateЗаписать узкий вывод; продолжить кодовый и бизнес-аудит
Stop и recovery
Сигнал
Program account отсутствует
Вероятная причина
Неверный cluster/ID или закрытый account
Действие
Не подписывать; восстановить адрес из instruction
Сигнал
Owner не loader-v3
Вероятная причина
Выбран неверный decoder
Действие
Перейти к документации точного loader
Сигнал
ProgramData pointer не совпадает
Вероятная причина
RPC/parser/cache ошибка или другой program
Действие
Сверить raw bytes на finalized slot
Сигнал
Slot/authority различаются между RPC
Вероятная причина
Разная commitment/lag или недавний deploy, upgrade либо ExtendProgram
Действие
Дождаться finalized и повторить
Сигнал
Authority изменилась после аудита
Вероятная причина
Control plane обновился
Действие
Перепроверить bytecode, history и governance
Сигнал
Authority=None
Вероятная причина
Loader-v3 immutable state
Действие
Записать узкий вывод; продолжить кодовый и бизнес-аудит

Финальный артефакт включает cluster/genesis, program ID, finalized slot, owner, ProgramData address, authority, slot последней loader-v3 операции, bytecode hash, точную deploy, upgrade или ExtendProgram instruction, отдельную authority-change history и application instruction. В отдельном гайде показаны instruction accounts в versioned transaction. Отдельно проверьте token-account полномочия: mint/freeze authority токена не равны upgrade authority программы.

Источники

Мы используем прямые ссылки и фиксируем дату проверки. Полный текст чужих материалов не перепечатывается.

  1. Solana Docs — Programs Solana · Проверено 24 августа 2026 г. в 09:25 GMT+5
  2. Solana Docs — Deploying Programs Solana · Проверено 24 августа 2026 г. в 09:25 GMT+5
  3. Solana Docs — Reading program accounts Solana Foundation · Проверено 24 августа 2026 г. в 09:25 GMT+5
  4. Solana RPC — getAccountInfo Solana · Проверено 24 августа 2026 г. в 09:25 GMT+5
  5. Agave — pinned loader-v3 implementation Anza · Проверено 24 августа 2026 г. в 12:03 GMT+5
  6. Solana Program — pinned loader-v4 source and IDL Anza / Solana Program · Проверено 24 августа 2026 г. в 11:17 GMT+5
Материал носит информационный характер и не является индивидуальной рекомендацией. Криптоактивы связаны с риском волатильности, технических сбоев, хищения и полной потери средств.