Free option problem

Atomic Swap: prendi la firma e scappa

Nel precedente post di questa breve serie implicitamente dedicata all’atomic swap:

abbiamo parlato di Interledger e di come funzioni il protocollo.

Tra le sue caratteristiche principali spicca la pacchettizzazione del valore e cioé la capacità di “scindere” l’asset da trasferire in tante parti, pacchetti appunto, più piccole così da aumentare la sicurezza e la velocità.

E’ proprio in ambito di sicurezza che parti più piccole unite ad un timeout più basso in fase di Prepare, permettono di mitigare il Free option problem.

Cos’è il Free option problem?

E’ un problema congenito degli state channels, canali che “mantengono” lo stato, come appunto sono i canali di pagamento.

E’ una variante del fair exchange problem, un problema notissimo nel campo della crittografia, che può essere così riassunto:

Alice e Bob vogliono scambiarsi le firme. Se Bob invia per primo la sua, Alice potrebbe anche semplicemente non inviare la propria e proseguire avendo già tutto quello di cui ha bisogno -ndr la firma di Bob-. Se Alice inviasse per prima la sua firma, la situazione sarebbe identica ma a parti invertite.

Più o meno la stessa cosa potrebbe accadere con gli state channels.

Vediamone brevemente il funzionamento per capire come il free option problem si presenta:

Alice e Bob si mettono d’accordo sull’entità di un certo pagamento o di qualsivoglia altra forma di scambio. A questo “stato”, accordo, assegnano un valore incrimentale o id univoco, e lo firmano. A questo punto sia Alice che Bob possono provare l’uno all’altro vicendevolmente che entrambi hanno stretto questo accordo e che questo è lo stato più recente. Se ad uno dei due dovesse venire la voglia di dichiarare il falso indicando come stato attuale non il precedente accordo ma uno più vecchio, l’altro potrebbe smentirlo mostrando l’accordo firmato con l’id più alto.

Molte implementazioni di state channel includono il concetto di periodo di challenge. Questo è un periodo di tempo, timeout, dopo il quale non è più possibile smentire un aggiornamento precedente presentandone uno più nuovo. Consideriamolo alla stregua del cutoff delle 17e30 delle nostre banche in Italia.

L’uso del challenge period ha trovato largo impiego nei canali di pagamento, permettendo a Bob e Alice di avere un conteggio aggiornato di quanto a vicenda si devono, aggiornandolo di volta in volta con un overhead estremamente basso.

Questo conteggio è supportato dal denaro depositato da uno o da entrambi su una blockchain o affidato a una terza parte fidata. Quando uno dei due vuole “prelevare” i soldi, presenta lo stato più recente. Al termine del challenge period, l’operazione diviene effettiva e non può essere annullata.

Come si presenta il Free option problem negli state channels?

Il problema prende il suo nome dal fatto che sia stato scoperto per la prima volta nell’uso degli state channels per il trading di asset.

Supponiamo che un canale di stato venga utilizzato da Alice e Bob per il trading di petrolio e di grano.

Il channel state registra il saldo di petrolio e grano di Alice, e l’equivalente di grano e petrolio di Bob.

Questo conteggio è supportato dalle quantità di entrambe gli asset a disposizione mantenuti in un magazzino con deposito a garanzia.

Quando Alice vuole scambiare con Bob del petrolio con del grano, crea un nuovo state channel con il suo saldo di petrolio diminuito e il suo saldo di grano aumentato, facendo il conteggio opposto con i saldi di Bob. Aumenta il numero di sequenza, lo firma e lo invia a Bob.

Se Bob si rifiuta di restituire la sua firma, ora ha una free option.

Se lo desidera, può presentare lo stato che Alice gli ha appena inviato e ricevere più petrolio, o presentare lo stato precedente e ricevere più grano.

Potrebbe scegliere diversamente in base a come si muove il mercato.

Alice gli ha appena fornito una free option.

I problemi per Alice però non sono finiti qui.

Alcune implementazioni degli state channel hanno un meccanismo di garanzia contro le frodi che “costringono” chi tenta di chiudere il canale a inviare un deposito cauzionale insieme al suo stato di chiusura.

Se dovesse essere presentato uno stato successivo rispetto a quello dichiarato in chiusura del canale, il deposito cauzionale viene ritirato come risarcimento per tentata frode.

Questo ha lo scopo di dissuadere le persone dal sottomettere in modo disonesto vecchi stati.

Tornando al nostro esempio se Alice vuole chiudere il canale, deve inviare lo stato più recente che ha. Tuttavia, Bob ha uno stato successivo con un numero di sequenza più alto e cioé più recente.

Se Alice invia il suo ultimo stato, Bob può inviare il suo stato successivo e prendere anche il deposito di lei.

Diciamo subito che il free option problem non può essere risolto ma solo mitigato usando una, o una combinazione, delle seguenti “tecniche” che si basano comunque tutte sul principio che non deve esistere nella catena degli state channels un solo punto in cui una delle due parti ha tutte le informazioni necessarie e valide mentre l’altra no.

Trasferimenti incrementali

E’ una delle tecniche utilizzate da Interledger che consiste appunto nel suddividere un tasferimento in tanti pacchetti più piccoli. Diciamo che limita il danno ma non protegge da eventuali “multe per comportamento scorretto” (vedi i depositi cauzionali di cui si parlava prima).

Timeout incrementale

Spieghiamolo con un esempio:

Alice invia a Bob un aggiornamento di stato trasferendo l’intero importo con un timeout brevissimo.

Quando Bob le ha inviato la sua firma su questo aggiornamento di stato, Alice invia un aggiornamento di stato con un timeout più lungo.

In questo modo, Alice e Bob si concedono reciprocamente delle free options che non sono comunque valide per molto tempo.

Questo è particolarmente adatto per gli scambi, in cui il valore di una free options è determinato da quanto si muove il mercato.

È anche una soluzione parziale al problema delle multe per tentata frode discusse sopra: se Alice vuole chiudere il canale, ma Bob ha un aggiornamento successivo, può solo aspettare che l’aggiornamento di stato di Bob non sia più valido.

Probabilità incrementale

Anche qui ci affidiamo a un esempio:

Alice e Bob hanno ciascuno un certo numero di coppie di chiavi separate con cui firmano gli aggiornamenti di stato (facciamo siano 50).

Alice invia a Bob un aggiornamento firmato dalla prima coppia di chiavi. Quando Bob ha risposto con la firma della prima delle sue coppie, Alice invia una firma dalla sua prossima coppia di chiavi.

Questo continua fino a quando l’aggiornamento ha 50 firme sia per Alice e Bob.

Quando uno di loro vuole chiudere il canale, la blockchain o il deposito a garanzia sceglie un numero casuale. Questo è usato per stabilire il numero di firme richieste per considerare valido l’aggiornamento di stato.

Ad esempio, se la blockchain o il deposito scegliesse 0,34 come numero casuale, sarebbero richieste 17 firme da parte Alice e di Bob.

Naturalmente, se il processo è stato eseguito correttamente, la probabilità di validità è sempre al 100%.

Se uno tra i due interrompe il processo in anticipo, avrà solo una possibilità maggiore del 2% di avere un aggiornamento di stato valido.

Questo naturalmente non è il massimo se una parte ha una posta in gioco maggiore o una tolleranza al rischio molto più bassa rispetto all'altra.

Credits: 
- Jehan Tremback -The free option problem