Riassunto

Implementazione Stateless: i validator non memorizzano lo stato completo del sistema, ma verificano solo i trasferimenti tramite prove crittografiche.

Implementazione Stateful: ogni validator memorizza e aggiorna lo stato completo del sistema (modello tradizionale della mainnet Ethereum).

Lo stato senza stato si basa su prove compatte (alberi Verkle, STARK) e su un livello di dati disponibili (DA) robusto.

Punti principali: costo hardware molto inferiore + maggiore decentralizzazione rispetto alla dimensione della prova e larghezza di banda maggiore.

Realtà 2025: il modello Stateless puro è ancora raro; la maggior parte delle architetture modulari utilizza un'esecuzione Stateless combinata con DA/stato (modello ibrido).

Esempi rappresentativi: Ethereum Verge (Verkle), Polygon AggLayer, rollups su Celestia, e ponti pigri

Perché è importante il modello di esecuzione?

Il modo in cui i nodi blockchain accedono e aggiornano lo stato non è più un semplice dettaglio di implementazione; diventa uno degli strumenti principali per scalare e ottenere sovranità nel design modulare. Con lo sviluppo di rollups, appchains e L2 sovrani, gli architetti devono decidere se i validatori devono portare con sé terabyte di dati storici o se possono verificare il passaggio di stato senza memorizzare lo stato.

La scelta tra Stateless e Stateful influisce direttamente sulla decentralizzazione, sulle barriere hardware, sui costi di disponibilità dei dati e sulla capacità di interoperabilità cross-chain.

Definizione di 2 Modelli

Esecuzione Stateful – Modello Tradizionale

Nel modello Stateful, ogni nodo completo mantiene una copia aggiornata completa di tutto lo stato del sistema (saldi degli account, memorizzazione dei contratti intelligenti, codici hash, ecc.). Quando un blocco viene proposto:

Il produttore di blocchi include transazioni e un nuovo root di stato.

Ogni validatore riesegue ogni transazione su una copia dello stato locale.

Se il root di stato risultante corrisponde al root nel blocco, il blocco viene accettato.

Ethereum, Solana, BNB Chain, e la maggior parte delle L1 monolitiche operano in questo modo. Il vantaggio è la semplicità e la conferma immediata dello stato: qualsiasi nodo può rispondere "qual è il saldo dell'indirizzo X?" senza dover interagire con nessun altro.

Il chiaro svantaggio nel 2025: i nodi Ethereum completi attualmente superano i 14 TB e continuano a crescere. Anche i nodi già ridotti necessitano di SSD ~1 TB e RAM 32+ GB, escludendo la possibilità di operare per la maggior parte degli utenti privati.

Esecuzione Stateless

