I payment channel si basano sull’idea di sostituire una transazione e aggiornarne il suo stato prima della sua conferma su blockchainUn’analisi dei payment channel

Questo articolo è stato postato origiriamente sul blog di Chainside e tradotto in italiano dalla redazione di Next Generation Currency.

Le transazioni off-chain sembrano essere la migliore opzione per risolvere la scalabilità di Bitcoin. Molti stanno testando e implementando infrastrutture di pagamenti off-chain, pochi hanno realmente compreso come funziona.

Il problema

In primis, perché abbiamo bisogno di effettuare transazioni off-chain? Gli utenti che usano Bitcoin desiderano la massima sicurezza nelle transazioni e la blockchain è certamente il miglior sistema disponibile per ottenerla. Il problema è che la blockchain è alquanto costosa e inefficiente, perché ogni partecipante al network deve conservare una copia completa dello storico di tutte le transazioni; ciò significa che l’uso della blockchain dovrebbe essere limitato allo scopo di garantire una partecipazione sostenibile al network.

La limitazione della quantità di dati che possono essere inclusi sulla blockchain provoca, inevitabilmente, competizione tra gli utenti che desiderano includere la transazione nel registro, facendo aumentare i costi di transazione. Perciò, per mantenere la blokchain sicura e sostenibile, è bene usarla il minimo indispensabile e trovare altri sistemi per transare, senza però rinunciare ai benefici che rendono i pagamenti bitcoin unici.

Off-chain payment channel

I payment channel si basano sull’idea della sostituzione di una transazione e dell’aggiornamento del suo stato prima che venga confermata in blockchain.

Quest’idea è più vecchia di quanto si pensi, Satoshi stesso aveva implementato un protocollo simile nella prima release del client di Bitcoin (tuttavia al tempo il suo obiettivo non era quello di migliorare la scalabilità, ma di abilitare l’high-frequency trading tra gruppi di utenti).

Sostituendo le transazioni prima dell’inoltro al network, molti scambi possono avvenire senza utilizzare la lenta e costosa blockchain.

I cosiddetti pagamenti off-chain possono essere suddivisi in tre differenti gruppi:

  1. Payment channels monodirezionali
  2. Payment channel bidirezionali time-based
  3. Payment channel bidirezionali punishment based

Payment Channel Monodirezionali

I payment channel monodirezionali sono stati implementati la prima volta nel 2013, quando Matt Corallo e Mike Hearn ne abilitarono il supporto su Bitcoin, al tempo però ebbero poco successo dati i casi d’uso limitati, anche perché davano solo la possibilità di trasferire valore da A a B non permettendo alla stessa di tornare indietro da B verso A.

La struttura dei payment channel monodirezionali è la seguente:

  • Alice invia 1 BTC a uno smart contract multisig 2-of-2 tra Alice e Bob
  • Per inviare 0.1 BTC a Bob, Alice crea e firma una transazione che assegna 0.9 BTC a sé stessa e una che assegna 0.1 BTC a Bob e la invia a Bob.
  • Per inviare altri 0.2 BTC a Bob, Alice aggiorna lo stato del payment channel creando un’altra transazione che invia 0.7 BTC a sé stessa e 0.3 BTC a Bob.
  • Alice non può registrare sul network, quindi includere nella blockchain, nessuna di queste transazioni finché non avrà la firma di Bob (ricordate che i fondi sono bloccati in un contratto multisig)
  • Bob è sempre incentivato a registrare solo l’ultimo stato del payment channel, poiché esso rappresenta l’outcome per lui migliore.
  • Per proteggere Alice dal rischio di non cooperazione da parte di Bob a controfirmare l’ultimo stato del payment channel (bloccando di fatto i fondi di Alice) viene creata una transazione con time-lock che permette di restituire a Alice tutti i BTC bloccati nel multisig con Bob. Il time-lock è necessario per assicurarsi che Alice possa usare tale transazione se e solo se Bob risulta non raggiungibile.
  • Prima della scadenza del periodo time-lock, Bob registrerà sulla blockchain solo l’ultimo stato del payment channel al fine di evitare che Alice registri la transazione con time-lock.

Tuttavia, la transazione time-locked non è una soluzione ideale, in quanto sarebbe vulnerabile ad attacchi di malleabilità. Per mitigare questo rischio, nel 2015 un upgrade del protocollo Bitcoin ha introdotto il CLTV (check lock-time verify). CLTV permette di includere il time-lock nello script del contratto stesso, invece di creare una transazione ad hoc, evitando il problema della malleabilità.

N.B. Poiché questi payment channel hanno una vita limitata, è insicuro per Bob continuare ad eseguire transazioni dopo la scadenza del time-lock, rendendo necessaria la chiusura del canale prima di tale scadenza.

Time-based payment channels bidirezionali 

A differenza dei payment channel monodirezionali, dove è solamente Alice che può inviare dei soldi a Bob, e non viceversa, i canali bidirezionali consentono un flusso in entrambe le direzioni.

