È un sistema per ottenere un consenso tra i partecipanti ad una rete sullo stato o sui dati.

I sistemi distribuiti decentralizzati, come Bitcoin, affrontano una sfida fondamentale: come raggiungere un accordo (consenso) sullo stato condiviso del sistema tra partecipanti indipendenti, potenzialmente non fidati e geograficamente dispersi, in assenza di un'autorità centrale.

Bitcoin risolve questo problema, noto anche come il Problema dei Generali Bizantini, attraverso una combinazione innovativa di crittografia a chiave pubblica, un meccanismo di proof-of-work, incentivi economici e un insieme definito di regole protocollari.
Questo approccio permette a nodi disconnessi di seguire una direzione comune e mantenere un registro pubblico distribuito e immutabile, la blockchain, senza la necessità di istruzioni centralizzate.

Per garantire l'ordine, la sicurezza e la coerenza all'interno di questa rete decentralizzata, è essenziale disporre di regole chiare che governino il comportamento dei partecipanti.

Tuttavia, non tutte le regole nel protocollo Bitcoin hanno lo stesso scopo, ambito di applicazione o livello di rigidità.
È quindi necessario distinguere nettamente tra:

• Consensus rules, regole di consensus: le regole che definiscono la validità intrinseca delle transazioni e dei blocchi che compongono il registro condiviso
• Policy rules: le regole che governano il comportamento locale dei singoli nodi, la gestione delle risorse e l'interazione nella rete.

Comprendere questa distinzione è cruciale per afferrare appieno il funzionamento interno, la sicurezza e le dinamiche economiche di Bitcoin.

La distinzione tra "consensus" e "policy" è ampiamente accettata e utilizzata, specialmente in riferimento all'implementazione di riferimento Bitcoin Core.

Secondo l'interpretazione prevalente nel contesto Bitcoin, la modifica delle Consensus rules e quindi di qualsiasi regola che influenzi la validità dei blocchi o delle transazioni richiede un aggiornamento coordinato dei partecipanti della rete (soft fork o hard fork) e non può essere soggetta a cambiamenti discrezionali da parte dei miner.

La tabella seguente riassume i punti chiave di distinzione tra Consensus rules e Policy rules:

Questa tabella evidenzia come le Consensus rules stabiliscano la "verità" oggettiva e condivisa della blockchain, mentre le Policy rules gestiscano il flusso "soggettivo" e locale delle transazioni in attesa di diventare parte di quella verità.

Un aspetto interessante emerge da questo confronto: mentre le Consensus rules mirano a un accordo assoluto e universale, le Policy rules abbracciano la variazione locale come una necessità pratica per operare in una rete eterogenea con risorse finite. La rete Bitcoin è composta da nodi con hardware, connessioni di rete e tolleranze ai costi operativi molto diversi. Imporre regole identiche e rigide sull'uso delle risorse (come una dimensione fissa della mempool per tutti) potrebbe escludere partecipanti con meno risorse o risultare inefficiente per quelli con capacità maggiori. Le Policy rules permettono a ciascun nodo di impostare limiti locali basati sulle proprie capacità e priorità. Questa flessibilità locale consente alla rete di funzionare nonostante l'eterogeneità, ma al costo intrinseco di avere mempool frammentate e non perfettamente sincronizzate. Si può quindi considerare la policy come un' "imperfezione necessaria": la mancanza di una singola mempool globale è un compromesso accettato in cambio della resilienza, dell'efficienza e dell'accessibilità per una gamma più ampia di partecipanti. La policy agisce come un meccanismo tampone che permette ai nodi di partecipare secondo le proprie possibilità, mentre il consensus fornisce la verità fondamentale e ultima su cui tutti devono concordare.

Relazione Simbiotica: Come la Policy Supporta il Consensus

Nonostante le loro nette differenze, le Consensus rules e le Policy rules non operano in isolamento. Esiste una relazione simbiotica in cui le policy agiscono come un livello preparatorio, di filtraggio e di gestione cruciale che supporta e facilita il funzionamento del meccanismo di consensus sottostante.

L'interfaccia primaria dove questa interazione avviene è la mempool. La mempool è l'area di attesa dinamica dove le policy vengono applicate. Funziona come un buffer tra le transazioni grezze trasmesse sulla rete P2P e la loro potenziale inclusione in un blocco, che è un evento governato dal consensus.

Le policy supportano il consensus attraverso diversi meccanismi:

• Filtraggio dello Spam: Policy come minrelaytxfee e i limiti "dust" impediscono che il livello di consensus (cioè i miner che assemblano i blocchi) venga sommerso da un volume eccessivo di transazioni economicamente insignificanti o potenzialmente dannose. Questo preserva le risorse dei nodi e dei miner per l'elaborazione di attività economiche valide.
• Prioritizzazione per i Miner: Le policy basate sulle commissioni (priorità a sat/vB elevati, RBF per aumentare le commissioni) aiutano i miner, che sono attori economicamente razionali, a selezionare in modo efficiente le transazioni dalla loro mempool che massimizzano i loro profitti (commissioni raccolte). Questo allinea gli incentivi economici dei miner con la funzione di conferma delle transazioni della rete e, di fatto, ordina le transazioni presentate per l'inclusione nel blocco a livello di consensus.
• Protezione delle Risorse: Limiti come maxmempool assicurano che i nodi non esauriscano la memoria a causa di un accumulo eccessivo di transazioni non confermate, permettendo loro di rimanere operativi e continuare a partecipare alla validazione e propagazione dei blocchi, che sono attività essenziali per il consensus.
• Facilitazione della Validazione: Inoltrando prevalentemente transazioni "standard", le policy aiutano a garantire che i miner ricevano transazioni che hanno un'alta probabilità di superare rapidamente i controlli di validità del consensus. Anche se imperfetta, una certa coerenza tra le mempool dei nodi può anche contribuire a una validazione più rapida dei nuovi blocchi ricevuti.

