Dieser Leitfaden dient als Referenz für Entwickler, die verifizierte Builds für ihre Programme auf Solana implementieren möchten. Wir behandeln, was verifizierte Builds sind, wie man sie verwendet, besondere Überlegungen und Best Practices, um die Authentizität Ihres Programms onchain sicherzustellen.

Was sind verifizierte Builds?

Verifizierte Builds stellen sicher, dass das ausführbare Programm, das Sie im Solana-Netzwerk bereitstellen, mit dem Quellcode in Ihrem Repository übereinstimmt. Dadurch können Entwickler und Benutzer darauf vertrauen, dass das onchain ausgeführte Programm genau der öffentlichen Codebasis entspricht, was Transparenz und Sicherheit fördert.

Der Verifizierungsprozess umfasst den Vergleich des Hashs des Onchain-Programms mit dem Hash des lokal aus dem Quellcode erstellten Programms. Dies stellt sicher, dass keine Diskrepanzen zwischen den beiden Versionen bestehen.

Obwohl ein verifizierter Build nicht als sicherer als ein nicht verifizierter Build betrachtet werden sollte, ermöglicht der Build Entwicklern, selbst zu überprüfen, ob der Quellcode mit dem übereinstimmt, was onchain bereitgestellt wurde. Mithilfe des Quellcodes 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 diesen gepflegt. Weitere Details finden Sie im Leitfaden im ursprünglichen Repository für verifizierte Builds sowie den Verifizierungsprozess direkt in der Anza-Toolsuite, sobald dies dort unterstützt wird.

Wie funktioniert es?

Der Verifizierungsprozess erfolgt durch den Vergleich des Hashs des Onchain-Programms mit dem Hash des lokal aus dem Quellcode erstellten Programms. Du erstellst dein Programm in einer kontrollierten Umgebung mithilfe der Solana Verify CLI und Docker. Dies stellt sicher, dass der Build-Prozess deterministisch und über verschiedene Systeme hinweg konsistent ist. Sobald du die ausführbare Datei hast, kannst du sie im Solana-Netzwerk deployen. Während des Build-Prozesses wird ein PDA des Verify-Programms erstellt. Dieser PDA enthält alle Daten, die zur Verifizierung des Programms erforderlich sind. Der PDA enthält die Programmadresse, die Git-URL, den Commit-Hash und die Argumente, die zum Erstellen des Programms verwendet wurden.

Mithilfe der 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 vollständig vertrauenslos selbst verifizieren oder eine eigene Verify-API betreiben, die von OtterSec gepflegt wird, um Nutzern einen einfachen Zugangspunkt zur Überprüfung der Verifizierung zu bieten. Du kannst diese API-Aufrufe bereits im Solana Explorer und auf SolanaFM sowie an anderen Stellen in Verwendung sehen.

Warum sollte ich verifizierte Builds verwenden?

Die Verwendung verifizierter Builds bietet folgende Vorteile:

• Sicherheit: Garantiert, dass das Onchain laufende Programm mit dem Quellcode übereinstimmt und verhindert böswillige Änderungen.

• Transparenz: Ermöglicht es anderen Nutzern und Entwicklern zu validieren, dass das Onchain-Programm vertrauenswürdig ist, indem sie es mit der öffentlichen Codebasis vergleichen.

• Vertrauen: Erhöht das Nutzervertrauen, da verifizierte Builds demonstrieren, dass das Onchain-Verhalten deines Programms mit deinem öffentlichen Code übereinstimmt. Beim Erstellen verifizierbarer Programme minimierst du Risiken, die mit der Ausführung nicht autorisierter oder bösartiger Programme verbunden sind. Es stellt außerdem sicher, dass du Best Practices einhältst und Sicherheitsforschern eine einfache Möglichkeit gibst, 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, Ihre Dokumentation, Ihr Programm-SDK oder IDL finden und Sie können auch einfach über GitHub kontaktiert werden, falls es ein Problem gibt.

