Vai al contenuto
Financial Context Wiki

Rollup

Come i rollup eseguono transazioni, pubblicano dati e impegni, verificano transizioni di stato, regolano su un livello base e introducono rischi operativi specifici.

Aggiornato

Solo a scopo educativo; non è consulenza finanziaria, d’investimento, sui bridge o di sicurezza. Le garanzie di un rollup dipendono dai contratti distribuiti, dal sistema di prova, dalla disponibilità dei dati, dai permessi dell’operatore, dalla governance e dal livello base, tutti soggetti a modifiche.

Risposta diretta

Un rollup è un modello di scalabilità blockchain che esegue transazioni fuori da un livello base, usando quel livello per pubblicare dati o impegni definiti dal protocollo e regolare transizioni di stato contestate o provate. Molte transazioni condividono il costo dei dati e del regolamento sul livello base. Un rollup è quindi più della compressione e una state root da sola non fornisce i dati per ricostruire la catena.

I rollup ottimistici accettano in genere le dichiarazioni di stato salvo che una contestazione con prova di errore dimostri una transizione non valida. I rollup ZK inviano prove di validità verificate dal contratto di regolamento. Questi nomi descrivono l’accettazione delle transizioni, non una garanzia universale su decentralizzazione del sequencer, archiviazione, controllo degli aggiornamenti, commissioni o tempi di prelievo.

Come funziona

  • Ordinare ed eseguire. Un sequencer o altro meccanismo seleziona e ordina le transazioni e calcola lo stato risultante. L’utente può ricevere una ricevuta rapida prima della conferma sul livello base.
  • Pubblicare i dati. Il sistema pubblica dati di input sufficienti, spesso come calldata o blob, sul livello base oppure usa un’altra disponibilità dati. Questa determina se nodi indipendenti possono ricostruire e verificare lo stato.
  • Impegnare lo stato. Il rollup pubblica state root o altri impegni che lo vincolano a un risultato. L’impegno è compatto, ma non è la cronologia delle transazioni sottostante.
  • Verificare le transizioni. Il modello ottimistico dipende da una finestra di contestazione e un processo di prove di errore distribuito; quello ZK da una prova di validità e un verificatore on-chain. Errori, permessi e operatività contano in entrambi.
  • Regolare e prelevare. I contratti del livello base determinano accettazione e finalizzazione di messaggi e asset. I prelievi canonici possono subire ritardi di prova, contestazione o finalità; un bridge rapido aggiunge un fornitore di liquidità e rischio di controparte.
  • Aggiornare e recuperare. Governance, consigli di sicurezza, guardiani o amministratori possono sospendere o aggiornare contratti. Timelock, via di fuga e inclusione forzata vanno verificati sulla specifica distribuzione.

Esempio

Si supponga un batch di 1,000 transazioni. Gli utenti pagano insieme 0.8 ETH, i dati sul livello base costano 0.5 ETH e l’esecuzione del rollup 0.2 ETH. Il residuo non spiegato è 0.8 - 0.5 - 0.2 = 0.1 ETH, cioè 0.1 / 1,000 = 0.0001 ETH per transazione prima di generazione delle prove, infrastruttura, batch falliti, costo del capitale e rimborsi. È una riconciliazione dei costi, non profitto dell’operatore.

Prima di considerare finale il batch, verificare se la ricevuta proviene solo dal sequencer, se dati e impegno hanno raggiunto il livello base, se la finestra di prova di errore è terminata o la prova di validità è stata accettata e se il messaggio di prelievo è diventato separatamente eseguibile.

Rischi

  • Un sequencer centralizzato può censurare, riordinare o interrompere temporaneamente le transazioni.
  • Dati del batch mancanti o indisponibili possono impedire ricostruzione e uscite indipendenti.
  • Programmi di prova di errore, circuiti di validità, verificatori o client possono contenere bug.
  • Contestatori o produttori di prove possono essere offline, censurati, senza fondi o autorizzati male.
  • Congestione, riorganizzazione o guasto del livello base può ritardare pubblicazione, prova e regolamento.
  • Chiavi di aggiornamento, guardiani o governance possono cambiare codice, parametri o bridge.
  • Bridge canonici e mappature dei token possono fallire nonostante l’esecuzione corretta.
  • Commissioni, tempi di prova e ritardi di prelievo variano e possono cambiare dopo aggiornamenti.

Idee sbagliate comuni

  • Tutti i rollup conservano tutto per sempre sul livello base. Formati di pubblicazione e garanzie di archivio variano; i blob non sono memoria permanente.
  • Una ricevuta del sequencer è regolamento finale. Può essere solo una promessa iniziale di ordinamento.
  • ZK significa privato. Le prove di validità attestano il calcolo corretto; la privacy è una scelta separata.
  • Ottimistico significa senza verifica. La correttezza richiede dati riproducibili, un sistema di prove di errore funzionante e partecipanti capaci di contestare.
  • Commissioni medie inferiori eliminano il rischio operativo. Il regolamento condiviso può ridurre i costi, ma restano dipendenze da sequencer, prove, governance, bridge e dati.

Argomenti correlati

Fonti

Navigazione

Cerca nella wiki...