---
title: "Architettura blockchain modulare"
description: "Guida basata sulle dipendenze per separare esecuzione, sequenziamento, disponibilità dei dati, consenso, regolamento, prove, bridge, governance e archiviazione."
image: "https://wiki.fcontext.com/og.png"
---

> Documentation Index
> Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Architettura blockchain modulare

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

<a id="answer"></a>

## 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.

<a id="mechanism"></a>

## 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.

<a id="example"></a>

## 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.

<a id="risks"></a>

## 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à.

<a id="misconceptions"></a>

## 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.

<a id="related"></a>

## Argomenti correlati

- [Layer 2](/it/crypto/layer2/)
- [Disponibilità dei dati](/it/crypto/data-availability/)
- [Rollup](/it/crypto/rollup/)

<a id="sources"></a>

## Fonti

- [Scaling](https://ethereum.org/developers/docs/scaling/) - Ethereum.org (consultato: 2026-08-13)
- [Data availability](https://ethereum.org/developers/docs/data-availability/) - Ethereum.org (consultato: 2026-08-13)
- [EIP-4844: Shard Blob Transactions](https://eips.ethereum.org/EIPS/eip-4844) - Ethereum Improvement Proposals (consultato: 2026-08-13)
- [Optimistic Rollups](https://ethereum.org/developers/docs/scaling/optimistic-rollups/) - Ethereum.org (consultato: 2026-08-13)
- [Zero-knowledge rollups](https://ethereum.org/developers/docs/scaling/zk-rollups/) - Ethereum.org (consultato: 2026-08-13)
- [Rollup Node](https://specs.optimism.io/protocol/rollup-node.html) - OP Stack Specification (consultato: 2026-08-13)
- [Derivation](https://specs.optimism.io/protocol/derivation.html) - OP Stack Specification (consultato: 2026-08-13)
- [LazyLedger: A Distributed Data Availability Ledger With Client-Side Smart Contracts](https://arxiv.org/abs/1905.09274) - arXiv (consultato: 2026-08-13)

Source: https://wiki.fcontext.com/it/crypto/modular-blockchain/index.mdx