Vai al contenuto
Financial Context Wiki

Trilemma della blockchain

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.

Aggiornato

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

Fonti autorevoli

Navigazione

Cerca nella wiki...