Policy e Consensus rules nel protocollo Bitcoin

Uno sguardo approfondito

La polemica mai del tutto sopita all'interno della community Bitcoin, su come vadano trattate le transazioni che contengono dati, è stata riaccesa dalla proposta di Peter Todd di modificare le regole relative all'operatore OP_Return.

Questa discussione è particolarmente attiva negli space "21 milioni di chiacchiere" su X/Twitter.

Anche il podcast di Turtlecute ha dedicato di recente un episodio in cui ha approfondito il tema con Daniela Brozzoni, analizzando anche le dinamiche del confronto con i Bitcoin Core Developer.

Per evitare che la discussione si polarizzi in sterili posizioni ideologiche, con proposte difficili o impossibili da implementare, è fondamentale comprendere che la proposta impatta le Policy Rules e non le Consensus Rules del protocollo Bitcoin.

Capire la netta distinzione tra:

• Consensus Rules: le regole che definiscono la validità intrinseca delle transazioni e dei blocchi che compongono il registro condiviso

• Policy Rules: chiamate anche standardness, le regole che governano il comportamento locale dei singoli nodi, la gestione delle risorse e l'interazione nella rete peer-to-peer.

è cruciale per afferrare appieno il funzionamento interno, la sicurezza e le dinamiche economiche di Bitcoin, e poter ragionare su quale è il funzionamento attuale di Bitcoin e quale potrà essere in futuro.

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à.

2. Consensus Rules: Il Fondamento Incrollabile di Bitcoin

2.1. Definizione

Le Consensus Rules (che in italiano vengono a volte tradotte in “Regole di consenso”) costituiscono l'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.

2.2. Scopo

Lo scopo primario delle Consensus Rules è 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.

2.3. Caratteristiche

Le Consensus Rules sono caratterizzate da:

• Obbligatorietà e Universalità: Ogni full node che partecipa alla rete deve aderire esattamente allo stesso set di Consensus Rules. 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 Consensus Rules è 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 chain split, 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, Consensus Rules.

È il caso ad esempio del peso del blocco, che nella recente versione 29.0 di Bitcoin Core è passato da 4000 WU a 3992 WU proprio a causa di un bug.

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 Consensus Rules, 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.

2.4. Applicazione e Conseguenze della Violazione

• Meccanismo di Applicazione: L'applicazione delle Consensus Rules è distribuita. Ogni full node verifica autonomamente e indipendentemente ogni transazione ricevuta e ogni nuovo blocco proposto rispetto all'intero set di Consensus Rules. 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 Consensus Rules tra diverse fazioni della rete porta inevitabilmente a un chain split, ovvero a una scissione permanente della blockchain in due catene distinte e incompatibili.

2.5. Esempi Illustrativi di Consensus Rules

Esistono numerose Consensus Rules 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 unit, introdotte con SegWit) di un blocco valido. Storicamente era 1MB, ora con SegWit il limite è di 4 milioni di weight unit.

• 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, periodo di tempo chiamato cooldown.

• 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 Consensus Rules 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.

3. Policy Rules: I Guardiani Configurabili dell'Accesso

3.1. Definizione

Le Policy Rules (spesso chiamate policy del nodo o policy della mempool) sono un insieme di linee guida configurabili che i singoli nodi Bitcoin utilizzano per prendere decisioni locali riguardanti le transazioni non confermate. Specificamente, determinano quali transazioni un nodo accetterà nella propria area di attesa temporanea (la memory pool o mempool), quali inoltrerà ad altri nodi della rete (relay), e quali priorità assegnerà loro, in particolare in vista della potenziale inclusione in un blocco da parte dei miner.

Crucialmente, queste regole sono locali a ciascun nodo. Ciò significa che nodi diversi possono operare con policy diverse, portando a stati della mempool non uniformi attraverso la rete. Non esiste una singola "mempool globale"; ogni nodo mantiene la propria versione basata sulle transazioni che ha ricevuto e sulle policy che applica.

3.2. Scopo

Le Policy Rules servono a diversi scopi pratici, principalmente legati alla gestione delle risorse del nodo e all'efficienza della rete P2P:

• Gestione delle Risorse: Proteggere le risorse computazionali e di memoria del nodo (CPU, RAM, larghezza di banda) limitando il numero, la dimensione e la complessità delle transazioni non confermate che vengono processate, memorizzate e ritrasmesse.

