Questa guida è pensata come riferimento per gli sviluppatori che vogliono implementare build verificate per i loro programmi su Solana. Tratteremo cosa sono le build verificate, come utilizzarle, considerazioni speciali e best practice per garantire l'autenticità del tuo programma sulla blockchain.

Cosa sono le build verificate?

Le build verificate assicurano che il programma eseguibile che distribuisci sulla rete di Solana corrisponda al codice sorgente nel tuo repository. Grazie a questo, sviluppatori e utenti possono avere la certezza che il programma in esecuzione sulla blockchain corrisponda esattamente alla base di codice pubblica, promuovendo trasparenza e sicurezza.

Il processo di verifica prevede il confronto dell'hash del programma sulla blockchain con l'hash del programma compilato localmente dal codice sorgente. Questo garantisce che non ci siano discrepanze tra le due versioni.

Sebbene una build verificata non debba essere considerata più sicura di una build non verificata, la build permette agli sviluppatori di verificare autonomamente che il codice sorgente corrisponda a ciò che è distribuito sulla blockchain. Utilizzando il codice sorgente, uno sviluppatore può quindi validare cosa esegue il codice quando invia una transazione.

La pipeline di build verificate è stata ideata e viene mantenuta da Ellipsis Labs e OtterSec. Per maggiori dettagli, segui la guida nel repository originale delle build verificate e il processo di verifica della build direttamente nella suite di strumenti Anza, una volta supportato.

Come funziona?

Il processo di verifica viene effettuato confrontando l'hash del programma onchain con l'hash del programma compilato localmente dal codice sorgente. Compili il tuo programma in un ambiente controllato utilizzando Solana Verify CLI e Docker. Questo garantisce che il processo di compilazione sia deterministico e coerente su diversi sistemi. Una volta ottenuto l'eseguibile, puoi distribuirlo sulla rete Solana. Durante il processo di compilazione verrà creato un PDA del programma verify. Questo PDA contiene tutti i dati necessari per verificare il programma. Il PDA contiene l'indirizzo del programma, l'URL git, l'hash del commit e gli argomenti utilizzati per compilare il programma.

Utilizzando i dati nel PDA, chiunque può eseguire localmente il comando del programma verify e controllare se il programma è stato compilato dal codice sorgente fornito. Quindi tutti possono verificare autonomamente in modo completamente trustless o possono eseguire la propria API di verifica mantenuta da OtterSec per fornire un punto di accesso facile agli utenti per controllare la verifica. Puoi già vedere queste chiamate API utilizzate in Solana Explorer e SolanaFM, tra gli altri.

Perché dovrei usare build verificate?

L'utilizzo di build verificate offre i seguenti vantaggi:

• Sicurezza: garantisce che il programma in esecuzione onchain corrisponda al codice sorgente, prevenendo alterazioni dannose.

• Trasparenza: permette ad altri utenti e sviluppatori di convalidare che il programma onchain sia affidabile confrontandolo con il codebase pubblico.

• Fiducia: aumenta la fiducia degli utenti, poiché le build verificate dimostrano che il comportamento onchain del tuo programma è allineato con il tuo codice pubblico. Quando costruisci programmi verificabili, riduci al minimo i rischi associati all'esecuzione di codice non autorizzato o dannoso. Garantisce inoltre che tu rispetti le migliori pratiche e offri ai ricercatori di sicurezza un modo semplice per contattarti. Anche i wallet e altri strumenti possono consentire più facilmente le transazioni dal tuo programma finché è verificato.

• Individuabilità: quando fornisci una build verificata del tuo programma, tutti possono trovare il tuo codice sorgente, la documentazione, l'SDK o l'IDL del programma e possono anche contattarti facilmente tramite GitHub in caso di problemi.

Come creo build verificate?

Per creare build verificate, dovrai seguire questi passaggi:

Riepilogo:

• Effettua il commit del tuo codice in un repository pubblico
• Crea una build verificata in Docker
• Distribuisci la build verificata
• Verifica il programma distribuito tramite API pubblica

Se verifichi il tuo programma che non è stato compilato in un container Docker, molto probabilmente fallirà perché le build dei programmi Solana non sono deterministiche su sistemi diversi.

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 remote submit-job --program-id <program-id> --uploader <address>

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

Come verificare il tuo programma quando è controllato da un Multisig come Squads

Affinché la verifica remota funzioni, è necessario scrivere i dati di verifica in un PDA firmato dall'autorità del programma. Se il tuo programma è controllato da un multisig, puoi esportare questa transazione di scrittura PDA e inviarla tramite Squads Protocol o un'altra soluzione multisig a tua scelta.

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

