Solana documentatieProgramma's ontwikkelen

Programma's verifiëren

Deze gids is bedoeld als referentie voor ontwikkelaars die geverifieerde builds willen implementeren voor hun programma's op Solana. We behandelen wat geverifieerde builds zijn, hoe je ze gebruikt, speciale overwegingen en best practices om de authenticiteit van je programma op de blockchain te waarborgen.

Wat zijn geverifieerde builds?

Geverifieerde builds zorgen ervoor dat het uitvoerbare programma dat je op het Solana- netwerk implementeert, overeenkomt met de broncode in je repository. Hierdoor kunnen ontwikkelaars en gebruikers erop vertrouwen dat het programma dat op de blockchain draait precies overeenkomt met de openbare codebase, wat transparantie en veiligheid bevordert.

Het verificatieproces omvat het vergelijken van de hash van het programma op de blockchain met de hash van het lokaal gebouwde programma uit de broncode. Dit zorgt ervoor dat er geen discrepanties tussen de twee versies zijn.

Hoewel een geverifieerde build niet als veiliger moet worden beschouwd dan een niet-geverifieerde build, stelt de build ontwikkelaars in staat om zelf te verifiëren dat de broncode overeenkomt met wat er op de blockchain is geïmplementeerd. Met behulp van de broncode kan een ontwikkelaar dan valideren wat de code uitvoert bij het verzenden van een transactie.

De geverifieerde builds-pipeline is bedacht en wordt onderhouden door Ellipsis Labs en OtterSec. Voor meer details, volg de handleiding in de originele verified builds repository en het verificatieproces direct in de Anza toolsuite, zodra dit daar wordt ondersteund.

Hoe werkt het?

Het verificatieproces wordt uitgevoerd door de hash van het onchain programma te vergelijken met de hash van het lokaal gebouwde programma vanuit de broncode. Je bouwt je programma in een gecontroleerde omgeving met behulp van de Solana Verify CLI en Docker. Dit zorgt ervoor dat het bouwproces deterministisch en consistent is op verschillende systemen. Zodra je het uitvoerbare bestand hebt, kun je het implementeren op het Solana-netwerk. Tijdens het bouwproces wordt een PDA van het verify programma aangemaakt. Deze PDA bevat alle gegevens die nodig zijn om het programma te verifiëren. De PDA bevat het programma-adres, git-url, commit-hash en de argumenten die zijn gebruikt om het programma te bouwen.

Met behulp van de gegevens in de PDA kan iedereen het verify programma-commando lokaal uitvoeren en controleren of het programma is gebouwd vanuit de opgegeven broncode. Vervolgens kan iedereen volledig trustless voor zichzelf verifiëren of hun eigen verify API gebruiken, onderhouden door OtterSec, om een gemakkelijk toegangspunt te bieden voor gebruikers om de verificatie te controleren. Je kunt deze API-aanroepen al zien worden gebruikt in de Solana Explorer en SolanaFM, onder andere plaatsen.

Waarom zou ik geverifieerde builds moeten gebruiken?

Het gebruik van geverifieerde builds biedt de volgende voordelen:

  • Veiligheid: garandeert dat het programma dat onchain draait overeenkomt met de broncode, waardoor kwaadaardige wijzigingen worden voorkomen.

  • Transparantie: stelt andere gebruikers en ontwikkelaars in staat om te valideren dat het onchain programma betrouwbaar is door het te vergelijken met de openbare codebase.

  • Vertrouwen: vergroot het vertrouwen van gebruikers, aangezien geverifieerde builds aantonen dat het onchain gedrag van je programma in lijn is met je openbare code. Bij het bouwen van verifieerbare programma's minimaliseer je risico's die gepaard gaan met het uitvoeren van ongeautoriseerde of kwaadaardige code. Het zorgt er ook voor dat je voldoet aan best practices en beveiligingsonderzoekers een gemakkelijke manier biedt om contact met je op te nemen. Ook kunnen wallets en andere tools transacties van je programma gemakkelijker toestaan zolang het geverifieerd is.

  • Vindbaarheid: wanneer je een geverifieerde build van je programma levert, kan iedereen je broncode, documentatie, programma-SDK of IDL vinden en kunnen ze ook gemakkelijk contact met je opnemen via GitHub in geval van problemen.

Hoe maak ik geverifieerde builds?

Om geverifieerde builds te maken, moet je deze stappen volgen:

