Skip to main content
Questa pagina è il registro canonico delle revisioni di sicurezza indipendenti sui componenti di Intention. Dice che cosa è stato sottoposto ad audit, che cosa è in revisione e — cosa altrettanto importante — che cosa non è ancora stato sottoposto ad audit.

​
Stato attuale

Il bridge cross-chain è il componente sotto revisione di sicurezza indipendente. Il perimetro copre i contratti sulla catena esterna e l’infrastruttura di firma che li regge: custodia, verifica delle firme, il percorso di prelievo in due fasi con il suo periodo di contestazione, e la propagazione dell’insieme di validatori attraverso il confine fra le catene. La priorità data al bridge è deliberata. È l’unico componente il cui modello di sicurezza non è quello della rete: metà gira su un’altra catena, con validatori propri e modalità di guasto proprie, ed è il punto in cui una compromissione si traduce nel modo più diretto in fondi persi. Il resto del protocollo è verificabile rieseguendo i blocchi; un contratto di bridge su una catena esterna no. Il revisore e il report saranno pubblicati qui alla conclusione, con perimetro e risultanze.
Questo è l’unico audit indipendente attualmente in perimetro. Gli altri componenti — il kernel di esecuzione, il consenso e la stanza di compensazione — sono coperti dai controlli interni descritti qui sotto, non da una revisione esterna. L’assenza di un audit pubblicato non è prova dell’assenza di difetti. Regolati di conseguenza, soprattutto prima della mainnet.

​
Come leggere un report quando verrà pubblicato

Un audit utile risponde a tre domande: che cosa era in perimetro, che cosa hanno esaminato davvero i revisori e che cosa resta aperto alla pubblicazione. Ogni report pubblicato qui renderà esplicite tutte e tre.
  • Il perimetro è un hash di commit più un elenco enumerato di componenti. Un file o un contratto non elencato non è stato sottoposto ad audit.
  • Le risultanze sono classificate per gravità. Le risultanze a rischio accettato riportano la motivazione ed eventuali controlli mitiganti, invece di essere omesse.
  • Il diff rispetto all’audit è tracciato a parte. Ogni modifica successiva all’audit che tocca codice già revisionato viene segnalata, così puoi capire se il report pubblicato descrive ancora il sistema in esecuzione.
Quest’ultimo punto è quello che più spesso manca altrove. Un audit descrive un commit preciso. Il codice cambiato da allora è codice che nessuno ha rivisto, e un report che non lo dice sopravvaluta ciò che copre.

​
Revisione continua

Gli audit puntuali poggiano su controlli che vengono eseguiti di continuo:
  • Vincoli di revisione su ogni modifica al kernel, al consenso e al bridge.
  • Fuzzing e test basati su proprietà sulle macchine a stati di matching, rischio e regolamento, inclusi controlli di determinismo che rieseguono blocchi consolidati e confrontano i risultati byte per byte.
  • Test differenziali fra build indipendenti del motore: una divergenza è trattata come un bug di consenso, non come un test fallito.
  • Bug bounty pubblico per una copertura esterna continua.

​
Dove proseguire

Bug bounty

Perimetro, gravità e come segnalare una vulnerabilità.

Informativa sui rischi

Che cosa resta esposto, detto senza giri di parole.

Bridge

Il componente sotto revisione, e dove si collocano le sue ipotesi di fiducia.

Milestone

Che cosa è già rilasciato e che cosa è vincolato alle date che restano.
Le domande sul perimetro di un audit o su una risultanza specifica vanno a contact@intention.xyz. Le segnalazioni di vulnerabilità devono seguire il processo descritto nella pagina bug bounty, non essere sollevate qui.