Wie erstelle ich verifizierte Builds?

Um verifizierte Builds zu erstellen, müssen Sie diese Schritte befolgen:

Zusammenfassung:

• Committen Sie Ihren Code in ein öffentliches Repository
• Erstellen Sie einen verifizierten Build in Docker
• Deployen Sie den verifizierten Build
• Verifizieren Sie das deployete Programm gegen die öffentliche API

Wenn Sie Ihr Programm verifizieren, das nicht in einem Docker-Container erstellt wurde, wird es höchstwahrscheinlich fehlschlagen, da Solana-Programm-Builds nicht deterministisch über verschiedene Systeme hinweg sind.

curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh

cargo install solana-verify

cargo install solana-verify --version $VERSION

cargo install solana-verify --git https://github.com/Ellipsis-Labs/solana-verifiable-build --rev 13a1db2

[workspace]
members = ["program/programs/*"]
resolver = "2"

[profile.release]
overflow-checks = true
lto = "fat"
codegen-units = 1

[profile.release.build-override]
opt-level = 3
incremental = false
codegen-units = 1

[package]
name = "waffle"
version = "0.1.0"
edition = "2021"

[lib]
name = "waffle"
crate-type = ["cdylib", "lib"]

[dependencies]
solana-program = "2.1.0"

solana-verify build

solana-verify build --library-name $PROGRAM_LIB_NAME

solana-verify get-executable-hash target/deploy/$PROGRAM_LIB_NAME.so

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

solana-verify get-program-hash -u $NETWORK_URL $PROGRAM_ID

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

solana-verify verify-from-repo --remote -um --program-id PhoeNiXZ8ByJGLkxNfZRnkUfjvmuYqLR89jjFHGqdXY https://github.com/Ellipsis-Labs/phoenix-v1

solana-verify remote submit-job --program-id <program-id> --uploader <address>

solana-verify remote get-job-status --job-id <job-id>

So verifizieren Sie Ihr Programm, wenn es von einer 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 einer Multisig kontrolliert wird, können Sie diese Write-PDA-Transaktion exportieren und über Squads Protocol oder eine andere Multisig-Lösung Ihrer Wahl einreichen.

solana-verify build

solana config set --url "PayedMainnetRPCAddress" // the public endpoint will be rate limited too much
solana program deploy target/deploy/verify_squads.so

solana-verify verify-from-repo https://github.com/solana-developers/verify-squads --program-id 6XBGfP17P3KQAKoJb2s5M5fR4aFTXzPeuC1af2GYkvhD

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

P6vBfcPaaXb8fZoT3NBAYEcdtEj7tubA1k2gBxmFKZ3UWF5YyrmDMFTvLKALCJoUuRsPAjMckudYruCu3eeWQtuDrFbEMLxLFutnKXac974fnkMivcwUdY66VLjbxQT6ATmcy7F4hBtz1G4P1h6iBJLhb8WtrtgY3i4qq45MUEb7RjuMEfUFXKrNgPdGxkz5xvMHq3dxKRcpmEK5k2DkeW6SUQYBVe19Ga3B9GyhTX8k3CMt9JCEah13WyRnQd8GjoK6sTEvGJym6xDNvmd8yiJYSNcaYwEJsjHEUf4Yh6kAC7ki2KRvVAr3NVe1gjqK9McrwSQjtUatvydTG8Zovcr7PPUEMf3yPMgKXjZLB2QpkH63yTTYdNAnWFuv9E6b6nYRqye5XcNi436yKw5U14fXh65yK34bgYLi9328UT1huJELsJU9BRGnGUmb6GWp6c2WL5BhnzgNTSnt9TXFfEgUMzhvKzpVBxLP44hwqqBdyUhHFysCF37531PnmiESq8x1xou23xJ6FcQbc199754MkqQd7tX9CUznGzAEqHGkzn3VBoJnojsKtgYmiTYbdRsT1CU18MbYEE7WvGAvXyxxbpNzbAcc94HrnM6cqRGmwhEBroPfFghTdmzg9D

