1. Introduzione
Il modello Unspent Transaction Output (UTXO) di Bitcoin, sebbene elegante per il trasferimento concorrente di valuta, presenta limitazioni significative per l'implementazione di smart contract complessi e con stato, a causa della mancanza di uno stato mutabile condiviso. I covenant emergono come un primitivo linguistico critico proposto per estendere Bitcoin Script, consentendo a una transazione di imporre vincoli sugli script delle transazioni di riscatto future. Questo articolo affronta la lacuna nei modelli formali e astratti per i covenant, che sono stati descritti principalmente da una prospettiva di basso livello e focalizzata sull'implementazione sin dalla loro nascita intorno al 2013. Fornendo una base formale, il lavoro mira a semplificare il ragionamento sulle proprietà dei contratti, a consentire la specifica di casi d'uso avanzati oltre le capacità attuali di Bitcoin e a facilitare la progettazione di astrazioni di programmazione di livello superiore.
2. Il Modello Bitcoin Puro
L'articolo adatta una formalizzazione del modello di transazione core di Bitcoin. Nel modello UTXO, lo stato della blockchain è definito da un insieme di output di transazione non spesi. Ogni output contiene un valore (quantità di bitcoin) e uno scriptPubKey (script di blocco) che specifica le condizioni richieste per spenderlo. Una transazione di spesa fornisce uno scriptSig (script di sblocco) e fa riferimento all'UTXO che desidera consumare. La validazione comporta l'esecuzione degli script concatenati. Fondamentalmente, lo standard Bitcoin Script è limitato: non può introspezionare o vincolare la struttura della transazione di spesa oltre la verifica della firma e l'aritmetica/logica di base, impedendo la creazione di contratti che impongono protocolli multi-step.
3. Modello Formale dei Covenant
Il contributo principale è un modello formale che astrae i proposti opcode dei covenant (come OP_CHECKTEMPLATEVERIFY).
3.1. Primitivi dei Covenant & Sintassi
Il modello introduce predicati dei covenant come estensioni di Bitcoin Script. Un covenant è essenzialmente un vincolo $C(T_x, T_{next})$ che valuta vero o falso, dove $T_x$ è la transazione corrente che viene spesa e $T_{next}$ è la proposta transazione di spesa. Il predicato può ispezionare campi di $T_{next}$, come i suoi script di output, gli importi o i locktime.
3.2. Semantica Operazionale
La regola di validazione è estesa: per un UTXO con un covenant, la validazione di una transazione di spesa $T_{next}$ richiede non solo che il suo scriptSig soddisfi l'originale scriptPubKey, ma anche che il predicato del covenant $C$ valga per la coppia $(T_x, T_{next})$. Questo è definito formalmente utilizzando regole di semantica operazionale che integrano il controllo del covenant nella logica di validazione Bitcoin esistente.
3.3. Covenant Ricorsivi & Macchine a Stati
Una variante potente è il covenant ricorsivo, dove $C$ può imporre che l'output di $T_{next}$ stesso contenga lo stesso (o un correlato) covenant $C'$. Ciò consente l'implementazione di macchine a stati su Bitcoin: ogni transazione rappresenta una transizione di stato, con il covenant che garantisce che le regole della macchina a stati siano seguite attraverso una catena di transazioni. L'articolo formalizza ciò come una sequenza di transazioni $T_1, T_2, ..., T_n$ dove per ogni $i$, $C(T_i, T_{i+1})$ vale.
4. Specificare Contratti Bitcoin Complessi
Il modello formale è applicato per specificare contratti attualmente inesprimibili o macchinosi in Bitcoin puro.
4.1. Vault & Prelievi con Time-Lock
I covenant possono creare "vault" dove i fondi rubati possono essere recuperati. Una transazione può richiedere che qualsiasi prelievo di grandi dimensioni debba prima andare a un output con time-lock, consentendo al proprietario di annullarlo se non autorizzato. Ciò è specificato da un covenant che controlla il campo nLockTime e la struttura di output di $T_{next}$.
4.2. Canali di Pagamento & Lightning Network
Sebbene Lightning Network esista, i covenant possono semplificare e rendere più sicura la sua costruzione sottostante. Possono imporre che la transazione di chiusura di un canale debba essere lo stato più recente, prevenendo la trasmissione di stati vecchi, vincolando la transazione di spesa a corrispondere a un aggiornamento pre-firmato.
4.3. Primitivi di Finanza Decentralizzata (DeFi)
Costrutti DeFi semplici come debito garantito o swap non-custodiali diventano possibili. Un covenant può bloccare fondi in una transazione che può essere spesa solo da una transazione che presenta una prova crittografica valida di pagamento da una controparte o di liquidazione.
5. Primitivi di Linguaggio di Alto Livello
L'articolo discute come i covenant possano servire come target di compilazione per linguaggi contrattuali di alto livello. Primitivi come "preleva dopo il tempo T", "spendi solo se la controparte firma" o "transisci lo stato da A a B" possono essere mappati direttamente a specifici vincoli di covenant, elevando il livello di astrazione per gli sviluppatori di contratti Bitcoin.
6. Insight Fondamentale & Prospettiva dell'Analista
Insight Fondamentale: Bartoletti et al. non stanno solo proponendo un altro opcode per covenant; stanno fornendo la teoria formale mancante che trasforma un hack intelligente in un paradigma di programmazione legittimo e analizzabile per Bitcoin. Questa è la chiave che sblocca l'ingegneria sistematica di contratti complessi e sicuri su blockchain UTXO, andando oltre lo scripting ad-hoc.
Flusso Logico: L'argomentazione è convincentemente semplice: 1) Il modello UTXO di Bitcoin manca di stato, limitando i contratti. 2) I covenant proposti come soluzione sono scarsamente compresi formalmente. 3) Pertanto, costruiamo un modello formale. 4) Utilizzando questo modello, dimostriamo che può esprimere casi d'uso complessi e preziosi (vault, canali, DeFi). 5) Questo formalismo poi abilita naturalmente la progettazione di linguaggi di livello superiore. È un classico percorso "la teoria abilita la pratica" eseguito con precisione.
Punti di Forza & Debolezze: Il punto di forza principale è colmare il divario tra teoria crittografica/PL e ingegneria Bitcoin—un divario che ha portato a bug costosi nel modello basato su account di Ethereum. La semantica formale consente la verifica delle proprietà, un grande vantaggio. La debolezza, implicitamente riconosciuta, è l'economia politica di Bitcoin. Come nota l'articolo, l'"approccio estremamente cauto" di Bitcoin rende il dispiegamento di nuovi opcode come i covenant un compito erculeo, indipendentemente dalla loro eleganza formale. Il successo di Layer-2 come Lightning senza covenant nativi solleva anche interrogativi sulla necessità rispetto alla piacevolezza. Inoltre, la sicurezza del modello si basa sull'assunzione che i campi vincolati (come gli hash degli script) siano sufficienti; effetti di interazione imprevisti con altri opcode potrebbero persistere.
Insight Azionabili: Per i ricercatori, questo articolo è una roadmap: usare metodi formali per de-rischiare e chiarire gli aggiornamenti blockchain. Per gli sviluppatori, iniziare a progettare framework contrattuali ora assumendo che i covenant esisteranno (come visto su Liquid o Stacks). Per gli sviluppatori del protocollo Bitcoin, l'articolo fornisce la base rigorosa necessaria per sostenere BIP 119 (OP_CTV) o proposte simili—trasforma una richiesta di funzionalità in una specifica ingegneristica. Il takeaway più grande: il futuro degli smart contract Bitcoin non riguarda l'imitazione di Ethereum, ma il sfruttamento del paradigma unico UTXO+covenant per creare una nuova classe di applicazioni decentralizzate, potenzialmente più sicure e scalabili.
7. Dettagli Tecnici & Formalizzazione
Il modello formale definisce transazioni, script e validazione in modo contestuale. Un dettaglio tecnico chiave è la rappresentazione del vincolo del covenant. Sia $ exttt{tx}$ a rappresentare una transazione. Un covenant può essere visto come una funzione:
$\text{Covenant}_{\text{cond}} : \texttt{tx}_{\text{current}} \times \texttt{tx}_{\text{next}} \times \sigma \rightarrow \{\text{True}, \text{False}\}$
dove $\sigma$ rappresenta il contesto di validazione (altezza del blocco, ecc.). Il predicato $\text{cond}$ può essere una congiunzione di controlli sui campi di $\texttt{tx}_{\text{next}}$:
$\text{cond} \equiv (\texttt{hashOutputs}(\texttt{tx}_{\text{next}}) = H) \land (\texttt{nLockTime}(\texttt{tx}_{\text{next}}) > T) \land ...$
Ciò si allinea con proposte come OP_CHECKTEMPLATEVERIFY, che spinge un hash di parti specificate della transazione di spesa sullo stack per il confronto. La proprietà ricorsiva è formalizzata assicurando che un output di $\texttt{tx}_{\text{next}}$ contenga uno script $S'$ che a sua volta impone un covenant $\text{Covenant}_{\text{cond}'}$.
8. Framework di Analisi & Caso Esempio
Esempio: Un Semplice Contratto Vault
Obiettivo: Creare un UTXO che può essere speso in due modi: 1) Istantaneamente, ma solo verso un indirizzo specifico di "cold storage". 2) Verso qualsiasi indirizzo, ma solo dopo un ritardo di 30 giorni (consentendo la cancellazione in caso di furto).
Applicazione del Framework utilizzando il Modello Formale:
1. Script di Blocco Iniziale (scriptPubKey): Contiene una condizione di covenant $C_1$.
2. Covenant $C_1(T_{vault}, T_{spend})$: Deve valutare a Vero. Controlla:
a) Percorso A (Istantaneo): $\texttt{hashOutputs}(T_{spend}) = H_{cold}$ // L'output deve avere hash corrispondente all'indirizzo di cold storage pre-committato.
b) Percorso B (Ritardato): $\texttt{nLockTime}(T_{spend}) \geq \text{currentBlock} + 4320$ (30 giorni in blocchi) E $\texttt{hashOutputs}(T_{spend})$ può essere qualsiasi cosa.
3. Validazione: Quando si spende l'UTXO del vault con $T_{spend}$, il nodo Bitcoin esegue lo script. Richiede una firma dal proprietario del vault e verifica che $C_1$ valga per la coppia di transazioni.
Questo esempio dimostra come il predicato $C(T_x, T_{next})$ del modello formale sia istanziato con controlli concreti sui campi della transazione successiva, abilitando una proprietà di sicurezza (recupero dal furto) impossibile in Bitcoin base.
9. Applicazioni Future & Direzioni
La formalizzazione apre diverse strade future:
- Compilatori Verificati: Costruire compilatori da linguaggi di alto livello (come estensioni di Simplicity o Miniscript) a Bitcoin Script con covenant incorporati, con prove formali di correttezza.
- Covenant Cross-Chain: Esplorare covenant che condizionano le spese a eventi provenienti da altre blockchain o oracoli, utilizzando prove crittografiche come SPV, come accennato da lavori precedenti su "bridge" e ricerche recenti sui rollup.
- Covenant che Preservano la Privacy: Integrare controlli dei covenant con prove a conoscenza zero (ad es., utilizzando firme Taproot/Schnorr) per nascondere la logica del contratto pur continuando a imporla, una direzione esplorata in progetti come Ark.
- Analisi di Sicurezza Formale: Utilizzare il modello per analizzare sistematicamente la sicurezza delle costruzioni di covenant proposte contro attacchi economici e crittografici, simile al lavoro svolto sugli smart contract di Ethereum dalla comunità dell'IEEE Symposium on Security and Privacy.
- Semplificazione dei Protocolli Layer-2: Riprogettare protocolli come Lightning Network o sidechain (Liquid) per renderli più efficienti e con minimizzazione della fiducia sfruttando covenant nativi, riducendo la necessità di complesse watchtower o federazioni.
10. Riferimenti
- M. Bartoletti, S. Lande, R. Zunino. Bitcoin covenants unchained. arXiv:2006.03918v2 [cs.PL]. 2020.
- S. Nakamoto. Bitcoin: A Peer-to-Peer Electronic Cash System. 2008.
- J. Poon, T. Dryja. The Bitcoin Lightning Network: Scalable Off-Chain Instant Payments. 2016.
- M. Moser, I. Eyal, E. G. Sirer. Bitcoin Covenants. Financial Cryptography 2016 Workshops.
- Bitcoin Improvement Proposal 119 (BIP 119). OP_CHECKTEMPLATEVERIFY.
- G. Wood. Ethereum: A Secure Decentralised Generalised Transaction Ledger. Ethereum Yellow Paper. 2014.
- A. Miller, et al. Hashed Timelock Contracts (HTLCs). 2017.
- R. O'Connor. Simplicity: A New Language for Blockchains. Proceedings of the 2017 Workshop on Programming Languages and Analysis for Security.
- Blockstream. Liquid Network. https://blockstream.com/liquid/
- IEEE Symposium on Security and Privacy. Multiple papers on smart contract security analysis. Vari anni.