Samenvatting:

  • Commit je code naar een openbare repository
  • Bouw een geverifieerde build in docker
  • Deploy de geverifieerde build
  • Verifieer het gedeployde programma tegen de openbare API

Als je je programma verifieert dat niet in een docker-container is gebouwd, zal het waarschijnlijk mislukken omdat Solana-programmabuilds niet deterministisch zijn op verschillende systemen.

Installeer Docker en Cargo

Installeer de benodigde tools en zorg ervoor dat je Docker en Cargo hebt geïnstalleerd. Docker biedt een gecontroleerde bouwomgeving om consistentie te waarborgen, en Cargo wordt gebruikt voor het beheren van Rust-pakketten.

  • Docker: volg de stappen op de Docker-website om Docker voor jouw platform te installeren. Zorg er na de installatie voor dat de Docker-service draait volgens deze verdere handleiding.
  • Cargo: als je Cargo nog niet hebt geïnstalleerd, kun je het installeren door het volgende commando uit te voeren:
curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh

Installeer de Solana Verify CLI

De Solana Verify CLI is het belangrijkste hulpmiddel voor het verifiëren van builds. Solana Verify CLI wordt momenteel onderhouden door Ellipsis Labs en kan worden geïnstalleerd met Cargo.

Je kunt het installeren door het volgende uit te voeren:

cargo install solana-verify

Als je een specifieke versie van de CLI nodig hebt, kun je de versie vastleggen met:

cargo install solana-verify --version $VERSION

Indien gewenst kun je een versie rechtstreeks installeren vanaf een specifieke commit:

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

Project voorbereiden

Om te verifiëren tegen een repository moet deze een Cargo.lock bestand in de hoofdmap van je repository hebben. Als je slechts één programma in je repository hebt en een cargo.lock bestand in je hoofdmap, kun je direct naar de volgende stap gaan en je programma bouwen.

Als je programma zich in een submap bevindt en je een rust workspace hebt, moet je een workspace Cargo.toml bestand aanmaken in de hoofdmap van je repository.

Je kunt dit Cargo.toml voorbeeld als voorinstelling gebruiken:

