Vai al contenuto
Financial Context Wiki

Consenso di Nakamoto: validità, chainwork, conferme e riorganizzazioni

Il consenso di Nakamoto combina regole di validità applicate indipendentemente, produzione permissionless di blocchi proof of work, propagazione e selezione della catena valida con il maggior lavoro cumulativo. Occorre analizzare separatamente viste locali, chainwork, conferme, riorganizzazioni, ipotesi di prefisso comune, incentivi e attacchi di rete.

Aggiornato

Solo a scopo educativo; non costituisce consulenza né raccomandazione d’investimento. Gli investimenti possono comportare perdite.

Risposta diretta

Il consenso di Nakamoto è il processo di tipo Bitcoin in cui i nodi applicano indipendentemente le regole di validità, i produttori proof of work estendono blocchi senza un elenco permissioned di membri, i blocchi si propagano su una rete peer-to-peer e ogni nodo sceglie il ramo valido con il maggior proof of work cumulativo. Ordina transazioni valide secondo la vista osservata dal nodo; non rende valida una transazione non valida, non stabilisce fatti esterni al registro e non crea finalità deterministica immediata.

La validità precede la selezione della catena. Un ramo con header, proof of work, transazione, script, output già speso, importo coinbase o limite di blocco non valido viene rifiutato, qualunque altezza o lavoro dichiari. Fra i rami che rispettano le regole del nodo e hanno dati disponibili, il chainwork cumulativo, non il solo numero di blocchi, determina la catena attiva. “Catena più lunga” è quindi un’abbreviazione informale per la catena valida che rappresenta il massimo lavoro proof of work.

La punta attiva è provvisoria. Blocchi validi concorrenti possono dare temporaneamente viste locali diverse a nodi onesti ben connessi; ulteriore lavoro normalmente risolve il fork e un nodo può scollegare un ramo e collegarne un altro durante una riorganizzazione. Le conferme di una transazione ne misurano la profondità nella catena attiva corrente dell’osservatore. Maggiore profondità può ridurre la probabilità di recupero in un modello specificato di hashrate e rete, ma nessun numero di conferme è universalmente finale.

Il termine descrive più dell’hashing. L’argomento di sicurezza dipende anche da validità di blocchi e transazioni, propagazione peer-to-peer, adozione onesta della catena valida di maggior lavoro, sufficiente potenza mineraria effettiva onesta, comportamento economico e utenti che osservano indipendentemente rete e software previsti. Prefisso comune, crescita e qualità della catena sono proprietà formali dimostrate solo entro modelli dichiarati, non fatti incondizionati di ogni catena proof of work operativa.

Come analizzare il consenso di Nakamoto

  1. Fissare identità e ambito d’osservazione. Registra chain, network, genesis hash, client version, regole di consenso, checkpoint o impostazioni assume-valid, osservatore, peer e orario. Acquisisci bestblockhash, height e chainwork; due nodi possono riportare onestamente punte diverse mentre i messaggi si propagano.
  2. Validare prima di confrontare il lavoro. Verifica collegamento degli header, vincoli temporali, target decodificato, proof of work, commitment Merkle e witness, transazioni, script, spese UTXO, coinbase e limiti di risorse. Un ramo invalid non diventa idoneo dichiarando più altezza o lavoro.
  3. Ricostruire l’albero osservato. Collega ogni candidato tramite hash del blocco precedente a un antenato noto e distingue blocchi completi da soli header. Riconcilia gli stati active, valid-fork, valid-headers, headers-only e invalid tramite interfacce come getchaintips; non definire ogni punta visibile una catena concorrente valida.
  4. Ricalcolare il lavoro cumulativo. Decodifica il target nBits di ogni header e calcola il lavoro rappresentato con le regole intere dell’implementazione, concettualmente work = floor(2^256 / (target + 1)). Somma lungo gli antenati e confronta rami validi dall’antenato comune; altezza, hashrate stimato ed etichette dei pool non sostituiscono chainwork.
  5. Tracciare selezione e riorganizzazione. Riproduci la scelta del candidato di maggior lavoro, l’ordine locale in parità e lo stato d’arrivo. Se appare un ramo valido migliore, individua il fork, scollega il vecchio suffisso, collega il nuovo, aggiorna l’UTXO set e riconcilia le transazioni con il mempool e i registri applicativi.
  6. Definire una politica di conferma basata sul rischio. Calcola confirmations = tip_height - block_height + 1 solo per un blocco nella catena attiva corrente. Dichiara valore a rischio, reversibilità, quota dell’attaccante, propagazione, esposizione eclipse, tasso stale osservato, profondità e risposta; sei è una convenzione, non una soglia di finalità del protocollo.
  7. Sottoporre a stress l’intero argomento. Prova partizioni, latenza, blocchi trattenuti, selfish mining, attacchi eclipse, concentrazione di pool e hardware, variazioni improvvise di hashrate, incentivi di commissioni e sussidio, divergenza dei client, riorganizzazioni profonde e recupero. Collega le conclusioni a prefisso comune, crescita, qualità, persistenza e liveness solo sotto le ipotesi del modello citato.

Il risultato è una spiegazione riproducibile e specifica per l’osservatore di quale storia valida un nodo scelga ora e perché. Le regole definiscono l’ammissibilità; proof of work rende costose storie alternative; la propagazione espone il lavoro; fork choice seleziona la storia corrente; e la politica di conferma decide quando l’applicazione agisce. Riassumere questi livelli come “approvazione della rete” nasconde le condizioni che possono fallire.

Esempi svolti

1. Il lavoro non valido non vince

Supponi che il ramo A riporti valid_A = false e chainwork_A = 1,200 units, mentre B abbia valid_B = true e chainwork_B = 1,000 units. Il nodo rifiuta A e sceglie B. Il lavoro si confronta solo fra candidati ammissibili; proof of work non autorizza coinbase eccessiva, firma non valida o doppia spesa.