Il modello di sicurezza di questo tipo di canale è differente, in quanto entrambe le parti potrebbero essere incentivate nel registrare un vecchio stato del canale in momenti differenti. A tal fine esistono due possibili approcci: time-based security o punishment-based security.

Un channel time-based riesce a garantire la sicurezza grazie all’uso di transazioni con un time-lock. I time-lock sono strutturati in maniera tale che l’ultimo stato del canale abbia sempre il valore più basso, rendendolo quindi quello che può esse trasmesso in blockchain per primo. Ogni nuova transazione avente un time-lock più basso invalida quindi tutte le precedenti, aggiornando così lo stato del canale.

Per rendere questo sistema veramente trust-less, è necessario permettere alla prima transazione di rimborsare i fondi ad entrambe le parti prima che qualsiasi bitcoin venga spostato dal contratto multisig, per coprirsi dal rischio che una delle parti non collabori e i fondi rimangano bloccati.

Tuttavia, la creazione di una transazione che spende un’altra transazione non confermata espone le parti al rischio di attacchi di malleabilità. Proprio per questo motivo, è possibile utilizzare solamente transazioni SegWit, in quanto esse sono immuni ad attacchi di questo tipo.

Payment Channel 02

Ciò nonostante, questo modello presenta un’evidente problema, in quanto la sicurezza del canale può essere garantita solamente sino alla scadenza del primo time lock, dopo il quale bisogna chiudere il canale (inviando i fondi ad entrambe le parti, per esempio), dando quindi allo stesso una durata predeterminata.

Per superare questo problema è possibile implementare un meccanismo di sicurezza che utilizza un time-lock relativo, invece del time-lock assoluto appena analizzato.



Con l’utilizzo di un time-lock relativo il tempo inizierà a decorrere solamente una volta che la transazione verrà inclusa nel blocco. Per implementare canali senza data di scadenza predefinita è necessario quindi usare una speciale transazione di “kick-off” con le firme di entrambe le parti, il cui unico scopo è quello di attivare “countdown” del time-lock.

La transazione in questione verrà trasmessa su blockchain solamente quando una delle due parti vorrà chiudere il canale unilateralmente (nel caso in cui entrambe le parti fossero d’accordo sulla chiusura del canale, potrebbero semplicemente eseguire una transazione finale, con i loro indirizzi e i relativi saldi).

Nonostante l’utilizzo di una time-lock relativo migliori di gran lunga la durata di un payment channel, rimangono ancora grosse limitazioni: la durata di un canale risulta infatti essere limitata dal numero di volte che il time-lock può essere abbassato. Anche qui, fortunatamente, è possibile utilizzare una strategia per estendere la durata del canale: quando il time-lock della transazione si sta avvicinando allo zero, invece di fare settlement e di inviare denaro ad entrambe le parti, gli utenti possono inviare nuovamente bitcoin al multisig, creando una nuova transazione di kick-off per alzare il time-lock e continuare ad eseguire transazioni. Tale procedura può essere ripetuta tutte le volte necessarie ma a caro prezzo, in quanto la chiusura unilaterale del canale richiederà più transazioni (una per ogni transazione kick-off), con il rischio di pagare fee molto alte.

Questa struttura richiede un monitoraggio della blockchain per controllare continuamente se l’altra parte ha registrato la transazione kick-off. In questa eventualità, bisogna essere pronti a chiudere il canale aggiornato all’ultimo stato, prima che sia possibile includere le altre transazioni precedenti sulla blockchain.

Punishment-based payment channel

Un altro tipo di approccio per la creazione di payment channel senza scadenze temporali basa la propria sicurezza sulla punizione di una controparte malevola piuttosto che sulla durata del canale. L’idea rimane quella di bloccare i fondi in un contratto multisig tra le parti coinvolte, ma implementando un sistema di incentivi per tentativi di frode. La parti in questione creano e firmano delle transazioni verso uno smart contract più complesso, che rende possibile la sostituzione delle transazioni in maniera sicura.

Questo modello è quello usato per le implementazioni del Lightning Network.

Per avviare il canale, Alice e Bob devono entrambi generare un segreto (i.e. un numero random) e scambiarsi l’hash dello stesso. Successivamente, le due parti creano una transazione (funding transaction) per depositare dei fondi in un contratto multisig 2-of-2. Nell’ipotesi in cui entrambi mettano 0.5 BTC, prima di trasmettere la transazione sul network creano entrambi una successiva transazione, chiamata committment transaction. Nella committment transaction Alice invia 0.5 BTC a se stessa e 0.5 BTC ad un contratto dove possono essere spesi da Bob dopo un certo periodo di tempo (ad esempio una settimana dopo l’inclusione della transazione su blockchain) o da Alice, includendo nella transazione il segreto generato precedentemente da Bob.

A questo punto Alice firma la transazione e la invia a Bob, che può firmarla e registrarla su blockchain in qualsiasi momento qualora decida di chiudere il canale (nel caso in cui avesse bisogno di liquidità on-chain o Alice fosse disonesta).