Nel modello Stateless, i validatori non memorizzano lo stato del sistema localmente. Invece, ogni transazione (o lotto) è accompagnata da una prova crittografica che conferma che la transazione ha accesso alle parti di stato necessarie (ad esempio: ramo Merkle nell'albero Patricia o prova Verkle).

Il processo di verifica diventa:

Il produttore di blocchi allega prove + transazioni + nuovo root di stato.

I validatori controllano la validità delle prove rispetto al root di stato accettato più vicino.

I validatori rieseguono le transazioni solo con i dati di prova forniti.

Se il root di stato calcolato corrisponde a quanto dichiarato nel blocco, viene accettato.

Nessun nodo memorizza più di pochi blocchi di stato recenti. Il carico si sposta dallo storage alla larghezza di banda e alla verifica crittografica.

Considerazioni Tecniche Durante la Scalabilità

Requisiti Hardware e Decentralizzazione

Stateless ha chiaramente il sopravvento in questo aspetto. Un client Ethereum Stateless è in fase di test sulla rete testnet Verge e può funzionare senza problemi su mini-PC da 300 USD o persino su cluster Raspberry Pi 5 di alta gamma. Nel frattempo, eseguire un nodo Stateful su quasi tutte le L1/L2 richiede hardware aziendale.

Prova pratica: i nodi DA leggeri di Celestia hanno funzionato Stateless con <8 GB di RAM, mentre i nodi esecutivi di Ethereum si trovano a fronteggiare il problema dell'espansione dello stato.

Larghezza di banda e Dimensione

Il principale svantaggio dell'esecuzione Stateless pura è sempre il problema dell'espansione della prova. Con l'albero Merkle-Patricia classico di Ethereum, una singola transazione ERC-20 richiede spesso ~1–3 KB di dati di prova. Anche con 1.000 transazioni/secondo, questo si traduce in decine di megabit/secondo solo per la prova, superando la soglia pratica per un client Stateless.

Questo è il motivo per cui l'intero ecosistema sta correndo verso gli alberi Verkle e la ricorsione STARK: entrambi riducono la dimensione della prova di 20–30× e rendono il client Stateless praticabile su larga scala.

Garantire la Disponibilità dei Dati

Client Stateless è sicuro solo grazie al livello di disponibilità dei dati di base. Se il produttore di blocchi nasconde una parte della prova o delta di stato, il validatore Stateless non può rilevare frodi senza tutti i dati.

Questo è il motivo per cui l'esecuzione Stateless è quasi sempre combinata con un livello DA dedicato (Celestia, Ethereum DAS dopo Praga, Avail). Il livello DA rimane Stateful, il che significa che deve memorizzare e fornire dati, ma i validatori che eseguono mantengono la leggerezza e lo Stateless.

Contrattualità Sincrona & Asincrona

Rollups Stateful (ad esempio: Arbitrum One prima di Atlas, catena OP Stack) forniscono contrattualità sincrona: un token su questo rollup può essere utilizzato in un altro rollup nello stesso blocco se condivide il livello di pagamento comune.

Il design Stateless tende a favorire la contrattualità asincrona poiché la prova di stato richiede tempo per essere generata e diffusa. Progetti come Polygon AggLayer e il ponte SP1 di Succinct stanno affrontando questo problema con meccanismi di conferma anticipata e un ponte Stateless comune.

Implementazione Pratica

Ethereum – Alberi Verkle

L'imminente aggiornamento "Verge" di Ethereum sostituisce l'albero Patricia Merkle con alberi Verkle, riducendo la dimensione della prova da kilobyte a ~30–50 byte per slot di storage. EIP-6800 e EIP-7691 pongono le basi per un client Stateless completo entro il 2026–2027. Quando implementato, chiunque può eseguire un nodo di verifica completo su un laptop mentre verifica l'intera catena.

Celestia + Rollups – DA Stateless, Esecuzione Ibrida

Celestia è completamente Stateless per il campionamento della disponibilità dei dati. I rollup registrati su Celestia (ad esempio: Doma, Movement) attualmente eseguono nodi Stateful, ma progetti come Eclipse e Citrus (rollup SVM su Celestia) stanno reindirizzando i client SVM Stateless con prove STARK e DA Celestia.

Polygon AggLayer – Ponte Stateless Multiuso

AggLayer implementa un aggregatore di prove Stateless comune. Le catene separate possono mantenere stato interno, ma i messaggi cross-chain sono dimostrati tramite ZK Stateless basato sul root di stato comune. Questo offre la sicurezza del livello di pagamento comune senza obbligare ogni validatore a memorizzare lo stato di ogni catena.

Metodi Ibridi – Soluzioni Pratiche

L'esecuzione puramente Stateless è ancora rara in produzione. La maggior parte dei gruppi adotta uno dei tre modelli ibridi:

Esecuzione Stateful + verifica Stateless (ad esempio: il prover boojum di zkSync Era genera prove che qualsiasi nodo Stateless può verificare)

Client Stateless + DA/stato di base (modello Ethereum + Celestia)

Livello di ponte Stateless su catena Stateful (AggLayer, firma sulla catena di Near)

Questi modelli ibridi catturano gran parte dei vantaggi della decentralizzazione mentre controllano i costi della prova.

Implementazione nel Futuro

Entro il 2027, l'assunzione predefinita nell'architettura modulare potrebbe essere "esecuzione Stateless, disponibilità dei dati e pagamenti minimi Stateful". Progressi negli alberi Verkle, ricorsione STARK e distribuzione di prove decentralizzate (ad esempio: Rete Portal, client leggeri Helios) stanno rimuovendo gli ultimi grandi ostacoli.

Per i costruttori che scelgono il modello di esecuzione oggi:

Se la massima priorità è la decentralizzazione e la sovranità a lungo termine → scegliere Stateless fin dall'inizio (in combinazione con Celestia/Avail/Ethereum DAS)

Se è necessaria la contrattualità sincrona e si accettano requisiti hardware superiori → esecuzione Stateful con forti riduzioni dei dati e un percorso di transizione verso Stateless

Il modello Stateless non è una soluzione universale, ma sta diventando un prerequisito per qualsiasi catena desideri mantenere la neutralità e l'accessibilità globale man mano che lo stato cresce all'infinito.

Il futuro della blockchain scalabile e sovrana è un luogo in cui nessuna entità, per quanto ben finanziata, deve memorizzare l'intera storia della catena per partecipare al consenso. Quel futuro è in fase di costruzione.