Se un osservatore ha solo gli header di A e un altro i blocchi completi, gli stati possono differire fino al termine di download e validazione. Un ramo con header validi non prova che tutte le transazioni e transizioni abbiano superato la validazione completa.

2. L’altezza non è lavoro cumulativo

In un esempio semplificato con target variabile, C aggiunge sei blocchi da 100 unità, cioè 6 * 100 = 600 units. D aggiunge cinque blocchi da 130, cioè 5 * 130 = 650 units. Se entrambi sono validi e partono dallo stesso lavoro, D è il ramo di maggior lavoro pur avendo un blocco in meno.

Se due punte valide hanno esattamente 650 units, la parità non obbliga tutti i nodi a vedere subito la stessa punta. Ordine d’arrivo e stato locale possono differire finché un altro blocco valido rende un ramo più pesante. Una vista transitoria in parità non è finalità globale deterministica.

3. Le conferme possono essere rimosse

Una transazione inclusa all’altezza 100 con punta attiva 105 ha tip_height - block_height + 1 = 105 - 100 + 1 = 6 confirmations. Supponi che un ramo valido alternativo si separi dopo 99 e diventi quello di maggior lavoro all’altezza 106 senza la transazione. La riorganizzazione scollega i vecchi blocchi 100 through 105; la transazione perde le sei conferme attive e può tornare nel mempool, entrare in conflitto o restare assente.

Le applicazioni devono riconciliare hash e ascendenza, non memorizzare solo il numero sei. Accredito su exchange, beni consegnati, messaggi bridge e regolamento di derivati possono essere economicamente irreversibili anche quando la storia della catena fonte non lo è.

4. La probabilità di recupero dipende dal modello

Nel modello illustrativo del whitepaper Bitcoin, sia la quota dell’attaccante q = 0.10, quella onesta p = 0.90 e il vantaggio onesto z = 6. L’approssimazione di Poisson dà lambda = z * (q / p) = 0.6666667 e P(catch up) = 0.0002428027 = 0.02428027%. Con q = 0.30 alla stessa profondità sale a P(catch up) = 0.1321111687 = 13.21111687%.

Questi numeri non sono garanzie attuali di Bitcoin. Il calcolo assume tentativi hash indipendenti e stabili e le condizioni di gara del modello; omette isolamento eclipse, vantaggio di propagazione, strategie selfish, reazioni di prezzo e noleggio, bug e risposta applicativa. Una politica deve dichiarare il modello e provare condizioni peggiori, non citare solo sei conferme.

Rischi ed errori di revisione

Errori di protocollo e misurazione

  • Confrontare lavoro prima di validare indipendentemente header, corpo e ascendenza.
  • Chiamare vincitore il ramo più alto o visto per primo senza calcolare chainwork cumulativo.
  • Usare numero di blocchi, hashrate nominale, quota pool o etichetta explorer come proxy di chainwork.
  • Mescolare mainnet, testnet, signet, fork, versioni client, checkpoint o identità genesis.
  • Trattare dati solo-header, indisponibili o ottimistici come storia pienamente validata.
  • Ignorare decodifica del target, aritmetica intera, collegamento dell’hash precedente o antenato comune.
  • Leggere un RPC o explorer come vista globale senza contesto di hash, altezza, tempo e peer.

Errori di rete, incentivi e controllo

  • Assumere propagazione istantanea o identico ordine d’arrivo su tutti i nodi.
  • Trattare la parità di lavoro come uno stato globale unico, non viste locali temporanee.
  • Ignorare blocchi stale, latenza, ritenzione, selfish mining e vantaggio di propagazione.
  • Deducere miner indipendenti dai nomi dei pool o proprietà fisica dalle quote dei pool.
  • Ignorare concentrazione di pool, firmware, produttori, hosting, energia, geografia e rete.
  • Trattare le ricompense come prova che l’estensione onesta è sempre ottimale per tutti.
  • Omettere esposizione a eclipse, partizioni, Sybil, peer poisoning, DoS e manipolazione temporale.

Errori di regolamento e sicurezza

  • Chiamare una conferma finalità del protocollo o promettere che sei non possono essere rimosse.
  • Applicare una stessa conta a ogni valore, controparte, reversibilità e minaccia.
  • Trasformare l’esempio probabilistico del whitepaper in probabilità di attacco misurata oggi.
  • Dire che la maggioranza hash falsifica firme, prende monete arbitrarie o valida inflazione.
  • Dire che una minoranza hash non può deviare con profitto né causare riorganizzazione o censura.
  • Equiparare la punta di maggior lavoro a fatti esterni, proprietà legale o regolamento applicativo.

Errori comuni

  • La catena più lunga ha sempre più blocchi. I nodi Bitcoin scelgono la catena valida con maggior lavoro cumulativo; l’altezza può essere un proxy inadeguato se i target differiscono.
  • I miner decidono quali regole sono valide. Propongono blocchi; ogni full node applica indipendentemente le proprie regole configurate.
  • Sei conferme creano finalità assoluta. Sei è una convenzione; il rischio dipende da modello, profondità, avversario, propagazione e integrità dell’osservazione.
  • Un attaccante al 51% può spendere monete altrui. L’hash può sostenere riorganizzazione, doppia spesa e censura, ma non fornisce la firma privata altrui né fa accettare inflazione non valida a nodi invariati.
  • Hashrate totale elevato prova decentralizzazione e sicurezza. Contano anche controllo effettivo, visibilità, accesso hardware, coordinamento dei pool, diversità client, incentivi e durata.

Argomenti correlati

Fonti

Navigazione

Cerca nella wiki...