Programme verifizieren
Dieser Leitfaden dient als Referenz für Entwickler, die verifizierte Builds für ihre Programme auf Solana implementieren möchten. Wir werden behandeln, was verifizierte Builds sind, wie man sie verwendet, besondere Überlegungen und bewährte Praktiken, um die Authentizität deines Programms in der Blockchain zu gewährleisten.
Was sind verifizierte Builds?
Verifizierte Builds stellen sicher, dass das ausführbare Programm, das du im Solana-Netzwerk bereitstellst, mit dem Quellcode in deinem Repository übereinstimmt. Dadurch können Entwickler und Nutzer darauf vertrauen, dass das in der Blockchain laufende Programm genau dem öffentlichen Codebase entspricht, was Transparenz und Sicherheit fördert.
Der Verifizierungsprozess beinhaltet den Vergleich des Hashs des Programms in der Blockchain mit dem Hash des lokal aus dem Quellcode erstellten Programms. Dies stellt sicher, dass es keine Diskrepanzen zwischen den beiden Versionen gibt.
Obwohl ein verifizierter Build nicht als sicherer als ein nicht verifizierter Build angesehen werden sollte, ermöglicht der Build Entwicklern, selbst zu überprüfen, ob der Quellcode mit dem übereinstimmt, was in der Blockchain bereitgestellt wird. Mit dem Quellcode kann ein Entwickler dann validieren, was der Code beim Senden einer Transaktion ausführt.
Die Pipeline für verifizierte Builds wurde von Ellipsis Labs und OtterSec konzipiert und wird von ihnen gepflegt. Weitere Details findest du im Leitfaden im ursprünglichen Repository für verifizierte Builds sowie im Verifizierungsprozess direkt in der Anza Tool-Suite, sobald diese dort unterstützt wird.
Wie funktioniert es?
Der Verifizierungsprozess erfolgt durch den Vergleich des Hashs des Onchain-Programms mit dem Hash des lokal erstellten Programms aus dem Quellcode. Du erstellst dein Programm in einer kontrollierten Umgebung mit der Solana Verify CLI und Docker. Dies stellt sicher, dass der Build-Prozess deterministisch und konsistent über verschiedene Systeme hinweg ist. Sobald du die ausführbare Datei hast, kannst du sie im Solana-Netzwerk bereitstellen. Während des Build-Prozesses wird ein PDA des Verify-Programms erstellt. Dieser PDA enthält alle notwendigen Daten zur Verifizierung des Programms. Der PDA enthält die Programm-Adresse, Git-URL, Commit-Hash und die Argumente, die zum Erstellen des Programms verwendet wurden.
Mit den Daten im PDA kann jeder den Verify-Programmbefehl lokal ausführen und überprüfen, ob das Programm aus dem bereitgestellten Quellcode erstellt wurde. Dann kann jeder selbst vollständig vertrauenslos verifizieren oder seine eigene Verify-API betreiben, die von OtterSec gepflegt wird, um einen einfachen Zugriffspunkt für Benutzer zur Überprüfung der Verifizierung bereitzustellen. Du kannst diese API-Aufrufe bereits im Solana Explorer und SolanaFM unter anderem sehen.
Warum sollte ich verifizierte Builds verwenden?
Die Verwendung verifizierter Builds bietet folgende Vorteile:
-
Sicherheit: Garantie, dass das onchain laufende Programm mit dem Quellcode übereinstimmt und bösartige Änderungen verhindert werden.
-
Transparenz: Ermöglicht anderen Benutzern und Entwicklern zu validieren, dass das Onchain- Programm vertrauenswürdig ist, indem sie es mit der öffentlichen Codebasis vergleichen.
-
Vertrauen: Erhöht das Vertrauen der Benutzer, da verifizierte Builds zeigen, dass das Onchain-Verhalten deines Programms mit deinem öffentlichen Code übereinstimmt. Beim Erstellen verifizierbarer Programme minimierst du Risiken im Zusammenhang mit der Ausführung nicht autorisierter oder bösartiger Codes. Es stellt auch sicher, dass du bewährte Praktiken einhältst und Sicherheitsforschern einen einfachen Weg bietest, dich zu kontaktieren. Auch Wallets und andere Tools können Transaktionen von deinem Programm leichter zulassen, solange es verifiziert ist.
-
Auffindbarkeit: Wenn Sie einen verifizierten Build Ihres Programms bereitstellen, kann jeder Ihren Quellcode, Dokumentation, Programm-SDK oder IDL finden und Sie auch einfach über GitHub kontaktieren, falls es ein Problem gibt.
Wie erstelle ich verifizierte Builds?
Um verifizierte Builds zu erstellen, müssen Sie diese Schritte befolgen:
Zusammenfassung:
- Commiten Sie Ihren Code in ein öffentliches Repository
- Erstellen Sie einen verifizierten Build in Docker
- Deployen Sie den verifizierten Build
- Verifizieren Sie das bereitgestellte Programm über die öffentliche API
Wenn Sie Ihr Programm verifizieren, das nicht in einem Docker-Container gebaut wurde, wird es höchstwahrscheinlich fehlschlagen, da Solana-Programm-Builds nicht deterministisch über verschiedene Systeme hinweg sind.
Docker und Cargo installieren
Installieren Sie die notwendigen Tools und stellen Sie sicher, dass Docker und Cargo installiert sind. Docker bietet eine kontrollierte Build-Umgebung, um Konsistenz zu gewährleisten, und Cargo wird für die Verwaltung von Rust-Paketen verwendet.
- Docker: Folgen Sie den Schritten auf der Docker-Website, um Docker für Ihre Plattform zu installieren. Stellen Sie nach der Installation sicher, dass der Docker-Dienst läuft, indem Sie dieser Anleitung weiter folgen.
- Cargo: Wenn Sie Cargo noch nicht installiert haben, können Sie es installieren, indem Sie den folgenden Befehl ausführen:
curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
Die Solana Verify CLI installieren
Die Solana Verify CLI ist das Hauptwerkzeug zur Verifizierung von Builds. Die Solana Verify CLI wird derzeit von Ellipsis Labs gepflegt und kann mit Cargo installiert werden.
Sie können sie installieren, indem Sie Folgendes ausführen:
cargo install solana-verify
Wenn Sie eine bestimmte Version der CLI benötigen, können Sie die Version festlegen mit:
cargo install solana-verify --version $VERSION
Bei Bedarf können Sie eine Version direkt von einem bestimmten Commit installieren:
cargo install solana-verify --git https://github.com/Ellipsis-Labs/solana-verifiable-build --rev 13a1db2
Projekt vorbereiten
Um gegen ein Repository zu verifizieren, muss es eine Cargo.lock
Datei im
Hauptverzeichnis deines Repositories haben. Wenn du nur ein Programm in deinem
Repository hast und eine cargo.lock
Datei in deinem Hauptverzeichnis, kannst
du direkt zum nächsten Schritt gehen und dein Programm bauen.
Wenn dein Programm in einem Unterordner ist und du einen Rust-Workspace hast,
musst du eine Workspace Cargo.toml
Datei im Hauptverzeichnis deines
Repositories erstellen.
Du kannst dieses Cargo.toml
Beispiel als Vorlage verwenden:
[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
Stelle sicher, dass dein Programm im workspace/members
Array ist und dass die
Cargo.toml
deines Programms den korrekten lib
Namen konfiguriert hat.
Wichtig ist der
lib name
und nicht der Paketname!
So etwa:
[package]name = "waffle"version = "0.1.0"edition = "2021"[lib]name = "waffle"crate-type = ["cdylib", "lib"][dependencies]solana-program = "2.1.0"
In diesem Repository
kannst du ein Beispiel für einen Workspace mit einem Programm in einem
Unterordner sehen. Beachte auch, dass wenn das Programm in einem Unterordner
ist, du später diesen Ordner als --mount-path
zum verify-from-repo
Befehl
hinzufügen musst.
In diesem Repository findest du ein Anchor-Beispiel. In diesem Repository findest du ein natives Rust-Beispiel.
Mit dieser Cargo.toml
Datei kannst du dann cargo generate-lockfile
ausführen, um eine Lock-Datei zu erstellen und mit dem Bauen deines Programms
fortzufahren.
Verifizierbare Programme bauen
Um dein Solana-Programm verifizierbar zu bauen, navigiere zum Verzeichnis, das
die Cargo.toml
Datei deines Workspaces enthält, und führe aus:
solana-verify build
Dies kopiert deine Umgebung in einen Docker-Container und baut sie auf deterministische Weise.
Stelle sicher, dass du tatsächlich den verifizierten Build bereitstellst und ihn nicht versehentlich mit
anchor build
odercargo build-sbf
überschreibst, da diese höchstwahrscheinlich nicht zum gleichen Hash führen und daher deine Verifizierung fehlschlagen wird.
Für Projekte mit mehreren Programmen können Sie ein bestimmtes Programm mithilfe des Bibliotheksnamens (nicht des Paketnamens) erstellen:
solana-verify build --library-name $PROGRAM_LIB_NAME
Dieser Prozess gewährleistet deterministische Builds und kann einige Zeit in Anspruch nehmen, besonders auf bestimmten Systemen (z.B. M1 MacBook), da er in einem Docker- Container ausgeführt wird. Für schnellere Builds wird die Verwendung eines Linux-Rechners mit x86-Architektur empfohlen.
Sobald der Build abgeschlossen ist, können Sie den Hash der ausführbaren Datei mit dem folgenden Befehl abrufen:
solana-verify get-executable-hash target/deploy/$PROGRAM_LIB_NAME.so
Deployment verifizierbarer Programme
Sobald Sie Ihr Programm erstellt und dessen Hash abgerufen haben, können Sie es im Solana-Netzwerk deployen. Es wird empfohlen, eine Multi-Signatur- oder Governance- Lösung wie Squads Protocol für sichere Deployments zu verwenden, aber Sie können auch direkt deployen mit:
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
Eine derzeit passende niedrige priority fee können Sie von Ihrem RPC-Provider anfordern, zum Beispiel Quicknode.
Um zu überprüfen, ob das deployete Programm mit der erstellten ausführbaren Datei übereinstimmt, führen Sie aus:
solana-verify get-program-hash -u $NETWORK_URL $PROGRAM_ID
Sie können verschiedene Versionen auf verschiedenen Solana-Clustern (d.h. devnet, testnet, mainnet) deployen. Stellen Sie sicher, dass Sie die korrekte Netzwerk-URL für den gewünschten Solana-Cluster verwenden, gegen den Sie ein Programm verifizieren möchten. Die Remote-Verifizierung funktioniert nur im Mainnet.
Verifizierung gegen Repositories
Um ein Programm gegen sein öffentliches Repository zu verifizieren, verwenden Sie:
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
Während Sie den verifizierten Build in Ihrem Programmverzeichnis ausführen, müssen Sie beim Ausführen von
verify-from-repo
das Flag--mount-path
hinzufügen. Dies ist der Pfad zum Ordner, der dieCargo.toml
enthält, die den Bibliotheksnamen Ihres Programms enthält.
Dieser Befehl vergleicht den Onchain-Programm-Hash mit dem ausführbaren Hash, der aus dem Quellcode am angegebenen Commit-Hash erstellt wurde.
Am Ende fragt der Befehl, ob du deine Verifizierungsdaten onchain hochladen möchtest. Wenn du das tust, wird der Solana Explorer sofort die Verifizierungsdaten deines Programms anzeigen. Bis es durch einen Remote-Build verifiziert wurde, wird es als unverifiziert angezeigt. Im nächsten Schritt erfährst du, wie du dein Programm gegen eine öffentliche API verifizieren kannst.
Wenn du die Verifizierung an eine bestimmte Version binden möchtest, kannst du
das --commit-hash
Flag zum Befehl hinzufügen.
Gegen öffentliche API verifizieren
Schließlich kannst du das Programm auch direkt gegen jeden verifizieren, der die Verify-API ausführt:
solana-verify verify-from-repo --remote -um --program-id PhoeNiXZ8ByJGLkxNfZRnkUfjvmuYqLR89jjFHGqdXY https://github.com/Ellipsis-Labs/phoenix-v1
Es wird empfohlen, eine kostenpflichtige RPC-URL zu verwenden, da du sonst auf Ratenbegrenzungen der kostenlosen RPCs stoßen könntest. Anstelle von
-um
solltest du--url yourRpcUrl
für eine zuverlässigere Verifizierung verwenden.
Das --remote
Flag sendet eine Build-Anfrage an die OtterSec-API, die einen
Remote-Build deines Programms auslöst. Sobald der Build abgeschlossen ist,
überprüft das System, ob der Onchain-Hash deines Programms mit dem Hash des
generierten Build- Artifakts aus deinem Repository übereinstimmt.
Der Standard ist die OtterSec API.
Achte darauf, "Ja" zu wählen, wenn du gefragt wirst, ob du die Verifizierungsdaten onchain hochladen möchtest. Dies wird von der API verwendet, um zu überprüfen, dass du die Verifizierungsdaten hochgeladen hast.
Du kannst auch manuell einen Remote-Job auslösen mit:
solana-verify remote submit-job --program-id <program-id> --uploader <address>
Wobei der Uploader die Adresse ist, die die Berechtigung hat, in die PDA zu schreiben. Das sollte in den meisten Fällen die Programmberechtigung sein. Wenn Ihr Programm von einem Multisig kontrolliert wird, fahren Sie bitte im Multisig-Verifizierungsteil dieser Anleitung unten fort.
Dies wird einen Job an die OtterSec API übermitteln und Sie können dann den Job-Status überprüfen mit:
solana-verify remote get-job-status --job-id <job-id>
Sobald die Verifizierung erfolgreich abgeschlossen ist, was einige Zeit dauern kann, wird Ihr Programm als verifiziert angezeigt in der OtterSec API für einzelne Programme und im Solana Explorer, SolanaFM, SolScan und schließlich auch auf der von der Community betriebenen Website SolanaVerify.org, die von 0xDeep gepflegt wird, sowie in der OtterSec verified programs API und zuletzt im Verified Programs Dune Dashboard, was zu einem gesünderen Solana-Ökosystem beiträgt.
Wie man sein Programm verifiziert, wenn es von einem Multisig wie Squads kontrolliert wird
Damit die Remote-Verifizierung funktioniert, müssen Sie die Verifizierungsdaten in eine PDA schreiben, die von der Programmberechtigung signiert ist. Wenn Ihr Programm von einem Multisig kontrolliert wird, können Sie diese PDA-Schreibtransaktion exportieren und über Squads Protocol oder eine andere Multisig-Lösung Ihrer Wahl einreichen.
1. Das verifizierbare Programm erstellen
Erstellen Sie zunächst das Programm:
solana-verify build
Dies erstellt einen verifizierbaren Build mit einem Docker-Container unter
Verwendung der Solana-Version, die in der Cargo.lock
Datei angegeben ist.
2. Das Programm bereitstellen
solana config set --url "PayedMainnetRPCAddress" // the public endpoint will be rate limited too muchsolana program deploy target/deploy/verify_squads.so
Für den Rest dieser Multisig-Anleitung verwenden wir eine Beispiel-Programm-ID
von 6XBGfP17P3KQAKoJb2s5M5fR4aFTXzPeuC1af2GYkvhD
.
3. Commit und Verifizierung gegen Repository
Sobald das erledigt ist, committen wir das Projekt zu GitHub. Hier ist ein Beispiel: https://github.com/solana-developers/verify-squads
Optional: Prüfen Sie, ob Sie zuerst lokal verifizieren können (dieser Befehl
verwendet eine Beispiel-Programm-ID
6XBGfP17P3KQAKoJb2s5M5fR4aFTXzPeuC1af2GYkvhD
):
solana-verify verify-from-repo https://github.com/solana-developers/verify-squads --program-id 6XBGfP17P3KQAKoJb2s5M5fR4aFTXzPeuC1af2GYkvhD
Nur um sicherzustellen, dass Ihre Parameter korrekt sind.
4. Übertragen der Programmautorität an die Multisig
Falls Sie die Autorität Ihres Programms noch nicht an die Multisig übertragen haben, kopieren Sie die Multisig-Autorität. Sie benötigen sie im nächsten Schritt.
5. PDA-Transaktion exportieren
Wenn Sie Ihre Programmautorität lokal haben, werden Sie aufgefordert, die
Build-Daten onchain hochzuladen, wenn Sie den Befehl
solana-verify verify-from-repo
verwenden.
Da Sie dies nicht tun können, wenn Sie eine Multisig verwenden, müssen Sie die PDA-Transaktion manuell exportieren und dann die Transaktion über Squads auslösen.
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
Dies gibt Ihnen eine base58-codierte Transaktion zurück. Wenn Sie eine
base64-codierte Transaktion für die Verwendung in einem Transaktions-Inspector
wünschen, können Sie --encoding base64
verwenden.
P6vBfcPaaXb8fZoT3NBAYEcdtEj7tubA1k2gBxmFKZ3UWF5YyrmDMFTvLKALCJoUuRsPAjMckudYruCu3eeWQtuDrFbEMLxLFutnKXac974fnkMivcwUdY66VLjbxQT6ATmcy7F4hBtz1G4P1h6iBJLhb8WtrtgY3i4qq45MUEb7RjuMEfUFXKrNgPdGxkz5xvMHq3dxKRcpmEK5k2DkeW6SUQYBVe19Ga3B9GyhTX8k3CMt9JCEah13WyRnQd8GjoK6sTEvGJym6xDNvmd8yiJYSNcaYwEJsjHEUf4Yh6kAC7ki2KRvVAr3NVe1gjqK9McrwSQjtUatvydTG8Zovcr7PPUEMf3yPMgKXjZLB2QpkH63yTTYdNAnWFuv9E6b6nYRqye5XcNi436yKw5U14fXh65yK34bgYLi9328UT1huJELsJU9BRGnGUmb6GWp6c2WL5BhnzgNTSnt9TXFfEgUMzhvKzpVBxLP44hwqqBdyUhHFysCF37531PnmiESq8x1xou23xJ6FcQbc199754MkqQd7tX9CUznGzAEqHGkzn3VBoJnojsKtgYmiTYbdRsT1CU18MbYEE7WvGAvXyxxbpNzbAcc94HrnM6cqRGmwhEBroPfFghTdmzg9D
6. Transaktion über Squads einreichen
Gehen Sie zum Squads-Transaktionsbuilder und importieren Sie die base58-codierte Transaktion. Stellen Sie sicher, dass in der Simulation die Transaktion nur einen Aufruf an das Osec-Verify-Programm und das Computer-Budget-Programm enthält und nichts anderes!
7. Remote-Verifizierungsauftrag einreichen
Sobald die Transaktion an Squads erfolgreich war, können Sie den Remote-Auftrag einreichen:
solana-verify remote submit-job --program-id 6XBGfP17P3KQAKoJb2s5M5fR4aFTXzPeuC1af2GYkvhD--uploader <your program authority>
Das war's! Sie haben Ihr Programm gegen ein öffentliches Repository verifiziert und einen Remote-Auftrag an die OtterSec-API gesendet. Sie sollten es jetzt im Solana Explorer und an anderen Stellen sehen können.
8. Aktualisieren des Programms (Optional)
Wenn Sie Ihr Programm aktualisieren, müssen Sie eine neue PDA-Transaktion exportieren und diese erneut über Squads einreichen.
So führen Sie eine Aktualisierung des Programms durch:
solana-verify buildsolana program write-buffer target/deploy/verify_squads.so --with-compute-unit-price 50000 --max-sign-attempts 50
Übertragen Sie dann die Buffer-Autorität an die Multisig oder erstellen Sie den Buffer direkt mit der Autorität der Multisig.
solana program set-buffer-authority Fu3k79g53ZozAj47uq1tXrFy4QbQYh7y745DDsxjtyLR --new-buffer-authority 3JG6ULvZVCrkKtSSskKNJGe8RNZGFe8Ruev9KUhxzK5K
9. Exportieren und Einreichen einer neuen PDA-Transaktion
Vergessen Sie nicht, Ihre Änderungen auf GitHub zu übertragen. Exportieren Sie die PDA-Upgrade-Transaktion erneut:
solana-verify export-pda-tx https://github.com/solana-developers/verify-squads --program-id 6XBGfP17P3KQAKoJb2s5M5fR4aFTXzPeuC1af2GYkvhD --uploader 3JG6ULvZVCrkKtSSskKNJGe8RNZGFe8Ruev9KUhxzK5K
Reichen Sie die Transaktion erneut über Squads ein.
Ein Beispiel für eine Transaktion finden Sie hier.
Reichen Sie dann einen weiteren Remote-Build ein:
solana-verify remote submit-job --program-id 6XBGfP17P3KQAKoJb2s5M5fR4aFTXzPeuC1af2GYkvhD --uploader 3JG6ULvZVCrkKtSSskKNJGe8RNZGFe8Ruev9KUhxzK5K
Das Ergebnis sollte etwa so aussehen:
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 on-chain 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
Herzlichen Glückwunsch, Sie haben Ihr Programm nach einem Multisig-Upgrade verifiziert!
Verifizierung über Docker-Image
Sie können Ihr Programm auch gegen ein Docker-Image verifizieren, indem Sie den folgenden Befehl ausführen:
solana-verify verify-from-image -eexamples/hello_world/target/deploy/hello_world.so -iellipsislabs/hello_world_verifiable_build:latest -p2ZrriTQSVekoj414Ynysd48jyn4AX6ZF4TTJRqHfbJfn
Dieser Befehl lädt das unter ellipsislabs/hello_world_verifiable_build:latest
gespeicherte Image und überprüft, ob der Hash des ausführbaren Pfads im
Container mit dem Hash des On-Chain-Programms übereinstimmt, das dem Befehl
übergeben wurde. Da der Build bereits in ein Image hochgeladen wurde, ist kein
vollständiger Neuaufbau der ausführbaren Datei erforderlich, was viel Zeit
sparen kann.
Das Dockerfile, das das Image ellipsislabs/hello_world_verifiable_build:latest
erstellt, finden Sie im Ellipsis Labs Repository
/examples/hello_world.
Unten sehen Sie die erwartete Ausgabe:
Verifying image: "ellipsislabs/hello_world_verifiable_build:latest", on network"https://api.mainnet-beta.solana.com" against program ID2ZrriTQSVekoj414Ynysd48jyn4AX6ZF4TTJRqHfbJfn Executable path in container:"examples/hello_world/target/deploy/hello_world.so"Executable hash:08d91368d349c2b56c712422f6d274a1e8f1946ff2ecd1dc3efc3ebace52a760 Program hash:08d91368d349c2b56c712422f6d274a1e8f1946ff2ecd1dc3efc3ebace52a760 Executablematches on-chain program data ✅
Beispiel eines verifizierten Builds
Hier ist ein Beispiel für die Verifizierung eines Beispielprogramms mit der ID
FWEYpBAf9WsemQiNbAewhyESfR38GBBHLrCaU3MpEKWv
unter Verwendung des Quellcodes
aus diesem Repository:
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
Standardmäßig verwendet der Befehl verify-from-repo
den letzten Commit im main
Branch. Du kannst auch einen bestimmten Commit definieren, falls du weiter am
Repository arbeiten möchtest, indem du den Parameter commit-hash
verwendest:
--commit-hash 5b82b86f02afbde330dff3e1847bed2d42069f4e
Schließlich kannst du das Programm auch direkt gegen die OtterSec API verifizieren:
solana-verify verify-from-repo https://github.com/solana-developers/verified-program --url YOUR-RPC-URL --remote --program-id FWEYpBAf9WsemQiNbAewhyESfR38GBBHLrCaU3MpEKWv --mount-path waffle --library-name waffle --commit-hash 5b82b86f02afbde330dff3e1847bed2d42069f4e
Der Befehl --remote
sendet eine Build-Anfrage an die OtterSec API, die einen
Remote-Build deines Programms auslöst. Sobald der Build abgeschlossen ist,
überprüft das System, ob der Onchain-Hash deines Programms mit dem Hash des
generierten Build- Artifakts aus deinem Repository übereinstimmt.
Beliebte Programme, die bereits verifiziert sind
Phoenix
solana-verify verify-from-repo -um --program-id PhoeNiXZ8ByJGLkxNfZRnkUfjvmuYqLR89jjFHGqdXY https://github.com/Ellipsis-Labs/phoenix-v1
Endgültiges Ergebnis:
Executable Program Hash from repo: 6877a5b732b3494b828a324ec846d526d962223959534dbaf4209e0da3b2d6a9On-chain 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
Beachte, dass wir
library-name
angeben mussten, da das Squads-Repository mehrere Programme enthält. Wir verwenden den Flag--bpf
, weilsquads_mpl
zuvor mit Anchor verifiziert wurde.
Endgültiges Ergebnis:
Executable Program Hash from repo: 72da599d9ee14b2a03a23ccfa6f06d53eea4a00825ad2191929cbd78fb69205cOn-chain 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
Endgültiges Ergebnis:
Executable Program Hash from repo: e31d58edeabc3c30bf6f2aa60bfaa5e492b41ec203e9006404b463e5adee5828On-chain 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
Endgültiges Ergebnis:
Executable Program Hash from repo: 890d68f48f96991016222b1fcbc2cc81b8ef2dcbf280c44fe378c523c108fad5On-chain Program Hash: 890d68f48f96991016222b1fcbc2cc81b8ef2dcbf280c44fe378c523c108fad5Program hash matches ✅
Fazit
Die Verwendung von verifizierten Builds auf Solana gewährleistet die Integrität und Vertrauenswürdigkeit Ihrer Programme im Netzwerk und ermöglicht Entwicklern, Ihre SDKs direkt über den Solana Explorer zu finden. Durch den Einsatz von Tools wie Solana Verify CLI und Docker können Sie überprüfbare und sichere Builds erstellen, die mit Ihrem Quellcode übereinstimmen. Treffen Sie stets die notwendigen Vorkehrungen, um konsistente Umgebungen zu nutzen, und erwägen Sie Governance- Lösungen für sichere Upgrades und Deployments.
Sicherheit + Haftungsausschluss
Obwohl verifizierte Builds ein leistungsstarkes Werkzeug zur Gewährleistung der Integrität Ihrer Solana-Programme sind, ist die Standardeinrichtung nicht vollständig vertrauenslos. Die Docker- Images werden von der Solana Foundation erstellt und gehostet.
Beachten Sie, dass Sie Ihr Projekt in einem heruntergeladenen Docker-Image bauen und dass Ihre gesamte Einrichtung einschließlich potenziell sensibler Informationen in dieses Docker-Image kopiert wird.
Wenn Sie eine vollständig vertrauenslose Einrichtung wünschen, können Sie die Docker-Images selbst erstellen und auf Ihrer eigenen Infrastruktur hosten. So können Sie sicherstellen, dass die Docker-Images nicht manipuliert wurden. Die Skripte zum Erstellen Ihrer eigenen Docker-Images finden Sie im Verified Builds Repository. Sie können es forken und die GitHub Actions selbst ausführen oder überprüfen, ob sie korrekt sind.
Darüber hinaus vertrauen Sie bei der Remote-Verifizierung der OtterSec API und dem Solana Explorer bis zu einem gewissen Grad.
Die API oder der Solana Explorer könnten möglicherweise falsche Informationen anzeigen, wenn sie kompromittiert werden.
Wenn Sie eine vollständig vertrauenslose Einrichtung wünschen, können Sie die
Verify API selbst
betreiben oder die Programmverifizierung lokal mit dem Befehl verify-from-repo
durchführen, wobei die On-Chain-Verifizierungsdaten verwendet werden, die in
einem
PDA
gespeichert sind, der von der Deploy-Autorität des Programms und dem
Verify-Programm
abgeleitet wird.
Das Verifizierungsprogramm wird vom OtterSec-Team bereitgestellt und ist noch nicht eingefroren, sodass es jederzeit aktualisiert werden kann.
Die Solana Foundation, OtterSec und das Ellipsis Labs-Team sind nicht verantwortlich für Verluste oder Schäden, die durch die Nutzung der Pipeline für verifizierte Builds entstehen können.
Security.txt für Solana-Programme
Zusätzlich zu verifizierten Builds können Sie auch eine security.txt
Datei zu
Ihrem Programm hinzufügen. In Zukunft wird die security.txt
, sobald
implementiert, den öffentlichen Schlüssel des Verifizierers für einfachen
Zugriff auf die in der Verifizierungs-PDA gespeicherten Daten enthalten. Die
PDA, die alle Informationen enthält, die zum Erstellen und Verifizieren eines
Programms benötigt werden, wird aus der Programmadresse und dem
Verifizierer-pubkey abgeleitet. Standardmäßig ist dies derselbe pubkey, der das
Programm erstellt und bereitgestellt hat. Es kann aber auch ein anderer pubkey
sein, der in der security.txt
angegeben werden kann.
Die security.txt
Funktion ermöglicht es Entwicklern, Kontakt- und
Sicherheitsinformationen direkt in ihre Solana-Smart-Contracts einzubetten.
Inspiriert von securitytxt.org bietet dieser Ansatz
einen standardisierten Weg für Sicherheitsforscher, um Projektbetreuer zu
kontaktieren, selbst wenn sie nur die Adresse des Vertrags kennen.
Warum security.txt verwenden?
Für viele Projekte, besonders kleinere oder private, kann die Identifizierung
der Entwickler anhand der Vertragsadresse schwierig und zeitaufwändig sein. Die
Einbettung einer security.txt
Datei im Programm stellt sicher, dass
Sicherheitsforscher leicht die richtigen Personen kontaktieren können, was
potenzielle Exploits verhindern und zeitnahe Fehlerberichte gewährleisten kann.
Wie man security.txt implementiert
Um eine security.txt
zu Ihrem Solana-Programm hinzuzufügen, führen Sie die
folgenden Schritte aus:
Fügen Sie die solana-security-txt
Abhängigkeit zu Ihrer Cargo.toml
hinzu:
[dependencies]solana-security-txt = "1.1.1"
Verwenden Sie das security_txt!
Makro in Ihrem Vertrag, um Ihre
Sicherheitsinformationen zu definieren. Sie können Kontaktdaten, Projekt-URLs
und sogar eine Sicherheitsrichtlinie einschließen. Hier ein Beispiel:
#[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!"}
Sobald die security.txt
Informationen in Ihrem Programm eingebettet sind,
können sie leicht über Tools wie den Solana Explorer abgefragt werden, wodurch
sichergestellt wird, dass Ihre Kontakt- und Sicherheitsdetails für jeden
verfügbar sind, der potenzielle Probleme melden möchte.
Best practices
-
Links verwenden: Für Informationen, die sich wahrscheinlich ändern werden (z.B. Kontaktdaten), wird empfohlen, auf eine Webseite zu verlinken, anstatt sie direkt in den Vertrag einzubinden. Dies vermeidet die Notwendigkeit häufiger Programm-Upgrades.
-
Verifizierung: Überprüfen Sie vor der Bereitstellung das Format und den Inhalt mit dem
query-security-txt
Tool, das sowohl Onchain-Programme als auch lokale Binärdateien validieren kann:
query-security-txt target/bpfel-unknown-unknown/release/my_contract.so
Durch das Einbetten von Sicherheitskontaktinformationen direkt in Ihren Vertrag erleichtern Sie es Forschern, Sie zu erreichen, was eine bessere Sicherheit und Kommunikation innerhalb des Solana-Ökosystems fördert.
Dies ist ein Beispiel dafür, wie security.txt im Solana Explorer aussieht
Das security.txt
Projekt wird von
Neodyme Labs gepflegt
Is this page helpful?