Vai al contenuto
Financial Context Wiki

Reti Layer 2

Guida specifica per deployment a esecuzione, disponibilità dei dati, validazione dello stato, settlement, finalità, sequencer, governance, bridge, commissioni e uscite eseguibili nelle Layer 2.

Aggiornato

Solo a scopo educativo; non costituisce consulenza né raccomandazione d’investimento. Gli investimenti possono comportare perdite.

Risposta diretta

Una Layer 2 è un protocollo che esegue o coordina attività al di fuori di una chain di base, affidandosi a quest’ultima per una parte definita di validazione, disponibilità dei dati, settlement o applicazione delle uscite. L’etichetta non è uno standard universale. Un rollup che pubblica dati sufficienti e impone le transizioni di stato tramite fault proof o prove di validità presenta ipotesi di fiducia diverse da un validium, state channel, sidechain, bridge multisig o registro di un exchange, anche se tutti i prodotti si definiscono L2.

Per un deployment specifico occorre chiedere cosa accetta effettivamente il contratto L1, dove risiedono i dati di derivazione, chi ordina le transazioni, come viene rifiutato uno stato non valido, quando un blocco diventa safe o finalized, chi può aggiornare o mettere in pausa il sistema e se un utente può uscire senza l’operatore. Conferme più rapide e commissioni inferiori sono proprietà utili, ma da sole non dimostrano sicurezza ereditata.

Come funziona

  1. Fissare l’identità del sistema: chain ID di L1 e L2, genesi e fork, stack e versione del rollup, contratti di settlement e bridge, implementazioni proxy, tipo di prova o gioco di disputa, modalità di disponibilità dei dati, sequencer e riferimenti dei blocchi. Trattare il nome del sito e il termine L2 come metadati di individuazione, non come autenticazione.
  2. Classificare l’architettura su assi separati. Registrare ambiente di esecuzione, modello di ordinamento, meccanismo di validazione dello stato, ubicazione dei dati, chain di settlement e percorso di custodia. Optimistic e validity rollup, validium, channel e sidechain combinano questi assi diversamente; un motore compatibile con EVM non rende equivalenti le rispettive sicurezze.
  3. Ricostruire la pipeline dello stato. Seguire invio dell’utente, ordinamento del sequencer, esecuzione L2, codifica del batch, pubblicazione dei dati, state commitment, contestazione tramite fault proof o verifica della prova di validità, inclusione L1 e finalità L1. Verificare che software indipendente possa derivare lo stato L2 dichiarato dagli input definiti dal protocollo.
  4. Separare disponibilità e liveness. Determinare se i dati risiedono in calldata o blob L1, in un sistema DA esterno o presso un comitato; individuare le ipotesi di conservazione e recupero. Testare indisponibilità del sequencer, inclusione forzata, invio alternativo, guasto di proposer o prover, inoltro dei messaggi e percorso esatto di escape o prelievo.
  5. Separare tempi ed etichette di stato. Un blocco confermato dal sequencer o unsafe può precedere la pubblicazione dei dati; un blocco safe può precedere la finalità L1; accettazione della prova, risoluzione della disputa, maturazione del prelievo e rilascio del bridge possono aggiungere vincoli indipendenti. Usare le definizioni del deployment, non un numero universale di conferme o una regola fissa di sette giorni.
  6. Mappare controllo ed economia. Esaminare amministratori dei proxy, ritardi di aggiornamento, poteri di security council e guardian, stato di pausa, scalari delle commissioni, token del gas, capacità del batch e destinatari delle commissioni. Tenere registri separati per esecuzione L2, pubblicazione L1 o DA, addebiti dell’operatore, commissioni del bridge, gas di destinazione e costo dell’attesa; una quotazione non garantisce l’esecuzione.
  7. Riconciliare gli esiti dell’utente. Verificare contratto e rappresentazione esatti del token, addebito all’origine, accredito a destinazione, status della ricevuta, radici di stato e messaggio, hash dei blocchi safe e finalized, approvazioni residue e un riscatto o un’uscita di mercato eseguibile. Ricontrollare la configurazione dopo ogni aggiornamento e non dedurre la sicurezza del bridge dal sistema di prove del rollup.

