Ten przewodnik jest przeznaczony jako odniesienie dla deweloperów, którzy chcą wdrożyć zweryfikowane kompilacje dla swoich programów na platformie Solana. Omówimy, czym są zweryfikowane kompilacje, jak z nich korzystać, specjalne uwagi oraz najlepsze praktyki, aby zapewnić autentyczność Twojego programu w łańcuchu bloków.
Czym są zweryfikowane kompilacje?
Zweryfikowane kompilacje zapewniają, że wykonywalny program, który wdrażasz w sieci Solana, odpowiada kodowi źródłowemu w Twoim repozytorium. Dzięki temu deweloperzy i użytkownicy mogą mieć pewność, że program działający w łańcuchu bloków dokładnie odpowiada publicznej bazie kodu, co promuje przejrzystość i bezpieczeństwo.
Proces weryfikacji polega na porównaniu skrótu programu w łańcuchu bloków ze skrótem programu lokalnie zbudowanego z kodu źródłowego. To zapewnia brak rozbieżności między obiema wersjami.
Chociaż zweryfikowana kompilacja nie powinna być uważana za bardziej bezpieczną niż niezweryfikowana, umożliwia ona deweloperom samodzielne zweryfikowanie, że kod źródłowy odpowiada temu, co zostało wdrożone w łańcuchu bloków. Korzystając z kodu źródłowego, deweloper może następnie zweryfikować, co kod wykonuje podczas wysyłania transakcji.
Pipeline zweryfikowanych kompilacji został opracowany i jest utrzymywany przez Ellipsis Labs oraz OtterSec. Aby uzyskać więcej szczegółów, zapoznaj się z przewodnikiem w oryginalnym repozytorium zweryfikowanych kompilacji oraz procesem weryfikacji kompilacji bezpośrednio w zestawie narzędzi Anza, gdy tylko będzie tam obsługiwany.
Jak to działa?
Proces weryfikacji polega na porównaniu skrótu programu znajdującego się w łańcuchu bloków z hashem programu zbudowanego lokalnie z kodu źródłowego. Budujesz swój program w kontrolowanym środowisku, używając Solana Verify CLI i Dockera. Zapewnia to, że proces budowy jest deterministyczny i spójny na różnych systemach. Po uzyskaniu pliku wykonywalnego możesz wdrożyć go w sieci Solana. Podczas procesu budowy zostanie utworzony PDA programu verify. Ten PDA zawiera wszystkie dane niezbędne do weryfikacji programu. PDA zawiera adres programu, URL repozytorium git, hash commita oraz argumenty użyte do budowy programu.
Korzystając z danych zawartych w PDA, każdy może lokalnie uruchomić polecenie verify program i sprawdzić, czy program został zbudowany z dostarczonego kodu źródłowego. Następnie każdy może zweryfikować to samodzielnie, całkowicie bez zaufania, lub uruchomić własne verify API zarządzane przez OtterSec, aby zapewnić użytkownikom łatwy punkt dostępu do sprawdzania weryfikacji. Możesz już zobaczyć te wywołania API używane w Solana Explorer i SolanaFM, między innymi.
Dlaczego warto korzystać ze zweryfikowanych buildów?
Korzystanie ze zweryfikowanych buildów zapewnia następujące korzyści:
-
Bezpieczeństwo: Gwarancja, że program działający w łańcuchu bloków odpowiada kodowi źródłowemu, co zapobiega złośliwym zmianom.
-
Przejrzystość: Umożliwia innym użytkownikom i deweloperom weryfikację, że program w łańcuchu bloków jest godny zaufania, porównując go z publiczną bazą kodu.
-
Zaufanie: Zwiększa zaufanie użytkowników, ponieważ zweryfikowane buildy pokazują, że zachowanie programu w łańcuchu bloków jest zgodne z publicznym kodem. Tworząc programy możliwe do weryfikacji, minimalizujesz ryzyko związane z uruchamianiem nieautoryzowanego lub złośliwego kodu. Zapewnia to również zgodność z najlepszymi praktykami i ułatwia badaczom bezpieczeństwa kontakt z Tobą. Ponadto portfele i inne narzędzia mogą łatwiej akceptować transakcje z Twojego programu, o ile jest on zweryfikowany.
-
Odkrywalność: Gdy udostępniasz zweryfikowaną wersję swojego programu, każdy może znaleźć Twój kod źródłowy, dokumentację, SDK programu lub IDL, a także łatwo skontaktować się z Tobą przez GitHub w przypadku problemów.
Jak tworzyć zweryfikowane wersje?
Aby stworzyć zweryfikowane wersje, musisz wykonać następujące kroki:
Podsumowanie:
- Zatwierdź swój kod w publicznym repozytorium
- Zbuduj zweryfikowaną wersję w Dockerze
- Wdróż zweryfikowaną wersję
- Zweryfikuj wdrożony program względem publicznego API
Jeśli zweryfikujesz swój program, który nie został zbudowany w kontenerze Dockera, najprawdopodobniej weryfikacja się nie powiedzie, ponieważ kompilacje programów Solana nie są deterministyczne na różnych systemach.
Zainstaluj Docker i Cargo
Zainstaluj niezbędne narzędzia, upewnij się, że masz zainstalowane Docker i Cargo. Docker zapewnia kontrolowane środowisko kompilacji, aby zagwarantować spójność, a Cargo służy do zarządzania pakietami Rust.
- Docker: Wykonaj kroki opisane na stronie Dockera, aby zainstalować Dockera dla swojej platformy. Po instalacji upewnij się, że usługa Dockera działa, postępując zgodnie z dalszymi wskazówkami w tym przewodniku.
- Cargo: Jeśli nie masz jeszcze zainstalowanego Cargo, możesz je zainstalować, uruchamiając następujące polecenie:
curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
Zainstaluj Solana Verify CLI
Solana Verify CLI to główne narzędzie używane do weryfikacji kompilacji. Solana Verify CLI jest obecnie utrzymywane przez Ellipsis Labs i można je zainstalować za pomocą Cargo.
Możesz je zainstalować, uruchamiając:
cargo install solana-verify
Jeśli potrzebujesz konkretnej wersji CLI, możesz przypiąć wersję za pomocą:
cargo install solana-verify --version $VERSION
Jeśli chcesz, możesz zainstalować wersję bezpośrednio z konkretnego commita:
cargo install solana-verify --git https://github.com/Ellipsis-Labs/solana-verifiable-build --rev 13a1db2
Przygotowanie projektu
Aby zweryfikować względem repozytorium, musi ono zawierać plik Cargo.lock w
katalogu głównym repozytorium. Jeśli masz tylko jeden program w repozytorium i
plik cargo.lock w katalogu głównym, możesz przejść od razu do następnego kroku
i zbudować swój program.
Jeśli Twój program znajduje się w podfolderze i korzystasz z workspace rust,
musisz utworzyć plik workspace Cargo.toml w katalogu głównym repozytorium.
Możesz użyć tego przykładu Cargo.toml jako wzorca:
[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
Upewnij się, że Twój program znajduje się w tablicy workspace/members oraz że
Cargo.toml Twojego programu ma poprawnie skonfigurowaną nazwę lib.
Ważna jest
lib name, a nie nazwa pakietu!
Coś takiego:
[package]name = "waffle"version = "0.1.0"edition = "2021"[lib]name = "waffle"crate-type = ["cdylib", "lib"][dependencies]solana-program = "2.1.0"
W tym repozytorium
możesz zobaczyć przykład workspace z programem w podfolderze. Zwróć także uwagę,
że jeśli program jest w podfolderze, później musisz dodać ten folder jako
--mount-path do polecenia verify-from-repo.
W tym repozytorium znajdziesz przykład z Anchor. W tym repozytorium znajdziesz przykład natywnego Rust.
Mając plik Cargo.toml na miejscu, możesz uruchomić cargo generate-lockfile,
aby utworzyć plik lock i kontynuować budowanie programu.
Budowanie weryfikowalnych programów
Aby zweryfikowanie zbudować swój program Solana, przejdź do katalogu
zawierającego plik Cargo.toml workspace i uruchom:
solana-verify build
To skopiuje Twoje środowisko do kontenera Docker i zbuduje je w sposób deterministyczny.
Upewnij się, że faktycznie wdrażasz zweryfikowaną kompilację i nie nadpisujesz jej przypadkowo przez
anchor buildlubcargo build-sbf, ponieważ najprawdopodobniej nie wygenerują one tego samego hasha i przez to weryfikacja się nie powiedzie.
W przypadku projektów z wieloma programami możesz zbudować konkretny program, używając nazwy biblioteki (a nie nazwy pakietu):
solana-verify build --library-name $PROGRAM_LIB_NAME
Ten proces zapewnia deterministyczne kompilacje i może zająć trochę czasu, szczególnie na niektórych systemach (np. M1 MacBook), ponieważ działa w kontenerze docker. Dla szybszych kompilacji zaleca się użycie maszyny z systemem Linux działającej na architekturze x86.
Po zakończeniu kompilacji możesz uzyskać hash pliku wykonywalnego za pomocą następującego polecenia:
solana-verify get-executable-hash target/deploy/$PROGRAM_LIB_NAME.so
Wdrażanie weryfikowalnych programów
Po zbudowaniu programu i uzyskaniu jego hasha możesz wdrożyć go w sieci Solana. Zaleca się użycie rozwiązania wielopodpisowego lub zarządzania, takiego jak Squads Protocol dla bezpiecznych wdrożeń, ale możesz również wdrożyć bezpośrednio za pomocą:
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
Obecnie odpowiednia niska opłata priorytetowa, którą możesz zażądać od swojego dostawcy rpc, na przykład Quicknode.
Aby zweryfikować, czy wdrożony program odpowiada zbudowanemu plikowi wykonywalnemu, uruchom:
solana-verify get-program-hash -u $NETWORK_URL $PROGRAM_ID
Możesz mieć różne wersje wdrożone na różnych klastrach Solana (tj. devnet, testnet, mainnet). Upewnij się, że używasz poprawnego adresu URL sieci dla wybranego klastra Solana, który chcesz zweryfikować. Zdalna weryfikacja będzie działać tylko na mainnet.
Weryfikacja względem repozytoriów
Aby zweryfikować program względem jego publicznego repozytorium, użyj:
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
Podczas uruchamiania zweryfikowanej kompilacji w katalogu programu, przy wykonywaniu
verify-from-repomusisz dodać flagę--mount-path. Będzie to ścieżka do folderu zawierającegoCargo.toml, który zawiera nazwę biblioteki twojego programu.
To polecenie porównuje hash programu znajdującego się w łańcuchu bloków z hashem wykonywalnym zbudowanym na podstawie źródła w określonym commicie.
Na końcu polecenie zapyta, czy chcesz przesłać dane weryfikacyjne na łańcuch bloków. Jeśli to zrobisz, Solana Explorer natychmiast wyświetli dane weryfikacyjne twojego programu. Dopóki nie zostanie zweryfikowany przez zdalne kompilowanie, będzie wyświetlany jako niezweryfikowany. Dowiedz się, jak możesz zweryfikować swój program za pomocą publicznego API w następnym kroku.
Jeśli chcesz zablokować weryfikację do konkretnego wydania, możesz dodać flagę
--commit-hash do polecenia.
Weryfikacja za pomocą publicznego API
Po przesłaniu PDA weryfikacji onchain za pomocą verify-from-repo, prześlij
zdalne zadanie weryfikacji do
OtterSec API:
solana-verify remote submit-job --program-id <program-id> --uploader <address>
--uploader to adres, który przesłał PDA weryfikacji, zazwyczaj uprawnienie do
aktualizacji programu. Jeśli Twój program jest kontrolowany przez multisig,
kontynuuj w sekcji
weryfikacja multisig
tego przewodnika poniżej.
Przestarzała flaga
--remotewverify-from-repozostała wycofana. Najpierw prześlij swoje PDA, a następnie uruchomremote submit-job.
Spowoduje to przesłanie zadania do OtterSec API. Status zadania możesz sprawdzić za pomocą:
solana-verify remote get-job --job-id <job-id>
Po pomyślnym zakończeniu weryfikacji, co może chwilę potrwać, będziesz mógł zobaczyć swój program jako zweryfikowany w OtterSec API dla pojedynczych programów oraz w Solana Explorer, SolanaFM, SolScan oraz docelowo również na prowadzonej przez społeczność stronie SolanaVerify.org utrzymywanej przez 0xDeep i OtterSec verified programs API oraz na koniec w Verified Programs Dune Dashboard przyczyniając się do zdrowszego ekosystemu Solany.
Jak zweryfikować program kontrolowany przez Multisig, np. Squads
Aby zdalna weryfikacja działała, musisz zapisać dane weryfikacyjne w PDA podpisanym przez administratora programu. Jeśli Twój program jest kontrolowany przez multisig, możesz wyeksportować tę transakcję zapisu PDA i przesłać ją przez Squads Protocol lub inne wybrane przez Ciebie rozwiązanie multisig.
1. Zbuduj weryfikowalny program
Najpierw zbuduj program:
solana-verify build
Spowoduje to zbudowanie weryfikowalnego buildu przy użyciu kontenera Docker z
wersją Solany określoną w pliku Cargo.lock.
2. Wdróż program
solana config set --url "PayedMainnetRPCAddress" // the public endpoint will be rate limited too muchsolana program deploy target/deploy/verify_squads.so
W pozostałej części tego przewodnika po multisig użyjemy przykładowego ID
programu 6XBGfP17P3KQAKoJb2s5M5fR4aFTXzPeuC1af2GYkvhD.
3. Zatwierdź i zweryfikuj względem repozytorium
Po wykonaniu tych czynności zatwierdzamy projekt na GitHubie. Oto przykład: https://github.com/solana-developers/verify-squads
Opcjonalnie: Sprawdź, czy możesz najpierw zweryfikować lokalnie (to polecenie
używa przykładowego ID programu 6XBGfP17P3KQAKoJb2s5M5fR4aFTXzPeuC1af2GYkvhD):
solana-verify verify-from-repo https://github.com/solana-developers/verify-squads --program-id 6XBGfP17P3KQAKoJb2s5M5fR4aFTXzPeuC1af2GYkvhD
Tylko po to, aby upewnić się, że parametry są poprawne.
4. Przenieś uprawnienia programu do multisig
Jeśli jeszcze nie przeniosłeś uprawnień swojego programu do multisig, skopiuj uprawnienia multisig. Będą potrzebne w następnym kroku.
5. Eksportuj transakcję PDA
Gdy masz uprawnienia programu lokalnie, zostaniesz poproszony o przesłanie
danych build w łańcuchu podczas używania polecenia
solana-verify verify-from-repo.
Ponieważ nie możesz tego zrobić podczas korzystania z multisig, musisz ręcznie wyeksportować transakcję PDA, a następnie wywołać transakcję przez 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
Zwróci to transakcję zakodowaną w base58. Jeśli chcesz uzyskać transakcję
zakodowaną w base64 do użycia w inspektorze transakcji, możesz użyć
--encoding base64.
P6vBfcPaaXb8fZoT3NBAYEcdtEj7tubA1k2gBxmFKZ3UWF5YyrmDMFTvLKALCJoUuRsPAjMckudYruCu3eeWQtuDrFbEMLxLFutnKXac974fnkMivcwUdY66VLjbxQT6ATmcy7F4hBtz1G4P1h6iBJLhb8WtrtgY3i4qq45MUEb7RjuMEfUFXKrNgPdGxkz5xvMHq3dxKRcpmEK5k2DkeW6SUQYBVe19Ga3B9GyhTX8k3CMt9JCEah13WyRnQd8GjoK6sTEvGJym6xDNvmd8yiJYSNcaYwEJsjHEUf4Yh6kAC7ki2KRvVAr3NVe1gjqK9McrwSQjtUatvydTG8Zovcr7PPUEMf3yPMgKXjZLB2QpkH63yTTYdNAnWFuv9E6b6nYRqye5XcNi436yKw5U14fXh65yK34bgYLi9328UT1huJELsJU9BRGnGUmb6GWp6c2WL5BhnzgNTSnt9TXFfEgUMzhvKzpVBxLP44hwqqBdyUhHFysCF37531PnmiESq8x1xou23xJ6FcQbc199754MkqQd7tX9CUznGzAEqHGkzn3VBoJnojsKtgYmiTYbdRsT1CU18MbYEE7WvGAvXyxxbpNzbAcc94HrnM6cqRGmwhEBroPfFghTdmzg9D
6. Prześlij transakcję przez Squads
Przejdź do kreatora transakcji Squads i zaimportuj transakcję zakodowaną w base58. Upewnij się, że w symulacji transakcja zawiera tylko wywołanie programu weryfikacyjnego osec oraz programu budżetu komputerowego i nic więcej!
7. Prześlij zdalne zadanie weryfikacyjne
Gdy transakcja do Squads zakończyła się pomyślnie, możesz przesłać zdalne zadanie:
solana-verify remote submit-job --program-id 6XBGfP17P3KQAKoJb2s5M5fR4aFTXzPeuC1af2GYkvhD--uploader <your program authority>
To jest to! Zweryfikowałeś swój program w publicznym repozytorium i przesłałeś zdalne zadanie do API OtterSec. Powinieneś teraz być w stanie zobaczyć jego odzwierciedlenie w eksploratorze Solany i innych miejscach.
8. Aktualizacja programu (Opcjonalnie)
Gdy zaktualizujesz swój program, musisz wyeksportować nową transakcję PDA i przesłać ją przez Squads ponownie.
Wykonanie aktualizacji programu:
solana-verify buildsolana program write-buffer target/deploy/verify_squads.so --with-compute-unit-price 50000 --max-sign-attempts 50
Następnie przenieś uprawnienia do bufora na multisig lub bezpośrednio utwórz bufor z uprawnieniami multisig.
solana program set-buffer-authority Fu3k79g53ZozAj47uq1tXrFy4QbQYh7y745DDsxjtyLR --new-buffer-authority 3JG6ULvZVCrkKtSSskKNJGe8RNZGFe8Ruev9KUhxzK5K
9. Eksportowanie i przesyłanie nowej transakcji PDA
Nie zapomnij zatwierdzić swoich zmian na githubie. Wyeksportuj ponownie transakcję upgrade PDA:
solana-verify export-pda-tx https://github.com/solana-developers/verify-squads --program-id 6XBGfP17P3KQAKoJb2s5M5fR4aFTXzPeuC1af2GYkvhD --uploader 3JG6ULvZVCrkKtSSskKNJGe8RNZGFe8Ruev9KUhxzK5K
Prześlij transakcję ponownie przez Squads.
Przykładową transakcję możesz zobaczyć tutaj.
Następnie prześlij kolejne zdalne kompilowanie:
solana-verify remote submit-job --program-id 6XBGfP17P3KQAKoJb2s5M5fR4aFTXzPeuC1af2GYkvhD --uploader 3JG6ULvZVCrkKtSSskKNJGe8RNZGFe8Ruev9KUhxzK5K
Powinno to dać wynik podobny do poniższego:
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
Gratulacje, zweryfikowałeś swój program po aktualizacji multisig!
Weryfikacja z obrazu Docker
Możesz również zweryfikować swój program względem obrazu Docker, uruchamiając następujące polecenie:
solana-verify verify-from-image -eexamples/hello_world/target/deploy/hello_world.so -iellipsislabs/hello_world_verifiable_build:latest -p2ZrriTQSVekoj414Ynysd48jyn4AX6ZF4TTJRqHfbJfn
To polecenie wczytuje obraz przechowywany pod adresem
ellipsislabs/hello_world_verifiable_build:latest i weryfikuje, czy skrót
ścieżki wykonywalnej w kontenerze jest taki sam jak skrót programu onchain
dostarczanego do polecenia. Ponieważ kompilacja została już przesłana do obrazu,
nie ma potrzeby pełnej rekompilacji pliku wykonywalnego, co może zajmować dużo
czasu.
Plik Dockerfile tworzący obraz
ellipsislabs/hello_world_verifiable_build:latest można znaleźć w repozytorium
ellipsis labs
/examples/hello_world.
Poniżej znajdują się oczekiwane dane wyjściowe:
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 ✅
Przykładowa zweryfikowana kompilacja
Oto przykład weryfikacji przykładowego programu o identyfikatorze
FWEYpBAf9WsemQiNbAewhyESfR38GBBHLrCaU3MpEKWv przy użyciu kodu źródłowego z
tego repozytorium:
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
Domyślnie polecenie verify-from-repo pobiera ostatni commit z gałęzi main.
Możesz również wskazać określony commit, jeśli chcesz kontynuować pracę nad
repozytorium, używając parametru commit-hash:
--commit-hash 5b82b86f02afbde330dff3e1847bed2d42069f4e
Gdy zostaniesz o to poproszony, odpowiedz tak, aby przesłać swoje PDA weryfikacji onchain. Następnie wyślij zdalne zadanie weryfikacji do API OtterSec:
solana-verify remote submit-job --program-id FWEYpBAf9WsemQiNbAewhyESfR38GBBHLrCaU3MpEKWv --uploader <your-upgrade-authority>
Popularne programy, które są już zweryfikowane
Phoenix
solana-verify verify-from-repo -um --program-id PhoeNiXZ8ByJGLkxNfZRnkUfjvmuYqLR89jjFHGqdXY https://github.com/Ellipsis-Labs/phoenix-v1
Końcowe dane wyjściowe:
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
Zauważ, że musieliśmy określić
library-name, ponieważ repozytorium Squads zawiera wiele programów. Używamy flagi--bpf, ponieważsquads_mplbył wcześniej zweryfikowany z Anchor.
Końcowe dane wyjściowe:
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
Końcowe dane wyjściowe:
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
Końcowe dane wyjściowe:
Executable Program Hash from repo: 890d68f48f96991016222b1fcbc2cc81b8ef2dcbf280c44fe378c523c108fad5Onchain Program Hash: 890d68f48f96991016222b1fcbc2cc81b8ef2dcbf280c44fe378c523c108fad5Program hash matches ✅
Często zadawane pytania
Moja weryfikacja nie powiodła się. Co powinienem zrobić?
Sprawdź te typowe problemy:
- Nieprawidłowy sygnatariusz: Upewnij się, że Twój sygnatariusz jest
autoryzowany do aktualizacji programu, uruchamiając
solana program show YourProgramId - Brak PDA w sieci: Uruchom
solana-verify verify-from-repo -umi wybierz TAK po wyświetleniu monitu. Bez przesłania PDA API nie będzie mogło pobrać metadanych weryfikacji. - Niezgodność danych PDA: Zaktualizuj swoje PDA, jeśli ponownie wdrożyłeś program. Dane PDA muszą być zgodne z wdrożonym programem.
- Nieprawidłowy skrót commita: Utwórz PDA, używając dokładnego skrótu commita, który wdrożyłeś
- Różnice w środowisku kompilacji: Używaj Dockera z solana-verify podczas tworzenia PDA
Skrót lokalnej kompilacji nie zgadza się ze skrótem w sieci. Dlaczego?
Zazwyczaj oznacza to:
- Używasz różnych wersji łańcucha narzędzi Rust/Solana
- Twoje zależności zostały zaktualizowane między kompilacjami
- Nie kompilowałeś w kontenerze Docker
- Przełączyłeś się na niewłaściwy commit
Napraw to, kompilując za pomocą solana-verify build w Dockerze, używając
dokładnego commita, który wdrożyłeś.
Jak długo potrwa moja weryfikacja?
Spodziewaj się następujących ram czasowych w zależności od rozmiaru programu:
- Proste programy: 1–5 minut
- Złożone programy: 5–15 minut
- Bardzo duże programy: do 30 minut
Śledź postęp, korzystając z punktu końcowego statusu zadania.
Mój program jest niezmienny (brak autoryzacji aktualizacji). Jak mogę go zweryfikować?
Jeśli Twój program nie ma autoryzacji aktualizacji lub został uczyniony niezmiennym, zanim zdążyłeś utworzyć PDA, mamy adres z białej listy dla tej sytuacji. Skontaktuj się z nami pod adresem contact@osec.io, a pomożemy Ci zweryfikować program.
Czym jest PDA i dlaczego ma znaczenie?
Twój PDA (Program Derived Account) umożliwia weryfikację bez zaufania:
- Przechowywanie On-Chain: Przechowuj metadane weryfikacji (adres URL
repozytorium, hash commita, parametry kompilacji) onchain w PDA należącym do
programu Otter Verify (
verifycLy8mB96wd9wqq3WDXQwM4oU6r42Th37Db9fC) - Kryptograficzne Powiązanie: Twój PDA jest wyprowadzany z adresu Twojego programu, tworząc niezmienne powiązanie z danymi weryfikacyjnymi
- Zdecentralizowane Zaufanie: Każdy może odczytać Twój PDA i niezależnie zweryfikować Twój program
Dlaczego muszę utworzyć PDA przed użyciem API?
API działa wyłącznie z PDA onchain, ponieważ:
- Bez Zaufania: API odrzuca dowolne dane — używa wyłącznie tych, które Twój upgrade authority zapisał onchain
- Prostsze: Wystarczy podać sygnatariusza + program_id; API pobiera wszystko inne z Twojego PDA
- Odporność na Manipulacje: Twój PDA tworzy niezmienialny rekord, który każdy może zweryfikować niezależnie
- Dowód Własności: Twój sygnatariusz musi być upgrade authority, kryptograficznie potwierdzając, że kontrolujesz program
Jak często powinienem weryfikować swój program?
Weryfikuj swój program:
- Po każdym wdrożeniu lub aktualizacji
- Gdy aktualizujesz repozytorium źródłowe
- Nie martw się o ponowną weryfikację w innych przypadkach — API automatycznie ponownie weryfikuje wszystkie programy co 24 godziny
Co się dzieje, gdy aktualizuję swój program?
Wykonaj poniższe kroki po aktualizacji:
- API wykrywa aktualizację i usuwa weryfikację Twojego programu.
- Zaktualizuj swój PDA o nowe metadane weryfikacji:
solana-verify verify-from-repo -um \--program-id YourProgramId... \https://github.com/your-org/your-program
- Prześlij nowe żądanie weryfikacji przy użyciu swojego upgrade authority
- API zweryfikuje nową wersję na podstawie zaktualizowanego PDA
Ważne: Zawsze aktualizuj swój PDA za pomocą upgrade authority z nowym haszem commita dla zaktualizowanego programu.
Czy mogę ufać wynikom weryfikacji?
Tak – system jest zaprojektowany tak, aby był niezaufany i niezależnie weryfikowalny:
Co sprawia, że jest godny zaufania:
- PDA w łańcuchu: Twoje metadane weryfikacji są przechowywane onchain, nie kontrolowane przez żadną centralną instancję
- Dowód uprawnień do aktualizacji: Tylko organ posiadający uprawnienia do aktualizacji Twojego programu może tworzyć/aktualizować PDA
- Niezależna weryfikacja: Każdy może zweryfikować, odczytując Twoje PDA i
uruchamiając
solana-verifylokalnie - Ciągła ponowna weryfikacja: API automatycznie ponownie weryfikuje wszystkie programy co 24 godziny
Zrozum te ograniczenia:
- Weryfikacja potwierdza, że źródło odpowiada wdrożeniu – NIE że Twój kod jest bezpieczny
- Zawsze przeglądaj kod przed interakcją z programami
- Zweryfikowany ≠ poddany audytowi ani bezpieczny
- Sprawdź repozytorium i commit w PDA, aby potwierdzić, że pochodzi z zaufanego źródła
Jak mogę samodzielnie zweryfikować program?
Zweryfikuj dowolny program samodzielnie, odczytując jego PDA onchain i uruchamiając weryfikację lokalnie:
Krok 1: Odczytaj PDA w łańcuchu
# Install solana-verify if you haven'tcargo install solana-verify# Get the PDA datasolana-verify list-program-pdas --program-id YourProgramId...
Krok 2: Zweryfikuj lokalnie
# 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
To dowodzi:
- Metadane PDA są autentyczne (przechowywane onchain)
- Kod źródłowy w repozytorium PDA odpowiada wdrożonemu programowi
- Nie musisz ufać API – zweryfikuj wszystko samodzielnie onchain
Czy ktoś inny może zweryfikować mój program bez mojego pozwolenia?
Tak, właśnie dlatego wymagamy, aby podpisującym był organ posiadający uprawnienia do aktualizacji. Weryfikację uznajemy za ważną tylko wtedy, gdy podpisującym jest organ posiadający uprawnienia do aktualizacji.
Czego potrzebuję, aby tworzyć weryfikowalne kompilacje?
Zainstaluj następujące narzędzia:
- Docker (do deterministycznych kompilacji)
- Cargo (menedżer pakietów Rust)
- Solana Verify CLI:
cargo install solana-verify - Publiczne repozytorium Git z Twoim kodem źródłowym
Czy mogę weryfikować prywatne repozytoria?
Nie – weryfikacja wymaga publicznego kodu źródłowego:
- Twoje PDA przechowuje publiczny adres URL repozytorium, który jest dostępny dla każdego
- Weryfikacja bez zaufania zależy od publicznego dostępu do kodu
- Użytkownicy muszą mieć możliwość odczytu kodu źródłowego, aby zrozumieć, co robi Twój program
- Cały cel polega na tym, aby użytkownicy mogli niezależnie potwierdzić, że kod źródłowy odpowiada wdrożeniu
Prywatne repozytoria naruszają podstawowy model zaufania systemu weryfikacji.
Jak zweryfikować program kontrolowany przez Squads Multisig?
Wykonaj następujące kroki dla programów kontrolowanych przez 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...
Ważne: Zawsze weryfikuj lokalnie (krok 2), aby potwierdzić, że hash kompilacji jest zgodny zanim wyeksportujesz transakcję PDA.
Podsumowanie
Korzystanie z zweryfikowanych kompilacji na Solanie gwarantuje integralność i wiarygodność Twoich programów w sieci oraz pozwala deweloperom znaleźć Twoje SDK bezpośrednio z poziomu Solana Explorer. Wykorzystując narzędzia takie jak Solana Verify CLI i Docker, możesz utrzymywać weryfikowalne i bezpieczne kompilacje zgodne z Twoim kodem źródłowym. Zawsze stosuj niezbędne środki ostrożności, aby korzystać ze spójnych środowisk, i rozważ rozwiązania zarządcze umożliwiające bezpieczne aktualizacje i wdrożenia.
Bezpieczeństwo i zastrzeżenia
Choć zweryfikowane kompilacje są potężnym narzędziem zapewniającym integralność Twoich programów na Solanie, w domyślnej konfiguracji nie są całkowicie pozbawione elementu zaufania. Obrazy Docker są budowane i hostowane przez Solana Foundation.
Pamiętaj, że budujesz swój projekt w pobranym obrazie Docker i że cała Twoja konfiguracja jest kopiowana do tego obrazu Docker podczas budowania, łącznie z potencjalnie wrażliwymi informacjami.
Jeśli chcesz mieć całkowicie niezależną od zaufania konfigurację, możesz samodzielnie zbudować obrazy Docker i hostować je na własnej infrastrukturze. W ten sposób możesz mieć pewność, że obrazy Docker nie zostały zmodyfikowane. Skrypty do tworzenia własnych obrazów Docker znajdziesz w repozytorium Verified builds. Możesz je sforkować i samodzielnie uruchomić akcje GitHub lub sprawdzić, czy są poprawne.
Ponadto, w przypadku zdalnej weryfikacji, ufasz API OtterSec oraz Solana Explorer w pewnym stopniu.
API lub Solana Explorer może potencjalnie wyświetlać nieprawidłowe informacje, jeśli zostanie zagrożony.
Jeśli chcesz mieć całkowicie niezaufane środowisko, możesz samodzielnie
uruchomić
Verify API lub
przeprowadzić weryfikację programu lokalnie przy użyciu polecenia
verify-from-repo, korzystając z danych weryfikacyjnych on-chain zapisanych w
PDA,
który jest wyprowadzany z uprawnień do wdrożenia programu oraz
programu weryfikującego.
Program weryfikujący jest wdrożony przez zespół OtterSec i nie jest jeszcze zablokowany, więc może zostać zaktualizowany w dowolnym momencie.
Solana Foundation, OtterSec oraz zespół Ellipsis Labs nie ponoszą odpowiedzialności za żadne straty ani szkody, które mogą wyniknąć z korzystania z potoku zweryfikowanych kompilacji.
Security.txt dla programów Solana
Oprócz zweryfikowanych kompilacji możesz również dodać plik security.txt do
swojego programu. W przyszłości, po wdrożeniu, security.txt będzie
przechowywać klucz publiczny weryfikatora w celu łatwego dostępu do danych
weryfikacyjnych zapisanych w PDA weryfikacji. PDA zawierający wszystkie
informacje potrzebne do zbudowania i weryfikacji programu jest wyprowadzany z
adresu programu oraz pubkey weryfikatora. Domyślnie jest to ten sam pubkey,
który zbudował i wdrożył program. Może to być również inny pubkey, który można
określić w security.txt.
Funkcja security.txt umożliwia programistom osadzanie informacji kontaktowych
i dotyczących bezpieczeństwa bezpośrednio w ich inteligentnych kontraktach
Solana. Zainspirowana przez securitytxt.org, to
podejście zapewnia ustandaryzowany sposób dla badaczy bezpieczeństwa na kontakt
z opiekunami projektu, nawet jeśli znają tylko adres kontraktu.
Dlaczego warto używać security.txt?
W przypadku wielu projektów, szczególnie mniejszych lub prywatnych,
zidentyfikowanie programistów na podstawie samego adresu kontraktu może być
trudne i czasochłonne. Osadzenie pliku security.txt w programie zapewnia, że
badacze bezpieczeństwa mogą łatwo skontaktować się z odpowiednimi osobami, co
potencjalnie zapobiega exploitom i zapewnia terminowe zgłaszanie błędów.
Jak wdrożyć security.txt
Aby dodać security.txt do swojego programu Solana, wykonaj następujące kroki:
Dodaj zależność solana-security-txt do swojego Cargo.toml:
[dependencies]solana-security-txt = "1.1.1"
Użyj makra security_txt! w swoim kontrakcie, aby zdefiniować informacje
dotyczące bezpieczeństwa. Możesz uwzględnić dane kontaktowe, adresy URL
projektu, a nawet politykę bezpieczeństwa. Oto przykład:
#[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!"}
Po osadzeniu informacji security.txt w programie można je łatwo znaleźć za
pomocą narzędzi takich jak Solana Explorer, dzięki czemu dane kontaktowe i
informacje dotyczące bezpieczeństwa są dostępne dla każdego, kto chce zgłosić
potencjalne problemy.
Najlepsze praktyki
-
Używaj linków: W przypadku informacji, które mogą się zmieniać (np. danych kontaktowych), zaleca się linkowanie do strony internetowej zamiast kodowania ich bezpośrednio w kontrakcie. Pozwala to uniknąć konieczności częstych aktualizacji programu.
-
Weryfikacja: Przed wdrożeniem zweryfikuj format i treść za pomocą narzędzia
query-security-txt, które może walidować zarówno programy onchain, jak i lokalne pliki binarne:
query-security-txt target/bpfel-unknown-unknown/release/my_contract.so
Osadzając informacje kontaktowe dotyczące bezpieczeństwa bezpośrednio w kontrakcie, ułatwiasz badaczom nawiązanie z Tobą kontaktu, co sprzyja lepszemu bezpieczeństwu i komunikacji w ekosystemie Solana.
To jest przykład tego, jak security.txt wygląda w Solana Explorer
Projekt security.txt jest utrzymywany przez
Neodyme Labs
Możesz sprawdzić status weryfikacji i przeglądać zweryfikowane programy na verify.osec.io.
Is this page helpful?