Verifica da immagine Docker

Puoi anche verificare il tuo programma rispetto a un'immagine Docker eseguendo il seguente comando:

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

Questo comando carica l'immagine salvata in ellipsislabs/hello_world_verifiable_build:latest e verifica che l'hash del percorso dell'eseguibile nel container sia lo stesso dell'hash del programma on-chain fornito al comando. Poiché la build è già stata caricata su un'immagine, non è necessaria una ricostruzione completa dell'eseguibile, che potrebbe richiedere molto tempo.

Il Dockerfile che crea l'immagine ellipsislabs/hello_world_verifiable_build:latest si trova nel repository di Ellipsis Labs /examples/hello_world.

Di seguito è riportato l'output atteso:

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 ✅

Esempio di build verificata

Ecco un esempio di verifica di un programma di esempio con ID FWEYpBAf9WsemQiNbAewhyESfR38GBBHLrCaU3MpEKWv utilizzando il codice sorgente di questo 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

Per impostazione predefinita, il comando verify-from-repo prende l'ultimo commit sul branch main. È anche possibile definire un commit specifico nel caso in cui si voglia continuare a lavorare sul repository utilizzando il parametro commit-hash: --commit-hash 5b82b86f02afbde330dff3e1847bed2d42069f4e

Quando richiesto, rispondere sì per caricare il PDA di verifica onchain. Quindi inviare un lavoro di verifica remota tramite le API di OtterSec:

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

Programmi popolari già verificati

Phoenix

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

Output finale:

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

Si noti che è stato necessario specificare library-name perché il repository di Squads include più programmi. Utilizziamo il flag --bpf perché squads_mpl è stato precedentemente verificato con Anchor.

Output finale:

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

Output finale:

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

Output finale:

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

Domande frequenti

La mia verifica non riesce. Cosa devo fare?

Controlla questi problemi comuni:

• Firmatario errato: Conferma che il tuo firmatario sia l'autorità di aggiornamento del programma eseguendo solana program show YourProgramId
• Nessun PDA onchain: Esegui solana-verify verify-from-repo -um e seleziona SÌ quando richiesto. Senza caricare il PDA, l'API non può recuperare i metadati di verifica.
• Dati PDA non corrispondenti: Aggiorna il tuo PDA se hai ridistribuito il programma. I dati del PDA devono corrispondere al programma distribuito.
• Hash del commit errato: Crea il tuo PDA utilizzando l'hash del commit esatto che hai distribuito
• Differenze nell'ambiente di build: Usa Docker con solana-verify quando crei il tuo PDA

L'hash della mia build locale non corrisponde all'hash onchain. Perché?

Di solito significa:

• Stai utilizzando versioni diverse della toolchain Rust/Solana
• Le tue dipendenze sono state aggiornate tra una build e l'altra
• Non hai eseguito la build in un container Docker
• Hai estratto il commit sbagliato

Risolvi il problema eseguendo la build con solana-verify build in Docker utilizzando il commit esatto che hai distribuito.

Quanto tempo richiederà la mia verifica?

Aspettati questi tempi in base alla dimensione del tuo programma:

• Programmi semplici: 1-5 minuti
• Programmi complessi: 5-15 minuti
• Programmi molto grandi: fino a 30 minuti

Monitora il progresso utilizzando l'endpoint di stato del job.

Il mio programma è immutabile (nessuna autorità di aggiornamento). Come posso verificarlo?

Se il tuo programma non ha un'autorità di aggiornamento o è stato reso immutabile prima che tu potessi creare un PDA, abbiamo un indirizzo nella whitelist per questa situazione. Contattaci all'indirizzo contact@osec.io e ti aiuteremo a far verificare il tuo programma.

Cos'è il PDA e perché è importante?

Il tuo PDA (Program Derived Account) consente la verifica trustless:

• Archiviazione On-Chain: Memorizza i metadati di verifica (URL del repository, hash del commit, parametri di build) onchain in un PDA di proprietà del programma Otter Verify (verifycLy8mB96wd9wqq3WDXQwM4oU6r42Th37Db9fC)
• Collegamento Crittografico: Il tuo PDA è derivato dall'indirizzo del tuo programma, creando un collegamento immutabile ai tuoi dati di verifica
• Fiducia Decentralizzata: Chiunque può leggere il tuo PDA e verificare indipendentemente il tuo programma

Perché devo creare il PDA prima di utilizzare l'API?

L'API funziona esclusivamente con PDA onchain perché:

• Trustless: L'API rifiuta dati arbitrari - utilizza solo ciò che la tua upgrade authority ha memorizzato onchain
• Più Semplice: Basta fornire il signer + program_id; l'API recupera tutto il resto dal tuo PDA
• A Prova di Manomissione: Il tuo PDA crea un registro immutabile che chiunque può verificare in modo indipendente
• Prova di Proprietà: Il tuo signer deve essere l'upgrade authority, dimostrando crittograficamente che controlli il programma

Con quale frequenza dovrei verificare il mio programma?

Verifica il tuo programma:

• Dopo ogni distribuzione o aggiornamento
• Quando aggiorni il tuo repository sorgente
• Non preoccuparti di ri-verificare in altri casi - l'API ri-verifica automaticamente tutti i programmi ogni 24 ore

Cosa succede quando aggiorno il mio programma?

Segui questi passaggi dopo l'aggiornamento:

1. L'API rileva il tuo aggiornamento e annulla la verifica del tuo programma.
2. Aggiorna il tuo PDA con i nuovi metadati di verifica:

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

3. Invia una nuova richiesta di verifica utilizzando la tua upgrade authority
4. L'API verificherà la tua nuova versione rispetto al PDA aggiornato

Importante: Aggiorna sempre il tuo PDA utilizzando la tua upgrade authority con il nuovo hash del commit per il programma aggiornato.

Posso fidarmi dei risultati della verifica?

Sì - il sistema è progettato per essere trustless e verificabile in modo indipendente:

Cosa lo rende affidabile:

• PDA on-chain: I metadati della tua verifica risiedono on-chain, non controllati da alcuna autorità centrale
• Prova dell'autorità di aggiornamento: Solo l'autorità di aggiornamento del tuo programma può creare/aggiornare il PDA
• Verifica indipendente: Chiunque può verificare leggendo il tuo PDA ed eseguendo solana-verify in locale
• Riverifica continua: L'API riverifica automaticamente tutti i programmi ogni 24 ore

Comprendi queste limitazioni:

• La verifica conferma che il sorgente corrisponde al deployment - NON che il tuo codice è sicuro
• Rivedi sempre il codice prima di interagire con i programmi
• Verificato ≠ sottoposto ad audit, o sicuro
• Controlla il repository e il commit nel PDA per confermare che provenga da una fonte attendibile

Come posso verificare un programma in modo indipendente?

Verifica qualsiasi programma autonomamente leggendo il suo PDA on-chain ed eseguendo la verifica in locale:

Passo 1: Leggi il PDA on-chain

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

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

Passo 2: Verifica in locale

# 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

Questo dimostra:

1. I metadati del PDA sono autentici (archiviati on-chain)
2. Il codice sorgente nel repository del PDA corrisponde al programma distribuito
3. Non hai bisogno di fidarti dell'API - verifica tutto tu stesso on-chain

Qualcun altro può verificare il mio programma senza autorizzazione?

Sì, è proprio per questo motivo che richiediamo che il firmatario sia l'autorità di aggiornamento. Consideriamo la verifica valida solo se il firmatario è l'autorità di aggiornamento.

Cosa mi serve per creare build verificabili?

Installa questi strumenti:

• Docker (per build deterministiche)
• Cargo (gestore di pacchetti Rust)
• Solana Verify CLI: cargo install solana-verify
• Un repository Git pubblico con il tuo codice sorgente

Posso verificare repository privati?

No - la verifica richiede il codice sorgente pubblico:

• Il tuo PDA memorizza un URL di repository pubblico accessibile a tutti
• La verifica trustless dipende dall'accesso al codice pubblico
• Gli utenti devono poter leggere il tuo codice sorgente per capire cosa fa il tuo programma
• Lo scopo principale è consentire agli utenti di verificare in modo indipendente che il sorgente corrisponda al deployment

I repository privati compromettono il modello di fiducia fondamentale del sistema di verifica.

Come verifico un programma controllato da Squads Multisig?

Segui questi passaggi per i programmi controllati da 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...

Importante: Verifica sempre in locale (passaggio 2) per confermare che l'hash di build corrisponda prima di esportare la transazione PDA.

Conclusione

Utilizzare build verificate su Solana garantisce l'integrità e l'affidabilità dei tuoi programmi sulla rete e consente agli sviluppatori di trovare i tuoi SDK direttamente da Solana Explorer. Sfruttando strumenti come Solana Verify CLI e Docker, puoi mantenere build verificabili e sicure in linea con il tuo codice sorgente. Adotta sempre le precauzioni necessarie per utilizzare ambienti coerenti e considera soluzioni di governance per aggiornamenti e deployment sicuri.

