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.

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>

Hoe je programma te verifiëren als het wordt beheerd door een multisig zoals Squads

Voor de externe verificatie moet je de verificatiegegevens schrijven naar een PDA die is 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.

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

Verifiëren vanuit docker-image

Je kunt je programma ook verifiëren tegen een docker-image door het volgende commando 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

Dit commando laadt de image die is opgeslagen op ellipsislabs/hello_world_verifiable_build:latest, en verifieert dat de hash van het uitvoerbare pad in de container hetzelfde is als de hash van het onchain programma dat aan het commando is meegegeven. Omdat de build al naar een image is geüpload, is er geen volledige rebuild van het uitvoerbare bestand nodig, wat lang kan duren.

Het Dockerfile dat de image ellipsislabs/hello_world_verifiable_build:latest creëert, 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 on-chain program data ✅

Voorbeeld van een 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 definiëren als je verder wilt werken aan de repository door de commit-hash parameter te gebruiken: --commit-hash 5b82b86f02afbde330dff3e1847bed2d42069f4e

Tot slot kun je het programma ook direct verifiëren via de OtterSec API:

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

Het --remote commando stuurt een buildverzoek naar de OtterSec API, die een externe build van je programma start. Zodra de build is voltooid, verifieert het systeem dat de onchain hash van je programma overeenkomt met de hash van het gegenereerde build artefact van je repository.

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

Merk op dat we de library-name moesten specificeren omdat de Squads repo meerdere programma's bevat. We gebruiken de --bpf vlag omdat squads_mpl eerder geverifieerd was met Anchor.

Eindresultaat:

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

Eindresultaat:

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

Eindresultaat:

Executable Program Hash from repo: 890d68f48f96991016222b1fcbc2cc81b8ef2dcbf280c44fe378c523c108fad5
On-chain 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 on-chain 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-gegevens komen niet overeen: Werk uw PDA bij als u uw programma opnieuw hebt geïmplementeerd. Uw PDA-gegevens moeten overeenkomen met uw geïmplementeerde programma.
• Onjuiste commit-hash: Maak uw PDA aan met de exacte commit-hash die u hebt geïmplementeerd
• Verschillen in build-omgeving: Gebruik Docker met solana-verify bij het aanmaken van uw PDA

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

Dit betekent meestal:

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

Los dit op door te bouwen met solana-verify build in Docker met de exacte commit die u hebt geïmplementeerd.

Hoe lang duurt mijn verificatie?

Verwacht deze 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 met behulp van het jobstatus-endpoint.

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

Als uw programma geen upgrade-autoriteit heeft of onveranderlijk is gemaakt voordat u een PDA kon aanmaken, hebben we hiervoor een goedgekeurd adres. Neem contact met ons op via contact@osec.io en we helpen u uw programma te laten verifiëren.

Wat is de PDA en waarom is deze belangrijk?

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

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

Waarom moet ik de PDA aanmaken voordat ik de API gebruik?

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 ondertekener + program_id op; de API haalt al het andere uit uw PDA
• Fraudebestendig: Uw PDA creëert een onveranderlijk record dat iedereen onafhankelijk kan verifiëren
• Eigendomsbewijs: Uw ondertekener 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 broncode-repository bijwerkt
• Maak u verder geen zorgen over herverificatie - de API herverifieert automatisch alle programma's elke 24 uur

Wat gebeurt er wanneer ik mijn programma upgrade?

Volg deze stappen na het upgraden:

1. De API detecteert uw upgrade en maakt de verificatie van uw programma ongedaan.
2. Update uw PDA met nieuwe verificatiemetadata:

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

3. Dien een nieuw verificatieverzoek in met uw upgrade-autoriteit
4. De API zal uw nieuwe versie verifiëren tegen de bijgewerkte PDA

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

Kan ik de verificatieresultaten vertrouwen?

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

Wat het betrouwbaar maakt:

• On-Chain PDA: Je verificatiemetadata staat on-chain, niet gecontroleerd door een centrale autoriteit
• Upgrade Authority Bewijs: Alleen de upgrade authority van je programma kan de PDA aanmaken/bijwerken
• Onafhankelijke Verificatie: Iedereen kan verifiëren door je PDA te lezen en solana-verify lokaal uit te voeren
• Continue Herverificatie: De API herverifieert automatisch alle programma's elke 24 uur

Begrijp deze beperkingen:

• Verificatie bevestigt dat de bron overeenkomt met de deployment - NIET dat je code veilig is
• Controleer altijd de code voordat je met programma's interacteert
• Geverifieerd ≠ geauditeerd of veilig
• Controleer de repository en commit in de PDA om te bevestigen dat deze van een betrouwbare bron komt

