Nel protocollo Bitcoin il termine Consensus Rules, in italiano Regole di consenso, viene utilizzato a quell'insieme di criteri di validazione rigorosi, non negoziabili e universalmente applicati che tutti i full node della rete Bitcoin devono far rispettare per determinare la validità delle transazioni e dei blocchi.

Queste regole definiscono collettivamente lo stato condiviso e la storia del registro Bitcoin (la blockchain), garantendo che tutti i partecipanti onesti convergano sulla stessa versione della verità. Sono codificate direttamente nel software del nodo client e rappresentano la definizione fondamentale del protocollo stesso.

Nella classificazione del protocollo Bitcoin e dei meccanismi di consenso rappresentano una distinzione rispetto alle Policy rules.

Scopo

Lo scopo primario delle regole di consensus è permettere alla rete distribuita di raggiungere un accordo univoco e coerente sullo stato del registro, nonostante l'assenza di un'autorità centrale e la potenziale presenza di attori malintenzionati.

Servono a:

• Garantire la Validità: Stabilire i criteri oggettivi per cui una transazione o un blocco sono considerati validi e possono essere aggiunti alla blockchain.
• Prevenire Attacchi Fondamentali: Impedire azioni fraudolente come il double-spending (spendere gli stessi bitcoin più volte) e la spesa non autorizzata (spendere bitcoin senza possedere la chiave privata corrispondente).
• Definire le Proprietà Economiche: Stabilire le caratteristiche monetarie fondamentali di Bitcoin, come l'offerta limitata e il tasso di emissione decrescente (halving).
• Mantenere la Coerenza della Storia: Assicurare che la blockchain sia un registro cronologico e immutabile degli eventi.

Caratteristiche

Le regole di consensus sono caratterizzate da:

• Obbligatorietà e Universalità: Ogni full node che partecipa alla rete deve aderire esattamente allo stesso set di regole di consensus. Qualsiasi deviazione, anche minima, porta all'incompatibilità con il resto della rete.
• Ambito Globale: Si applicano all'intera rete Bitcoin, non sono specifiche di un singolo nodo. L'accordo su queste regole è ciò che definisce la rete stessa.
• Immutabilità (Pratica) e Difficoltà di Modifica: Cambiare le regole di consensus è un processo complesso e delicato che richiede un ampio accordo all'interno della comunità e un aggiornamento coordinato del software su tutta la rete. Questo avviene tipicamente tramite un soft fork (introducendo regole più restrittive, compatibili con i vecchi nodi) o un hard fork (introducendo cambiamenti incompatibili che richiedono l'aggiornamento di tutti i nodi). Gli hard fork sono particolarmente rischiosi perché, in assenza di un consenso quasi unanime ("near-unanimity"), possono portare a una divisione permanente della rete e della valuta.

Un aspetto sottile ma fondamentale è che il "consensus" non riguarda solo le regole scritte in una specifica, ma anche la loro precisa implementazione nel software client dominante (storicamente, Bitcoin Core).
Anche bug, stranezze o interpretazioni specifiche nell'implementazione di riferimento possono diventare, di fatto, regole di consensus. Questo perché qualsiasi nodo che si discosti da questo comportamento preciso, anche se aderisce alla regola "intesa", rischierebbe di produrre blocchi o transazioni considerati invalidi dalla maggioranza della rete, perdendo così la sincronizzazione. Di conseguenza, raggiungere il consenso in pratica significa aderire al comportamento esatto dell'implementazione di riferimento, compresi i suoi eventuali difetti, fino a quando questi non vengono corretti tramite un aggiornamento coordinato della rete (fork). Ciò rende la creazione da zero di implementazioni alternative di full node estremamente difficile e rischiosa, data la necessità di una perfetta compatibilità comportamentale. Inoltre, il meccanismo di consenso di Bitcoin, spesso chiamato Nakamoto Consensus, non è semplicemente un insieme statico di regole, ma un processo emergente. L'accordo sulla catena valida emerge dall'interazione di nodi che seguono regole semplici (validare secondo le regole di consensus, costruire sulla catena valida più lunga vista per prima) e sono guidati da incentivi economici (i miner cercano di ottenere le ricompense dei blocchi evitando di creare blocchi orfani). I nodi validano blocchi e transazioni in base alle regole fisse. I miner investono potenza di calcolo (Proof-of-Work) per creare nuovi blocchi validi, estendendo la catena che percepiscono come la più lunga e valida. I nodi accettano il primo blocco valido che vedono estendere la catena più lunga. Gli incentivi economici spingono i miner a costruire sulla catena che ha la maggiore probabilità di essere accettata dagli altri, minimizzando il rischio di lavoro sprecato su blocchi orfani. Nel tempo, questo processo porta la rete a convergere su un'unica storia della catena, superando disaccordi temporanei (fork accidentali). Il consenso, quindi, è dinamico e probabilistico nel breve termine (finché i blocchi non sono profondamente sepolti nella catena), basandosi tanto sulla teoria dei giochi e sugli incentivi economici quanto su regole deterministiche.

Applicazione e Conseguenze della Violazione