Cargo.toml
[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

Zorg ervoor dat je programma in de workspace/members array staat en dat het Cargo.toml van je programma de juiste lib naam geconfigureerd heeft.

Belangrijk is de lib name, niet de package naam!

Zoiets als dit:

waffle/Cargo.toml
[package]
name = "waffle"
version = "0.1.0"
edition = "2021"
[lib]
name = "waffle"
crate-type = ["cdylib", "lib"]
[dependencies]
solana-program = "2.1.0"

In deze repository kun je een voorbeeld zien van een workspace met een programma in een submap. Merk ook op dat wanneer het programma zich in een submap bevindt, je later deze map moet toevoegen als --mount-path aan het verify-from-repo commando.

In deze repository vind je een Anchor voorbeeld. In deze repository vind je een native rust voorbeeld.

Met dit Cargo.toml bestand op zijn plaats kun je vervolgens cargo generate-lockfile uitvoeren om een lock-bestand aan te maken en doorgaan met het bouwen van je programma.

Verifieerbare programma's bouwen

Om je Solana-programma verifieerbaar te bouwen, navigeer je naar de map met het Cargo.toml bestand van je workspace en voer je uit:

solana-verify build

Dit zal je omgeving kopiëren naar een docker container en het op een deterministische manier bouwen.

Zorg ervoor dat je daadwerkelijk de geverifieerde build deployt en deze niet per ongeluk overschrijft met anchor build of cargo build-sbf, aangezien deze hoogstwaarschijnlijk niet in dezelfde hash zullen resulteren en je verificatie dus zal mislukken.

Voor projecten met meerdere programma's kun je een specifiek programma bouwen door de bibliotheek-naam te gebruiken (niet de pakketnaam):

solana-verify build --library-name $PROGRAM_LIB_NAME

Dit proces zorgt voor deterministische builds en kan enige tijd duren, vooral op bepaalde systemen (bijv. M1 MacBook) omdat het binnen een docker-container draait. Voor snellere builds wordt een Linux-machine met x86-architectuur aanbevolen.

Zodra de build is voltooid, kun je de hash van het uitvoerbare bestand ophalen met het volgende commando:

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

Verifieerbare programma's implementeren

Zodra je je programma hebt gebouwd en de hash hebt opgehaald, kun je het implementeren op het Solana-netwerk. Het wordt aanbevolen om een multi-signature of governance-oplossing zoals Squads Protocol te gebruiken voor veilige implementaties, maar je kunt ook direct implementeren met:

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

Een momenteel passende lage prioriteitsvergoeding kun je opvragen bij je rpc-provider, bijvoorbeeld Quicknode.

Om te verifiëren dat het geïmplementeerde programma overeenkomt met het gebouwde uitvoerbare bestand, voer je uit:

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

Je kunt verschillende versies hebben geïmplementeerd op verschillende Solana-clusters (bijv. devnet, testnet, mainnet). Zorg ervoor dat je de juiste netwerk-URL gebruikt voor de gewenste Solana-cluster waartegen je een programma wilt verifiëren. Verificatie op afstand werkt alleen op mainnet.

Verifiëren tegen repositories

Om een programma te verifiëren tegen zijn openbare repository, gebruik je:

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

Terwijl je de geverifieerde build uitvoert in je programmamap, moet je bij het uitvoeren van verify-from-repo de --mount-path flag toevoegen. Dit is het pad naar de map die de Cargo.toml bevat met de bibliotheknaam van je programma.

Dit commando vergelijkt de onchain programma-hash met de uitvoerbare hash die is gebouwd vanuit de broncode op de gespecificeerde commit-hash.

Aan het einde van het commando wordt gevraagd of je je verificatiegegevens onchain wilt uploaden. Als je dat doet, zal de Solana Explorer onmiddellijk je programma's verificatiegegevens tonen. Totdat het geverifieerd is door een externe build, wordt het als ongeverifieerd weergegeven. Leer in de volgende stap hoe je je programma kunt verifiëren tegen een openbare API.

Als je de verificatie wilt vastzetten aan een bepaalde release, kun je de --commit-hash flag aan het commando toevoegen.

Verifiëren tegen openbare API

Nadat je je verificatie-PDA onchain hebt geüpload met verify-from-repo, dien je een remote verificatietaak in bij de OtterSec API:

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

De --uploader is het adres dat de verificatie-PDA heeft geüpload, meestal de upgrade-autoriteit van je programma. Als je programma wordt beheerd door een multisig, verder in het multisig-verificatie gedeelte van deze handleiding hieronder.

De verouderde --remote vlag op verify-from-repo is afgeschaft. Upload eerst je PDA en voer daarna remote submit-job uit.

Dit dient een taak in bij de OtterSec API. Je kunt de taakstatus controleren met:

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

Zodra de verificatie succesvol is voltooid, wat even kan duren, kun je je programma als geverifieerd zien in de OtterSec API voor afzonderlijke programma's en in de Solana Explorer, SolanaFM, SolScan en uiteindelijk ook op de door de community beheerde website SolanaVerify.org onderhouden door 0xDeep en de OtterSec geverifieerde programma's API en tot slot in het Verified Programs Dune Dashboard wat bijdraagt aan een gezonder Solana-ecosysteem.

Hoe je je programma verifieert wanneer het wordt beheerd door een Multisig zoals Squads

Om de remote verificatie te laten werken, moet je de verificatiegegevens schrijven naar een PDA ondertekend door de programma-autoriteit. Als je programma wordt beheerd door een multisig, kun je deze schrijf-PDA-transactie exporteren en indienen via Squads Protocol of een andere multisig-oplossing naar keuze.

1. Bouw het verifieerbare programma

Bouw eerst het programma:

solana-verify build

Dit bouwt een verifieerbare build met behulp van een Docker-container met de Solana- versie die is opgegeven in het Cargo.lock bestand.

2. Implementeer het programma

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

Voor de rest van deze multisig-handleiding gebruiken we een voorbeeld programma-ID van 6XBGfP17P3KQAKoJb2s5M5fR4aFTXzPeuC1af2GYkvhD.

3. Commit en verifieer tegen de repository

Zodra dat gedaan is, committen we het project naar GitHub. Hier is een voorbeeld: https://github.com/solana-developers/verify-squads

Optioneel: Kijk of je eerst lokaal kunt verifiëren (dit commando gebruikt het voorbeeld programma-ID 6XBGfP17P3KQAKoJb2s5M5fR4aFTXzPeuC1af2GYkvhD):

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

Alleen om er zeker van te zijn dat je parameters correct zijn.

4. Draag programmabeheer over aan multisig

Als je de programmarechten nog niet hebt overgedragen aan de multisig, kopieer dan de multisig-autoriteit. Je hebt deze nodig in de volgende stap.

5. Exporteer PDA-transactie

Wanneer je de programmarechten lokaal hebt, word je gevraagd om de buildgegevens on-chain te uploaden bij gebruik van het commando solana-verify verify-from-repo.

Omdat je dat niet kunt doen wanneer je een multisig gebruikt, moet je de PDA-transactie handmatig exporteren en de transactie vervolgens via Squads activeren.

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

Dit geeft je een base58-transactie terug. Als je een base64-gecodeerde transactie wilt voor gebruik in een transactie-inspecteur, kun je --encoding base64 gebruiken.

P6vBfcPaaXb8fZoT3NBAYEcdtEj7tubA1k2gBxmFKZ3UWF5YyrmDMFTvLKALCJoUuRsPAjMckudYruCu3eeWQtuDrFbEMLxLFutnKXac974fnkMivcwUdY66VLjbxQT6ATmcy7F4hBtz1G4P1h6iBJLhb8WtrtgY3i4qq45MUEb7RjuMEfUFXKrNgPdGxkz5xvMHq3dxKRcpmEK5k2DkeW6SUQYBVe19Ga3B9GyhTX8k3CMt9JCEah13WyRnQd8GjoK6sTEvGJym6xDNvmd8yiJYSNcaYwEJsjHEUf4Yh6kAC7ki2KRvVAr3NVe1gjqK9McrwSQjtUatvydTG8Zovcr7PPUEMf3yPMgKXjZLB2QpkH63yTTYdNAnWFuv9E6b6nYRqye5XcNi436yKw5U14fXh65yK34bgYLi9328UT1huJELsJU9BRGnGUmb6GWp6c2WL5BhnzgNTSnt9TXFfEgUMzhvKzpVBxLP44hwqqBdyUhHFysCF37531PnmiESq8x1xou23xJ6FcQbc199754MkqQd7tX9CUznGzAEqHGkzn3VBoJnojsKtgYmiTYbdRsT1CU18MbYEE7WvGAvXyxxbpNzbAcc94HrnM6cqRGmwhEBroPfFghTdmzg9D

6. Dien transactie in via Squads

Ga naar de Squads-transactiebouwer en importeer de base58-gecodeerde transactie. Zorg ervoor dat de transactie in de simulatie alleen een aanroep heeft naar het osec-verificatieprogramma en het computerbudgetprogramma, en niets anders!

7. Dien externe verificatietaak in

Zodra de transactie naar Squads succesvol was, kun je de externe taak indienen:

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

Dat is het! Je hebt je programma geverifieerd aan de hand van een publieke repository en een externe taak ingediend bij de OtterSec API. Je zou het nu moeten kunnen zien in de Solana Explorer en op andere plaatsen.

8. Het programma bijwerken (Optioneel)

Wanneer je je programma bijwerkt, moet je een nieuwe PDA-transactie exporteren en deze opnieuw via Squads indienen.

Een update uitvoeren op het programma:

solana-verify build
solana program write-buffer target/deploy/verify_squads.so --with-compute-unit-price 50000 --max-sign-attempts 50

Draag vervolgens die bufferbevoegdheid over aan de multisig of maak de buffer direct aan met de bevoegdheid van de multisig.

solana program set-buffer-authority Fu3k79g53ZozAj47uq1tXrFy4QbQYh7y745DDsxjtyLR --new-buffer-authority 3JG6ULvZVCrkKtSSskKNJGe8RNZGFe8Ruev9KUhxzK5K

9. Nieuwe PDA-transactie exporteren en indienen

Vergeet niet je wijzigingen naar GitHub te pushen. Exporteer de PDA-upgradetransactie opnieuw:

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

Dien de transactie opnieuw in via Squads.

Je kunt een voorbeeldtransactie bekijken hier.

Dien vervolgens een nieuwe externe build in:

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

Dit zou er ongeveer zo uit moeten zien:

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 onchain 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

Gefeliciteerd, je hebt je programma geverifieerd na een multisig-upgrade!

Verifiëren vanuit een Docker-image

Je kunt je programma ook verifiëren aan de hand van een Docker-image door de volgende opdracht uit te voeren:

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

Deze opdracht laadt de image op die is opgeslagen op ellipsislabs/hello_world_verifiable_build:latest, en verifieert dat de hash van het uitvoerbare pad in de container overeenkomt met de hash van het onchain- programma dat aan de opdracht is meegegeven. Omdat de build al naar een image is geüpload, is er geen volledige herbouw van het uitvoerbare bestand nodig, wat veel tijd kan kosten.

Het Dockerfile dat de image ellipsislabs/hello_world_verifiable_build:latest aanmaakt, is te vinden in de Ellipsis Labs-repository /examples/hello_world.

Hieronder staat de verwachte uitvoer:

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 onchain program data ✅

Voorbeeld geverifieerde build

Hier is een voorbeeld van het verifiëren van een voorbeeldprogramma met de ID FWEYpBAf9WsemQiNbAewhyESfR38GBBHLrCaU3MpEKWv met behulp van de broncode uit deze 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

Standaard neemt het verify-from-repo commando de laatste commit op de main-branch. Je kunt ook een specifieke commit opgeven als je verder wilt werken aan de repository door de parameter commit-hash te gebruiken: --commit-hash 5b82b86f02afbde330dff3e1847bed2d42069f4e

Wanneer daarom gevraagd wordt, antwoord je met ja om je verificatie-PDA onchain te uploaden. Dien vervolgens een externe verificatietaak in via de OtterSec API:

solana-verify remote submit-job --program-id FWEYpBAf9WsemQiNbAewhyESfR38GBBHLrCaU3MpEKWv --uploader <your-upgrade-authority>

Populaire programma's die al geverifieerd zijn

Phoenix

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

Eindresultaat:

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

Let op: we moesten de library-name opgeven omdat de Squads-repository meerdere programma's bevat. We gebruiken de vlag --bpf omdat squads_mpl eerder geverifieerd was met Anchor.

Eindresultaat:

Executable Program Hash from repo: 72da599d9ee14b2a03a23ccfa6f06d53eea4a00825ad2191929cbd78fb69205c
Onchain 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

Eindresultaat:

Executable Program Hash from repo: e31d58edeabc3c30bf6f2aa60bfaa5e492b41ec203e9006404b463e5adee5828
Onchain 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

Eindresultaat:

Executable Program Hash from repo: 890d68f48f96991016222b1fcbc2cc81b8ef2dcbf280c44fe378c523c108fad5
Onchain Program Hash: 890d68f48f96991016222b1fcbc2cc81b8ef2dcbf280c44fe378c523c108fad5
Program hash matches ✅

Veelgestelde vragen

Mijn verificatie mislukt. Wat moet ik doen?

Controleer deze veelvoorkomende problemen:

  • Verkeerde ondertekenaar: Bevestig dat uw ondertekenaar de upgrade-autoriteit van het programma is door solana program show YourProgramId uit te voeren
  • Geen onchain PDA: Voer solana-verify verify-from-repo -um uit en selecteer JA wanneer daarom wordt gevraagd. Zonder het uploaden van de PDA kan de API uw verificatiemetadata niet ophalen.
  • PDA-gegevensmismatch: Werk uw PDA bij als u uw programma opnieuw heeft gedeployed. Uw PDA-gegevens moeten overeenkomen met uw gedeployde programma.
  • Onjuiste commit-hash: Maak uw PDA aan met de exacte commit-hash die u heeft gedeployed
  • Verschillen in buildomgeving: Gebruik Docker met solana-verify bij het aanmaken van uw PDA

Mijn lokale build-hash komt niet overeen met de onchain-hash. Waarom?

Dit betekent meestal:

  • U gebruikt verschillende versies van de Rust/Solana-toolchain
  • Uw afhankelijkheden zijn bijgewerkt tussen builds
  • U heeft niet gebuild in een Docker-container
  • U heeft de verkeerde commit uitgecheckt

Los dit op door te bouwen met solana-verify build in Docker met behulp van de exacte commit die u heeft gedeployed.

Hoe lang duurt mijn verificatie?

Verwacht de volgende tijdsduren op basis van uw programmagrootte:

  • Eenvoudige programma's: 1-5 minuten
  • Complexe programma's: 5-15 minuten
  • Zeer grote programma's: Tot 30 minuten

Volg uw voortgang via het eindpunt voor de taakstatus.

Mijn programma is onveranderlijk (geen upgrade-autoriteit). Hoe kan ik het verifiëren?

Als uw programma geen upgrade-autoriteit heeft of onveranderlijk werd gemaakt voordat u een PDA kon aanmaken, hebben wij een gewhitelistet adres voor deze situatie. Neem contact met ons op via contact@osec.io, en wij helpen u uw programma geverifieerd te krijgen.

Wat is de PDA en waarom is het belangrijk?

Uw PDA (Program Derived Account) maakt vertrouwensloze verificatie mogelijk:

  • On-Chain Opslag: Sla uw verificatiemetadata (repo-URL, commit-hash, buildparameters) op in een PDA die eigendom is van het Otter Verify-programma (verifycLy8mB96wd9wqq3WDXQwM4oU6r42Th37Db9fC)
  • Cryptografische Koppeling: Uw PDA wordt afgeleid van uw programmaadres, waardoor een onveranderlijke koppeling naar uw verificatiegegevens ontstaat
  • Gedecentraliseerd Vertrouwen: Iedereen kan uw PDA lezen en uw programma onafhankelijk verifiëren

Waarom moet ik de PDA aanmaken vóór het gebruik van de API?

De API werkt alleen met on-chain PDA's omdat:

  • Vertrouwensloos: De API weigert willekeurige gegevens — het gebruikt alleen wat uw upgrade-autoriteit on-chain heeft opgeslagen
  • Eenvoudiger: Geef alleen de ondertekenaar en program_id op; de API haalt alles overige op uit uw PDA
  • Manipulatiebestendig: Uw PDA creëert een onveranderlijk record dat iedereen onafhankelijk kan verifiëren
  • Eigendomsbewijs: Uw ondertekenaar moet de upgrade-autoriteit zijn, wat cryptografisch bewijst dat u het programma beheert

Hoe vaak moet ik mijn programma verifiëren?

Verifieer uw programma:

  • Na elke implementatie of upgrade
  • Wanneer u uw bronrepository bijwerkt
  • Maak u geen zorgen over herhaalde verificatie — de API verifieert automatisch alle programma's elke 24 uur opnieuw

Wat gebeurt er wanneer ik mijn programma upgrade?

Volg deze stappen na een upgrade:

  1. De API detecteert uw upgrade en markeert uw programma als niet-geverifieerd.
  2. Werk uw PDA bij met nieuwe verificatiemetadata:
solana-verify verify-from-repo -um \
--program-id YourProgramId... \
https://github.com/your-org/your-program
  1. Dien een nieuw verificatieverzoek in met uw upgrade-autoriteit
  2. De API verifieert uw nieuwe versie aan de hand van de bijgewerkte PDA

Belangrijk: Werk uw PDA altijd bij met uw upgrade-autoriteit en gebruik de nieuwe commit-hash voor het geüpgradede programma.

Kan ik de verificatieresultaten vertrouwen?

Ja - het systeem is ontworpen om trustless en onafhankelijk verifieerbaar te zijn:

Wat het betrouwbaar maakt:

  • On-Chain PDA: Je verificatiemetadata leeft onchain, niet beheerd door een centrale autoriteit
  • Bewijs van upgrade-autoriteit: Alleen de upgrade-autoriteit van jouw programma kan de PDA aanmaken/bijwerken
  • Onafhankelijke verificatie: Iedereen kan verifiëren door jouw PDA te lezen en solana-verify lokaal uit te voeren
  • Doorlopende herverificatie: De API herverifieert automatisch alle programma's elke 24 uur

Begrijp deze beperkingen:

  • Verificatie bevestigt dat de broncode overeenkomt met de implementatie - NIET dat jouw code veilig is
  • Bekijk altijd de code voordat je interactie hebt met programma's
  • Geverifieerd ≠ geauditeerd of veilig
  • Controleer de repository en de commit in de PDA om te bevestigen dat deze afkomstig is van een vertrouwde bron

Hoe kan ik een programma onafhankelijk verifiëren?

Verifieer elk programma zelf door de onchain PDA te lezen en verificatie lokaal uit te voeren:

Stap 1: Lees de On-Chain PDA

# Install solana-verify if you haven't
cargo install solana-verify
# Get the PDA data
solana-verify list-program-pdas --program-id YourProgramId...

Stap 2: Lokaal verifiëren

# 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 onchain program hash

Dit bewijst:

  1. De PDA-metadata is authentiek (onchain opgeslagen)
  2. De broncode in de repository van de PDA komt overeen met het geïmplementeerde programma
  3. Je hoeft de API niet te vertrouwen - verifieer alles zelf onchain

Kan iemand anders mijn programma verifiëren zonder toestemming?

Ja, dat is de reden waarom we vereisen dat de ondertekenaar de upgrade-autoriteit is. We beschouwen de verificatie alleen als geldig als de ondertekenaar de upgrade-autoriteit is.

Wat heb ik nodig om verifieerbare builds te maken?

Installeer deze tools:

  • Docker (voor deterministische builds)
  • Cargo (Rust-pakketbeheerder)
  • Solana Verify CLI: cargo install solana-verify
  • Een openbare Git-repository met jouw broncode

Kan ik privérepositories verifiëren?

Nee - verificatie vereist openbare broncode:

  • Uw PDA slaat een openbare repository-URL op die iedereen kan openen
  • Betrouwbare verificatie zonder vertrouwde partij vereist toegang tot openbare code
  • Gebruikers moeten uw broncode kunnen lezen om te begrijpen wat uw programma doet
  • Het hele doel is om gebruikers in staat te stellen onafhankelijk te verifiëren dat de broncode overeenkomt met de implementatie

Privérepositories doorbreken het kernvertrouwensmodel van het verificatiesysteem.

Hoe verifieer ik een programma dat wordt beheerd door Squads Multisig?

Volg deze stappen voor programma's die worden beheerd via multisig:

# 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...

Belangrijk: Verifieer altijd lokaal (stap 2) om te bevestigen dat de build-hash overeenkomt voordat u de PDA-transactie exporteert.

Conclusie

Het gebruik van geverifieerde builds op Solana waarborgt de integriteit en betrouwbaarheid van uw programma's op het netwerk en stelt ontwikkelaars in staat uw SDK's rechtstreeks via een Solana Explorer te vinden. Door gebruik te maken van tools zoals de Solana Verify CLI en Docker kunt u verifieerbare en veilige builds onderhouden die overeenkomen met uw broncode. Neem altijd de nodige voorzorgsmaatregelen om consistente omgevingen te gebruiken en overweeg governance-oplossingen voor veilige upgrades en implementaties.

Beveiliging + Disclaimer

Hoewel geverifieerde builds een krachtig hulpmiddel zijn voor het waarborgen van de integriteit van uw Solana-programma's, is de standaardinstelling niet volledig zonder vertrouwde partij. De Docker-images worden gebouwd en gehost door de Solana Foundation.

Houd er rekening mee dat u uw project bouwt in een gedownload Docker-image en dat uw volledige configuratie wordt gekopieerd naar dat Docker-image voor het bouwen, inclusief mogelijk gevoelige informatie.

Als u een volledig vertrouwensloze opstelling wilt hebben, kunt u de Docker-images zelf bouwen en hosten op uw eigen infrastructuur. Op deze manier kunt u er zeker van zijn dat de Docker-images niet zijn gemanipuleerd. U kunt de scripts voor het aanmaken van uw eigen Docker-images vinden in de Verified builds-repository en u kunt deze forken en de GitHub Actions zelf uitvoeren, of valideren dat ze correct zijn.

Bovendien vertrouwt u bij de externe verificatie in zekere mate op de OtterSec API en de Solana Explorer.

De API of Solana Explorer kan mogelijk onjuiste informatie weergeven als deze gecompromitteerd is.

Als u een volledig vertrouwensloze opzet wilt, kunt u de Verify API zelf uitvoeren of de programmaverificatie lokaal uitvoeren met het verify-from-repo commando, waarbij u gebruikmaakt van de on-chain verificatiegegevens die zijn opgeslagen in een PDA die is afgeleid van de deploy-autoriteit van het programma en het verificatieprogramma.

Het verificatieprogramma is ingezet door het OtterSec-team en is nog niet bevroren, waardoor het op elk moment kan worden bijgewerkt.

De Solana Foundation, OtterSec en het Ellipsis Labs-team zijn niet verantwoordelijk voor eventuele verliezen of schade die kunnen ontstaan door het gebruik van de geverifieerde builds-pipeline.

Security.txt voor Solana-programma's

Naast geverifieerde builds kunt u ook een security.txt bestand aan uw programma toevoegen. In de toekomst, zodra geïmplementeerd, zal de security.txt de verifier publieke sleutel bevatten voor eenvoudige toegang tot de verificatiegegevens die zijn opgeslagen in de verificatie-PDA. De PDA met alle informatie die nodig is om een programma te bouwen en te verifiëren, is afgeleid van het adres van het programma en de verifier pubkey. Standaard is dit dezelfde pubkey waarmee het programma is gebouwd en ingezet. Maar het kan ook een andere pubkey zijn die kan worden opgegeven in de security.txt.

De security.txt functie stelt ontwikkelaars in staat om contact- en beveiligingsinformatie direct in hun Solana smart contracts op te nemen. Geïnspireerd door securitytxt.org, biedt deze aanpak een gestandaardiseerde manier voor beveiligingsonderzoekers om contact op te nemen met projectbeheerders, zelfs als ze alleen het adres van het contract kennen.

Waarom security.txt gebruiken?

Voor veel projecten, met name kleinere of privéprojecten, kan het lastig en tijdrovend zijn om de ontwikkelaars te identificeren aan de hand van alleen het contractadres. Door een security.txt bestand in het programma in te sluiten, kunnen beveiligingsonderzoekers eenvoudig contact opnemen met de juiste personen, wat exploits kan voorkomen en tijdige bugmeldingen garandeert.

Hoe security.txt te implementeren

Om een security.txt aan uw Solana-programma toe te voegen, volgt u de volgende stappen:

Voeg de solana-security-txt afhankelijkheid toe aan uw Cargo.toml:

Cargo.toml
[dependencies]
solana-security-txt = "1.1.1"

Gebruik de security_txt! macro in uw contract om uw beveiligingsinformatie te definiëren. U kunt contactgegevens, project-URL's en zelfs een beveiligingsbeleid opnemen. Hier is een voorbeeld:

#[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!"
}

