Fermata #243 - Covenant parte 3: OP_CAT

OP_CAT è un opcode del linguaggio di script di Bitcoin. Fu inizialmente parte del set di opcodes di Bitcoin, ma venne disabilitato nel 2010 da Satoshi Nakamoto insieme ad altri opcodes per ragioni di sicurezza​.

L’idea di reintrodurre OP_CAT ha ripreso vigore negli ultimi anni. Ethan Heilman, ricercatore e co-fondatore di BastionZero, e Armin Sabouri, ingegnere di Botanix Labs, hanno avanzato una proposta formale per riportare OP_CAT in Bitcoin Script nel 2023. La proposta è stata discussa inizialmente sulla bitcoin-dev mailing list il 21 ottobre 2023, accompagnata da una bozza di Bitcoin Improvement Proposal (BIP). Nella primavera 2024, la proposta è diventata ufficialmente BIP-347​.

Funzionamento tecnico di OP_CAT

OP_CAT è un’operazione molto semplice a prima vista: serve per unire due pezzi di dati e farli diventare uno solo. Si pensi di avere due post-it, ognuno con una scritta sopra. OP_CAT prende quei due foglietti e li incolla uno dietro l’altro, creando un unico post-it con entrambi i messaggi. In gergo tecnico si dice che concatena i dati.

Bitcoin Script si basa su uno stack, cioè una sorta di pila di elementi dati. OP_CAT prende i due elementi in cima a questa pila, li unisce e rimette il risultato in cima. Questo permette a uno script di costruire, mentre viene eseguito, dati più grandi o complessi a partire da elementi più piccoli.

Per evitare abusi o problemi di sicurezza - come la creazione di script troppo grandi che consumano troppa memoria - OP_CAT funziona solo se i due pezzi di dati che deve unire non superano una certa dimensione complessiva. Questo limite – 520 byte – è stato introdotto con Taproot nel 2021. È anche uno dei motivi per cui nel 2010 Satoshi aveva deciso di disattivare OP_CAT insieme ad altre operazioni: all’epoca non esistevano limiti precisi e il rischio di abusi era più alto.

La proposta prevede un soft-fork, che, come spiegato nella fermata #58, è un aggiornamento retrocompatibile. In parole semplici, OP_CAT verrebbe introdotto rinominando un operatore dormiente (spiegati nella fermata #241 dedicata a CTV), nello specifico OP_SUCCESS126.

Perché tutto questo sforzo per una funzione che, alla fine, incolla due dati?

Bitcoin Script è volutamente un linguaggio molto minimale: è stato progettato per essere sicuro e difficile da attaccare, ma questo lo rende anche poco flessibile. L’aggiunta di OP_CAT è come inserire nella cassetta degli attrezzi un coltellino svizzero che permette di costruire logiche più sofisticate.

Con OP_CAT, per esempio, uno script potrebbe prendere vari dati inseriti da chi sta cercando di spendere un output (come un numero, un indirizzo, una firma), unirli, e controllare se il risultato corrisponde a un valore atteso. Questo rende possibile costruire verifiche più intelligenti, come quelle necessarie per i covenant – contratti che non solo decidono chi può spendere i fondi, ma anche come e dove potranno essere spesi in futuro.

Innovazione o fumo negli occhi?

OP_CAT da solo non realizza completamente un covenant, ma è l’ingrediente mancante per costruirne molti. Combinando OP_CAT con altri opcodes esistenti è possibile implementare condizioni complesse. Rispetto a OP_CTV, OP_CAT è più flessibile e apre la porta a covenants più generali e programmabili. L'opcode permette di costruire dinamicamente stringhe di dati, combinarle e verificare che il risultato corrisponda a un hash previsto. In questo senso, OP_CAT non sostituisce CTV, ma lo completa: mentre CTV dà controllo assoluto e deterministico su una sola transazione, OP_CAT permette di scrivere condizioni più generiche, in grado di verificare interattivamente la validità di diversi tipi di spesa, finché rispettano certi criteri predefiniti.

Ma non è tutto oro quel che luccica. Tra le molte promesse associate a OP_CAT, una delle più pubblicizzate è la possibilità di migliorare la scalabilità off-chain e l’interoperabilità tra blockchain. Ma se da un lato è vero che un linguaggio più potente può abilitare costruzioni tecniche più complesse, dall’altro va mantenuto un certo grado di realismo – soprattutto quando le proposte arrivano da ambienti più inclini all’hype che al rigore progettuale.

Uno degli esempi più emblematici è il progetto CatVM, presentato dal gruppo dei Taproot Wizards (sì, quelli degli Ordinals e degli NFT su Bitcoin). Secondo la loro narrazione, OP_CAT permetterebbe la nascita di un “bridge permissionless” tra Bitcoin e altre reti, capace di muovere BTC verso Layer 2 o addirittura altre blockchain compatibili con la Ethereum Virtual Machine (EVM), come se si potessero trasportare asset tra mondi diversi semplicemente concatenando qualche dato e verificando un hash. Il bridge funzionerebbe, dicono, senza custodi, senza federazioni, senza fiducia: trustless, magico e sicuro.

