Fermata #241 - Covenant parte 1: CTV

Già due anni fa, con questa newsletter, ospitai un dibattito tra Giacomo Zucco e Alekos Filini su CTV, una delle proposte di soft-fork più discusse al tempo. Le cose oggi non sono molto cambiate, se non che a CTV si sono aggiunte nuove proposte per applicare i cosiddetti covenant a Bitcoin.

Con questa fermata, dunque, inizia un ciclo di puntate il cui obiettivo è esplorare le opzioni principali: come funzionano, quali implicazioni hanno, quali i pro e i contro di ciascuna. CheckTemplateVerify non può che essere la prima protagonista. Per rendere il tutto più chiaro e possibilmente comprensibile anche a un pubblico non tecnico, serve però partire dalle basi.

Bitcoin Script

Bitcoin Script è un linguaggio di scripting semplice e non Turing-completo, usato per definire le condizioni di spesa delle transazioni Bitcoin. Un opcode (operational code) è essenzialmente un comando o funzione all’interno di uno script Bitcoin​. Gli opcode operano su uno insieme di dati: ad esempio, OP_ADD è l’opcode che somma due numeri, mentre OP_EQUAL confronta due valori per verificarne l’uguaglianza​. Gli opcode possono svolgere operazioni matematiche, logiche o crittografiche (come OP_CHECKSIG che verifica firme digitali), permettendo di creare smart contract rudimentali su Bitcoin.

Bitcoin Script include anche opcode riservati (come i vari OP_NOP – no-operation) che al momento attuale non fanno nulla, ma sono destinati ad eventuali futuri aggiornamenti del protocollo. Proprio sfruttando uno di questi opcode dormienti è possibile introdurre nuove funzionalità tramite soft fork: i nodi non aggiornati continueranno a trattare l’opcode come un’istruzione priva di effetto — accettandolo comunque come valido — mentre i nodi aggiornati ne applicheranno la nuova semantica, consentendo così un aggiornamento cosiddetto retro-compatibile.

L’opcode OP_CHECKTEMPLATEVERIFY

OP_CHECKTEMPLATEVERIFY - abbreviato in OP_CTV - è un opcode proposto per Bitcoin tramite la Bitcoin Improvement Proposal BIP-119 di Jeremy Rubin​. La proposta prevede di riutilizzare l’opcode inutilizzato OP_NOP4 assegnandogli una nuova semantica: quella, per l’appunto, di OP_CHECKTEMPLATEVERIFY​.

In termini semplici, OP_CTV permette a uno script di vincolare l’output di una transazione affinché possa essere speso solo tramite una specifica transazione predefinita (o da un insieme predefinito di transazioni). Tecnicamente, lo script di blocco (locking script) di un UTXO include un hash crittografico a 32 byte – chiamato template hash o commitment hash – che rappresenta il modello della transazione di spesa consentita. Quando qualcuno tenta di spendere quell’UTXO, l’opcode OP_CTV verifica che l’hash della transazione corrente corrisponda esattamente al valore atteso nello script​.

In concreto, OP_CTV vincola la struttura di una futura transazione on-chain: versione, locktime, numero di input e output, hash degli output (comprendente gli indirizzi e importi di destinazione) e altri campi vengono inclusi nel calcolo dell’hash che l’opcode controlla​. Questo significa che l’UTXO protetto da CTV potrà essere sbloccato solo da una transazione che rispetta esattamente quel template prestabilito.

L’idea è quella di consentire al mittente di una transazione di imporre condizioni sul modo in cui il destinatario potrà spendere gli UTXO ricevuti​. In Bitcoin oggi gli script possono vincolare solo le azioni del mittente (ad esempio richiedendo che presenti una firma valida); con CTV invece il mittente può “programmare in anticipo” le regole di spesa future degli UTXO, creando quello che viene chiamato in generale un covenant. È importante notare che BIP-119 è progettato deliberatamente in modo non ricorsivo: la restrizione si applica solo alla prossima transazione. In altre parole, OP_CTV permette covenant predefiniti limitati a uno specifico percorso di spesa e non covenant generali o ricorsivi che continuerebbero a vincolare i coin per sempre​. Questo vincolo riduce la complessità e i potenziali rischi, come vedremo in seguito.

Il contesto storico: Jeremy Rubin e l’ipotesi Speedy Trial