Zodra de security.txt informatie in uw programma is ingesloten, kan deze eenvoudig worden opgevraagd via tools zoals de Solana Explorer, zodat uw contact- en beveiligingsgegevens beschikbaar zijn voor iedereen die potentiële problemen wil melden.

Best practices

  • Gebruik links: Voor informatie die waarschijnlijk zal veranderen (bijv. contactgegevens), wordt aanbevolen te verwijzen naar een webpagina in plaats van deze hard te coderen in het contract. Dit voorkomt de noodzaak van frequente programma-upgrades.

  • Verificatie: Verifieer vóór de implementatie het formaat en de inhoud met behulp van de query-security-txt tool, die zowel onchain-programma's als lokale binaire bestanden kan valideren:

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

Door beveiligingscontactinformatie rechtstreeks in uw contract in te sluiten, maakt u het voor onderzoekers gemakkelijker om u te bereiken, wat de beveiliging en communicatie binnen het Solana-ecosysteem bevordert.

Dit is een voorbeeld van hoe security.txt eruitziet in de Solana Explorer

Het security.txt project wordt onderhouden door Neodyme Labs

U kunt de verificatiestatus controleren en geverifieerde programma's bekijken op verify.osec.io.

Is this page helpful?

Inhoudsopgave

Wat zijn geverifieerde builds?Hoe werkt het?Waarom zou ik geverifieerde builds moeten gebruiken?Hoe maak ik geverifieerde builds?Installeer Docker en CargoInstalleer de Solana Verify CLIProject voorbereidenVerifieerbare programma's bouwenVerifieerbare programma's implementerenVerifiëren tegen repositoriesVerifiëren tegen openbare APIHoe je je programma verifieert wanneer het wordt beheerd door een Multisig zoals Squads1. Bouw het verifieerbare programma2. Implementeer het programma3. Commit en verifieer tegen de repository4. Draag programmabeheer over aan multisig5. Exporteer PDA-transactie6. Dien transactie in via Squads7. Dien externe verificatietaak in8. Het programma bijwerken (Optioneel)9. Nieuwe PDA-transactie exporteren en indienenVerifiëren vanuit een Docker-imageVoorbeeld geverifieerde buildPopulaire programma's die al geverifieerd zijnPhoenixSquads V3Drift V2Marginfi V2Veelgestelde vragenMijn verificatie mislukt. Wat moet ik doen?Mijn lokale build-hash komt niet overeen met de onchain-hash. Waarom?Hoe lang duurt mijn verificatie?Mijn programma is onveranderlijk (geen upgrade-autoriteit). Hoe kan ik het verifiëren?Wat is de PDA en waarom is het belangrijk?Waarom moet ik de PDA aanmaken vóór het gebruik van de API?Hoe vaak moet ik mijn programma verifiëren?Wat gebeurt er wanneer ik mijn programma upgrade?Kan ik de verificatieresultaten vertrouwen?Hoe kan ik een programma onafhankelijk verifiëren?Kan iemand anders mijn programma verifiëren zonder toestemming?Wat heb ik nodig om verifieerbare builds te maken?Kan ik privérepositories verifiëren?Hoe verifieer ik een programma dat wordt beheerd door Squads Multisig?ConclusieBeveiliging + DisclaimerSecurity.txt voor Solana-programma'sWaarom security.txt gebruiken?Hoe security.txt te implementerenBest practices
Pagina Bewerken
© 2026 Solana Foundation. Alle rechten voorbehouden.