Analisi del paper pubblicato dallo sviluppatore Peter Todd. Non solo CTV: i covenant più interessanti e le proposte di layer-2 per migliorare la scalabilità di Bitcoin.
In Bitcoin le transazioni on-chain seguono un rapporto uno a uno: per ogni transazione è necessario effettuare una transazione sulla timechain. Il Lightning Network migliora tale rapporto, permettendo a molte transazioni di avvenire in un singolo canale, legato a un solo UTXO.
Tuttavia avere un UTXO per ogni utente potrebbe non essere sufficiente per la scalabilità del protocollo. Per questo motivo esistono diverse proposte per permettere a più persone di condividere il possesso di un singolo UTXO in modo indipendente, migliorando ulteriormente la scalabilità della rete.
Cos’è un layer-2
Una soluzione di tipo layer-2 (L2) è definita come un sistema progettato per permettere transazioni più frequenti rispetto alle transazioni on-chain.
Nel paper Todd chiarisce che un L2 deve soddisfare due requisiti fondamentali:
- garantire che nessuno possa rubare fondi;
- permettere ai proprietari dei fondi di ritirarli unilateralmente senza la cooperazione di terze parti.
Tale definizione consente di escludere dalla categoria dei L2 soluzioni come Liquid, Cashu, Fedimint, RGB e Statechain, sistemi che prevedono il controllo di terzi sui fondi o che non permettono di transare direttamente bitcoin in maniera trustless.
Come spacchettare un UTXO per più persone? Canali e V-UTXO
Tra le varie soluzioni di scalabilità L2 emergono due principali approcci: i canali e i V-UTXO.
Il modello dei canali, utilizzato dal Lightning Network, si basa su transazioni pre-firmate tra le parti, che dividono un UTXO e consentono transazioni continue senza la necessità di registrarle on-chain, a meno che non sia necessario risolvere una disputa tra le due parti.
Dall’altro lato, il modello dei V-UTXO (Virtual UTXO), come proposto dal progetto Ark, offre un approccio dove gli UTXO vengono virtualizzati e gestiti off-chain, consentendo transazioni tra utenti senza creare nuovi UTXO “reali” sulla blockchain. I V-UTXO possono essere creati, trasferiti e spesi in modo efficiente, con un coordinatore che gestisce la loro durata e validità. Potremmo paragonare i V-UTXO a un assegno con scadenza che viene emesso da una banca in seguito al deposito di fondi. Tale approccio permette di condividere un singolo UTXO tra più utenti, riducendo il carico sulla timechain e migliorando la scalabilità.
Lightning Network: stato attuale e limiti
Secondo Todd, il Lightning Network è attualmente il sistema L2 più avanzato per Bitcoin, ma presenta alcune limitazioni importanti:
- Scalabilità: Lightning richiede almeno un UTXO per ogni utente finale, limitando la scalabilità complessiva.
- Liquidità: i fondi devono essere bloccati in canali per facilitare le transazioni.
- Interattività: i destinatari devono essere online per ricevere pagamenti in modo sicuro.
Nonostante tali ostacoli, il Lightning Network rimane efficace per il routing di pagamenti, e molte proposte di soluzioni L2 intendono integrarsi con il LN.
Proposte di L2 più interessanti
Channel Factories
Con le Channel Factories, invece di aprire un canale tra due soli utenti, più persone si accordano per creare un unico indirizzo multisig su cui depositare i propri fondi.
Dall’indirizzo multisig bloccato sulla timechain, vengono creati canali off-chain tra gli utenti. Ogni utente può aprire un canale con gli altri. Questi canali possono essere chiusi e riaperti senza mai tornare sulla timechain, a patto che le transazioni non superino la quantità di fondi inizialmente depositati sull’indirizzo multisig.
Le Channel Factories permettono quindi a più utenti di condividere un singolo UTXO, riducendo il numero di transazioni on-chain necessarie per aprire e chiudere canali.
Non richiedono aggiornamenti al protocollo Bitcoin per funzionare, ma nella pratica sono complicate da gestire se ci sono troppi partecipanti, rendendo difficile ottenere un vero beneficio di scalabilità. Per migliorare la gestione e permettere a singoli partecipanti di agire senza coinvolgere tutti, sono state proposte soluzioni come OP_Evict o OP_CTV.
LN-Symmetry/Eltoo
Conosciuto anche come Eltoo, LN-Symmetry semplifica i canali Lightning rimuovendo le penalità per la pubblicazione di stati errati, permettendo invece di correggere una versione sbagliata dello stato del canale con una nuova transazione. Tale proposta semplifica la gestione di un nodo Lightning, facilitando la procedura di backup in maniera affidabile e sicura.
Sebbene non migliori direttamente la scalabilità, può facilitare l’implementazione di soluzioni come le Channel Factories.
LN-Symmetry richiede una modifica al protocollo di Bitcoin (soft-fork) per abilitare SIGHASH_ANYPREVOUT, che permette alle transazioni di stato di riutilizzare altre transazioni di stato durante gli aggiornamenti.
Ark
L’architettura del protocollo Ark propone l’uso di UTXO virtuali (V-UTXO) trasferibili e con scadenza, per aumentare la scalabilità di Bitcoin.
Un coordinatore centrale (Ark Service Provider), il quale non può accedere ai fondi degli utenti, gestisce la creazione e la gestione di V-UTXO attraverso round di tempo definiti, solitamente di quattro settimane.
Per ottenere un nuovo V-UTXO gli utenti devono tornare online prima della scadenza del round per evitare che i fondi diventino di proprietà dell’ASP.
Per raggiungere il suo pieno potenziale Ark richiede l’abilitazione dei covenant come CTV.
Covenant: una necessità per i L2?
Un covenant è un meccanismo che limita il modo in cui è possibile spendere un UTXO. Con un covenant, oltre alla firma della transazione, sono necessarie altre condizioni per poter spendere un UTXO.
I vincoli stabiliti dai covenant permettono di abilitare una serie di nuove proprietà per il protocollo Bitcoin.
I sistemi di L2 che permettono a più utenti di condividere un singolo UTXO hanno bisogno dei covenant per limitare come tale UTXO possa essere speso, così da applicare le regole e gli incentivi previsti dal protocollo L2.
Inizialmente Satoshi Nakamoto introdusse 15 opcode in Bitcoin Core, per poi rimuoverli poco dopo a causa di possibili bug futuri o conseguenze indesiderate.
Di seguito l’analisi di alcuni dei principali operatori (opcode) che abilitano alcuni tipi di covenant.
OP_Expire
OP_Expire è un operatore progettato per risolvere il problema degli attacchi di sostituzione degli HTLC (replacement cycling attack).
OP_Expire permette di rendere un UTXO non spendibile dopo un certo lasso di tempo, semplificando così le condizioni di spesa. OP_Expire potrebbe essere utile in diversi contesti come soluzione al problema del replacement cycling, ma non sembra essenziale per il funzionamento di Bitcoin.
SIGHASH_ANYPREVOUT
SIGHASH_ANYPREVOUT è stato originariamente proposto per LN-Symmetry per semplificare la gestione dei canali LN. In pratica permette di evitare la necessità di firmare separatamente ogni stato precedente del canale, che potrebbe dover essere ripristinato o aggiornato. Invece di dover creare e firmare molte transazioni per ogni possibile modifica del canale, SIGHASH_ANYPREVOUT consente di fare tutto in modo più efficiente e con meno complessità.
CTV
OP_CheckTemplateVerify (CTV) è una proposta che permette di limitare come un UTXO potrà essere speso in futuro. Ciò permette di stabilire alcune regole in anticipo su come un UTXO potrà essere speso, ma senza creare limitazioni ricorsive complicate, cioè non può creare regole che si applicano indefinitamente nel tempo a ogni transazione futura. Si tratta di una misura per gestire le transazioni in modo più controllato senza aggiungere eccessiva complessità.
Alcuni vincoli introdotti da CTV possono essere:
- un UTXO che può essere speso soltanto verso alcuni determinati indirizzi;
- un limite di quantità di bitcoin spendibile on-chain;
- un limite di output che una transazione può creare.
Uno dei casi d’uso che CTV consente di attivare in maniera compatibile è quello dei Vault. I Vault 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. In questo modo, i Vault offrono un ulteriore livello di sicurezza, consentendo all’utente di intervenire in caso di spese non autorizzate entro un determinato lasso di tempo.
Grazie alla sua semplicità, attualmente CTV ha il maggior sostegno tra la comunità tecnica rispetto a qualsiasi altra proposta di opcode per covenant.
OP_CAT
L’operatore di concatenazione, chiamato OP_CAT, prende due elementi da una pila di dati e li unisce in uno solo. In pratica, consente di unire due pezzi di dati in un unico pezzo durante l’esecuzione di una transazione Bitcoin.
Nonostante possa sembrare molto semplice, OP_CAT può essere molto potente e versatile.
Proprio per questo motivo, il principale problema risiede nella difficoltà di prevedere tutti i modi e tutte le possibilità di utilizzo che OP_CAT potrebbe rendere possibile.
Un argomento contro OP_CAT è che alcune delle nuove 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).
Secondo Todd, CTV rappresenta al momento il miglior compromesso per pensare a un eventuale soft fork, abilitare i casi d’uso proposti dal protocollo Ark e migliorare il funzionamento del Lightning Network.