• Prevenzione di Spam e Attacchi DoS: Filtrare transazioni considerate "spam" (es. transazioni con commissioni irrisorie) o che potrebbero far parte di un attacco Denial-of-Service volto a sovraccaricare i nodi o la rete (es. transazioni eccessivamente complesse o output "dust" che gonfiano l'UTXO set).

• Prioritizzazione delle Transazioni: Influenzare l'ordine in cui le transazioni vengono trattate e, soprattutto, selezionate dai miner. Tipicamente, le policy danno priorità alle transazioni che offrono commissioni più elevate per unità di dati (satoshis per virtual byte, sat/vB).

• Facilitazione del Mercato delle Commissioni: Policy come la commissione minima di relay (minrelaytxfee) e l'espulsione dalla mempool basata sulla commissione quando questa è piena contribuiscono a creare e regolare il mercato delle commissioni di transazione, un meccanismo essenziale per l'allocazione dello spazio limitato nei blocchi.

• Efficienza della Rete: Promuovere una propagazione più efficiente dei blocchi e una validazione più rapida mantenendo le mempool dei nodi ragionevolmente coerenti (sebbene, come detto, una coerenza perfetta non sia né garantita né necessaria).

Le Policy Rules possono essere viste come euristiche: scorciatoie pratiche e regole decisionali basate sull'esperienza e su assunzioni riguardo al comportamento economico razionale e alle condizioni tipiche della rete. Sono progettate per ottimizzare le prestazioni del nodo e proteggerlo da minacce percepite a livello P2P. Ad esempio, richiedere una commissione minima si basa sull'assunzione che transazioni al di sotto di tale soglia siano probabilmente spam o economicamente non serie. Espellere transazioni a bassa commissione quando la mempool è piena si basa sull'assunzione che quelle a commissione più alta siano più "importanti" o desiderate dai miner. Queste sono assunzioni pratiche per la gestione locale, non verità fondamentali sulla validità definite dal consensus. Un miner potrebbe, in teoria, includere una transazione non standard a commissione zero se lo desiderasse, anche se ciò sarebbe economicamente irrazionale a causa del costo opportunità. Le policy rappresentano quindi un livello di filtraggio e prioritizzazione "best effort", riflettendo la strategia dell'operatore del nodo (o del software predefinito) per gestire lo spazio delle transazioni non confermate.

3.3. Caratteristiche

Le Policy Rules si distinguono per:

• Configurabilità/Opzionalità: Gli operatori dei nodi possono spesso modificare le impostazioni di policy tramite file di configurazione o parametri di avvio. L'adesione alle policy predefinite non è strettamente obbligatoria per la partecipazione alla rete, sebbene discostarsene troppo possa isolare il nodo o causare inefficienze.

• Ambito Locale: Si applicano esclusivamente al singolo nodo che le implementa. Non c'è un meccanismo di enforcement a livello di rete per le policy.

• Variabilità e Flessibilità: Le policy possono cambiare molto più facilmente delle Consensus Rules. Possono variare tra diverse versioni del software del nodo, essere modificate dagli utenti, o adattarsi dinamicamente alle condizioni della rete (ad esempio, la soglia minima di commissione per l'accettazione nella mempool può aumentare automaticamente quando la mempool supera la sua capacità massima).

Questa natura locale e configurabile delle policy porta inevitabilmente a una mempool frammentata. Poiché ogni nodo applica le proprie regole (riguardo a commissioni, dimensioni, standard, regole RBF, limiti di memoria, tempi di scadenza, ecc.) e riceve transazioni in momenti diversi a causa della latenza di rete, l'insieme di transazioni non confermate detenuto da un nodo può differire, a volte significativamente, da quello di un altro nodo nello stesso istante.

Di conseguenza, fare affidamento sul fatto che una transazione sia "nella mempool" non è una garanzia affidabile della sua futura conferma. I mempool explorer online mostrano la vista della mempool di uno specifico nodo (o di un insieme limitato di nodi) che gestisce il servizio. La conferma definitiva avviene solo quando la transazione è inclusa in un blocco valido accettato dal consensus della rete.

3.4. Applicazione e Conseguenze della Violazione

• Meccanismo di Applicazione: Il software del nodo esegue controlli basati sulle policy locali su ogni transazione non confermata che riceve. Solo se la transazione supera questi controlli, viene aggiunta alla mempool del nodo e potenzialmente inoltrata ai peer connessi.

• Conseguenze della Violazione: Una transazione che viola le Policy Rules di un nodo viene tipicamente scartata da quel nodo. Non viene aggiunta alla sua mempool e non viene inoltrata ad altri.
  È importante sottolineare che questo rifiuto è locale. La stessa transazione potrebbe essere perfettamente valida secondo le Consensus Rules e potrebbe essere accettata da altri nodi con policy meno restrittive, o inclusa direttamente in un blocco da un miner una mining pool che utilizzano le proprie policy, o ricevuta "out-of-band" cioè, non tramite il relay P2P standard come ad esempio il servizio Slipstream di Mara o Mempool accelerator di Mempool space.
  La violazione di una regola di policy non rende una transazione o un blocco invalidi a livello di consensus.
  Inoltre, transazioni già presenti nella mempool possono essere espulse (evicted) se le condizioni cambiano e non soddisfano più le policy dinamiche, come la soglia minima di commissione che aumenta quando la mempool si riempie.

3.5. Esempi Illustrativi di Policy Rules

Molte Policy Rules sono implementate con valori predefiniti nel client Bitcoin Core, ma possono essere modificate. Esempi comuni includono:

• Commissione Minima di Relay (minrelaytxfee): Una commissione minima (espressa in sat/vB) richiesta affinché una transazione sia considerata per l'inoltro e l'accettazione nella mempool. Il valore predefinito è spesso 1 sat/vB.

• Capacità Massima della Mempool (maxmempool): La quantità massima di memoria (RAM) che un nodo alloca per conservare le transazioni non confermate. Un default comune è 300 MB. Quando questo limite viene raggiunto, il nodo inizia a espellere le transazioni con la commissione più bassa per fare spazio a quelle nuove (se hanno una commissione sufficientemente alta).

• Scadenza della Mempool (mempoolexpiry): Il periodo di tempo dopo il quale una transazione non confermata viene rimossa dalla mempool se non è stata inclusa in un blocco. Il default è spesso 336 ore (14 giorni).

• Limite Dust: Una soglia minima per il valore degli output di una transazione. Output con un valore inferiore a questo limite (considerati "dust") potrebbero essere rifiutati o non inoltrati, poiché il costo per spenderli in futuro potrebbe superare il loro valore, contribuendo a gonfiare inutilmente l'insieme UTXO.

• Controlli di Standard (IsStandard()): Un insieme di regole aggiuntive che definiscono quali tipi di transazioni sono considerate "standard" e quindi sicure da inoltrare sulla rete. Transazioni che sono valide secondo il consensus ma non sono "standard" (es. utilizzano script non comuni o formati particolari) potrebbero non essere inoltrate dalla maggior parte dei nodi.

• Policy di Replace-by-Fee (RBF): Regole che determinano se e come una transazione non confermata può essere sostituita da una nuova versione inviata dallo stesso mittente, tipicamente per aumentarne la commissione e accelerarne la conferma. Le varianti includono Opt-in RBF (BIP 125), che richiede un segnale esplicito nella transazione originale, e Full RBF, che permette la sostituzione senza segnale preventivo, purché vengano soddisfatte determinate condizioni. Le condizioni tipiche includono il pagamento di una commissione assoluta e marginale superiore.

• Limiti su Antenati/Discendenti: Restrizioni sul numero massimo (es. 25) e sulla dimensione totale (es. 101 kvB) di un gruppo di transazioni non confermate correlate (una transazione e tutti i suoi antenati o discendenti non confermati) che possono coesistere nella mempool. Servono a prevenire certi tipi di attacchi (es. transaction pinning) e a limitare la complessità del calcolo delle priorità basate sulle commissioni degli antenati. La proposta "Cluster Mempool" mira a sostituire questi limiti con un meccanismo più robusto.

• Policy sulla Dimensione Massima della Transazione (maxtxsizepolicy): Un nodo può rifiutarsi di inoltrare o accettare nella mempool transazioni che superano una certa dimensione, anche se questa dimensione è inferiore al limite imposto dal consensus.

• Altre Policy Relative agli Script: Limiti sulla dimensione massima dello script, sul numero massimo di operazioni non-push per script, o sul numero massimo di chiavi pubbliche in un'operazione CHECKMULTISIG (es. maxscriptsizepolicy, maxopsperscriptpolicy, maxpubkeyspermultisigpolicy).

4. Confronto tra Consensus e Policy: Un'Analisi Comparativa

Per cristallizzare le differenze fondamentali tra le Consensus Rules e le Policy Rules, è utile un confronto diretto basato sulle caratteristiche discusse in precedenza. La tabella seguente riassume i punti chiave di distinzione:

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.

5. La 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, o le mining pool, tipicamente costruiscono i loro blocchi candidati, o block template, selezionando transazioni dalla propria mempool locale, la quale è stata popolata e filtrata secondo le proprie policy (o quelle predefinite del software che utilizzano).

Questo processo, in particolare nel contesto delle mining pool moderne, sta evolvendo grazie a protocolli come Stratum V2 o Datum, che consentono ai singoli miner di definire localmente le proprie policy sulla selezione delle transazioni, contribuendo così in modo granulare alla proposta di block template che viene poi coordinata e finalizzata a livello di pool.

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.

Far girare un nodo per un utente serve quindi anche per calcolare le fee ottimali per le proprie transazioni: rendersi ciechi, attraverso impostazioni locali della mempool, a transazioni che possono alterare pesantemente l’occupazione della mempool, significa rendere inutile il nodo per questo scopo.

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.

6. 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.

---

Bibliografia

1. Bitcoin - Wikipedia, https://en.wikipedia.org/wiki/Bitcoin

2. FAQ mempool https://mempool.space/docs/faq

3. What are blockchain consensus rules? - Bitstamp, https://www.bitstamp.net/learn/security/what-are-blockchain-consensus-rules/

4. Consensus Mechanism Overview - WisdomTree, https://www.wisdomtree.com/investments/-/media/base-media-files/corporate-site/wisdomtree_consensus_mechanism_overview.pdf

5. Bitcoin mining and consensus: How to reach an agreement for validating the blockchain? - Banco Santander, https://www.santander.com/en/stories/blockchain-consensus

6. Bitcoin rules vs. Consensus rules - CoinGeek, https://coingeek.com/bitcoin-rules-vs-consensus-rules/

7. Updating Consensus | Saylor Academy, https://learn.saylor.org/mod/book/tool/print/index.php?id=36383

8. Consensus - Bitcoin Wiki, https://en.bitcoin.it/wiki/Consensus

9. Full node - Bitcoin Wiki, https://en.bitcoin.it/wiki/Full_node

10. What Are Consensus Mechanisms in Blockchain and Cryptocurrency? - Investopedia, https://www.investopedia.com/terms/c/consensus-mechanism-cryptocurrency.asp

11. What are Consensus Mechanisms? - Visa, https://usa.visa.com/solutions/crypto/consensus-mechanisms.html

12. How does Bitcoin work?, https://bitcoin.org/en/how-it-works

13. Bitcoin protocol - Wikipedia, https://en.wikipedia.org/wiki/Bitcoin_protocol

14. Vocabulary - Bitcoin Wiki, https://en.bitcoin.it/wiki/Vocabulary

15. What is the Bitcoin mempool, and how does it work? - Cointelegraph, https://cointelegraph.com/learn/what-is-the-bitcoin-mempool

16. Transactions - Bitcoin, https://developer.bitcoin.org/reference/transactions.html

17. What is the Bitcoin mempool, and how does it work? - OSL, https://osl.com/academy/article/what-is-the-bitcoin-mempool-and-how-does-it-work

18. Memory Pool | Waiting Area for Transactions - Learn Me A Bitcoin, https://learnmeabitcoin.com/technical/mining/memory-pool/

19. FAQ - mempool - Bitcoin Explorer, https://mempool.space/docs/faq

20. What Is a Mempool? - Ledger, https://www.ledger.com/academy/what-is-a-mempool

21. What is the Mempool? - How Blockchain Transactions Work - Blocknative, https://www.blocknative.com/blog/mempool-intro

22. What is Mempool? Definition & Meaning | Crypto Wiki - BitDegree, https://www.bitdegree.org/crypto/learn/crypto-terms/what-is-mempool

23. Transactions in mempool: best-practices and known issues - Stacks Forum, https://forum.stacks.org/t/transactions-in-mempool-best-practices-and-known-issues/11659

24. What Is the Bitcoin Mempool? Transaction Delays Explained - RockItCoin, https://www.rockitcoin.com/what-is-the-bitcoin-mempool/

25. bitcoin/doc/policy/mempool-replacements.md at master - GitHub, https://github.com/bitcoin/bitcoin/blob/master/doc/policy/mempool-replacements.md

26. Consensus cleanup soft fork https://bitcoinops.org/en/topics/consensus-cleanup-soft-fork/

27. What is the Bitcoin Mempool? A Beginner's Explanation (for 2025), https://99bitcoins.com/cryptocurrency/bitcoin/mempool/

28. Transaction replacement - Bitcoin Wiki, https://en.bitcoin.it/wiki/Transaction_replacement

29. Cluster mempool | Bitcoin Optech, https://bitcoinops.org/en/topics/cluster-mempool/