È fondamentale comprendere che i miner tipicamente costruiscono i loro blocchi candidati selezionando transazioni dalla propria mempool locale, la quale è stata popolata e filtrata secondo le proprie policy (o quelle predefinite del software che utilizzano). Pertanto, le policy adottate dai nodi e dai miner in tutta la rete influenzano collettivamente la composizione dei blocchi che vengono poi convalidati dal consensus, anche se le policy stesse non fanno parte delle Consensus rules.

Questa interazione ha un impatto diretto sulla formazione del mercato delle commissioni. Mentre le Consensus rules definiscono semplicemente che le commissioni possono esistere (come differenza tra input e output) , sono le Policy rules a definire come i nodi trattano le transazioni in base alle commissioni offerte (commissione minima di relay, prioritizzazione per fee rate, espulsione dalla mempool per basse commissioni). I miner, guidati dal profitto, selezionano le transazioni a commissione più alta dalle loro mempool filtrate dalle policy. Gli utenti, osservando i tempi di conferma e la congestione della mempool (che è influenzata dalle policy in atto sulla rete), aggiustano le commissioni che offrono per le loro transazioni. Questa interazione dinamica tra offerte degli utenti, policy dei nodi e selezione dei miner costituisce il mercato delle commissioni. Le Policy rules sono, di fatto, il motore operativo di questo mercato, che è essenziale per allocare lo spazio limitato nei blocchi e per fornire un incentivo economico ai miner, soprattutto man mano che il sussidio di blocco diminuisce nel tempo a causa degli halving.

Infine, sebbene la violazione delle policy non invalidi i blocchi, la comprensione e la potenziale manipolazione delle dinamiche della mempool attraverso le policy possono rappresentare una superficie di attacco indiretta. Ad esempio, attacchi come il "transaction pinning" (dove si crea una catena di transazioni che impedisce a una transazione target di essere sostituita tramite RBF) o lo sfruttamento di interazioni complesse tra le regole RBF e i limiti su antenati/discendenti potrebbero ostacolare la capacità di specifici utenti o applicazioni (come i protocolli di secondo livello) di ottenere conferme tempestive. Attori malintenzionati con una profonda conoscenza delle policy dei nodi potrebbero ottenere un vantaggio o disturbare l'esperienza di altri utenti. Anche se questo non infrange la validità del consensus, può influire sulla liveness (capacità di ottenere conferma) o sull' utilità percepita della rete per alcuni partecipanti. Questo è uno dei motivi per cui la progettazione delle policy è un'area attiva di ricerca e sviluppo (come dimostra la proposta Cluster Mempool ), poiché ha implicazioni significative per l'usabilità e la sicurezza a livello applicativo, anche se non modifica le regole fondamentali del consensus.

Ruoli Distinti, Scopo Unificato

In sintesi, il funzionamento robusto e ordinato della rete Bitcoin si basa su due insiemi distinti ma profondamente interconnessi di regole: le Consensus rules e le Policy rules.

Le Consensus rules formano il fondamento immutabile e universalmente applicato del protocollo. Definiscono cosa costituisce una transazione valida e un blocco valido, garantendo l'integrità del registro distribuito, prevenendo il double-spending e assicurando che tutti i partecipanti onesti convergano su un'unica storia condivisa della blockchain. Sono il cuore della sicurezza e dell'affidabilità di Bitcoin, applicate rigorosamente da ogni full node e modificabili solo attraverso processi di aggiornamento complessi e consensuali (fork).

Le Policy rules, d'altra parte, operano a un livello diverso. Sono meccanismi locali, flessibili e configurabili che i singoli nodi utilizzano per gestire le proprie risorse, filtrare il traffico di transazioni non confermate nella mempool e facilitare il processo di selezione delle transazioni da parte dei miner. Proteggono i nodi dallo spam e dagli attacchi DoS, contribuiscono a formare il mercato delle commissioni e forniscono un'interfaccia pratica tra il flusso caotico delle transazioni P2P e l'ordine rigoroso imposto dal consensus.

Le differenze chiave risiedono nel loro ambito (rete vs. nodo), obbligatorietà (mandatorie vs. configurabili), conseguenze della violazione (invalidità a livello di rete vs. rifiuto locale) e mutabilità (difficile vs. facile da cambiare).

Tuttavia, questa netta distinzione non implica isolamento. Esiste una forte interdipendenza: il consensus, per funzionare efficientemente su larga scala, si affida al filtraggio, alla prioritizzazione e alla gestione delle risorse operate dalle policy a livello di mempool. Le policy danno forma pratica ai requisiti astratti del consensus, agendo come un sistema immunitario decentralizzato che protegge il nucleo vitale del protocollo. Una comprensione approfondita di entrambe le categorie di regole – sia le fondamenta incrollabili del consensus sia le dinamiche flessibili delle policy – è quindi essenziale per chiunque desideri comprendere a fondo, utilizzare in modo sicuro, costruire applicazioni o analizzare criticamente la rete Bitcoin e le sue complesse interazioni tecniche ed economiche.