Это руководство предназначено для разработчиков, которые хотят реализовать проверенные сборки для своих программ на Solana. Мы рассмотрим, что такое проверенные сборки, как их использовать, особые аспекты и лучшие практики для обеспечения подлинности вашей программы в блокчейне.
Что такое проверенные сборки?
Проверенные сборки гарантируют, что исполняемая программа, которую вы разворачиваете в сети Solana, соответствует исходному коду в вашем репозитории. Благодаря этому разработчики и пользователи могут быть уверены, что программа, работающая в блокчейне, точно соответствует публичной кодовой базе, что способствует прозрачности и безопасности.
Процесс проверки включает сравнение хэша программы в блокчейне с хэшем локально собранной программы из исходного кода. Это гарантирует отсутствие расхождений между двумя версиями.
Хотя проверенная сборка не должна считаться более безопасной, чем непроверенная, она позволяет разработчикам самостоятельно убедиться, что исходный код соответствует тому, что развернуто в блокчейне. Используя исходный код, разработчик может затем проверить, что выполняет код при отправке транзакции.
Процесс проверенных сборок был разработан и поддерживается Ellipsis Labs и OtterSec. Для получения дополнительной информации следуйте руководству в оригинальном репозитории проверенных сборок, а также процессу проверки сборки непосредственно в наборе инструментов Anza, как только он будет поддерживаться там.
Как это работает?
Процесс верификации осуществляется путем сравнения хэша ончейн-программы с хэшем локально собранной программы из исходного кода. Вы собираете свою программу в контролируемой среде с использованием Solana Verify CLI и Docker. Это гарантирует, что процесс сборки будет детерминированным и последовательным на разных системах. После получения исполняемого файла вы можете развернуть его в сети Solana. В процессе сборки будет создан PDA программы верификации. Этот PDA содержит все данные, необходимые для верификации программы. В PDA включены адрес программы, URL-адрес git, хэш коммита и аргументы, использованные для сборки программы.
Используя данные из PDA, каждый может локально запустить команду программы верификации и проверить, была ли программа собрана из предоставленного исходного кода. Таким образом, каждый может самостоятельно и полностью без доверия убедиться в этом или запустить собственный API верификации, поддерживаемый OtterSec, чтобы предоставить пользователям удобную точку доступа для проверки верификации. Вы уже можете видеть эти вызовы API, используемые в Solana Explorer и SolanaFM, а также в других местах.
Зачем использовать проверенные сборки?
Использование проверенных сборок предоставляет следующие преимущества:
-
Безопасность: Гарантия того, что программа, работающая ончейн, соответствует исходному коду, предотвращая злонамеренные изменения.
-
Прозрачность: Позволяет другим пользователям и разработчикам убедиться в надежности ончейн-программы, сравнив её с публичным кодом.
-
Доверие: Повышение уверенности пользователей, так как проверенные сборки демонстрируют, что поведение вашей программы ончейн соответствует вашему публичному коду. Создавая проверяемые программы, вы минимизируете риски, связанные с запуском неавторизованного или вредоносного кода. Это также гарантирует соблюдение лучших практик и предоставляет исследователям безопасности простой способ связаться с вами. Кроме того, кошельки и другие инструменты могут легче разрешать транзакции от вашей программы, если она проверена.
-
Обнаруживаемость: когда вы предоставляете проверенную сборку вашей программы, каждый может найти ваш исходный код, документацию, SDK программы или IDL, а также легко связаться с вами через GitHub в случае возникновения проблемы.
Как создать проверенные сборки?
Чтобы создать проверенные сборки, вам нужно выполнить следующие шаги:
Резюме:
- Зафиксируйте ваш код в публичном репозитории
- Создайте проверенную сборку в Docker
- Разверните проверенную сборку
- Проверьте развернутую программу через публичный API
Если вы проверяете вашу программу, которая не была собрана в контейнере Docker, это, скорее всего, приведет к ошибке, так как сборки программ Solana не являются детерминированными на разных системах.
Установите Docker и Cargo
Установите необходимые инструменты, убедитесь, что Docker и Cargo установлены. Docker предоставляет контролируемую среду сборки для обеспечения согласованности, а Cargo используется для управления пакетами Rust.
- Docker: Следуйте инструкциям на сайте Docker, чтобы установить Docker для вашей платформы. После установки убедитесь, что служба Docker запущена, следуя этому руководству.
- Cargo: Если Cargo еще не установлен, вы можете установить его, выполнив следующую команду:
curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
Установите Solana Verify CLI
Solana Verify CLI — это основной инструмент, используемый для проверки сборок. Solana Verify CLI в настоящее время поддерживается Ellipsis Labs и может быть установлен с помощью Cargo.
Вы можете установить его, выполнив следующую команду:
cargo install solana-verify
Если вам нужна определенная версия CLI, вы можете зафиксировать версию с помощью:
cargo install solana-verify --version $VERSION
При необходимости вы можете установить версию напрямую из определенного коммита:
cargo install solana-verify --git https://github.com/Ellipsis-Labs/solana-verifiable-build --rev 13a1db2
Подготовка проекта
Чтобы выполнить проверку репозитория, в корневой директории вашего репозитория
должен быть файл Cargo.lock. Если в репозитории только одна программа и в
корне есть файл cargo.lock, вы можете сразу перейти к следующему шагу и
собрать свою программу.
Если ваша программа находится во вложенной папке и у вас используется rust
workspace, необходимо создать файл workspace Cargo.toml в корневой директории
репозитория.
Вы можете использовать этот пример Cargo.toml как шаблон:
[workspace]members = ["program/programs/*"]resolver = "2"[profile.release]overflow-checks = truelto = "fat"codegen-units = 1[profile.release.build-override]opt-level = 3incremental = falsecodegen-units = 1
Убедитесь, что ваша программа указана в массиве workspace/members, а файл
Cargo.toml вашей программы содержит корректно настроенное имя lib.
Важно именно
lib name, а не имя пакета!
Примерно так:
[package]name = "waffle"version = "0.1.0"edition = "2021"[lib]name = "waffle"crate-type = ["cdylib", "lib"][dependencies]solana-program = "2.1.0"
В этом репозитории вы
можете увидеть пример workspace с программой во вложенной папке. Обратите
внимание, что если программа находится во вложенной папке, позже вам нужно будет
добавить эту папку как --mount-path к команде verify-from-repo.
В этом репозитории вы найдете пример с anchor. В этом репозитории вы найдете пример с native rust.
Когда файл Cargo.toml готов, вы можете запустить cargo generate-lockfile,
чтобы создать lock-файл и продолжить сборку вашей программы.
Сборка проверяемых программ
Чтобы воспроизводимо собрать свою программу Solana, перейдите в директорию,
содержащую файл workspace Cargo.toml, и выполните:
solana-verify build
Это скопирует вашу среду в контейнер docker и выполнит сборку детерминированным образом.
Убедитесь, что вы действительно деплоите проверенную сборку и случайно не перезаписываете её с помощью
anchor buildилиcargo build-sbf, так как это, скорее всего, приведёт к другому хэшу, и ваша верификация не пройдёт.
Для проектов с несколькими программами вы можете собрать конкретную программу, используя имя библиотеки (а не имя пакета):
solana-verify build --library-name $PROGRAM_LIB_NAME
Этот процесс обеспечивает детерминированную сборку и может занять некоторое время, особенно на определённых системах (например, MacBook с процессором M1), так как он выполняется внутри контейнера Docker. Для более быстрой сборки рекомендуется использовать машину с архитектурой x86 на базе Linux.
После завершения сборки вы можете получить хэш исполняемого файла, используя следующую команду:
solana-verify get-executable-hash target/deploy/$PROGRAM_LIB_NAME.so
Развёртывание проверяемых программ
После того как вы собрали свою программу и получили её хэш, вы можете развернуть её в сети Solana. Рекомендуется использовать решение с мультиподписью или управление, такое как Squads Protocol, для безопасного развёртывания, но вы также можете развернуть напрямую с помощью:
solana program deploy -u $NETWORK_URL target/deploy/$PROGRAM_LIB_NAME.so --program-id $PROGRAM_ID --with-compute-unit-price 50000 --max-sign-attempts 100 --use-rpc
В настоящее время подходящая низкоприоритетная комиссия, которую вы можете запросить у вашего RPC-провайдера, например Quicknode.
Чтобы проверить, что развернутая программа соответствует собранному исполняемому файлу, выполните:
solana-verify get-program-hash -u $NETWORK_URL $PROGRAM_ID
У вас могут быть развернуты разные версии на разных кластерах Solana (например, devnet, testnet, mainnet). Убедитесь, что вы используете правильный URL сети для нужного кластера Solana, с которым вы хотите проверить программу. Удалённая проверка будет работать только в mainnet.
Проверка с репозиториями
Чтобы проверить программу с её публичным репозиторием, используйте:
solana-verify verify-from-repo -u $NETWORK_URL --program-id $PROGRAM_ID https://github.com/$REPO_PATH --commit-hash $COMMIT_HASH --library-name $PROGRAM_LIB_NAME --mount-path $MOUNT_PATH
При запуске проверенной сборки в каталоге вашей программы, при выполнении
verify-from-repoнеобходимо добавить флаг--mount-path. Это будет путь к папке, содержащейCargo.toml, в которой находится имя библиотеки вашей программы.
Эта команда сравнивает хэш программы в блокчейне с хэшем исполняемого файла, созданного из исходного кода на указанном коммите.
В конце команда спросит, хотите ли вы загрузить данные проверки в блокчейн. Если вы это сделаете, Solana Explorer сразу же покажет данные проверки вашей программы. Пока она не будет проверена удалённой сборкой, она будет отображаться как непроверенная. Узнайте, как вы можете проверить свою программу через публичный API, на следующем шаге.
Если вы хотите зафиксировать проверку на определённый релиз, вы можете добавить
флаг --commit-hash к команде.
Проверка через публичный API
После загрузки вашего верификационного PDA в блокчейн с помощью
verify-from-repo отправьте задание удалённой верификации в
OtterSec API:
solana-verify remote submit-job --program-id <program-id> --uploader <address>
--uploader — это адрес, который загрузил верификационный PDA, как правило это
authority обновления вашей программы. Если ваша программа управляется
мультисигом, продолжите чтение раздела
верификация через мультисиг
данного руководства ниже.
Устаревший флаг
--remoteвverify-from-repoбыл упразднён. Сначала загрузите ваш PDA, затем выполнитеremote submit-job.
Это отправляет задание в OtterSec API. Проверить статус задания можно с помощью:
solana-verify remote get-job --job-id <job-id>
После успешного завершения верификации, что может занять некоторое время, вы сможете увидеть вашу программу как верифицированную в OtterSec API для отдельных программ и в Solana Explorer, SolanaFM, SolScan, а также на поддерживаемом сообществом сайте SolanaVerify.org, который поддерживают 0xDeep и OtterSec verified programs API, и в конечном счёте в Verified Programs Dune Dashboard, что способствует созданию более здоровой экосистемы Solana.
Как верифицировать программу, управляемую мультисигом, например Squads
Для работы удалённой верификации необходимо записать данные верификации в PDA, подписанный authority программы. Если ваша программа управляется мультисигом, вы можете экспортировать транзакцию записи PDA и отправить её через Squads Protocol или другое решение для мультисига по вашему выбору.
1. Создание верифицируемой программы
Сначала соберите программу:
solana-verify build
Это создаст верифицируемую сборку с использованием Docker-контейнера на основе
версии Solana, указанной в файле Cargo.lock.
2. Разверните программу
solana config set --url "PayedMainnetRPCAddress" // the public endpoint will be rate limited too muchsolana program deploy target/deploy/verify_squads.so
В оставшейся части этого руководства по мультиподписи мы будем использовать
пример ID программы 6XBGfP17P3KQAKoJb2s5M5fR4aFTXzPeuC1af2GYkvhD.
3. Зафиксируйте изменения и проверьте соответствие репозиторию
После этого фиксируем проект на GitHub. Пример: https://github.com/solana-developers/verify-squads
Необязательно: попробуйте сначала выполнить верификацию локально (эта команда
использует пример ID программы 6XBGfP17P3KQAKoJb2s5M5fR4aFTXzPeuC1af2GYkvhD):
solana-verify verify-from-repo https://github.com/solana-developers/verify-squads --program-id 6XBGfP17P3KQAKoJb2s5M5fR4aFTXzPeuC1af2GYkvhD
Убедитесь, что параметры указаны верно.
4. Передайте права управления программой мультиподписи
Если вы ещё не передали права управления программой мультиподписи, скопируйте адрес авторитета мультиподписи — он понадобится на следующем шаге.
5. Экспортируйте транзакцию PDA
Когда права управления программой находятся локально у вас, при использовании
команды solana-verify verify-from-repo вам будет предложено загрузить данные
сборки в блокчейн.
Поскольку при использовании мультиподписи это сделать напрямую невозможно, необходимо вручную экспортировать транзакцию PDA и затем инициировать её через Squads.
solana-verify export-pda-tx https://github.com/solana-developers/verify-squads --program-id 6XBGfP17P3KQAKoJb2s5M5fR4aFTXzPeuC1af2GYkvhD --uploader <your program authority> --encoding base58 --compute-unit-price 0
В результате вы получите транзакцию в кодировке base58. Если вам нужна
транзакция в кодировке base64 для использования в инспекторе транзакций,
воспользуйтесь --encoding base64.
P6vBfcPaaXb8fZoT3NBAYEcdtEj7tubA1k2gBxmFKZ3UWF5YyrmDMFTvLKALCJoUuRsPAjMckudYruCu3eeWQtuDrFbEMLxLFutnKXac974fnkMivcwUdY66VLjbxQT6ATmcy7F4hBtz1G4P1h6iBJLhb8WtrtgY3i4qq45MUEb7RjuMEfUFXKrNgPdGxkz5xvMHq3dxKRcpmEK5k2DkeW6SUQYBVe19Ga3B9GyhTX8k3CMt9JCEah13WyRnQd8GjoK6sTEvGJym6xDNvmd8yiJYSNcaYwEJsjHEUf4Yh6kAC7ki2KRvVAr3NVe1gjqK9McrwSQjtUatvydTG8Zovcr7PPUEMf3yPMgKXjZLB2QpkH63yTTYdNAnWFuv9E6b6nYRqye5XcNi436yKw5U14fXh65yK34bgYLi9328UT1huJELsJU9BRGnGUmb6GWp6c2WL5BhnzgNTSnt9TXFfEgUMzhvKzpVBxLP44hwqqBdyUhHFysCF37531PnmiESq8x1xou23xJ6FcQbc199754MkqQd7tX9CUznGzAEqHGkzn3VBoJnojsKtgYmiTYbdRsT1CU18MbYEE7WvGAvXyxxbpNzbAcc94HrnM6cqRGmwhEBroPfFghTdmzg9D
6. Отправьте транзакцию через Squads
Перейдите в конструктор транзакций Squads и импортируйте транзакцию в кодировке base58. Убедитесь, что в симуляции транзакция содержит только вызов программы верификации osec и программы бюджета вычислений — и ничего больше!
7. Отправьте задание удалённой верификации
После успешного выполнения транзакции в Squads вы можете отправить задание удалённой верификации:
solana-verify remote submit-job --program-id 6XBGfP17P3KQAKoJb2s5M5fR4aFTXzPeuC1af2GYkvhD--uploader <your program authority>
Вот и всё! Вы верифицировали вашу программу через публичный репозиторий и отправили удалённое задание в API OtterSec. Теперь вы должны увидеть его отражение в обозревателе Solana и других местах.
8. Обновление программы (Необязательно)
При обновлении программы необходимо экспортировать новую PDA-транзакцию и снова отправить её через Squads.
Выполнение обновления программы:
solana-verify buildsolana program write-buffer target/deploy/verify_squads.so --with-compute-unit-price 50000 --max-sign-attempts 50
Затем передайте права на буфер мультиподписи или создайте буфер непосредственно с правами мультиподписи.
solana program set-buffer-authority Fu3k79g53ZozAj47uq1tXrFy4QbQYh7y745DDsxjtyLR --new-buffer-authority 3JG6ULvZVCrkKtSSskKNJGe8RNZGFe8Ruev9KUhxzK5K
9. Экспорт и отправка новой PDA-транзакции
Не забудьте зафиксировать изменения в GitHub. Снова экспортируйте транзакцию обновления PDA:
solana-verify export-pda-tx https://github.com/solana-developers/verify-squads --program-id 6XBGfP17P3KQAKoJb2s5M5fR4aFTXzPeuC1af2GYkvhD --uploader 3JG6ULvZVCrkKtSSskKNJGe8RNZGFe8Ruev9KUhxzK5K
Снова отправьте транзакцию через Squads.
Пример транзакции можно посмотреть здесь.
Затем отправьте на ещё одну удалённую сборку:
solana-verify remote submit-job --program-id 6XBGfP17P3KQAKoJb2s5M5fR4aFTXzPeuC1af2GYkvhD --uploader 3JG6ULvZVCrkKtSSskKNJGe8RNZGFe8Ruev9KUhxzK5K
Результат должен выглядеть примерно так:
Verification request sent with request id: b63339d2-163e-49ac-b55d-3454c1c2b5b3Verification in progress... ⏳ [00:18:02] ✅ Process completed. (Done in 18minutes) Program 6XBGfP17P3KQAKoJb2s5M5fR4aFTXzPeuC1af2GYkvhD has been verified.✅ The provided GitHub build matches the onchain hash. On Chain Hash:96f8c3d9400258f7759408d1f6f8435b4a24d9b52f5a0340d97907e567cb8773 ExecutableHash: 96f8c3d9400258f7759408d1f6f8435b4a24d9b52f5a0340d97907e567cb8773 Repo URL:https://github.com/Woody4618/verify-squads/tree/0fb0a2e30c15c51732c0ad5e837975a6f7bbc7edCheck the verification status at:https://verify.osec.io/status/6XBGfP17P3KQAKoJb2s5M5fR4aFTXzPeuC1af2GYkvhD Joburl: https://verify.osec.io/job/b63339d2-163e-49ac-b55d-3454c1c2b5b3
Поздравляем! Вы верифицировали программу после обновления с мультиподписью!
Верификация через Docker-образ
Вы также можете верифицировать программу через Docker-образ, выполнив следующую команду:
solana-verify verify-from-image -eexamples/hello_world/target/deploy/hello_world.so -iellipsislabs/hello_world_verifiable_build:latest -p2ZrriTQSVekoj414Ynysd48jyn4AX6ZF4TTJRqHfbJfn
Эта команда загружает образ, хранящийся по адресу
ellipsislabs/hello_world_verifiable_build:latest, и проверяет, совпадает ли
хэш исполняемого файла в контейнере с хэшем программы в блокчейне, переданной в
команду. Поскольку сборка уже была загружена в образ, полная пересборка
исполняемого файла не требуется — это экономит значительное время.
Dockerfile, создающий образ ellipsislabs/hello_world_verifiable_build:latest,
можно найти в репозитории ellipsis labs по пути
/examples/hello_world.
Ниже приведён ожидаемый вывод:
Verifying image: "ellipsislabs/hello_world_verifiable_build:latest", on network"https://api.mainnet.solana.com" against program ID2ZrriTQSVekoj414Ynysd48jyn4AX6ZF4TTJRqHfbJfn Executable path in container:"examples/hello_world/target/deploy/hello_world.so"Executable hash:08d91368d349c2b56c712422f6d274a1e8f1946ff2ecd1dc3efc3ebace52a760 Program hash:08d91368d349c2b56c712422f6d274a1e8f1946ff2ecd1dc3efc3ebace52a760 Executablematches onchain program data ✅
Пример верифицированной сборки
Вот пример верификации программы с идентификатором
FWEYpBAf9WsemQiNbAewhyESfR38GBBHLrCaU3MpEKWv с использованием исходного кода
из этого репозитория:
solana-verify verify-from-repo https://github.com/solana-developers/verified-program --url YOUR-RPC-URL --program-id FWEYpBAf9WsemQiNbAewhyESfR38GBBHLrCaU3MpEKWv --mount-path waffle --library-name waffle --commit-hash 5b82b86f02afbde330dff3e1847bed2d42069f4e
По умолчанию команда verify-from-repo берёт последний коммит из основной
ветки. Вы также можете указать конкретный коммит, если хотите продолжить работу
с репозиторием, используя параметр commit-hash:
--commit-hash 5b82b86f02afbde330dff3e1847bed2d42069f4e
При появлении запроса ответьте «да», чтобы загрузить ваш верификационный PDA в блокчейн. Затем отправьте задание удалённой верификации через OtterSec API:
solana-verify remote submit-job --program-id FWEYpBAf9WsemQiNbAewhyESfR38GBBHLrCaU3MpEKWv --uploader <your-upgrade-authority>
Популярные программы, уже прошедшие верификацию
Phoenix
solana-verify verify-from-repo -um --program-id PhoeNiXZ8ByJGLkxNfZRnkUfjvmuYqLR89jjFHGqdXY https://github.com/Ellipsis-Labs/phoenix-v1
Итоговый вывод:
Executable Program Hash from repo: 6877a5b732b3494b828a324ec846d526d962223959534dbaf4209e0da3b2d6a9Onchain Program Hash: 6877a5b732b3494b828a324ec846d526d962223959534dbaf4209e0da3b2d6a9Program hash matches ✅
Squads V3
solana-verify verify-from-repo https://github.com/Squads-Protocol/squads-mpl --commit-hash c95b7673d616c377a349ca424261872dfcf8b19d --program-id SMPLecH534NA9acpos4G6x7uf3LWbCAwZQE9e8ZekMu -um --library-name squads_mpl --bpf
Обратите внимание, что нам потребовалось указать
library-name, поскольку репозиторий Squads содержит несколько программ. Мы используем флаг--bpf, потому чтоsquads_mplбыла ранее верифицирована с помощью Anchor.
Итоговый вывод:
Executable Program Hash from repo: 72da599d9ee14b2a03a23ccfa6f06d53eea4a00825ad2191929cbd78fb69205cOnchain Program Hash: 72da599d9ee14b2a03a23ccfa6f06d53eea4a00825ad2191929cbd78fb69205cProgram hash matches ✅
Drift V2
solana-verify verify-from-repo -um --program-id dRiftyHA39MWEi3m9aunc5MzRF1JYuBsbn6VPcn33UH https://github.com/drift-labs/protocol-v2 --commit-hash 110d3ff4f8ba07c178d69f9bfc7b30194fac56d6 --library-name drift
Итоговый вывод:
Executable Program Hash from repo: e31d58edeabc3c30bf6f2aa60bfaa5e492b41ec203e9006404b463e5adee5828Onchain Program Hash: e31d58edeabc3c30bf6f2aa60bfaa5e492b41ec203e9006404b463e5adee5828Program hash matches ✅
Marginfi V2
solana-verify verify-from-repo -um --program-id MFv2hWf31Z9kbCa1snEPYctwafyhdvnV7FZnsebVacA https://github.com/mrgnlabs/marginfi-v2 --commit-hash d33e649e415c354cc2a1e3c49131725552d69ba0 --library-name marginfi -- --features mainnet-beta
Итоговый вывод:
Executable Program Hash from repo: 890d68f48f96991016222b1fcbc2cc81b8ef2dcbf280c44fe378c523c108fad5Onchain Program Hash: 890d68f48f96991016222b1fcbc2cc81b8ef2dcbf280c44fe378c523c108fad5Program hash matches ✅
Часто задаваемые вопросы
Верификация не проходит. Что делать?
Проверьте наиболее распространённые причины:
- Неверный подписант: Убедитесь, что ваш подписант является авторитетом
обновления программы, выполнив
solana program show YourProgramId - Отсутствует PDA в сети: Выполните
solana-verify verify-from-repo -umи выберите YES при появлении запроса. Без загрузки PDA API не сможет получить метаданные верификации. - Несоответствие данных PDA: Обновите ваш PDA, если программа была повторно развёрнута. Данные PDA должны соответствовать развёрнутой программе.
- Неверный хеш коммита: Создайте PDA, используя точный хеш коммита, который вы задеплоили
- Различия в среде сборки: Используйте Docker с solana-verify при создании PDA
Хеш локальной сборки не совпадает с хешем в сети. Почему?
Как правило, это означает:
- Вы используете разные версии тулчейна Rust/Solana
- Зависимости были обновлены между сборками
- Сборка выполнялась не в Docker-контейнере
- Вы переключились на неверный коммит
Исправьте это, выполнив сборку с помощью solana-verify build в Docker,
используя точный коммит, который вы задеплоили.
Сколько времени займёт верификация?
Ожидаемые сроки в зависимости от размера программы:
- Простые программы: 1–5 минут
- Сложные программы: 5–15 минут
- Очень большие программы: до 30 минут
Отслеживайте прогресс с помощью эндпоинта статуса задачи.
Моя программа неизменяема (нет авторитета обновления). Как её верифицировать?
Если у вашей программы нет авторитета обновления или она была сделана неизменяемой до того, как вы успели создать PDA, для подобных случаев у нас есть адрес из белого списка. Свяжитесь с нами по адресу contact@osec.io, и мы поможем верифицировать вашу программу.
Что такое PDA и почему это важно?
Ваш PDA (Program Derived Account) обеспечивает верификацию без необходимости доверия:
- Хранение на блокчейне: Сохраняйте метаданные верификации (URL репозитория,
хэш коммита, параметры сборки) в блокчейне в PDA, принадлежащем программе
Otter Verify (
verifycLy8mB96wd9wqq3WDXQwM4oU6r42Th37Db9fC) - Криптографическая связь: Ваш PDA выводится из адреса вашей программы, создавая неизменяемую привязку к данным верификации
- Децентрализованное доверие: Любой может прочитать ваш PDA и независимо верифицировать вашу программу
Почему необходимо создать PDA перед использованием API?
API работает только с PDA в блокчейне, потому что:
- Без доверия: API отклоняет произвольные данные — он использует только те данные, которые ваш upgrade authority сохранил в блокчейне
- Проще: Достаточно указать подписанта и program_id; всё остальное API получает из вашего PDA
- Защита от изменений: Ваш PDA создаёт неизменяемую запись, которую любой может верифицировать независимо
- Подтверждение владения: Ваш подписант должен быть upgrade authority, что криптографически доказывает контроль над программой
Как часто следует верифицировать программу?
Верифицируйте вашу программу:
- После каждого развёртывания или обновления
- При обновлении исходного репозитория
- В остальных случаях повторная верификация не требуется — API автоматически верифицирует все программы каждые 24 часа
Что происходит при обновлении программы?
Выполните следующие шаги после обновления:
- API обнаруживает обновление и снимает верификацию с вашей программы.
- Обновите ваш PDA с новыми метаданными верификации:
solana-verify verify-from-repo -um \--program-id YourProgramId... \https://github.com/your-org/your-program
- Отправьте новый запрос на верификацию, используя ваш upgrade authority
- API верифицирует вашу новую версию на основе обновлённого PDA
Важно: Всегда обновляйте ваш PDA через upgrade authority с новым хэшем коммита для обновлённой программы.
Можно ли доверять результатам верификации?
Да — система разработана так, чтобы быть безопасной без необходимости доверия и допускать независимую проверку:
Что делает её надёжной:
- On-Chain PDA: Метаданные верификации хранятся в блокчейне и не контролируются каким-либо центральным органом
- Доказательство права на обновление: Только владелец права на обновление вашей программы может создавать/обновлять PDA
- Независимая верификация: Любой желающий может выполнить проверку, прочитав
ваш PDA и запустив
solana-verifyлокально - Непрерывная повторная верификация: API автоматически повторно верифицирует все программы каждые 24 часа
Учитывайте следующие ограничения:
- Верификация подтверждает соответствие исходного кода развёртыванию — НЕ то, что ваш код безопасен
- Всегда проверяйте код перед взаимодействием с программами
- Верифицировано ≠ прошло аудит или является безопасным
- Проверьте репозиторий и коммит в PDA, чтобы убедиться, что источник заслуживает доверия
Как самостоятельно верифицировать программу?
Верифицируйте любую программу самостоятельно, прочитав её on-chain PDA и запустив верификацию локально:
Шаг 1: Чтение On-Chain PDA
# Install solana-verify if you haven'tcargo install solana-verify# Get the PDA datasolana-verify list-program-pdas --program-id YourProgramId...
Шаг 2: Локальная верификация
# Verify using the repository and commit & other arguments from the PDAsolana-verify verify-from-repo \--program-id YourProgramId... \https://github.com/your-org/your-program--commit-hash <commit-hash>... (other arguments from the PDA)# Confirm the hash output matches the onchain program hash
Это доказывает:
- Метаданные PDA являются подлинными (хранятся в блокчейне)
- Исходный код в репозитории PDA соответствует развёрнутой программе
- Вам не нужно доверять API — проверяйте всё самостоятельно в блокчейне
Может ли кто-то другой верифицировать мою программу без разрешения?
Да, именно поэтому мы требуем, чтобы подписантом являлся владелец права на обновление. Мы считаем верификацию действительной только в том случае, если подписант является владельцем права на обновление.
Что нужно для создания верифицируемых сборок?
Установите следующие инструменты:
- Docker (для детерминированных сборок)
- Cargo (менеджер пакетов Rust)
- Solana Verify CLI:
cargo install solana-verify - Публичный Git-репозиторий с вашим исходным кодом
Могу ли я верифицировать приватные репозитории?
Нет — верификация требует открытого исходного кода:
- Ваш PDA хранит URL публичного репозитория, доступного для всех
- Верификация без доверия зависит от открытого доступа к коду
- Пользователи должны иметь возможность читать исходный код, чтобы понять, что делает ваша программа
- Весь смысл заключается в том, чтобы пользователи могли самостоятельно убедиться, что исходный код соответствует развёртыванию
Приватные репозитории нарушают основную модель доверия системы верификации.
Как верифицировать программу, управляемую Squads Multisig?
Следуйте этим шагам для программ, управляемых мультиподписью:
# 1. Build and deploy normallysolana-verify buildsolana program deploy <your-program.so> --program-id YourProgramId...# 2. Verify locally first - confirm the hash matchessolana-verify verify-from-repo -um \--program-id YourProgramId... \https://github.com/your-org/your-program# 3. Export the PDA creation transactionsolana-verify export-pda-tx \--program-id YourProgramId... \https://github.com/your-org/your-program# 4. Execute the PDA transaction through your Squads Multisig interface# 5. After multisig execution, trigger remote verificationsolana-verify remote submit-job \--program-id YourProgramId... \--uploader YourMultisigAddress...
Важно: всегда выполняйте локальную верификацию (шаг 2), чтобы убедиться в совпадении хеша сборки перед экспортом транзакции PDA.
Заключение
Использование верифицированных сборок на Solana обеспечивает целостность и надёжность ваших программ в сети, а также позволяет разработчикам находить ваши SDK непосредственно через Solana Explorer. Используя такие инструменты, как Solana Verify CLI и Docker, вы можете поддерживать верифицируемые и безопасные сборки, соответствующие вашему исходному коду. Всегда принимайте необходимые меры предосторожности для обеспечения согласованности сред и рассмотрите решения для управления безопасными обновлениями и развёртываниями.
Безопасность и отказ от ответственности
Хотя верифицированные сборки являются мощным инструментом обеспечения целостности ваших программ на Solana, конфигурация по умолчанию не является полностью доверенной. Образы Docker собираются и размещаются Solana Foundation.
Учтите, что вы собираете свой проект в загруженном образе Docker и что всё ваше окружение, включая потенциально конфиденциальные данные, копируется в этот образ для сборки.
Если вы хотите получить полностью независимую от доверия конфигурацию, вы можете собрать образы Docker самостоятельно и разместить их на собственной инфраструктуре. Таким образом вы сможете быть уверены, что образы Docker не были подменены. Скрипты для создания собственных образов Docker можно найти в репозитории Verified builds — вы можете сделать его форк и запускать GitHub Actions самостоятельно или проверить их корректность.
Кроме того, при удалённой верификации вы в определённой степени доверяете API OtterSec и Solana Explorer.
API или Solana Explorer могут отображать некорректную информацию в случае компрометации.
Если вы хотите настроить полностью доверенную среду без посредников, вы можете
самостоятельно развернуть
Verify API или
выполнить верификацию программы локально с помощью команды verify-from-repo,
используя данные верификации из сети, сохранённые в
PDA,
который формируется на основе авторитета развёртывания программы и
программы верификации.
Программа верификации развёрнута командой OtterSec и на данный момент не заморожена, поэтому может быть обновлена в любое время.
Фонд Solana, OtterSec и команда Ellipsis Labs не несут ответственности за какие-либо убытки или ущерб, которые могут возникнуть в результате использования конвейера верифицированных сборок.
Security.txt для программ Solana
Помимо верифицированных сборок, вы также можете добавить файл security.txt в
свою программу. В будущем, после реализации, файл security.txt будет содержать
публичный ключ верификатора для удобного доступа к данным верификации,
хранящимся в PDA верификации. PDA, содержащий всю информацию, необходимую для
сборки и верификации программы, формируется на основе адреса программы и pubkey
верификатора. По умолчанию это тот же pubkey, который использовался для сборки и
развёртывания программы. Однако можно указать и другой pubkey в файле
security.txt.
Функция security.txt позволяет разработчикам встраивать контактную информацию
и сведения о безопасности непосредственно в смарт-контракты Solana.
Вдохновлённый проектом securitytxt.org, этот подход
обеспечивает стандартизированный способ связи исследователей безопасности с
сопровождающими проекта, даже если им известен только адрес контракта.
Зачем использовать security.txt?
Для многих проектов, особенно небольших или частных, идентификация разработчиков
только по адресу контракта может быть сложной и трудоёмкой задачей. Встраивание
файла security.txt в программу гарантирует, что исследователи безопасности
смогут легко связаться с нужными людьми, что потенциально позволяет
предотвратить эксплойты и обеспечить своевременное сообщение об ошибках.
Как реализовать security.txt
Чтобы добавить security.txt в вашу программу Solana, выполните следующие шаги:
Добавьте зависимость solana-security-txt в ваш Cargo.toml:
[dependencies]solana-security-txt = "1.1.1"
Используйте макрос security_txt! в вашем контракте для определения информации
о безопасности. Вы можете указать контактные данные, URL-адреса проекта и
политику безопасности. Пример:
#[cfg(not(feature = "no-entrypoint"))]use {default_env::default_env, solana_security_txt::security_txt};#[cfg(not(feature = "no-entrypoint"))]security_txt! {name: "MyProject",project_url: "https://myproject.com",contacts: "email:security@myproject.com,discord:security#1234",policy: "https://myproject.com/security-policy",// Optional Fieldspreferred_languages: "en,de",source_code: "https://github.com/solana-developers/solana-game-preset",source_revision: "5vJwnLeyjV8uNJSp1zn7VLW8GwiQbcsQbGaVSwRmkE4r",source_release: "",encryption: "",auditors: "Verifier pubkey: 5vJwnLeyjV8uNJSp1zn7VLW8GwiQbcsQbGaVSwRmkE4r",acknowledgements: "Thank you to our bug bounty hunters!"}
После того как информация security.txt встроена в вашу программу, её можно
легко получить с помощью таких инструментов, как Solana Explorer, что
обеспечивает доступность ваших контактных данных и сведений о безопасности для
всех, кто хочет сообщить о потенциальных проблемах.
Лучшие практики
-
Используйте ссылки: для информации, которая может изменяться (например, контактные данные), рекомендуется давать ссылку на веб-страницу, а не жёстко прописывать её в контракте. Это позволяет избежать необходимости частого обновления программы.
-
Верификация: перед развёртыванием проверьте формат и содержимое с помощью инструмента
query-security-txt, который позволяет валидировать как программы в сети, так и локальные бинарные файлы:
query-security-txt target/bpfel-unknown-unknown/release/my_contract.so
Встраивая контактную информацию по вопросам безопасности непосредственно в контракт, вы упрощаете связь с исследователями, способствуя улучшению безопасности и коммуникации в экосистеме Solana.
Вот пример того, как security.txt выглядит в Solana Explorer
Проект security.txt поддерживается
Neodyme Labs
Вы можете проверить статус верификации и просмотреть верифицированные программы на verify.osec.io.
Is this page helpful?