solana-verify remote submit-job --program-id 6XBGfP17P3KQAKoJb2s5M5fR4aFTXzPeuC1af2GYkvhD
--uploader <your program authority>

solana-verify build
solana 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

solana-verify export-pda-tx https://github.com/solana-developers/verify-squads --program-id 6XBGfP17P3KQAKoJb2s5M5fR4aFTXzPeuC1af2GYkvhD --uploader 3JG6ULvZVCrkKtSSskKNJGe8RNZGFe8Ruev9KUhxzK5K

solana-verify remote submit-job --program-id 6XBGfP17P3KQAKoJb2s5M5fR4aFTXzPeuC1af2GYkvhD --uploader 3JG6ULvZVCrkKtSSskKNJGe8RNZGFe8Ruev9KUhxzK5K

Verification request sent with request id: b63339d2-163e-49ac-b55d-3454c1c2b5b3
Verification in progress... ⏳ [00:18:02] ✅ Process completed. (Done in 18
minutes) Program 6XBGfP17P3KQAKoJb2s5M5fR4aFTXzPeuC1af2GYkvhD has been verified.
✅ The provided GitHub build matches the on-chain hash. On Chain Hash:
96f8c3d9400258f7759408d1f6f8435b4a24d9b52f5a0340d97907e567cb8773 Executable
Hash: 96f8c3d9400258f7759408d1f6f8435b4a24d9b52f5a0340d97907e567cb8773 Repo URL:
https://github.com/Woody4618/verify-squads/tree/0fb0a2e30c15c51732c0ad5e837975a6f7bbc7ed
Check the verification status at:
https://verify.osec.io/status/6XBGfP17P3KQAKoJb2s5M5fR4aFTXzPeuC1af2GYkvhD Job
url: https://verify.osec.io/job/b63339d2-163e-49ac-b55d-3454c1c2b5b3

Verifizierung aus Docker-Image

Du kannst dein Programm auch gegen ein Docker-Image verifizieren, indem du den folgenden Befehl ausführst:

solana-verify verify-from-image -e
examples/hello_world/target/deploy/hello_world.so -i
ellipsislabs/hello_world_verifiable_build:latest -p
2ZrriTQSVekoj414Ynysd48jyn4AX6ZF4TTJRqHfbJfn

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 Onchain-Programms übereinstimmt, das dem Befehl übergeben wurde. Da der Build bereits in ein Image hochgeladen wurde, ist kein vollständiger Rebuild der ausführbaren Datei erforderlich, was viel Zeit in Anspruch nehmen kann.

Das Dockerfile, das das Image ellipsislabs/hello_world_verifiable_build:latest erstellt, findest du im Repository von Ellipsis Labs unter /examples/hello_world.

Nachfolgend die erwartete Ausgabe:

Verifying image: "ellipsislabs/hello_world_verifiable_build:latest", on network
"https://api.mainnet.solana.com" against program ID
2ZrriTQSVekoj414Ynysd48jyn4AX6ZF4TTJRqHfbJfn Executable path in container:
"examples/hello_world/target/deploy/hello_world.so"

Executable hash:
08d91368d349c2b56c712422f6d274a1e8f1946ff2ecd1dc3efc3ebace52a760 Program hash:
08d91368d349c2b56c712422f6d274a1e8f1946ff2ecd1dc3efc3ebace52a760 Executable
matches on-chain program data ✅

Beispiel für einen verifizierten Build

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 auf dem Main-Branch. Du kannst auch einen bestimmten Commit definieren, falls du am Repository weiterarbeiten 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-Artefakts 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ültige Ausgabe:

Executable Program Hash from repo: 6877a5b732b3494b828a324ec846d526d962223959534dbaf4209e0da3b2d6a9
On-chain Program Hash: 6877a5b732b3494b828a324ec846d526d962223959534dbaf4209e0da3b2d6a9
Program 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