Sicurezza + Disclaimer

Sebbene le build verificate siano uno strumento potente per garantire l'integrità dei tuoi programmi Solana, la configurazione predefinita non è completamente trustless. Le immagini Docker sono create e ospitate dalla Solana Foundation.

Tieni presente che stai compilando il tuo progetto all'interno di un'immagine Docker scaricata e che l'intera configurazione, incluse potenzialmente informazioni sensibili, viene copiata in quell'immagine Docker durante la build.

Se desideri una configurazione completamente trustless, puoi creare le immagini Docker autonomamente e ospitarle sulla tua infrastruttura. In questo modo puoi essere certo che le immagini Docker non siano state manomesse. Puoi trovare gli script per creare le tue immagini Docker nel repository Verified builds e puoi eseguirne il fork, eseguire le GitHub Actions autonomamente o verificare che siano corrette.

Inoltre, per la verifica remota, ti affidi all'API di OtterSec e a Solana Explorer fino a un certo grado.

L'API o Solana Explorer potrebbero potenzialmente visualizzare informazioni errate se compromessi.

Se vuoi una configurazione completamente trustless, puoi eseguire autonomamente la Verify API oppure eseguire la verifica del programma in locale utilizzando il comando verify-from-repo e i dati di verifica on-chain salvati in un PDA derivato dall'autorità di deploy del programma e dal verify program.

Il verify program è distribuito dal team OtterSec e non è ancora congelato, quindi può essere aggiornato in qualsiasi momento.

La Solana Foundation, OtterSec e il team di Ellipsis Labs non sono responsabili di eventuali perdite o danni che potrebbero verificarsi dall'utilizzo della pipeline di build verificate.

Security.txt per i programmi Solana

Oltre alle build verificate, puoi anche aggiungere un file security.txt al tuo programma. In futuro, una volta implementato, security.txt conterrà la chiave pubblica del verificatore per un accesso facilitato ai dati di verifica memorizzati nel PDA di verifica. Il PDA contenente tutte le informazioni necessarie per compilare e verificare un programma è derivato dall'indirizzo del programma e dal pubkey del verificatore. Per impostazione predefinita, si tratta dello stesso pubkey che ha compilato e distribuito il programma, ma può essere anche un altro pubkey specificabile nel file security.txt.

La funzionalità security.txt consente agli sviluppatori di incorporare informazioni di contatto e di sicurezza direttamente nei loro smart contract Solana. Ispirata a securitytxt.org, questa soluzione offre un metodo standardizzato per consentire ai ricercatori di sicurezza di contattare i responsabili del progetto, anche se conoscono solo l'indirizzo del contratto.

Perché usare security.txt?

Per molti progetti, specialmente quelli più piccoli o privati, identificare gli sviluppatori partendo solo dall'indirizzo del contratto può essere difficile e dispendioso in termini di tempo. Includere un file security.txt nel programma garantisce che i ricercatori di sicurezza possano contattare facilmente le persone giuste, prevenendo potenziali exploit e assicurando segnalazioni di bug tempestive.

Come implementare security.txt

Per aggiungere un security.txt al tuo programma Solana, segui i passaggi seguenti:

Aggiungi la dipendenza solana-security-txt al tuo Cargo.toml:

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

Usa la macro security_txt! nel tuo contratto per definire le informazioni di sicurezza. Puoi includere dettagli di contatto, URL del progetto e persino una policy di sicurezza. Ecco un esempio:

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

Una volta che le informazioni security.txt sono incorporate nel tuo programma, possono essere facilmente consultate tramite strumenti come Solana Explorer, garantendo che i tuoi dettagli di contatto e di sicurezza siano disponibili a chiunque voglia segnalare potenziali problemi.

Best practice

• Usa i link: Per le informazioni soggette a cambiamenti (ad es. i dettagli di contatto), si consiglia di rimandare a una pagina web anziché inserirle direttamente nel contratto. Questo evita la necessità di frequenti aggiornamenti del programma.

• Verifica: Prima del deployment, verifica il formato e il contenuto usando lo strumento query-security-txt, che può validare sia i programmi onchain che i binari locali:

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

Incorporando le informazioni di contatto per la sicurezza direttamente nel tuo contratto, rendi più semplice per i ricercatori contattarti, favorendo una maggiore sicurezza e comunicazione all'interno dell'ecosistema Solana.

Questo è un esempio di come appare security.txt in Solana Explorer

Il progetto security.txt è mantenuto da Neodyme Labs

Puoi verificare lo stato di verifica e consultare i programmi verificati su verify.osec.io.