Vai al contenuto
Financial Context Wiki

Architettura blockchain modulare

Guida basata sulle dipendenze per separare esecuzione, sequenziamento, disponibilità dei dati, consenso, regolamento, prove, bridge, governance e archiviazione.

Aggiornato

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

Risposta diretta

L’architettura blockchain modulare è un metodo per analizzare come un sistema assegna le responsabilità, non una categoria di prodotto standardizzata. Esecuzione, ordinamento delle transazioni, state commitment, prove o dispute, pubblicazione dei dati e relativo consenso, regolamento, bridge, governance e archiviazione di lungo periodo possono essere riuniti in un protocollo, suddivisi tra più sistemi o duplicati tra provider. Un livello può svolgere più compiti e un compito può dipendere da più livelli.

La domanda utile non è quindi se un progetto sia «modulare», ma quale componente convalidi ciascun oggetto, chi lo controlli, che cosa accada quando si arresta e come gli utenti possano recuperare autonomamente stato o asset. Una ricevuta del sequencer non dimostra disponibilità dei dati né finalità; un validity proof non fornisce i dati; un commitment sulla chain di regolamento non dimostra la reperibilità permanente; e il regolamento condiviso non crea componibilità sincrona tra rollup.

Come funziona

  1. Identificare il sistema distribuito: chain ID di esecuzione e regolamento, versione del protocollo, macchina virtuale, contratti, indirizzi di bridge e asset, modalità di disponibilità dei dati, operatori, amministratori e blocco o istante osservato. La tassonomia commerciale non sostituisce la configurazione distribuita.
  2. Costruire una matrice delle responsabilità. Separare ingresso e sequenziamento delle transazioni, esecuzione deterministica, state commitment e prova o fault dispute, pubblicazione DA e relativo consenso, accettazione e finalità del regolamento, bridge e messaggistica cross-domain, aggiornamenti e pause, e conservazione storica. Registrare le sovrapposizioni senza forzare una funzione in un solo livello.
  3. Tracciare una transazione e il relativo batch end-to-end: input firmato, ricevuta locale o del sequencer, esecuzione ordinata, batch codificato e compresso, pubblicazione tramite calldata, blob o DA esterna, state claim e prova o disputa, finalità del regolamento, quindi esecuzione del messaggio o del prelievo. Conservare hash, versioni, ricevute e orologi a ogni confine.
  4. Identificare ogni oggetto verificato e ipotesi di fiducia. Distinguere il data commitment dai byte, la disponibilità durante la finestra del protocollo dalla successiva reperibilità, la validità dell’esecuzione dalla finalità del consenso e la contabilità del bridge dalla liquidità dell’asset. Indicare chi può riprodurre, provare, contestare, censurare, aggiornare, sospendere o trattenere ciascun oggetto.
  5. Ricostruire il registro di capacità e costi. Misurare byte grezzi e compressi, occupazione del batch, prezzo DA, costi di prova e regolamento, commissioni di esecuzione e operatore, gas del bridge e commissioni di liquidità. L’allocazione media del batch non equivale all’addebito effettivo all’utente o al costo marginale di un’altra transazione.
  6. Esercitare i guasti anziché leggere solo il throughput ordinario. Arrestare sequencer, batch poster, prover, challenger, servizio DA, RPC di regolamento e relayer del bridge; testare forced inclusion, derivazione indipendente, ricostruzione dei dati, prova o contestazione, retry, exit e recupero d’archivio sotto congestione e vincoli di aggiornamento.
  7. Riconciliare con evidenze canoniche. Collegare ricevute di esecuzione e state root a batch commitment, inclusione DA, stato della prova o del game, finalità del regolamento, messaggi del bridge e saldi finali degli asset. Ripetere la revisione delle dipendenze dopo una riorganizzazione, una modifica dei parametri, un aggiornamento del contratto o una migrazione DA.

