Vai al contenuto
Financial Context Wiki

Blockchain: stato, consenso e verifica

Una blockchain è un protocollo versionato per ordinare e convalidare le transizioni di stato tra repliche. I collegamenti hash sono solo un componente; la fiducia dipende dal consenso, dalle autorizzazioni, dalla verifica indipendente, dalla disponibilità dei dati, dalla governance e dal ripristino.

Aggiornato

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

Risposta diretta

Una blockchain è un protocollo versionato che consente a più repliche di ordinare le transazioni proposte, convalidare le transizioni di stato e convergere su una cronologia accettata secondo il consenso dichiarato e le ipotesi di rete. Un blocco è un contenitore definito dal protocollo con transazioni o altri dati, più impegni verso la cronologia precedente e lo stato risultante; la catena, o cronologia diretta, collega i contenitori accettati tramite impegni crittografici.

I collegamenti hash rendono rilevabili le modifiche storiche non autorizzate, ma da soli non rendono un sistema decentralizzato, immutabile o corretto. Tali proprietà dipendono da chi può proporre e convalidare, dalla possibilità per gli utenti di verificare in modo indipendente, dalle regole di scelta del fork e di finalità, dalla disponibilità dei dati, dalla diversità dei client, dalla governance, dal controllo delle chiavi, dagli incentivi e dalle procedure di recupero.

Le blockchain possono utilizzare modelli di stato UTXO, basati su account, oggetti o specifici dell’applicazione; proof of work, proof of stake, voto con tolleranza ai guasti bizantini o consenso permissioned; e finalità probabilistica o basata su checkpoint. La parola “blockchain” designa quindi un’ampia famiglia di architetture, non una garanzia di sicurezza né un singolo prodotto di database.

1
Creare

Un portafoglio costruisce una transazione con destinazione, valore, parametri di commissione e dati di protezione dalla riproduzione come input spesi o un nonce.

Come funziona

  1. Identifica con precisione la catena, la rete, la versione del protocollo, il modello di autorizzazione, il modello di stato e l’affermazione da verificare. Registra la genesi o il checkpoint attendibile, l’identificatore della catena, l’implementazione del client e l’autorità di aggiornamento.
  2. Costruisci i byte esatti della transazione e dell’autorizzazione. Prima della trasmissione, controlla la proprietà del mittente o degli input, il nonce o i riferimenti agli output non spesi, l’importo, la destinazione, i limiti delle commissioni, la finestra di validità, le firme e le chiamate dell’applicazione.
  3. Propagare la transazione attraverso peer o gateway. Distinguere l’ammissione locale e la politica di mempool dalla validità del consenso; un nodo può rifiutare, ritardare, sostituire o non ricevere mai una transazione che potrebbe essere valida in un blocco.
  4. Un proponente seleziona e ordina le transazioni in un blocco candidato e si impegna a campi del protocollo come genitore, transazione, ricevuta, stato o radici dei dati. L’ordinazione può influire sui risultati di esecuzione, sulle commissioni, sulle liquidazioni e sul valore estraibile.
  5. I nodi indipendenti deserializzano il blocco, verificano l’autorizzazione del consenso e ogni transizione di stato richiesta, ricalcolano gli impegni e rifiutano input non validi o non disponibili secondo le loro regole. Le firme del produttore o la prova del lavoro non annullano la convalida non riuscita.
  6. La scelta del fork seleziona tra storie valide concorrenti, mentre conferme, voti o checkpoint modificano il rischio di riorganizzazione nel tempo. “Incluso”, “sicuro” e “finalizzato” sono stati diversi e rimangono specifici del protocollo.
  7. Riconcilia lo stato del protocollo con l’intento dell’applicazione, la custodia, la contabilità del bridge o della piattaforma e i requisiti di archiviazione. Conserva i byte della transazione, l’hash del blocco, l’altezza o lo slot, la ricevuta, i log, la prova dello stato, lo stato di finalità, la versione del client e le evidenze ottenute da un endpoint indipendente.

