Protagonisti assoluti della discussione sul prossimo aggiornamento di Bitcoin: quali sono le proposte di covenant più rilevanti? Quali le posizioni della community?
L’idea di implementare i covenant su Bitcoin nasce dalla volontà di ampliare i casi d’uso del protocollo applicando delle restrizioni al codice di scripting. In pratica, i covenant consentono di limitare non solo l’utilizzo immediato di un UTXO, ma anche quello futuro. Tale funzionalità introduce nuove possibilità per applicazioni legate alla sicurezza, alla scalabilità e alla gestione dello spazio on-chain. Le proposte relative ai covenant sono oggetto di ampio dibattito: da un lato generano ottimismo per le potenzialità legate alla scalabilità della rete, dall’altro creano preoccupazioni legate alla maggiore complessità del protocollo – che potrebbe introdurre rischi oggi ignoti – e alla possibilità di compromettere la fungibilità di Bitcoin nel lungo periodo.
Di seguito una rassegna delle proposte più discusse.
CheckTemplateVerify (CTV)
CheckTemplateVerify (CTV) è una proposta che introduce un nuovo modo di controllare come gli UTXO potranno essere spesi in futuro. In pratica, CTV permette di “programmare” in anticipo una sequenza di transazioni, definendo esattamente come i fondi potranno muoversi. Ciò consente, per esempio, di creare un indirizzo con condizioni specifiche che consentano di spendere gli UTXO ricevuti in modalità predeterminate.
È come creare un percorso prestabilito per i bitcoin: una volta che i fondi vengono depositati su un determinato indirizzo, possono essere spostati solo in base alle regole definite inizialmente. Ciò aumenta la sicurezza e la prevedibilità delle transazioni future.
Cosa abilita?
CTV permette l’abilitazione di due nuovi casi d’uso:
- Vault di sicurezza: i valut sono un tipo di covenant che richiede due transazioni separate, inserite in due blocchi differenti, per permettere a un utente di spendere i fondi dal proprio wallet. La prima transazione serve come segnale che qualcuno sta cercando di spendere i fondi, dando all’utente la possibilità di bloccare la seconda transazione, che è quella che effettivamente completa l’operazione.
- Timeout Trees/Channel Factories: i Timeout Trees sono un sistema per organizzare pagamenti multipli in modo efficiente. Partendo da una singola transazione, CTV permette di creare automaticamente una serie di pagamenti collegati tra loro, come i rami di un albero. Ogni ramo segue regole precise e include vie d’uscita di emergenza.
Inoltre CTV migliora i protocolli e le applicazioni Bitcoin che si basano su transazioni pre-firmate.
CTV rappresenta un compromesso tra potenza e semplicità: offre miglioramenti importanti mantenendo la complessità sotto controllo, ma rinuncia alla flessibilità di soluzioni più elaborate.
ANYPREVOUT (APO)
ANYPREVOUT (APO) è una proposta che modifica il modo in cui le transazioni Bitcoin vengono firmate. A differenza del sistema attuale, dove ogni firma è legata a una specifica transazione precedente (UTXO), APO permette di creare firme valide per qualsiasi UTXO che soddisfi determinate condizioni.
È come avere una chiave che può aprire qualsiasi porta di un certo tipo, invece di una chiave specifica per una singola porta.
Cosa abilita?
APO è progettato principalmente per due scopi:
- Miglioramenti al Lightning Network: APO permette di rendere il Lightning Network più semplice e sicuro. Oggi, quando due persone aprono un canale Lightning, devono gestire molti stati diversi e sistemi di penalità per evitare truffe. APO semplifica il processo: rende più facile aggiornare i canali, riduce il rischio di perdere fondi per errori tecnici e permette di gestire meglio i backup.
- Protocollo Eltoo/LN-Symmetry: Eltoo è un nuovo modo di gestire i canali Lightning che diventa possibile grazie ad APO. Oggi, se qualcuno prova a usare uno stato vecchio del canale, perde tutti i suoi fondi come penalità. Con Eltoo, tale sistema punitivo non serve più: gli stati vecchi vengono semplicemente superati dai nuovi, rendendo il backup dei canali più semplice.
APO è una proposta focalizzata sul miglioramento del Lightning Network. Non è una soluzione generale per Bitcoin, ma risolve problemi specifici dei canali di pagamento. Può tecnicamente replicare le funzionalità di CTV, ma con alcuni svantaggi importanti. La replica richiede di salvare firme e transazioni pre-firmate, rendendo il processo più complicato e meno efficiente rispetto a CTV.
OP_CAT
OP_CAT è un’operazione che permette di unire (concatenare) due pezzi di informazione in uno solo durante l’esecuzione di una transazione Bitcoin. È come avere un operatore che prende due parole separate e le unisce in una sola frase.
Cosa abilita?
- Smart contract avanzati
OP_CAT permette di creare smart contract Bitcoin più sofisticati. Per esempio, rende possibile costruire wallet multisig in grado di cambiare le loro regole nel tempo, o vault che possono essere programmati con condizioni più complesse. È importante notare che OP_CAT, da solo, ha utilità limitate, ma quando combinato insieme alle firme di Schnorr permette di costruire strutture più elaborate. Altre proposte di covenant diventano più potenti e flessibili quando possono utilizzare la funzionalità di concatenazione offerta da OP_CAT.
- Covenant semplici
Con OP_CAT si possono creare forme semplificate di covenant, cioè regole che controllano come i bitcoin potranno essere spesi in futuro. Questo apre la porta a nuove applicazioni per la sicurezza e la gestione dei fondi, senza dover introdurre altre modifiche al protocollo Bitcoin.
Ma la flessibilità dell’operatore costituisce anche il suo principale punto debole, poiché rende difficile prevedere e controllare tutti i possibili utilizzi. Un’argomentazione contro OP_CAT è che alcune delle possibilità che potrebbe creare non sarebbero necessariamente vantaggiose per gli utenti di Bitcoin e potrebbero portare a conseguenze impreviste e non sempre positive per la rete (esempio: drivechain o progetti alternativi a Bitcoin).
TX_HASH
TX_HASH è una proposta che mira a colmare una lacuna nel sistema di scripting di Bitcoin: la capacità di ispezionare e verificare i dettagli delle transazioni in modo più granulare. Mentre la sua utilità tecnica è chiara, soprattutto per applicazioni di sicurezza avanzata, la complessità della sua implementazione potrebbe rappresentare un ostacolo alla sua adozione.
TX_HASH è uno strumento che permette di leggere e verificare i dettagli di una transazione Bitcoin direttamente all’interno di uno script.
Cosa abilita?
- Verifica avanzata
TX_HASH permette di controllare le transazioni in modi nuovi. Un wallet può verificare non solo chi sta spendendo i bitcoin, ma anche come verranno utilizzati in futuro.
- Vault intelligenti
Con TX_HASH si possono costruire vault più sofisticati che possono reagire a diverse situazioni. Per esempio, un vault può bloccare automaticamente i fondi se nota comportamenti sospetti, o può applicare regole diverse in base al tipo di transazione che viene tentata.
Confronto tra CTV e TX_HASH
CTV e TX_HASH rappresentano due approcci diversi al controllo delle transazioni future:
- con CTV è come scrivere un contratto dove ogni dettaglio è specificato in anticipo. È semplice ma rigido: tutto deve essere pianificato prima e non si possono fare modifiche.
- TX_HASH invece è più flessibile: permette di scegliere quali parti della transazione futura controllare. È come un contratto dove alcuni spazi vengono lasciati in bianco per essere compilati più tardi. Questo risolve problemi pratici come:
- la gestione delle commissioni (che possono variare nel tempo)
- il controllo selettivo di certi elementi della transazione
- la verifica che input e output abbiano gli stessi valori
Il protocollo Ark potrebbe tecnicamente funzionare anche attualmente, senza covenant, ma richiederebbe molta più interazione tra gli utenti.
Per funzionare al meglio, Ark ha bisogno di un sistema che permetta di programmare le transazioni future:
- CTV potrebbe essere utilizzato, ma è come usare un formato rigido prestabilito;
- TX_HASH sarebbe l’ideale, perché offre più flessibilità, come un modulo dove alcuni campi possono essere compilati in seguito.
La differenza è tra il dover pianificare tutto nei minimi dettagli in anticipo (CTV) e avere un piano generale con alcuni dettagli che possono essere definiti al momento del bisogno (TX_HASH).
LN_HANCE
LN_HANCE è un insieme di miglioramenti pensato specificamente per il Lightning Network. Combina diverse tecnologie (OP_CHECKSIGFROMSTACK + OP_PAIRCOMMIT + OP_INTERNALKEY + OP_CTV), tra cui CTV, per rendere i pagamenti Lightning più efficienti e sicuri.
Cosa abilita?
- Lightning Network ottimizzato
LN_HANCE rende più facile aprire e gestire i canali Lightning. Riduce il numero di transazioni necessarie per iniziare a usare Lightning (oggi per aprire un canale LN sono necessarie due transazioni una volta che il proprio nodo si è sincronizzato con la rete) e rende più economico muovere i fondi tra diversi canali. Introduce sistemi automatici per gestire i problemi comuni dei canali Lightning. Se un canale smette di funzionare o un partecipante diventa irraggiungibile, LN_HANCE può aiutare a recuperare i fondi o a ripristinare il canale senza intervento manuale.
- Vault intelligenti
Con LN_HANCE si possono costruire vault più sofisticati che possono reagire a diverse situazioni. Per esempio, un vault può bloccare automaticamente i fondi se nota comportamenti sospetti, o può applicare regole diverse in base al tipo di transazione che viene tentata.
- Timeout Trees/Channel Factories
LN_HANCE faciliterebbe l’uso delle Channel Factories, un metodo per aprire e gestire canali tra più utenti utilizzando un unico indirizzo multisig. I partecipanti depositano i loro fondi su un indirizzo condiviso on-chain e possono aprire, chiudere o gestire i canali off-chain senza dover tornare onchain, riducendo le transazioni sulla blockchain e ottimizzando l’uso dello spazio nei blocchi.
Senza aggiornamenti al protocollo, le Channel Factories funzionano già, ma diventano difficili da gestire con molti partecipanti. LN_HANCE utilizza soluzioni come OP_CTV e altre tecnologie per semplificare tale complessità, consentendo una gestione più efficiente e permettendo ad alcuni partecipanti di agire da soli senza dover coinvolgere tutti gli altri. Ciò le rende più scalabili e pratiche per reti con molti utenti.
- Protocollo Eltoo/LN-Symmetry
Come APO, anche LN_HANCE permette l’introduzione del protocollo Eltoo/LN-Symmetry.
Reazioni della comunità
Secondo Marco Argentieri, Ceo di Ark Labs, potrebbe essere più facile trovare un consenso su un soft fork che aggiunge diversi OP_Code specializzati e più semplici da un punto di vista tecnico piuttosto che un soft fork che prevede l’implementazione di un solo OP_Code più versatile. Ad Atlas21 Argentieri ha dichiarato:
“Se tutta la rete è favorevole all’implementazione dei covenant credo che la proposta che possa trovare un consenso maggiore sia The Great Script Restoration, un’idea proposta da Rusty Russell che punterebbe a riattivare molti degli OP_Code disattivati nel 2010 da Satoshi Nakamoto. Attivare ora, in maniera affrettata, un singolo OP_Code potrebbe rivelarsi una scelta limitante in futuro. Penso sia meglio fare un soft fork fatto bene rispetto ad ottenere delle funzionalità limitate subito per poi ritrovarsi a dover effettuare un nuovo soft fork”.
Per Giacomo Zucco, direttore di Plan B Network, la proposta migliore sarebbe APO, non tanto per una questione tecnica ma quanto per una motivazione politica. Ai microfoni di Atlas21 Zucco ha affermato:
“Penso che le persone che hanno proposto APO stiano facendo un ottimo e paziente lavoro di spiegazione per cercare di far capire i vantaggi della loro soluzione e convincere gli utenti ad integrarla. Al contrario penso che OP_CAT sia vittima del tentativo da parte di alcuni attori di prendere il sopravvento sulla governance di Bitcoin. Al momento OP_CTV sembra essere la proposta con il maggiore supporto”.
Secondo John Carvalho, Ceo di Synonym, i covenant non rappresentano una soluzione utile per far scalare Bitcoin, anzi potrebbero introdurre dei rischi al protocollo:
“I covenant sono una soluzione speculativa che interessa a poche persone, senza alcuna prova di reale necessità o impatto. Smettetela di cercare di cambiare il consenso. Smettetela di comportarvi come se sapeste cosa è meglio per gli altri. Non sapete nulla. State solo facendo supposizioni. La condivisione degli UTXO è una delle esperienze utente peggiori che abbia mai affrontato, e siete tutti un gruppo di egocentrici illusi che non meritano fiducia. Ogni progressista merita ogni lacrima di frustrazione finché non capisce che Bitcoin non è il loro campo giochi. Portate i vostri esperimenti su una shitcoin e dimostrate il loro valore lì”.