Esempi svolti

  • Costo e compressione di un batch. Un batch contiene 5,000 transazioni, 2,400 KB di input grezzi e 300 KB dopo la compressione. Il rapporto di compressione è 2,400 / 300 = 8.0x e i byte diminuiscono del 87.5%. Se DA costa 0.020 ETH e prova condivisa più regolamento costano 0.005 ETH, il costo medio condiviso è (0.020 + 0.005) / 5,000 = 0.000005 ETH/tx. Aggiungendo 0.000020 ETH/tx per esecuzione e operatore si ottiene 0.000025 ETH/tx. È un’allocazione, non un addebito garantito.
  • Limite del modello di campionamento. In un modello didattico, un avversario trattiene il 25% delle share e un client effettua 20 campioni uniformi indipendenti con reinserimento. La probabilità di non rilevare alcuna share trattenuta è 0.75^20 = 0.003171211939 = 0.3171211939%; la probabilità di rilevamento è 99.6828788061%. Peer correlati, serving adattivo, erasure coding e la regola di campionamento reale possono invalidare questo modello semplice.
  • Sicurezza e disponibilità di un committee. Un committee DA 5-of-7 può formare una nuova threshold attestation con al massimo 2 membri indisponibili; con 3 assenti ne restano solo 4 < 5. In base a una regola didattica basata unicamente sulle firme, il controllo di 5 firmatari autorizzati soddisfa la soglia. Un certificato non dimostra comunque che esistano cinque copie durevoli, che un utente possa recuperare ora i byte o che esecuzione e regolamento siano validi.
  • Più orologi e fast exit. Una soft confirmation didattica arriva in 2 seconds, il batch viene pubblicato dopo 8 minutes e la finalità del regolamento arriva 13 minutes dopo: il tempo esatto è 21 minutes 2 seconds. Se un prelievo ottimistico aggiunge ipotetici 7 days, il totale è 10,101 minutes 2 seconds. Un fast bridge che applica 0.15% su 10,000 USDC trattiene 15 USDC e consegna 9,985 USDC; la velocità aggiunge ipotesi su bridge, liquidity provider e riorganizzazione, anziché abbreviare l’orologio del protocollo.

Rischi

  • Identificazione errata delle responsabilità o dei confini reali.
  • Censura, riordino o indisponibilità del sequencer.
  • Forced inclusion indisponibile, permissioned o troppo lenta.
  • Indisponibilità del batch poster o dello state proposer.
  • Guasto del prover centralizzato o accumulo di prove.
  • Assenza di un fault challenger attivo, idoneo o finanziato.
  • Guasto di clock, bond, oracle o verifier del fault game.
  • Errore del validity circuit, proving system o verification key.
  • Data withholding durante la finestra di disponibilità richiesta.
  • Campionamento correlato, attacco eclipse o errore della vista di rete.
  • Collusione di soglia o compromissione delle chiavi del committee DA.
  • Dati disponibili al protocollo privi di archivi indipendenti durevoli.
  • Riorganizzazione del regolamento o classificazione errata della finalità.
  • Guasto di bridge, messenger, protezione dal replay o esecuzione di destinazione.
  • Insolvenza, carenza di inventario o prezzo sfavorevole del fast bridge.
  • Compromissione di amministratore, multisig o security council.
  • Aggiornamento immediato, versione incompatibile o ritardo di exit insufficiente.
  • Aumento delle commissioni DA, congestione dei blob, batch più piccoli o fine del sussidio.
  • Mancata corrispondenza tra stato, dati, prova, contratto o versione del client.
  • Ordinamento cross-domain asincrono, completamento parziale o errore di componibilità.

Falsi miti comuni

  • Un’architettura modulare è automaticamente più decentralizzata di una monolitica.
  • Un validity proof sostituisce disponibilità e reperibilità storica dei dati.
  • Il regolamento su Ethereum trasferisce ogni proprietà di sicurezza di Ethereum a ogni componente.
  • Un messaggio di successo del sequencer significa regolamento finale e prelievo eseguibile.
  • TPS più elevato, DA condivisa o regolamento condiviso garantiscono costi inferiori e componibilità sincrona.

Argomenti correlati

Fonti

Navigazione

Cerca nella wiki...