---
title: "Trilemma della blockchain"
description: "Il trilemma blockchain è un’euristica per confrontare scalabilità, decentralizzazione e sicurezza in presenza di carichi di lavoro e modelli di minaccia espliciti. Non è un teorema o una regola che i sistemi ne scelgano letteralmente solo due."
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.
# Trilemma della blockchain
> Solo a scopo educativo; non costituisce consulenza né raccomandazione d’investimento. Gli investimenti possono comportare perdite.
## Risposta diretta
Il trilemma della blockchain è un’euristica del design: aumentare la scalabilità, la decentralizzazione o la sicurezza nell’ambito di un modello di risorsa e fiducia fisso può esercitare pressione sulle altre dimensioni. Non è un teorema matematico di impossibilità, un punteggio additivo o una regola secondo cui ogni rete deve selezionare esattamente due proprietà.
Ciascun asse necessita di definizioni operative. La scalabilità include throughput sostenibile, latenza, tariffe e crescita dei dati o dello stato sotto il carico dichiarato. La decentralizzazione include convalida indipendente, ingresso e uscita senza autorizzazione e concentrazione tra stake o hash power, operatori, clienti, fornitori di cloud, geografia e governance. La sicurezza include sicurezza, vitalità, finalità, resistenza alla censura, disponibilità e ripristino dei dati secondo un modello avversario esplicito.
Lo sharding, i rollup, le prove di validità, i light client e il campionamento della disponibilità dei dati possono migliorare la frontiera fattibile cambiando chi esegue, scarica, archivia, dimostra o verifica i dati. Non cancellano i compromessi: spostano i costi delle risorse e introducono presupposti specifici del livello su sequenziatori, prover, sfidanti, ponti, chiavi di aggiornamento e disponibilità dei dati.
## Come funziona
1. Fissare la catena, la rete, la versione del protocollo, il livello e l'esatta rivendicazione architetturale. Identificare il consenso, l’esecuzione, la disponibilità dei dati, le componenti di regolamento e di governance invece di valutare solo un marchio.
2. Definire scalabilità, decentralizzazione e sicurezza con proxy misurabili, un carico di lavoro e una finestra di osservazione. Non aggiungere TPS, conteggio dei nodi e costo dell'attacco in un punteggio adimensionale.
3. Mappare chi propone, costruisce, ordina, convalida, archivia dati, dimostra, sfida, aggiorna, mette in pausa e consente l'uscita. Registrare i confini di autorizzazione, custodia e controllo di emergenza.
4. Misurare la decentralizzazione tra entità di stake o hash-power, nodi di convalida indipendenti, software client, hosting, geografia e governance. Includere hardware, larghezza di banda, spazio di archiviazione, tempo di sincronizzazione e barriere patrimoniali.
5. Misurare la sicurezza come sicurezza, vitalità, finalità, resistenza alla censura, disponibilità e recupero dei dati entro soglie contraddittorie dichiarate, ipotesi di correlazione e incentivi economici.
6. Misurare la scalabilità utilizzando throughput sostenuto e di coda, latenza di inclusione e finalità, tariffe sotto carico, byte, crescita dello stato, costi di sincronizzazione e verifica, oltre al comportamento durante la congestione o il guasto dei componenti.
7. Confrontare le architetture sullo stesso carico di lavoro e modello di minaccia, versione delle prove e dello stress sui guasti. Dichiarare quale costo o ipotesi di fiducia si è spostato tra gli strati piuttosto che affermare che il trilemma è stato risolto.
## Esempio
- Un'ipotetica catena completamente replicata che trasporta `2 MiB / 12 seconds` ha `7,200 blocks/day` e un ingresso grezzo di `2 * 7,200 = 14,400 MiB/day = 14.0625 GiB/day`. L'aumento del carico utile a `8 MiB` fornisce `57,600 MiB/day = 56.25 GiB/day`, esattamente `4x` prima dell'overhead del protocollo, degli indici, dello stato e della replica. La capacità aumenta, ma questa aritmetica non è un requisito completo del nodo.
- Supponiamo che gli operatori del palo controllino `34%, 22%, 18%, 16%, 10%`. Al di sotto della soglia di blocco dell'attività `>= 1/3` dichiarata, solo il primo operatore è idoneo. Sotto una soglia di controllo `>= 2/3` dichiarata, il prefisso più piccolo sono i primi tre: `34 + 22 + 18 = 74%`; i primi due totalizzano solo `56%`. I collegamenti alle entità reali e le soglie dei protocolli richiedono ancora la verifica.
- Se `10,000 transactions * 200 bytes = 2,000,000 bytes`, ma un rollup pubblica un `400,000-byte batch`, la media è `400,000 / 10,000 = 40 bytes/transaction` o `5x` compressione dei dati. Ciò non dice nulla di per sé sul rischio del sequenziatore, della prova, del bridge, della disponibilità dei dati o della chiave di aggiornamento.
- In un modello di campionamento illustrativo con `4,096 shares`, un avversario trattiene `25% = 1,024 shares`. Se vengono prese `30 independent uniform samples with replacement`, la probabilità di perdere tutte le azioni trattenute è `(3,072 / 4,096)^30 = 0.75^30 = 0.0001785821 = 0.01785821%`; il rilevamento modellato è `99.98214179%`. Indipendenza, uniformità e modello di ritenuta sono presupposti, non una garanzia di produzione.
## Rischi
- Trattare l'euristica del trilemma come un teorema universale dimostrato.
- Lasciare la scalabilità, la decentralizzazione o la sicurezza indefinite.
- Aggiunta di proxy diversi in un punteggio opaco o adimensionale.
- Scegliere il TPS di picco pubblicizzato invece del throughput sostenibile.
- Segnalazione delle medie nascondendo la latenza della coda e il comportamento del carico di errore.
- Utilizzo delle sole tariffe come misura di scalabilità senza carico di lavoro o sovvenzione.
- Trattare il nodo grezzo, il validatore o l'indirizzo conta come entità indipendenti.
- Ignorando la puntata delegata, l'hash power e il controllo comune dell'operatore.
- Ignorare la concentrazione di clienti, cloud, area geografica e governance.
- Escluse le barriere legate all'hardware, alla larghezza di banda, all'archiviazione, alla sincronizzazione e al capitale.
- Chiamare un sistema sicuro senza un avversario e una soglia dichiarati.
- Confondere sicurezza, vitalità, finalità, resistenza alla censura e ripresa.
- Ignorare la disponibilità dei dati, il recupero storico e la crescita dello stato.
- Esagerare le garanzie e le ipotesi del cliente leggero, della prova o del campionamento.
- Confrontando il throughput L1 e L2 come se le loro garanzie fossero identiche.
- Supponendo che un rollup erediti ogni proprietà di sicurezza del livello base.
- Ignorare le chiavi sequenziatore, prover, sfidante, bridge, admin e upgrade.
- Confronto di diverse versioni di protocollo, carichi di lavoro o finestre di osservazione.
- Dedurre la domanda di token o il valore dell'investimento dalla qualità dell'architettura.
- Dichiarare una soluzione permanente dopo che un'ottimizzazione ha spostato un collo di bottiglia.
## Errori comuni
- **Ogni blockchain deve scegliere esattamente due delle tre proprietà.** Il trilemma è un'euristica comparativa; i sistemi occupano frontiere di compromesso mutevoli sotto diversi presupposti.
- **Più validatori o nodi significano automaticamente maggiore decentralizzazione e sicurezza.** Il peso delle entità, il software, l'hosting, la geografia, la governance e la verifica indipendente sono importanti.
- **Un numero TPS elevato dimostra un decentramento scalabile.** Il carico di lavoro, l'hardware, la crescita dei dati, la latenza della coda, le tariffe e il comportamento in caso di fallimento determinano se la capacità è sostenibile.
- **L2, la modularità o lo sharding elimina il trilemma.** Questi progetti ridistribuiscono esecuzione, dati, prova e fiducia; ogni garanzia deve essere tracciata dall'inizio alla fine.
- **Le tre dimensioni sono punteggi scalari fissi o prevedono il valore del token.** Le misurazioni sono multidimensionali e con versioni, mentre l'economia dei token è una questione separata.
## Argomenti correlati
- [Blockchain](/it/crypto/blockchain/)
- [Livello 2](/it/crypto/layer2/)
- [blockchain modulare](/it/crypto/modular-blockchain/)
## Fonti autorevoli
- [Perché lo sharding è fantastico: demistificare le proprietà tecniche](https://vitalik.eth.limo/general/2021/04/07/sharding.html) - Vitalik Buterin (accesso: 2026-08-18)
- [Scalatura](https://ethereum.org/developers/docs/scaling/) - Ethereum.org (accesso: 2026-08-18)
- [Disponibilità dei dati](https://ethereum.org/developers/docs/data-availability/) - Ethereum.org (accesso: 2026-08-18)
- [Crea il tuo nodo Ethereum](https://ethereum.org/developers/docs/nodes-and-clients/run-a-node/) - Ethereum.org (accesso: 2026-08-18)
- [Diversità del cliente](https://ethereum.org/developers/docs/nodes-and-clients/client-diversity/) - Ethereum.org (accesso: 2026-08-18)
- [Attacco e difesa proof-of-stake di Ethereum](https://ethereum.org/developers/docs/consensus-mechanisms/pos/attack-and-defense/) - Ethereum.org (accesso: 2026-08-18)
- [Bitcoin: un sistema di cassa elettronico peer-to-peer](https://bitcoin.org/bitcoin.pdf) - Bitcoin.org (accesso: 2026-08-18)
- [Panoramica sulla tecnologia Blockchain](https://doi.org/10.6028/NIST.IR.8202) - NIST (accesso: 2026-08-18)
Source: https://wiki.fcontext.com/it/crypto/blockchain-trilemma/index.mdx