Solo a scopo didattico; non è consulenza finanziaria. Investire può causare perdite.
Risposta diretta
Un albero di Merkle trasforma ogni dato in una foglia tramite hash, combina ripetutamente gli hash vicini e produce una radice di Merkle. La radice impegna in modo compatto le foglie e le regole di ordine e hashing usate.
Una prova di Merkle contiene l’hash fratello di ogni livello per una foglia. Il verificatore ricalcola il percorso fino alla radice e accetta l’inclusione solo se coincide con una radice attendibile. Non servono le altre foglie.
L’impegno riguarda la rappresentazione dei dati, non la loro verità. Una radice corrispondente non prova che la fonte sia corretta, che i dati siano disponibili o che contratto, bridge, oracolo e mercato siano sicuri. Il verificatore deve ottenere radice e foglia tramite un protocollo autenticato e conoscere separazione di dominio, ordine e regole per foglie dispari.
Gli alberi di Merkle hanno usi diversi. Bitcoin inserisce la radice delle transazioni nell’header di ogni blocco; Ethereum usa un Trie di Merkle-Patricia modificato per lo stato e altre strutture autenticate. Codifica, formato delle prove, aggiornamenti e ipotesi di sicurezza non coincidono.
Come funziona
Il sistema definisce una codifica deterministica delle foglie e una funzione hash. Poi calcola l’hash di ogni foglia, di coppie di figli per creare i genitori e ripete fino alla radice. La prova deve indicare posizione o direzione se il protocollo non consente di dedurla.
In un albero binario bilanciato, una prova per una foglia tra 1024 richiede circa 10 hash fratelli, perché ogni livello raddoppia l’intervallo coperto. La dimensione dipende da forma, lunghezza dell’hash, regola dei duplicati e prove multiple o compresse.
La relazione centrale è parent = Hash(left || right) e root = fold(parent, leaves). È una notazione schematica: il protocollo può usare prefissi, altra arità o chiavi in un trie. La prova mostra coerenza con la costruzione, ma non autentica una radice non fidata indipendentemente.
In una blockchain la radice è impegnata da header, record di stato o contratto. Un client leggero richiede foglia e percorso, ricalcola la radice e applica regole di conferma, finalità, freschezza e disponibilità. La verifica degli hash non sostituisce tali regole.
Esempio
Supponiamo un blocco con 1024 transazioni in un albero binario. Una transazione può includere circa 10 hash fratelli invece delle altre 1023 transazioni. Servono comunque l’header e le regole di codifica e posizione.
Se la prova fallisce, controlla byte della foglia, ordine dei byte, padding, origine della radice e stato del blocco prima di concludere che la transazione manchi. Una prova valida per una radice non finalizzata o vecchia può non rappresentare lo stato canonico.
Per un saldo o premio mostrato, separa validità della prova e risultato economico. Commissioni, prezzi, slippage, permessi del contratto, limiti di prelievo o fonte indisponibile possono modificare l’importo. La prova verifica appartenenza, non un importo riscattabile.
Rischi
I rischi tecnici includono codifiche ambigue, uso errato dell’hash, debolezze di seconda preimmagine o collisione, ordine errato dei fratelli e radici non affidabili o obsolete. La separazione di dominio funziona solo se applicata coerentemente.
I rischi operativi sono esterni al calcolo. Bridge, oracolo, sequencer, exchange o amministratore possono pubblicare, ritardare, censurare o sostituire la radice; un guasto di disponibilità può impedire di ottenere foglia o prova; una riorganizzazione può invalidare una prova legata a un blocco precedente.
Prima di usare una prova, identifica chi autentica la radice, come si verificano freschezza e finalità, come si gestiscono foglie mancanti o dispari e se gli utenti possono recuperare i dati. Limita autorizzazioni ed esposizione quando la perdita non è delimitabile.
Idee sbagliate comuni
Mito 1: Una radice corrispondente prova dati veri
Prova solo che la foglia fornita è coerente con la radice impegnata secondo la costruzione. Un oracolo che impegna un valore errato farà verificare quel valore errato.
Mito 2: Una prova di Merkle rende l’intero sistema senza fiducia
Il verificatore si fida ancora di hash, codifica, percorso di autenticazione e sistema che fornisce i dati. Consenso, finalità, disponibilità e governance restano questioni separate.
Mito 3: Ogni blockchain usa lo stesso albero di Merkle
Alberi di transazioni Bitcoin, Trie di Merkle-Patricia Ethereum e alberi applicativi hanno layout e regole differenti. Un formato non si trasferisce automaticamente.
Mito 4: Una prova breve garantisce una transazione economica e sicura
La dimensione riduce il trasferimento, ma gas di verifica, letture, congestione, bug e rischi di prelievo o liquidazione possono prevalere.
Argomenti correlati
Fonti
- Blockchain Technology Overview - NIST (consultato: 2026-08-21)
- Merkle Trees - Bitcoin.org (consultato: 2026-08-21)
- Merkle Patricia Trie - Ethereum Foundation (consultato: 2026-08-21)