Esempi realizzati

  • Riconciliazione dello stato dell’account. Un account inizia con 10 ETH e nonce 41. Una transazione valida con nonce 41 trasferisce 2 ETH e consuma 0.00042 ETH in commissioni; lo stato successivo semplificato è quindi 10 - 2 - 0.00042 = 7.99958 ETH, il destinatario riceve 2 ETH e il nonce del mittente diventa 42. Una firma valida, da sola, non dimostrerebbe né il saldo precedente né la corretta esecuzione.
  • Conservazione UTXO. Una transazione spende input di 0.80 BTC e 0.35 BTC, per un totale di 1.15 BTC. Uscite di 1.00 BTC e 0.1496 BTC totale 1.1496 BTC; la differenza è di 1.15 - 1.1496 = 0.0004 BTC in commissioni. I nodi devono inoltre verificare che ogni output di riferimento esista, non sia speso e soddisfi le condizioni di spesa.
  • Dimensione della prova dell’impegno. In un albero Merkle binario bilanciato illustrativo con 8 leaves, un percorso di inclusione richiede log2(8) = 3 sibling hashes. Con gli hash 256-bit = 32-byte, questi fratelli occupano 3 * 32 = 96 bytes prima degli indici e della codifica. La prova lega una foglia ad una radice dichiarata; non dimostra che i dati di origine siano veritieri o attualmente disponibili.
  • Il peso non è il conteggio dei nodi. In un protocollo di voto illustrativo la cui regola di finalità dichiarata è >= 2/3 di peso, i validatori mantengono 30%, 25%, 20%, 15%, 10%. I primi tre totalizzano 30 + 25 + 20 = 75% e superano la regola, mentre i primi due totalizzano 55% e non lo fanno. Le soglie reali, la correlazione, l’equivoco e le regole di recupero devono provenire dal protocollo indicato.

Rischi

  • Utilizzo di catena, rete, fork, checkpoint o identificatore di catena errati.
  • Trattare un marchio come un protocollo completo o una specifica del modello di fiducia.
  • Supponendo che il solo collegamento hash impedisca le riscritture autorizzate o approvate dal consenso.
  • Confondere la proposta di blocco di un produttore con la convalida del nodo indipendente.
  • Trattare l’accettazione, la trasmissione, l’inclusione, il successo dell’esecuzione e la finalità di Mempool come un unico stato.
  • Firma di byte, domini o destinazioni diverse da quanto visualizzato nell’interfaccia.
  • Riutilizzare i nonce, spendere UTXO obsoleti o calcolare erroneamente commissioni e modifiche.
  • Affidarsi ai simboli dei token, alle etichette, agli eventi o alle interpretazioni dell’esploratore invece degli identificatori e dello stato del protocollo.
  • Trattare gli input firmati di Oracle, Bridge o documenti come prova che le affermazioni off-chain sono vere.
  • Ignorare l’ordine delle transazioni, la censura, il front-running e la concentrazione del proponente o del costruttore.
  • Conteggio di nodi o validatori senza risolvere operatori, pesi e infrastrutture comuni.
  • Ignorare la concentrazione di clienti, cloud, geografia, governance, chiavi e catena di fornitura del software.
  • Supponendo che tutti i modelli di consenso abbiano le stesse soglie di errore o semantica di finalità.
  • Ignorare spartizioni, definitività ritardata, riorganizzazioni, equivoci e procedure di recupero.
  • Accettare intestazioni di blocco o prove senza i presupposti richiesti sulla disponibilità dei dati.
  • Dipendere da un solo RPC, explorer, portafoglio, indicizzatore o piattaforma di custodia come fonte della verità.
  • Confondere il possesso o il controllo del protocollo con il titolo legale, il ricorso o la recuperabilità.
  • Sottovalutare la crescita dello stato, la perdita di archivi, i costi di sincronizzazione e le barriere hardware.
  • Ignorare chiavi di aggiornamento, pause di emergenza, recupero sociale e fork controversi.
  • Dedurre privacy, scalabilità, valore dell’investimento o sicurezza dell’applicazione dall’etichetta blockchain.

Errori comuni

  • Ogni blockchain è decentralizzata e immutabile. Autorizzazione, indipendenza dell’operatore, scelta del fork, governance e ripristino determinano chi può modificare o rifiutare la cronologia.
  • I dati registrati sulla catena devono essere veri. Il consenso può concordare sulla registrazione fedele di un prezzo falso, di un documento contraffatto o dell’input di un’applicazione dannosa.
  • Una transazione valida dimostra il risultato previsto. Potrebbe prendere di mira l’indirizzo sbagliato, essere ripristinata dopo aver consumato le commissioni, emettere eventi fuorvianti o dipendere da passaggi successivi di bridge e custodia.
  • Più repliche migliorano sempre la sicurezza. Le repliche sotto un unico operatore, client, cloud o chiave possono fallire insieme e potrebbero non fornire una verifica indipendente.
  • Una blockchain è sempre migliore di un database convenzionale. Un operatore fidato, la cancellazione richiesta, un rendimento elevato o una semplice risoluzione delle controversie possono rendere un sistema convenzionale più appropriato.

Argomenti correlati

Fonti autorevoli

Navigazione

Cerca nella wiki...