La proposta di introdurre OP_CTV risale al 2020, quando lo sviluppatore Jeremy Rubin pubblicò la BIP-119 con specifica e codice di riferimento​.

Dopo l’attivazione con successo del soft fork Taproot (novembre 2021), l’attenzione si è rivolta a quali potessero essere i prossimi upgrade del protocollo. CTV era (ed è) uno dei candidati principali, insieme ad altre proposte come ANYPREVOUT (BIP-118) o la reintroduzione di OP_CAT. Jeremy Rubin si fece promotore attivo di CTV: durante la conferenza Bitcoin 2022 a Miami raccolse feedback da sviluppatori e utenti, riscontrando interesse.

Subito dopo, il 19 aprile, Rubin inviò una mail alla bitcoin-dev mailing list proponendo un piano concreto per l’attivazione di CTV tramite Speedy Trial​. In breve, Speedy Trial è un metodo di attivazione rapida di un soft fork basato sul miner signaling: si dà ai miner un breve periodo per segnalare supporto all’upgrade nei blocchi che producono, con una soglia alta di adesione (ad es. 90% dei blocchi in un intervallo di difficoltà). Se la soglia viene raggiunta entro la finestra temporale, l’upgrade viene lockato per l’attivazione successiva; in caso contrario, l’attivazione non avviene. Taproot è stato attivato in questo modo.

Rubin auspicava un percorso simile, ma la reazione della community fu dura. Le motivazioni furono molteplici, ma il succo è che un soft-fork non si attiva a cuor leggero: se proprio c’è un consenso quasi unanime sui benefici di un upgrade, allora magari si può aspettare di concludere anche altre migliorie su cui si sta lavorando per poter includere tutto in un unico soft-fork. Mettere mano al Consenso non è un gioco da ragazzi e va fatto con estrema cautela, soprattutto se è stato già modificato recentemente. Di fronte alle polemiche lo stesso Rubin fece marcia indietro.

Dai vault alle channel factories

Tecnicamente CTV è apprezzato da molti per le nuove funzionalità che renderebbe possibili su Bitcoin. Vediamo le principali:

• Covenant e condizioni di spesa vincolate: un esempio base di covenant potrebbe essere il pagamento “a due fasi”: Alice invia BTC a Bob ma lo script è tale che Bob, per spendere quei BTC, deve a sua volta inviarli solo a Carol. Senza CTV ciò richiederebbe transazioni pre-firmate o altri escamotage; con CTV il tutto è codificato on-chain tramite l’hash del template di spesa.

• Vault: uno dei casi d’uso più discussi è la costruzione di vault, ovvero indirizzi speciali pensati per la custodia sicura di bitcoin a lungo termine. In un vault basato su CTV, l’utente può definire a priori condizioni stringenti su come e quanto si può prelevare dal suo deposito. Ad esempio, si potrebbe impostare che i fondi in cold storage possano uscire solo verso un certo indirizzo di destinazione pre-approvato (es. il proprio hot wallet) e con un ammontare limitato in un dato intervallo di tempo​. I vault quindi potrebbero migliorare la sicurezza di custodire bitcoin personalmente, riducendo i rischi di furto.

• Congestion control: un’altra applicazione riguarda la scalabilità on-chain, in particolare la gestione efficiente della congestione della mempool e delle commissioni. L’idea è di usare CTV per combinare e posticipare certi pagamenti durante i periodi di traffico elevato, distribuendoli poi quando la rete è meno sovraccarica​. Immaginiamo un grande exchange o processore di pagamenti che deve effettuare 1000 pagamenti verso i clienti. In momenti di blocchi pieni e commissioni elevate, invece di trasmettere 1000 transazioni separate (competendo per lo spazio e facendo impennare le fee), potrebbe emettere una sola transazione on-chain che contiene un unico output aggregato impegnato con CTV​. Questa transazione “compatta” viene confermata immediatamente, pagando fee minime, e funge da contenitore: al suo interno l’output è vincolato a un template che, ad esempio, espanderà quell’output in 1000 transazioni individuali verso ciascun destinatario finale. L’espansione effettiva avverrà più tardi, quando la domanda di spazio nei blocchi sarà calata e le fee più economiche​. In pratica è come se l’azienda “prenotasse” spazio in un blocco costoso con una sola operazione, e poi riempisse i dettagli dei pagamenti in blocchi successivi a basso costo. In sintesi, CTV permette di separare il momento in cui una transazione viene confermata on-chain dal momento in cui i destinatari finali ottengono i loro output, ottimizzando il costo totale di fee pagate.