Beachten Sie, dass wir library-name angeben mussten, da das Squads-Repository mehrere Programme enthält. Wir verwenden das Flag --bpf, weil squads_mpl zuvor mit Anchor verifiziert wurde.

Endgültige Ausgabe:

Executable Program Hash from repo: 72da599d9ee14b2a03a23ccfa6f06d53eea4a00825ad2191929cbd78fb69205c
On-chain Program Hash: 72da599d9ee14b2a03a23ccfa6f06d53eea4a00825ad2191929cbd78fb69205c
Program 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ültige Ausgabe:

Executable Program Hash from repo: e31d58edeabc3c30bf6f2aa60bfaa5e492b41ec203e9006404b463e5adee5828
On-chain Program Hash: e31d58edeabc3c30bf6f2aa60bfaa5e492b41ec203e9006404b463e5adee5828
Program 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ültige Ausgabe:

Executable Program Hash from repo: 890d68f48f96991016222b1fcbc2cc81b8ef2dcbf280c44fe378c523c108fad5
On-chain Program Hash: 890d68f48f96991016222b1fcbc2cc81b8ef2dcbf280c44fe378c523c108fad5
Program hash matches ✅

Häufig gestellte Fragen

Meine Verifizierung schlägt fehl. Was soll ich tun?

Überprüfen Sie diese häufigen Probleme:

• Falscher Signer: Bestätigen Sie, dass Ihr Signer die Upgrade-Authority des Programms ist, indem Sie solana program show YourProgramId ausführen
• Kein On-Chain-PDA: Führen Sie solana-verify verify-from-repo -um aus und wählen Sie JA, wenn Sie dazu aufgefordert werden. Ohne das Hochladen des PDA kann die API Ihre Verifizierungsmetadaten nicht abrufen.
• PDA-Daten stimmen nicht überein: Aktualisieren Sie Ihren PDA, wenn Sie Ihr Programm erneut bereitgestellt haben. Ihre PDA-Daten müssen mit Ihrem bereitgestellten Programm übereinstimmen.
• Falscher Commit-Hash: Erstellen Sie Ihren PDA mit dem exakten Commit-Hash, den Sie bereitgestellt haben
• Unterschiede in der Build-Umgebung: Verwenden Sie Docker mit solana-verify, wenn Sie Ihren PDA erstellen

Mein lokaler Build-Hash stimmt nicht mit dem On-Chain-Hash überein. Warum?

Dies bedeutet normalerweise:

• Sie verwenden unterschiedliche Rust/Solana-Toolchain-Versionen
• Ihre Abhängigkeiten wurden zwischen den Builds aktualisiert
• Sie haben nicht in einem Docker-Container gebaut
• Sie haben den falschen Commit ausgecheckt

Beheben Sie dies, indem Sie mit solana-verify build in Docker unter Verwendung des exakten Commits bauen, den Sie bereitgestellt haben.

Wie lange wird meine Verifizierung dauern?

Erwarten Sie diese Zeitrahmen basierend auf Ihrer Programmgröße:

• Einfache Programme: 1-5 Minuten
• Komplexe Programme: 5-15 Minuten
• Sehr große Programme: Bis zu 30 Minuten

Verfolgen Sie Ihren Fortschritt über den Job-Status-Endpunkt.

Mein Programm ist unveränderlich (keine Upgrade-Authority). Wie kann ich es verifizieren?

Wenn Ihr Programm keine Upgrade-Authority hat oder unveränderlich gemacht wurde, bevor Sie einen PDA erstellen konnten, haben wir eine Whitelist-Adresse für diese Situation. Kontaktieren Sie uns unter contact@osec.io, und wir helfen Ihnen, Ihr Programm zu verifizieren.

Was ist der PDA und warum ist er wichtig?

Ihr PDA (Program Derived Account) ermöglicht vertrauenslose Verifizierung:

• On-Chain-Speicherung: Speichern Sie Ihre Verifizierungsmetadaten (Repo-URL, Commit-Hash, Build-Parameter) on-chain in einem PDA, der dem Otter Verify-Programm gehört (verifycLy8mB96wd9wqq3WDXQwM4oU6r42Th37Db9fC)
• Kryptografische Verknüpfung: Ihr PDA wird von Ihrer Programmadresse abgeleitet, wodurch eine unveränderliche Verknüpfung zu Ihren Verifizierungsdaten entsteht
• Dezentrales Vertrauen: Jeder kann Ihren PDA lesen und Ihr Programm unabhängig verifizieren

Warum muss ich den PDA vor der Nutzung der API erstellen?

Die API funktioniert nur mit On-Chain-PDAs, weil:

• Vertrauenslos: Die API lehnt beliebige Daten ab – sie verwendet nur das, was Ihre Upgrade-Authority on-chain gespeichert hat
• Einfacher: Geben Sie einfach Signer + program_id an; die API holt alles andere aus Ihrem PDA
• Manipulationssicher: Ihr PDA erstellt einen unveränderlichen Datensatz, den jeder unabhängig verifizieren kann
• Eigentumsnachweis: Ihr Signer muss die Upgrade-Authority sein, was kryptografisch beweist, dass Sie das Programm kontrollieren

Wie oft sollte ich mein Programm verifizieren?

Verifizieren Sie Ihr Programm:

• Nach jedem Deployment oder Upgrade
• Wenn Sie Ihr Quellcode-Repository aktualisieren
• Machen Sie sich ansonsten keine Sorgen um eine erneute Verifizierung – die API verifiziert automatisch alle Programme alle 24 Stunden neu

Was passiert, wenn ich mein Programm upgrade?

Befolgen Sie diese Schritte nach einem Upgrade:

1. Die API erkennt Ihr Upgrade und hebt die Verifizierung Ihres Programms auf.
2. Aktualisieren Sie Ihren PDA mit neuen Verifizierungsmetadaten:

solana-verify verify-from-repo -um \
  --program-id YourProgramId... \
  https://github.com/your-org/your-program

3. Reichen Sie eine neue Verifizierungsanfrage mit Ihrer Upgrade-Authority ein
4. Die API wird Ihre neue Version gegen den aktualisierten PDA verifizieren

Wichtig: Aktualisieren Sie Ihren PDA immer mit Ihrer Upgrade-Authority und dem neuen Commit-Hash für das aktualisierte Programm.

Kann ich den Verifizierungsergebnissen vertrauen?

Ja – das System ist so konzipiert, dass es vertrauenslos und unabhängig überprüfbar ist:

Was es vertrauenswürdig macht:

• On-Chain-PDA: Ihre Verifizierungsmetadaten befinden sich in der Blockchain und werden von keiner zentralen Instanz kontrolliert
• Nachweis der Upgrade-Authority: Nur die Upgrade-Authority Ihres Programms kann das PDA erstellen/aktualisieren
• Unabhängige Verifizierung: Jeder kann durch Auslesen Ihres PDA und lokales Ausführen von solana-verify verifizieren
• Kontinuierliche Re-Verifizierung: Die API verifiziert automatisch alle Programme alle 24 Stunden neu

Verstehen Sie diese Einschränkungen:

• Die Verifizierung bestätigt, dass der Quellcode mit dem Deployment übereinstimmt – NICHT, dass Ihr Code sicher ist
• Überprüfen Sie stets den Code, bevor Sie mit Programmen interagieren
• Verifiziert ≠ auditiert oder sicher
• Überprüfen Sie das Repository und den Commit im PDA, um zu bestätigen, dass es aus einer vertrauenswürdigen Quelle stammt

Wie kann ich ein Programm unabhängig verifizieren?

Verifizieren Sie jedes Programm selbst, indem Sie dessen On-Chain-PDA auslesen und die Verifizierung lokal durchführen:

Schritt 1: On-Chain-PDA auslesen

# Install solana-verify if you haven't
cargo install solana-verify

