Le regole di policy, chiamate anche policy del nodo o policy della mempool, traducibile letteralmente in italiano con Regole di politica ma con il significato di Regole operative o Regole di comportamento, sono un insieme di linee guida configurabili che i singoli nodi Bitcoin utilizzano per prendere decisioni locali riguardanti le transazioni non confermate.

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

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.

Scopo

Le regole di policy 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 regole di policy 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.

Caratteristiche

Le regole di policy 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 regole di consensus. 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. Gli esploratori di mempool 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.

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 regole di policy 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 regole di consensus e potrebbe essere accettata da altri nodi con policy meno restrittive, o inclusa direttamente in un blocco da un miner che la riceve "out-of-band" (cioè, non tramite il relay P2P standard) o che utilizza policy personalizzate. 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.

Esempi Illustrativi di Regole di Policy

Molte regole di policy 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).