• Channel factories: CTV apre interessanti possibilità anche per Lightning Network. Un concetto chiave è quello di shared UTXO, ossia di UTXO condivisi da più partecipanti con condizioni di uscita predefinite, come descritto nella puntata dedicata ad ARK. Molti utenti potrebbero aprire canali Lightning tutti insieme usando una sola transazione on-chain​. In questo modo, per esempio, 50 canali verrebbero aperti con il solo costo on-chain di una transazione.

Molte di queste soluzioni sarebbero teoricamente possibili già oggi senza CTV (mediante transazioni pre-firmate, sequenze di time-lock, multisig complessi, ecc.), ma risultano impraticabili per via dell’elevata coordinazione, interattività e fiducia richiesta tra le parti​. CTV automatizza e codifica a livello di Consenso questi schemi, permettendo di realizzarli in modo trustless una volta distribuito il contratto iniziale​.

Le implicazioni socio-politiche

Al di là delle conseguenze tecniche ed economiche appena analizzate, CTV ha fatto parlare di sé anche per le potenziali implicazioni socio-politiche.

Uno dei timori più citati riguarda possibili abusi a livello di regolamentazione o censura. L’idea è la seguente: se Bitcoin introducesse la possibilità di vincolare gli indirizzi di uscita, potrebbe un governo o una grande azienda tentare di sfruttarla per imporre restrizioni? Ad esempio, uno scenario ipotizzato è quello di whitelist di indirizzi: un exchange o un custode potrebbe forzare i prelievi dei clienti dentro script CTV che consentono di spendere i coin solo verso un set di indirizzi “autorizzati” (magari indirizzi KYC verificati, o approvati da autorità di regolamentazione).

In tal modo, i bitcoin usciti da quell’exchange sarebbero marchiati: se provi a mandarli altrove, la transazione non sarebbe valida per via del covenant, a meno che il destinatario non sia nella whitelist. Questo potrebbe compromettere la fungibilità di Bitcoin – alcuni UTXO sarebbero spendibili solo verso certe destinazioni, diventando di fatto “monete diverse” da quelle libere​.

Questo scenario è preso molto sul serio dalla comunità, che giustamente ci tiene a proteggere la fungibilità e la neutralità della rete. Bisogna sottolineare però che CTV, per design, non permette covenants ricorsivi: non è possibile imporre vincoli che persistano in perpetuo transazione dopo transazione​.

Una whitelist veramente efficace per censurare richiederebbe che ogni output successivo resti vincolato a sua volta (coventant infinito); CTV invece consente solo di vincolare l’immediata prossima spesa, dopo di che il vincolo scompare. Quindi, se anche un exchange usasse CTV per limitare l’output di prelievo, l’utente potrebbe sempre scegliere di consumare quella transazione vincolata e poi ottenere coin liberi.

Inoltre, l’esperienza di CTV ha già avuto un impatto politico sul processo di upgrade di Bitcoin. La discussione su Speedy Trial vs consenso più organico ha mostrato due scuole di pensiero: una più frettolosa, desiderosa di innovare Bitcoin man mano che le migliorie sono pronte, e un’altra più conservatrice, che preferisce cambiare il protocollo solo in casi di necessità stringente e possibilmente accumulando più modifiche assieme per diradare i soft fork​. CTV è stato percepito da questi ultimi come non urgente e potenzialmente prematuro.

La vicenda ha anche sollevato domande su chi e come decidere quando c’è sufficiente consenso. A differenza di Taproot, dove c’era un chiaro sostegno quasi unanime, per CTV nel 2022 il consenso era nebuloso: molti sviluppatori erano favorevoli all’idea ma titubanti sui tempi; altri contrari al tempismo ma non al concetto in sé. In assenza di un consenso schiacciante, forzare una attivazione viene giustamente visto come controproducente​.

Per ora CTV rimane in attesa, ma non è escluso che in futuro – magari sotto una forma leggermente diversa – trovi la sua strada nel protocollo.