Vai al contenuto
Financial Context Wiki

ZK rollup

Guida orientata alla verifica di batch, prove di validità, disponibilità dei dati, stati di regolamento, commissioni, prelievi e rischi specifici dei deployment ZK rollup.

Aggiornato

Solo a scopo educativo; non è consulenza su investimenti, bridge o sicurezza. Un ZK rollup è affidabile solo quanto il programma provato, gli input pubblici, il percorso di disponibilità dei dati, i contratti, gli operatori, la governance e la catena di regolamento.

Risposta diretta

Uno ZK rollup, più precisamente un rollup di validità, esegue transazioni fuori da una catena di regolamento, le raggruppa in batch e invia impegni sui dati, dichiarazioni di stato e prove di validità ai contratti su quella catena. Il verificatore controlla le regole di transizione codificate senza rieseguire ogni transazione. I costi di pubblicazione e verifica vengono così ripartiti su molte transazioni.

La garanzia è specifica, non assoluta. Una prova verificata sostiene solo l’affermazione codificata dal programma distribuito e vincolata dagli input pubblici. Non dimostra da sola che i dati siano recuperabili, il sequencer attivo o equo, il blocco finale, il bridge corretto o un aggiornamento sicuro. “ZK” non implica neppure privacy: molti rollup pubblicano transazioni o differenze di stato.

1
Eseguire

Il prover esegue un batch o un calcolo e registra la transizione di stato risultante.

Come funziona

  1. Identificare il deployment: chain ID L1 e L2, contratti rollup e bridge, verificatore e versione della chiave, programma o circuiti provati, formato batch, modalità DA, sequencer, prover, amministratori, poteri di pausa e blocco osservato. Il nome dello stack non garantisce ogni deployment.
  2. Separare ordinamento e prova. Il sequencer può fornire una ricevuta e blocchi L2 prima che impegno o prova raggiungano L1. Registrare il batch esatto e distinguere ordinato, impegnato, provato, accettato, sicuro sul regolamento, finalizzato e prelievo completato.
  3. Ricostruire il batch. Ottenere transazioni, differenze di stato, blob sidecar o altro payload richiesto; verificare ordine e impegni; derivare radici precedente e nuova, radice di prelievi o messaggi e altri input pubblici. Una prova legata a catena, batch o radice errati prova un’altra affermazione.
  4. Verificare il percorso della prova. Confermare che la transazione abbia chiamato il verificatore previsto con prova, chiave e input attesi, sia riuscita, abbia emesso l’evento corretto e aggiornato lo slot giusto. Quando possibile, riprodurre verifica ed esecuzione con software indipendente.
  5. Verificare separatamente la disponibilità. I blob Ethereum offrono disponibilità nella finestra di protocollo e impegni, non archiviazione permanente. Un comitato esterno o livello DA alternativo aggiunge ipotesi proprie. Una prova valida non recupera dati mancanti necessari a ricostruire lo stato o uscire.
  6. Seguire depositi e prelievi da capo a fondo. Conciliare token e messenger canonici, importo, destinazione, nonce, radice di inclusione, prova, regola di finalità e saldo eseguito. Un bridge rapido anticipa liquidità con prezzi, instradamento e rischio di controparte propri; non accorcia l’orologio canonico.
  7. Monitorare operatività e controllo. Misurare arretrati di batch e prove, inclusione forzata e vie di uscita, diversità dei prover, upgrade, timelock, guardiani e modalità di emergenza. Ripetere dopo modifiche a contratto, circuito, chiave, DA o protocollo.

Esempi calcolati

  • Compressione. Un batch didattico contiene 10,000 transactions; 1,200 KB di input grezzo diventano 300 KB. Rapporto: 1,200 / 300 = 4.0x, riduzione: 1 - 300 / 1,200 = 75%, media decimale: 300,000 / 10,000 = 30 bytes/transaction. Non misurano solidità, crescita dello stato o archiviazione.
  • Ripartizione dei costi. Gli utenti pagano 3.0 ETH; dati L1 1.4 ETH, verifica 0.4 ETH, esecuzione L2 0.2 ETH. Il residuo è 3.0 - 1.4 - 0.4 - 0.2 = 1.0 ETH e la media 3.0 / 10,000 = 0.0003 ETH/transaction. Non è profitto netto: esclude proving, hardware, errori, bridge, capitale e imposte.
  • Ciclo di vita. Ricevuta a minute 0, impegno L1 a minute 12, prova accettata a minute 50, politica di finalità soddisfatta a minute 64 e prelievo canonico a minute 70. Tempo sequenziale: 12 + 38 + 14 + 6 = 70 minutes. Nessun istante precedente equivale al prelievo completato.

Rischi

  • Catena, deployment, contratto, batch, radice, verificatore, chiave o circuito errati.
  • Programma provato incompleto o sbagliato, fedelmente provato da un sistema solido.
  • Input pubblici, separatori di dominio, messaggi o parametri assenti o mal codificati.
  • Vulnerabilità di verificatore, precompilato, bridge, messenger o contratto di stato.
  • Materiale di setup compromesso o ipotesi crittografiche violate.
  • Censura, riordino, equivoco, fermo o pubblicazione tardiva del sequencer.
  • Fermo, centralizzazione, censura, scarsa capacità o arretrato crescente del prover.
  • Transazioni, differenze di stato o blob sidecar indisponibili, malformati o non archiviati.
  • Scambiare impegno o firma del comitato per recuperabilità attuale.
  • Riorganizzazione L1 o fiducia prematura in un regolamento non sicuro.
  • Upgrade privilegiati, timelock brevi, sostituzione, pause o bypass di emergenza.
  • Inclusione forzata, recupero o uscita assenti, disabilitati o inutilizzabili.
  • Bug del bridge canonico, mapping errato, replay, messaggi o prove di prelievo falliti.
  • Rischi di liquidità, prezzo, routing, insolvenza e controparte dei bridge rapidi.
  • Stime senza dati L1, proving, bridge, congestione o transazioni fallite.
  • Applicare a un rollup compatibilità EVM, finalità, privacy o sicurezza di un altro.

Errori comuni

  • Ogni ZK rollup nasconde importi, indirizzi e attività applicativa.
  • Una prova valida garantisce dati disponibili e ricostruzione dello stato.
  • Ricevuta del sequencer, prova accettata su L1 e prelievo finale sono equivalenti.
  • Le prove eliminano rischi di sequencer, prover, governance, upgrade e bridge.
  • Il sistema più economico o rapido produce automaticamente l’esito più sicuro.

Argomenti correlati

Fonti

Navigazione

Cerca nella wiki...