# Get the PDA data
solana-verify list-program-pdas --program-id YourProgramId...

Schritt 2: Lokal verifizieren

# Verify using the repository and commit & other arguments from the PDA
solana-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 on-chain program hash

Dies beweist:

1. Die PDA-Metadaten sind authentisch (in der Blockchain gespeichert)
2. Der Quellcode im Repository des PDA stimmt mit dem deployteten Programm überein
3. Sie müssen der API nicht vertrauen – verifizieren Sie alles selbst in der Blockchain

Kann jemand anderes mein Programm ohne Erlaubnis verifizieren?

Ja, das ist der Grund, warum wir verlangen, dass der Signer die Upgrade-Authority ist. Wir betrachten die Verifizierung nur dann als gültig, wenn der Signer die Upgrade-Authority ist.

Was benötige ich, um verifizierbare Builds zu erstellen?

Installieren Sie diese Tools:

• Docker (für deterministische Builds)
• Cargo (Rust-Paketmanager)
• Solana Verify CLI: cargo install solana-verify
• Ein öffentliches Git-Repository mit Ihrem Quellcode

Kann ich private Repositories verifizieren?

Nein – die Verifizierung erfordert öffentlichen Quellcode:

• Ihr PDA speichert eine öffentliche Repository-URL, auf die jeder zugreifen kann
• Die vertrauenslose Verifizierung hängt vom öffentlichen Code-Zugriff ab
• Benutzer müssen Ihren Quellcode lesen können, um zu verstehen, was Ihr Programm macht
• Der gesamte Zweck besteht darin, Benutzern eine unabhängige Überprüfung zu ermöglichen, dass der Quellcode mit dem Deployment übereinstimmt

Private Repositories brechen das Kern-Vertrauensmodell des Verifizierungssystems.

Wie verifiziere ich ein Programm, das von Squads Multisig kontrolliert wird?

Befolgen Sie diese Schritte für von Multisig kontrollierte Programme:

# 1. Build and deploy normally
solana-verify build
solana program deploy <your-program.so> --program-id YourProgramId...

# 2. Verify locally first - confirm the hash matches
solana-verify verify-from-repo -um \
  --program-id YourProgramId... \
  https://github.com/your-org/your-program

# 3. Export the PDA creation transaction
solana-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 verification
solana-verify remote submit-job \
  --program-id YourProgramId... \
  --uploader YourMultisigAddress...

Wichtig: Verifizieren Sie immer lokal (Schritt 2), um zu bestätigen, dass der Build-Hash übereinstimmt, bevor Sie die PDA-Transaktion exportieren.

Fazit

Die Verwendung von verifizierten Builds auf Solana stellt die Integrität und Vertrauenswürdigkeit Ihrer Programme im Netzwerk sicher und ermöglicht es Entwicklern, Ihre SDKs direkt über einen Solana Explorer zu finden. Durch die Nutzung von Tools wie der Solana Verify CLI und Docker können Sie verifizierbare und sichere Builds aufrechterhalten, die mit Ihrem Quellcode übereinstimmen. Treffen Sie stets die erforderlichen Vorkehrungen, um konsistente Umgebungen zu verwenden, und ziehen Sie Governance- Lösungen für sichere Upgrades und Deployments in Betracht.

Sicherheit + Haftungsausschluss

Obwohl verifizierte Builds ein leistungsstarkes Werkzeug zur Gewährleistung der Integrität Ihrer Solana-Programme sind, sind sie im Standard-Setup 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 erstellen und dass Ihr gesamtes Setup einschließlich potenziell sensibler Informationen zum Erstellen in dieses Docker-Image kopiert wird.

Wenn Sie ein vollständig vertrauensloses Setup wünschen, können Sie die Docker-Images selbst erstellen und auf Ihrer eigenen Infrastruktur hosten. Auf diese Weise können Sie sicher sein, dass die Docker-Images nicht manipuliert wurden. Sie finden die Skripte zum Erstellen Ihrer eigenen Docker-Images im Verified-Builds-Repository, und Sie können es forken und die GitHub-Actions selbst ausführen oder validieren, dass sie korrekt sind.