Esempi svolti

  • Economia del batch. Un batch contiene 2,000 transazioni con una media di 160 bytes dopo la compressione più 20,000 bytes di framing fisso, per 340,000 bytes. A $0.00002/byte, i dati costano $6.80; aggiungendo $4.00 di costo fisso per prova e settlement si ottengono $10.80, ovvero $0.0054/transaction. Con sole 200 transazioni, le stesse ipotesi producono 52,000 bytes, $1.04 di costo dati e $5.04 totali, ovvero $0.0252/transaction. Il batching riduce il costo medio soltanto alle ipotesi dichiarate su dimensione, utilizzo e commissioni.
  • Capacità rispetto al throughput realizzato. Una L2 ipotetica consente 60,000,000 gas ogni 2 seconds, quindi la sua capacità è 30,000,000 gas/second. Con 120,000 gas per operazione utente, il limite meccanico è 250 operations/second; con utilizzo effettivo del 72%, è 180 operations/second. Non misura finalità, decentralizzazione o throughput end-to-end; i limiti di dati, prova o sequencer possono intervenire prima.
  • Tre tempi di stato e un vincolo di prelievo. In una timeline didattica in stile OP, una transazione è confermata dal sequencer alle 12:00 UTC, il suo batch diventa safe dopo la pubblicazione L1 alle 12:07 e il blocco L1 che lo contiene diventa finalized alle 12:20. Se un prelievo dal bridge viene provato alle 14:00 e ha una maturazione illustrativa di 7-day, il primo rilascio possibile è alle 14:00 della settimana successiva, subordinatamente a gioco di disputa, pausa e condizioni L1. La finalità della transazione L2 alle 12:20 non coincide con il rilascio dal bridge.
  • Valore eseguibile dopo il bridge. Un utente deposita 1,000 USDC; una commissione di protocollo di 2 USDC lascia 998 USDC su L2, mentre il gas sulla chain di origine costa separatamente $7.50. Il token ricevuto ha un bid eseguibile di $0.995, impatto sul prezzo dello 0.20% e gas di uscita di $3, quindi il valore netto di uscita è 998 * 0.995 * (1 - 0.002) - 3 = $988.02398. Rispetto a $1,000, l’ammanco è $11.97602, ovvero 1.197602%; identità del token, diritto verso il bridge e liquidità contano oltre l’etichetta L2.

Rischi

  • Usare L1, L2, chain ID, deployment, fork o versione di protocollo errati.
  • Trattare un’etichetta commerciale L2 come classificazione standardizzata di sicurezza.
  • Confondere sidechain, validium, channel o registro custodial con un rollup.
  • Accettare RPC, explorer, bridge, token o indirizzo di contratto contraffatti.
  • Censura, equivocazione, indisponibilità o abuso dell’ordinamento privato da parte del sequencer.
  • Dati di batch e derivazione mancanti o ritardati.
  • Reticenza, guasto o collusione di un sistema DA esterno o comitato.
  • State commitment non validi o bug nel sistema di prove, gioco o verifier.
  • Fallimento di liveness di proposer, prover, challenger o relayer.
  • Congestione, censura, riorganizzazione o finalità ritardata della L1.
  • Confondere gli stati unsafe, safe, finalized, proven e withdrawable.
  • Percorsi di inclusione forzata o escape in pausa, costosi o inutilizzabili.
  • Aggiornamenti immediati dei proxy o finestre di uscita insufficienti.
  • Chiavi compromesse di amministratore, guardian o security council.
  • Guasto di escrow del bridge, mapping del token, decimali o rappresentazione.
  • Omettere dalle quotazioni costi di dati, esecuzione, operatore, bridge o destinazione.
  • Limiti di capacità o frequenza, congestione, slippage o carenza del token del gas.
  • Confondere compatibilità EVM con regole identiche di opcode, precompilati o sicurezza.
  • Messaggi cross-L2 che combinano ipotesi più deboli di finalità, bridge o dipendenza.
  • Confondere successo del wallet, TPS elevato o commissioni basse con sicurezza e finalità economica.

Errori comuni

  • Ogni rete definita Layer 2 eredita tutta la sicurezza di Ethereum.
  • Una conferma del sequencer equivale a finalità garantita da L1.
  • Prove di validità o fault proof risolvono automaticamente disponibilità dei dati e censura.
  • Il sistema di prove del rollup garantisce anche ogni token trasferito tramite bridge e ogni applicazione.
  • Commissioni inferiori o TPS maggiori dimostrano decentralizzazione, solvibilità e un’uscita eseguibile.

Argomenti correlati

Fonti

Navigazione

Cerca nella wiki...