Hoe kan ik een programma zelf verifiëren?

Verifieer elk programma zelf door de on-chain 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: Verifieer Lokaal

# 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

Dit bewijst:

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

Kan iemand anders mijn programma verifiëren zonder toestemming?

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

Wat heb ik nodig om verifieerbare builds te maken?

Installeer deze tools:

• Docker (voor deterministische builds)
• Cargo (Rust package manager)
• Solana Verify CLI: cargo install solana-verify
• Een publieke Git-repository met je broncode

Kan ik privérepositories verifiëren?

Nee - verificatie vereist openbare broncode:

• Je PDA slaat een openbare repository-URL op die iedereen kan raadplegen
• Trustless verificatie is afhankelijk van openbare toegang tot code
• Gebruikers moeten je broncode kunnen lezen om te begrijpen wat je programma doet
• Het hele doel is om gebruikers in staat te stellen zelfstandig te verifiëren dat de bron overeenkomt met de deployment

Privérepositories breken het kernvertrouwensmodel van het verificatiesysteem.

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

Volg deze stappen voor multisig-beheerde programma's:

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

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

Conclusie

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

Beveiliging + Disclaimer

Hoewel geverifieerde builds een krachtig hulpmiddel zijn om de integriteit van je Solana-programma's te waarborgen, is het niet volledig trustless in de standaardconfiguratie. De docker- images worden gebouwd en gehost door de Solana Foundation.

Houd er rekening mee dat je je project bouwt in een gedownloade docker-image en dat je volledige setup in die docker-image wordt gekopieerd voor de build, inclusief potentieel gevoelige informatie.

Als je een volledig trustless configuratie wilt, kun je de docker-images zelf bouwen en hosten op je eigen infrastructuur. Op deze manier kun je er zeker van zijn dat de docker-images niet zijn gemanipuleerd. Je vindt de scripts om je eigen docker-images te maken in de Verified builds repository en je kunt het forken en de github actions zelf uitvoeren of valideren dat ze correct zijn.

Bovendien vertrouw je voor de externe verificatie tot op zekere hoogte op de OtterSec API en de Solana Explorer.

De API of Solana Explorer kunnen mogelijk onjuiste informatie weergeven indien gecompromitteerd.

Als je een volledig trustless setup wilt hebben, kun je de Verify API zelf draaien of de programmaverificatie lokaal uitvoeren met het verify-from-repo commando, waarbij je gebruik maakt van de on-chain verificatiegegevens die zijn opgeslagen in een PDA die is afgeleid van de deploy authority van het programma en het verify programma.

Het verify programma is gedeployed door het OtterSec team en is nog niet bevroren, dus het kan op elk moment worden geüpgraded.

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 verified builds pipeline.

Security.txt voor Solana programma's

Naast verified builds kun je ook een security.txt bestand aan je programma toevoegen. In de toekomst, zodra geïmplementeerd, zal de security.txt de verifier public key bevatten voor eenvoudige toegang tot de verificatiegegevens die zijn opgeslagen in de verificatie PDA. De PDA die alle informatie bevat 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 die het programma heeft gebouwd en gedeployed. Maar het kan ook een andere pubkey zijn die kan worden gespecificeerd in de security.txt.

De security.txt functie stelt ontwikkelaars in staat om contact- en beveiligingsinformatie direct in hun Solana smart contracts in te bedden. 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, vooral kleinere of private projecten, kan het lastig en tijdrovend zijn om de ontwikkelaars te identificeren op basis van alleen het contractadres. Door een security.txt-bestand in het programma in te sluiten, kunnen beveiligingsonderzoekers gemakkelijk contact opnemen met de juiste personen, waardoor exploits mogelijk worden voorkomen en bugs tijdig worden gemeld.

Hoe security.txt te implementeren

Om een security.txt aan je Solana-programma toe te voegen, volg je de volgende stappen:

Voeg de solana-security-txt-dependency toe aan je Cargo.toml:

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

Gebruik de security_txt!-macro in je contract om je beveiligingsinformatie te definiëren. Je kunt contactgegevens, project-URL's en zelfs een beveiligingsbeleid toevoegen. 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 je programma is ingebed, kan deze eenvoudig worden opgevraagd via tools zoals de Solana Explorer, zodat je 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), is het aan te raden om naar een webpagina te linken in plaats van deze hard-coded in het contract op te nemen. Dit voorkomt de noodzaak van frequente programma-upgrades.

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

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

Door beveiligingscontactinformatie direct in je contract in te sluiten, maak je het voor onderzoekers gemakkelijker om je te bereiken, wat betere 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

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