Darüber hinaus vertrauen Sie bei der Remote-Verifizierung bis zu einem gewissen Grad der OtterSec API und dem Solana Explorer.

Die API oder der Solana Explorer könnten potenziell falsche Informationen anzeigen, wenn sie kompromittiert wurden.

Wenn Sie ein vollständig vertrauensfreies Setup haben möchten, können Sie die Verify API selbst betreiben oder die Programmverifizierung lokal selbst durchführen, indem Sie den verify-from-repo Befehl verwenden. Dabei nutzen Sie die On-Chain-Verifizierungsdaten, die in einem PDA gespeichert sind, der aus der Deployment-Authority des Programms und dem Verifizierungsprogramm 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 übernehmen keine Verantwortung für etwaige Verluste oder Schäden, die durch die Nutzung der Verified-Builds- Pipeline entstehen können.

Security.txt für Solana-Programme

Zusätzlich zu Verified Builds können Sie Ihrem Programm auch eine security.txt-Datei hinzufügen. Zukünftig wird die security.txt, sobald implementiert, den Verifier-Public-Key für einen einfachen Zugriff auf die im Verifizierungs-PDA gespeicherten Verifizierungsdaten enthalten. Der PDA, der alle Informationen enthält, die zum Erstellen und Verifizieren eines Programms benötigt werden, wird aus der Programmadresse und dem Verifier-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 eine standardisierte Möglichkeit für Sicherheitsforscher, Kontakt zu den Projektverantwortlichen aufzunehmen, selbst wenn sie nur die Adresse des Vertrags kennen.

Warum security.txt verwenden?

Für viele Projekte, insbesondere kleinere oder private, kann es schwierig und zeitaufwändig sein, die Entwickler allein anhand der Vertragsadresse zu identifizieren. Durch die Einbettung einer security.txt-Datei im Programm wird sichergestellt, dass Sicherheitsforscher problemlos die richtigen Personen kontaktieren können, wodurch potenzielle Exploits verhindert und rechtzeitige Fehlerberichte gewährleistet werden.

So implementieren Sie security.txt

Um Ihrem Solana-Programm eine security.txt hinzuzufügen, befolgen Sie die folgenden Schritte:

Fügen Sie die Abhängigkeit solana-security-txt zu Ihrer Cargo.toml hinzu:

[dependencies]
solana-security-txt = "1.1.1"

Verwenden Sie das Makro security_txt! in Ihrem Vertrag, um Ihre Sicherheitsinformationen zu definieren. Sie können Kontaktdaten, Projekt-URLs und sogar eine Sicherheitsrichtlinie angeben. Hier ist 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 Fields
    preferred_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 Ihr Programm eingebettet sind, können sie einfach ü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 (z. B. Kontaktdaten), wird empfohlen, auf eine Webseite zu verlinken, anstatt sie fest in den Vertrag zu codieren. Dies vermeidet die Notwendigkeit häufiger Programm-Upgrades.

• Verifizierung: Überprüfen Sie vor der Bereitstellung das Format und den Inhalt mit dem Tool query-security-txt, das sowohl Onchain-Programme als auch lokale Binärdateien validieren kann:

query-security-txt target/bpfel-unknown-unknown/release/my_contract.so

Durch die direkte Einbettung von Sicherheitskontaktinformationen in Ihren Vertrag erleichtern Sie es Forschern, Sie zu erreichen, und fördern so bessere Sicherheit und Kommunikation innerhalb des Solana-Ökosystems.

Dies ist ein Beispiel dafür, wie security.txt im Solana Explorer aussieht

Das security.txt-Projekt wird von Neodyme Labs gepflegt

Sie können den Verifizierungsstatus überprüfen und verifizierte Programme unter verify.osec.io durchsuchen.