Vai al contenuto principale

Ultimo aggiornamento della pagina: 26 febbraio 2026

Alberi di Verkle

Gli alberi di Verkle (una parola macedonia tra "Vector commitment" e "Merkle Trees") sono una struttura dati che può essere utilizzata per aggiornare i di Ethereum in modo che possano smettere di archiviare grandi quantità di dati di stato senza perdere la capacità di validare i blocchi.

Assenza di stato

Gli alberi di Verkle sono un passo fondamentale nel percorso verso i client di Ethereum senza stato (stateless). I client senza stato sono quelli che non devono archiviare l'intero database dello stato per validare i blocchi in arrivo. Invece di utilizzare la propria copia locale dello stato di Ethereum per verificare i blocchi, i client senza stato utilizzano un "witness" (testimone) dei dati di stato che arriva con il blocco. Un witness è una raccolta di singoli pezzi dei dati di stato necessari per eseguire un particolare insieme di transazioni e una prova crittografica che il witness fa realmente parte dei dati completi. Il witness viene utilizzato al posto del database dello stato. Affinché ciò funzioni, i witness devono essere molto piccoli, in modo da poter essere trasmessi in sicurezza attraverso la rete in tempo utile affinché i validatori li elaborino entro uno slot di 12 secondi. L'attuale struttura dei dati di stato non è adatta perché i witness sono troppo grandi. Gli alberi di Verkle risolvono questo problema consentendo witness di piccole dimensioni, rimuovendo una delle barriere principali ai client senza stato.

Cos'è un witness e perché ne abbiamo bisogno?

Verificare un blocco significa rieseguire le transazioni contenute nel blocco, applicare le modifiche al trie di stato di Ethereum e calcolare il nuovo hash radice. Un blocco verificato è quello il cui hash radice dello stato calcolato è uguale a quello fornito con il blocco (perché questo significa che il proponente del blocco ha realmente eseguito il calcolo che afferma di aver fatto). Negli attuali client di Ethereum, l'aggiornamento dello stato richiede l'accesso all'intero trie di stato, che è una grande struttura dati che deve essere archiviata localmente. Un witness contiene solo i frammenti dei dati di stato necessari per eseguire le transazioni nel blocco. Un validatore può quindi utilizzare solo quei frammenti per verificare che il proponente del blocco abbia eseguito le transazioni del blocco e aggiornato lo stato correttamente. Tuttavia, ciò significa che il witness deve essere trasferito tra i peer sulla rete di Ethereum abbastanza rapidamente da essere ricevuto ed elaborato da ciascun nodo in sicurezza entro uno slot di 12 secondi. Se il witness è troppo grande, alcuni nodi potrebbero impiegare troppo tempo per scaricarlo e stare al passo con la catena. Questa è una forza centralizzante perché significa che solo i nodi con connessioni Internet veloci possono partecipare alla validazione dei blocchi. Con gli alberi di Verkle non c'è bisogno di avere lo stato archiviato sul proprio disco rigido; tutto ciò di cui si ha bisogno per verificare un blocco è contenuto all'interno del blocco stesso. Sfortunatamente, i witness che possono essere prodotti dai trie di Merkle sono troppo grandi per supportare i client senza stato.

Perché gli alberi di Verkle consentono witness più piccoli?

La struttura di un Trie di Merkle rende le dimensioni dei witness molto grandi: troppo grandi per essere trasmesse in sicurezza tra i peer entro uno slot di 12 secondi. Questo perché il witness è un percorso che collega i dati, contenuti nelle foglie, all'hash radice. Per verificare i dati è necessario avere non solo tutti gli hash intermedi che collegano ogni foglia alla radice, ma anche tutti i nodi "fratelli" (sibling). Ogni nodo nella prova ha un fratello con cui viene sottoposto a hash per creare l'hash successivo lungo il trie. Si tratta di molti dati. Gli alberi di Verkle riducono le dimensioni del witness accorciando la distanza tra le foglie dell'albero e la sua radice ed eliminando anche la necessità di fornire nodi fratelli per verificare l'hash radice. Un'efficienza di spazio ancora maggiore sarà ottenuta utilizzando un potente schema di impegno polinomiale (polynomial commitment) invece dell'impegno vettoriale basato su hash. L'impegno polinomiale consente al witness di avere una dimensione fissa indipendentemente dal numero di foglie che dimostra.

Con lo schema di impegno polinomiale, i witness hanno dimensioni gestibili che possono essere facilmente trasferite sulla rete peer-to-peer. Ciò consente ai client di verificare le modifiche di stato in ogni blocco con una quantità minima di dati.

Qual è la struttura di un albero di Verkle?

Gli alberi di Verkle sono coppie (key,value) in cui le chiavi sono elementi da 32 byte composti da un tronco (stem) da 31 byte e un suffisso da un singolo byte. Queste chiavi sono organizzate in nodi di estensione e nodi interni. I nodi di estensione rappresentano un singolo tronco per 256 figli con suffissi diversi. Anche i nodi interni hanno 256 figli, ma possono essere altri nodi di estensione. La differenza principale tra la struttura dell'albero di Verkle e quella dell'albero di Merkle è che l'albero di Verkle è molto più piatto, il che significa che ci sono meno nodi intermedi che collegano una foglia alla radice e, di conseguenza, meno dati richiesti per generare una prova.

Diagramma di una struttura dati dell'albero di Verkle

Maggiori informazioni sulla struttura degli alberi di Verkle (opens in a new tab)

Progressi attuali

Le reti di test (testnet) degli alberi di Verkle sono già attive e funzionanti, ma ci sono ancora sostanziali aggiornamenti in sospeso per i client necessari per supportare gli alberi di Verkle. Puoi contribuire ad accelerare i progressi distribuendo contratti sulle reti di test o eseguendo i client della rete di test.

Guarda Guillaume Ballet spiegare la rete di test Condrieu Verkle (opens in a new tab) (nota che la rete di test Condrieu era basata sulla prova di lavoro ed è ora stata sostituita dalla rete di test Verkle Gen Devnet 6).

Letture consigliate

Ultimo aggiornamento della pagina: 26 febbraio 2026

Questo articolo è stato utile?