• Meccanismo di Applicazione: L'applicazione delle regole di consensus è distribuita. Ogni full node verifica autonomamente e indipendentemente ogni transazione ricevuta e ogni nuovo blocco proposto rispetto all'intero set di regole di consensus. I miner, a loro volta, includono nei blocchi che propongono solo transazioni che hanno precedentemente validato come conformi a queste regole.
• Conseguenze della Violazione: Qualsiasi transazione o blocco che violi anche una sola regola di consensus è considerato universalmente invalido e viene immediatamente rigettato da tutti i nodi conformi al protocollo. Un nodo che riceve dati invalidi può decidere di disconnettere e bannare temporaneamente il peer che li ha inviati per proteggersi da spam o attacchi. I miner che tentano di costruire blocchi invalidi o di estendere una catena contenente un blocco invalido sprecano le loro risorse computazionali (elettricità) e non riceveranno alcuna ricompensa, poiché i loro blocchi verranno ignorati dal resto della rete (diventando blocchi orfani). Un disaccordo fondamentale e persistente sulle regole di consensus tra diverse fazioni della rete porta inevitabilmente a un hard fork, ovvero a una scissione permanente della blockchain in due catene distinte e incompatibili.

Esempi Illustrativi di Regole di Consensus

Esistono numerose regole di consensus in Bitcoin. Alcuni esempi fondamentali includono:

• Algoritmo Proof-of-Work (PoW): I blocchi devono contenere un hash valido (calcolato tramite SHA-256d sull'header del blocco) che sia inferiore al target di difficoltà corrente.

• Aggiustamento della Difficoltà: L'algoritmo che regola il target di difficoltà del PoW ogni 2016 blocchi (circa due settimane) per mantenere un tempo medio di generazione dei blocchi intorno ai 10 minuti, nonostante le variazioni nella potenza di calcolo totale della rete.

• Programma di Emissione (Halving): La regola predefinita che dimezza la ricompensa per i miner (sussidio di blocco) ogni 210.000 blocchi (circa ogni quattro anni), controllando l'offerta di nuovi bitcoin. L'attuale ricompensa è di 3.125 BTC per blocco.

• Limiti sulla Dimensione/Peso del Blocco: Regole che definiscono la dimensione massima (in byte) o il peso massimo (in weight units, introdotte con SegWit) di un blocco valido. Storicamente era 1MB, ora con SegWit il limite è di 4 milioni di weight units. (Nota: BSV ha rimosso questi limiti fissi, considerandoli "consensus mutabile" ).

• Criteri di Validità delle Transazioni:

• Verifica delle Firme Digitali: Le transazioni devono contenere firme ECDSA valide che dimostrino la proprietà degli input spesi, verificabili tramite la chiave pubblica corrispondente (es. OP_CHECKSIG).
• Bilancio della Transazione: La somma dei valori degli input di una transazione deve essere maggiore o uguale alla somma dei valori degli output. La differenza costituisce la commissione per il miner.
• Prevenzione del Double-Spending: Gli input di una transazione devono fare riferimento a output di transazioni precedenti (UTXO) che non siano già stati spesi nella stessa catena.

• Maturità della Coinbase: I bitcoin appena creati in una transazione coinbase (la prima transazione di un blocco, che include il sussidio e le commissioni) possono essere spesi solo dopo che sono stati confermati da 100 blocchi successivi.

• Formato dei Dati: Transazioni e blocchi devono aderire a specifiche strutture dati e formati di serializzazione per essere considerati validi. Il formato raw della transazione è parte delle regole di consensus poiché il suo hash contribuisce al merkle root del blocco.

• Validità dello Script: Regole che governano l'esecuzione e la validità degli opcode utilizzati nel linguaggio di scripting di Bitcoin (Script) per definire le condizioni di spesa degli output.

• Regola del Blocco Genesi: Tutti i blocchi validi devono discendere, direttamente o indirettamente, dal blocco genesi originale creato da Satoshi Nakamoto.

Cartella src/consensus nel codice sorgente di Bitcoin

La cartella src/consensus nel codice sorgente di Bitcoin Core è una directory fondamentale che contiene la logica centrale per la validazione di blocchi e transazioni secondo le regole di consenso del protocollo Bitcoin. Queste regole sono essenziali per la sicurezza e l'integrità della rete Bitcoin, garantendo che tutti i nodi completi partecipanti concordino sulla stessa storia delle transazioni e sullo stato attuale della blockchain.

Questa cartella è distinta dal codice relativo alle "policy" (politiche), che potrebbe dettare come i singoli nodi danno priorità o gestiscono le transazioni (ad esempio, nel loro mempool), ma non influisce sulla validità fondamentale di blocchi e transazioni concordata dalla rete. Il codice all'interno di src/consensus deve essere deterministico e strettamente seguito da tutti i nodi completi per prevenire fork e mantenere un'unica blockchain coerente.

I file chiave e i loro scopi generali trovati all'interno della cartella src/consensus includono:

• consensus.h: Questo file header definisce varie costanti e parametri critici per il consenso. Questi possono includere valori come la dimensione massima consentita per un blocco (o il peso, nelle versioni più recenti), il numero massimo di operazioni di firma consentite per blocco o transazione, il periodo di maturazione delle coinbase (quanti blocchi devono passare prima che l'output di una transazione coinbase possa essere speso) e altri limiti e parametri che fanno parte delle regole di consenso della rete.
• validation.h / validation.cpp: Questi file contengono le funzioni e la logica responsabile della validazione di transazioni e blocchi rispetto alle regole di consenso definite. Ciò implica il controllo delle firme, la verifica dell'esecuzione degli script, la garanzia del rispetto dei limiti di dimensione, la validazione della struttura di transazioni e blocchi e la conferma che le transazioni non stiano tentando di effettuare doppi spese (double-spending) di output. Qui è dove vengono implementati i controlli dettagliati che determinano se un blocco o una transazione è valido secondo le regole della rete.
• amount.h: Questo file definisce probabilmente i tipi di dati e le funzioni per la gestione degli importi in Bitcoin e garantisce che i calcoli che coinvolgono gli importi aderiscano alle regole di consenso, inclusi i controlli relativi alla fornitura massima di moneta (MAX_MONEY) per prevenire bug inflazionistici.