Allo stesso tempo, Bob crea una commitment transaction speculare a quella di Alice (0.5 BTC a sé stesso e 0.5 BTC ad un contratto spendibile da Alice dopo un determinato lasso di tempo o da sé stesso, includendo il segreto di Alice).

Entrambe le parti firmano la commitment transaction e la inviano alla controparte, che la può firmare e trasmettere in qualsiasi momento.

Lo script della commitment transaction di Alice seguirà l’impostazione seguente:

Output 0: 0.5 BTC al seguente contratto

OP_DUP OP_HASH160 <hash160(pubK Alice)> OP_EQUALVERIFY OP_CHECKSIG

Output 1: 0.5 BTC al seguente contratto

OP_IF “+7 days” OP_CHECKSEQUENCEVERIFY OP_DROP <Bob pubkey> OP_CHECKSIG OP_ELSE OP_SHA256 <sha256(Bob secret)> OP_EQUALVERIFY <Alice pubkey> OP_CHECKSIG OP_ENDIF

 

A questo punto la funding transaction può essere eseguita e registrata sulla blockchain. Adesso Alice è certa che nel caso in cui Bob non risulti che i fondi sono bloccati nel canale, lei avrebbe la possibilità di chiudere il canale firmando e trasmettendo su blockchain la transazione contenente il segreto di Bob, recuperando quindi tutti i fondi. Tuttavia, Alice dovrà aspettare il periodo di tempo prestabilito dal time-lock, prima di poter riavere i fondi, ma questo non rappresenta in problema, in quanto durante questo arco temporale Bob non potrà spendere i fondi perché non è a conoscenza del segreto di Alice.

Lo script dell’address multisig in cui Alice e Bob invieranno il loro bitcoin sarà quindi il seguente:

OP_2 <pubK A> <pubK B> OP_2 OP_CHECKMULTISIG

Fino ad ora abbiamo spiegato come impostare il payment channel in maniera sicura e trust-less, ma non abbiamo ancora visto come avviene una transazione off-chain. In maniera simile a ciò che abbiamo già visto con I time-based channels, i pagamenti off-chain avvengono tramite l’aggiornamento delle transazioni precedenti, ma nel caso del punishment security model le vecchie transazioni vengono invalidate tramite il segreto e non tramite il time-lock.

Nel caso in cui Bob volesse pagare 0.1 BTC a Alice, entrambi dovranno prima generare un nuovo segreto e condividere gli hash corrispondenti. Questo segreto sarà poi utilizzato per la creazione di una nuova commitment transaction che invece di inviare 0.5 BTC ad Alice e 0.5 BTC a sé stesso, invierà 0.6 BTC ad Alice e 0.4 BTC a sé stesso (lo stato aggiornato del canale). In questo caso esisterebbero due commitment transaction, entrambe valide. Poiché Bob potrebbe provare a registrare sulla blockcain la vecchia transazione (che gli assicurerebbe un 0.1 BTC in più) è importante invalidarla e permettere una sicura sostituzione della transazione. Per fare ciò, entrambe le parti condivideranno il segreto generato per la prima transazione. In questo modo, nel caso in cui Bob provasse a registrare la prima transazione, Alice avrebbe tutto il tempo (stabilito in precedenza) per spendere i fondi di Bob bloccati nel contratto, fornendo il segreto di Bob.

A questo punto Bob sarà fortemente disincentivato a tentare di registrare la vecchia transazione – che gli accrediterebbe un 0.1 BTC extra – poiché rischierebbe di perdere la totalità dei fondi che ha messo nel canale.

Operazioni necessarie per includere una transazione nel payment channel.

Il processo descritto favorisce il sicuro aggiornamento delle transazioni, permettendo al canale di rimanere aperto fino a che si voglia, senza un aumento delle fee necessarie, ma richiedendo comunque un monitoraggio della blockchain.

Uno sguardo al futuro

I payment channel sono una possibile soluzione off-chain ai problemi di scalabilità delle blockchain, ma da soli non sono sufficienti, in quanto richiedono l’apertura di un canale (e il conseguente blocco dei fondi) per ogni persona con cui si vuole transare. Per superare questo problema, il Lightning Network ha introdotto un’ulteriore tecnica crittografica basata sugli hash, che permette ai canali di comunicare tra di loro creando una rete (questa è una spiegazione molto semplificata, qualora voleste approfondire è possibile scoprire di più riguardo al Lightning Network qui).

Nel frattempo, team di ricercatori stanno esplorando altre soluzioni per migliorare la scalabilità dei pagamenti con Bitcoin: le channels factories per bilanciare i payment channel off-chain, firme Schnorr e script MAST per ridurre il peso (migliorando anche la privacy) delle transazioni on-chain, e molte altre proposte.

Far scalare la Blockchain non è cosi facile e attualmente le risorse per finanziare lo sviluppo dell’infrastruttura sono limitate. Potrebbe volerci molto tempo per rendere Bitcoin competitivo rispetto a soluzioni centralizzate, ma Bitcoin è qui per rimanere nei secoli, quindi vale la pena attendere il tempo necessario per un corretto sviluppo.



Leave a Comment

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *

*