Riepilogo Tecnico: Integrazione Sicura di AltDA per gli Ethereum L2

Definizione del Problema

I sistemi di Disponibilità dei Dati Alternativi (AltDA) consentono ai rollup Ethereum Layer 2 (L2) di scalare pubblicando dati massivi su reti esterne (ad es. Celestia, EigenDA, Avail) inviando all'Ethereum solo riferimenti compatti. Sebbene ciò allevi i colli di bottiglia del throughput della disponibilità dei dati (DA) nativa di Ethereum, introduce una lacuna critica di sicurezza al confine dell'integrazione.

Gli attuali framework dell'ecosistema identificano rischi di alto livello, come le assunzioni di fiducia nei confronti del fornitore di DA o l'esistenza di un verificatore di DA. Tuttavia, essi non forniscono una specifica completa su come un L2 debba integrarsi con l'AltDA. Questa mancanza di una specifica rigorosa end-to-end crea "lacune di conoscenza" in cui:

1. I Verificatori di DA possono autenticare un'asserzione relativa a dati esterni senza provare che lo stato dell'L2 sia derivato da quei dati specifici.
2. Gli Impegni (Commitments) possono essere validi al momento della creazione, ma insicuri da consumare successivamente se il sistema di DA elimina i dati (pruning) o se la finestra temporale per il recupero scade.
3. L'Ambiguità può esistere laddove un impegno valido si vincoli a un blob che si decodifica in più payload di rollup o in payload non canonici.

Queste lacune possono portare a gravi modalità di fallimento, inclusi arresti degli L2, derivazioni inconsistenti tra nodi onesti, asserzioni di stato non valide e attacchi ai bridge dove i fondi vengono prelevati sulla base di transizioni di stato non verificate o conflittuali.

Metodologia

Il documento propone un framework di validazione canonica che modella il confine di integrazione AltDA come una pipeline di traduzione tipizzata, deterministica e totale. Gli autori definiscono il flusso come:
$$\text{InboxBytes} \rightarrow \text{AltDACommitment} \rightarrow \text{Blob} \rightarrow \text{RollupPayload}$$

La metodologia centrale consiste nel definire una Funzione di Validazione Totale ($F$) che mappa qualsiasi stringa di byte arbitraria dall'inbox L1 esattamente a uno di tre esiti:

1. RollupPayload(p): Un payload unico e valido per la logica di esecuzione dell'L2.
2. Drop (Scarto): Un input non valido che deve essere rifiutato deterministicamente.
3. Stall (Stallo): Una condizione temporanea (ad es. indisponibilità dei dati) che interrompe l'elaborazione ma non causa un fallimento del consenso, soggetta a politiche di riprova/timeout.

Il framework identifica sei obblighi semantici che devono essere applicati attraverso questa pipeline:

• Parsing Canonico: Gestione di byte arbitrari dell'inbox senza crash specifici dell'implementazione.
• Verifica della DA: Validazione del fatto che l'impegno sia autentico sotto il sistema di DA esterno.
• Recency (Recenza): Assicurazione che l'impegno sia abbastanza recente da permettere alle parti oneste di recuperare i dati entro la finestra di regolamento (settlement window).
• Vincolo Impegno-Blob (Commitment-to-Blob Binding): Prova che il blob recuperato corrisponda unicamente all'impegno.
• Unicità del Payload: Assicurazione che il blob si decodifichi in esattamente un payload di rollup canonico.
• Gestione Deterministica dei Fallimenti: Assicurazione che tutti gli input non validi risultino in un definito Drop o Stall piuttosto che in un comportamento indefinito.

Gli autori analizzano tre pattern di integrazione per determinare dove questi obblighi possono essere applicati:

1. Fault Proof Interattivo: Applicazione della validazione della DA all'interno del processo di risoluzione delle dispute.
2. Validity Proof: Inclusione della relazione di DA (verifica, vincolo, recenza) all'interno della dichiarazione della prova succinta.
3. Eager Inbox Verification (Verifica Anticipata dell'Inbox): Validazione degli impegni a livello del contratto dell'inbox L1 prima che entrino nella pipeline di derivazione.

Contributi Chiave

1. Modello di Validazione Tipizzato: Il documento introduce un modello formale che separa i byte dell'inbox L1, gli impegni AltDA, i blob esterni e i payload di rollup, chiarendo che la validità in un dominio non implica la validità in un altro.
2. Obblighi Semantici: Definisce esplicitamente i sei obblighi centrali richiesti per un'integrazione sicura, andando oltre le classificazioni di rischio di alto livello verso requisiti semantici concreti.
3. Tassonomia degli Attacchi: Gli autori derivano vettori di attacco concreti derivanti dalla mancanza di obblighi, tra cui:
   • Regolamento sotto-vincolato (Under-constrained settlement): Dove una transizione di stato viene accettata senza essere vincolata ai dati autenticati.
   • Arresti della derivazione: Dove input non validi causano il crash o la divergenza dei nodi onesti.
   • Fallimenti della sicurezza dei bridge: Dove vengono accettate rivendicazioni di stato conflittuali a causa di un legame dei dati ambiguo.
4. Valutazione di Architetture Rappresentative: Il framework viene applicato a integrazioni reali, incluse Celestia-Blobstream (OP e Arbitrum), EigenDA (OP e Arbitrum) e Avail-ZKsync. L'analisi rivela quali obblighi sono garantiti da componenti specifici (ad es. bridge di DA, contratti di inbox, sistemi di prova) e identifica le aree in cui le specifiche sono attualmente "non identificate" o richiedono ulteriori audit.

Risultati

La valutazione delle integrazioni esistenti dimostra che la presenza di un verificatore di DA o di un bridge è insufficiente per la sicurezza.

• Integrazioni Celestia: Sebbene Blobstream fornisca autenticazione, l'analisi ha rilevato che alcuni design (ad es. Hana/OP) mancavano di un'applicazione esplicita end-to-end della relazione di vincolo tra l'impegno autenticato e i dati consumati dalla derivazione. Anche le regole di recenza non sono state esplicitamente identificate nei materiali esaminati.
• Integrazioni EigenDA: Questi design (ad es. Hokulea/OP e Arbitrum) hanno mostrato un maggiore allineamento con il framework. L'integrazione di Arbitrum utilizza la "verifica anticipata" (eager verification) all'inbox, mentre l'integrazione di OP si affida alle prove di validità per imporre il predicato di DA. Gli autori non hanno trovato controlli mancanti nei pattern esaminati, pur sottolineando che questo non è una prova di sicurezza completa.
• Avail-ZKsync: Similmente a EigenDA, utilizza la verifica anticipata all'inbox. Tuttavia, come nel caso di Celestia, una condizione di recenza esplicita legata alla finestra di regolamento non è stata identificata nelle specifiche pubbliche.

I risultati confermano che l'integrazione sicura di AltDA non è determinata esclusivamente dal fornitore di DA, ma è una proprietà dell'intero stack di integrazione L2.

Significato e Rivendicazioni

Il documento sostiene che l'integrazione sicura di AltDA è una proprietà end-to-end del percorso di inbox, derivazione, prova e regolamento, piuttosto che una proprietà del fornitore di DA o di una singola chiamata di verifica.

Gli autori sostengono che l'industria si sia concentrata troppo sul "verificatore di DA" (che risponde se un fatto riguardante un sistema esterno è vero) e abbia trascurato la "relazione di integrazione" (che risponde se ogni input avversario al confine L2 conduce a un esito deterministico ed esigibile tramite regolamento).

Il significato di questo lavoro risiede nello spostamento del paradigma di sicurezza:

• Sposta il focus dalle "assunzioni di fiducia" agli "obblighi di validazione".
• Fornisce una specifica rigorosa per auditor e sviluppatori per garantire che lo strato di regolamento dell'L2 imponga la piena relazione tra gli input L1 e gli stati L2 accettati.
• Evidenzia come, senza l'applicazione di questa semantica di validazione totale, gli L2 affrontino rischi di regolamento sotto-vincolato e attacchi ai bridge, indipendentemente dalla forza crittografica del sistema di DA sottostante.

Il documento conclude che, man mano che gli L2 supportati da AltDA proteggono un valore sempre crescente, il confine di integrazione deve essere specificato e verificato con lo stesso rigore dei sistemi di esecuzione e regolamento del rollup stesso.