Ma l’idea presenta numerosi punti deboli e, soprattutto, appare più come una campagna di marketing che una vera ricerca tecnica. Non esistono implementazioni funzionanti, né documentazione formale, né audit, né testnet credibili. L’intera proposta è stata lanciata a suon di meme, NFT e video con gattini, sfruttando l’immaginario pop per catturare l’attenzione di utenti non tecnici. Va aggiunto che è difficile prendere sul serio un’iniziativa del genere quando viene dai co-fondatori di una collezione di ordinals e jpeg che si promuove come se fosse una tech company rivoluzionaria, ma che nei fatti lavora sull’immagine più che sul codice.

Anche i cosiddetti “trustless bridge” sono più uno slogan che una prospettiva concreta. Senza un modo affidabile per verificare cosa è successo su un L2, in particolar modo se centralizzato, concatenare l’hash di quel dato su L1 non significa nulla. In sostanza, OP_CAT può facilitare l’espressione di certe condizioni – ma non fornisce nessuna garanzia sulla loro attendibilità.

Sul fronte della scalabilità on-chain, si è parlato del ruolo che OP_CAT potrebbe avere in costrutti come CoinPool o Channel Factory, ovvero strutture che permettono a più utenti di condividere un UTXO e operare off-chain con poche transazioni. Anche qui l’idea è che OP_CAT consenta di vincolare il comportamento futuro di un output, costruendo dinamicamente condizioni che si verificano solo se una transazione segue uno schema predeterminato. Ma questa promessa non è nuova: concetti simili sono in circolazione da anni, già previsti con OP_CTV (che è molto più semplice e sicuro da analizzare), o con script complessi che non richiedono nuovi opcodes.

Il vero problema è che OP_CAT, per certi ambienti, non è solo un opcode. È diventato un simbolo di rottura culturale: tra chi, spesso per interessi personali, vuole “innovare” a ogni costo – anche importando nel mondo Bitcoin la logica del “move fast and break everything” tipica di Ethereum – e chi invece ritiene, a ragion veduta, che l’integrità, la semplicità e la prevedibilità siano le vere forze del protocollo.

Effetti sul Lighting Network ed eventuali rischi

Il Lightning Network potrebbe beneficiare indirettamente di OP_CAT. In particolare, c’è un legame con la proposta di eltoo (spiegata nella fermata precedente). Una delle strade per implementare eltoo senza introdurre un nuovo tipo di firma come ANYPREVOUT è attraverso i covenant intelligenti. Combinando OP_CAT con altri futuri opcodes come OP_CHECKSIGFROMSTACK (CSFS), gli script potrebbero ricostruire e verificare l’hash di una transazione direttamente nello script e controllare che corrisponda a uno stato autorizzato.

In parole semplici, OP_CAT fornirebbe la colla per prendere vari pezzi (chiave pubblica, messaggio, firma, ecc.), concatenarli e verificarli, all’interno dello script del canale. Questo avrebbe l’effetto di simulare il comportamento di ANYPREVOUT (o di CTV+CSFS, un’altra combinazione proposta) senza dover modificare le regole di firma: il covenant stesso si occuperebbe di accettare solo la transazione con l’ultimo stato autorizzato.

La domanda principale da porsi quando si parla delle possibili implicazioni di OP_CAT è una: dando ai programmatori più potenza, aumenta il rischio di script complessi potenzialmente scritti male? Un’opinione diffusa è che covenants e script più articolati possano portare a errori logici – ad esempio uno sviluppatore potrebbe definire un covenant con una condizione troppo permissiva o un bug che lo rende inutile, mettendo a rischio i fondi. Tuttavia, questo è un rischio opt-in: starà agli utilizzatori scegliere di usare script avanzati solo quando sono ben testati.

Dal lato privacy, i covenant introdotti da OP_CAT hanno effetti ambivalenti. Da una parte, la capacità di imporre regole ai futuri spend potrebbe ridurre la fungibilità: se alcuni UTXO sono “marchiati” da covenants molto rigidi, potrebbero diventare distinguibili e meno intercambiabili con UTXO “normali”. Ma la critica è in gran parte confutata dal fatto che le condizioni di spesa in un covenant sono determinate volontariamente dall’utente che blocca i fondi. Nessuno può inserire a posteriori un vincolo su un UTXO altrui: se un governo volesse farlo, dovrebbe controllare il 100% delle volte in cui quei bitcoin vengono spostati, cosa impraticabile; inoltre gli utenti potrebbero rifiutarsi di accettare depositi con covenant indesiderati.

Un’altra critica viene da chi preferirebbe un salto concettuale maggiore invece che modifiche incrementali. Ad esempio, il linguaggio Simplicity (sviluppato da Blockstream) promette di sostituire Bitcoin Script con un sistema molto più espressivo e formale che eliminerebbe il bisogno di aggiungere opcodes uno ad uno. Alcuni sviluppatori – vedasi ad esempio la posizione di Rusty Russell – suggeriscono che stiamo “spremendo il massimo da Bitcoin Script” e siamo vicini al limite, per cui forse sarebbe meglio introdurre direttamente Simplicity anziché OP_CTV, OP_CAT ecc. che aggiungono toppe al vecchio Script.

Quindi quali sono le prospettive per OP_CAT?

Sul fronte dell’adozione tecnica, OP_CAT è oggi uno dei candidati principali per il prossimo upgrade di Bitcoin insieme a OP_CHECKTEMPLATEVERIFY (BIP-119) e APO. Non c’è però ancora un consenso diffuso: verosimilmente, nel corso del 2025 vedremo aumentare il dibattito su se e come includere OP_CAT (magari insieme ad altri opcodes complementari) in un prossimo soft-fork combinato.