Giocare a scacchi dentro un canale Lightning e lasciare la posta al vincitore, senza affidarsi all’avversario: è il «party trick» scelto per presentare LN-GAP, una proposta di contratti Lightning governati da programmi arbitrari. L’autore, waxwing (Adam Gibson per la newsletter Bitcoin Optech #427), l’ha presentata il 4 ottobre sulla mailing list Bitcoin-Dev. Il paper non prevede modifiche al consenso di Bitcoin, ma il codice è solo un proof of concept e la fiducia, ammette lo stesso autore, si sposta su un comitato.
Cos’è LN-GAP e quale problema vuole risolvere
LN-GAP sta per «Lightning Network governed by arbitrary programs». Il paper breve lo descrive come un meccanismo per contratti bilaterali off-chain che dipendono da calcoli arbitrari. In caso di disputa si chiude su Bitcoin con un numero costante di transazioni, senza bisezione on-chain (cioè senza restringere il disaccordo passo dopo passo sulla blockchain). L’idea generale, precisa il paper, non è nuova: è nuovo il meccanismo.
Il nodo, scrive l’autore, è che Lightning «non può giudicare il silenzio» (nostra traduzione di «cannot adjudicate silence»). Se un giocatore smette di rispondere, l’altro resta costretto a giocare la partita on-chain, e il paper ricorda che una partita a scacchi può durare 50-100 mosse. La premessa tecnica, spiegata nel post sulla mailing list, è che dimostrare un errore costa molto meno che dimostrare la correttezza di un intero programma: per provare che una mossa è illegale basta mostrare un pezzo su una casella.
Il «venue»: un comitato che attesta solo i tempi
Il pezzo che manca a Lightning, nella proposta, è il venue: un comitato che attesta soltanto se un messaggio firmato è stato pubblicato prima di una scadenza. Non conosce il significato della mossa e non custodisce i fondi. Nei test descritti dal paper il comitato ha 5 membri e ne servono 3 per attestare che una mossa non è arrivata in tempo.
La disputa tra Alice e Bob parte dal claim di Alice: «nessuna mossa o mossa sbagliata da Bob». Bob può rispondere con un rebuttal, cioè la sua mossa insieme all’attestazione del venue. Alice può chiudere con una disproof, che indica la regola violata o prova che la mossa è arrivata fuori tempo. Rebuttal e disproof sono opzionali: di norma non servono transazioni on-chain, e al massimo ne servono tre (quattro, a seconda di come si conta).
Per l’assenza di una mossa ogni membro usa una firma «a un bit», verificata con OP_CHECKSIGADD (un’istruzione di Script che conta le firme valide). Per la pubblicazione, il paper introduce EC-OTS, firme una tantum su punti di curva ellittica. Il venue è pagato con commissioni trasferite in modo atomico lungo i canali, ma questo, avverte il paper, richiede PTLC, con implicazioni per la versione di Lightning in uso, e il README del repository indica che il pagamento delle commissioni non è ancora costruito.
I numeri misurati sul proof of concept
La Tabella 1 del paper riporta le dimensioni misurate su un nodo regtest con un venue da 5 membri. Il claim di assenza pesa 188 vbyte (l’unità di misura del peso di una transazione) e l’attestazione not_timely, con 3 flag su 5, 254 vbyte. La disproof per gli scacchi è di circa 4.950 vbyte. La parte pesante è il rebuttal: 24.121 vbyte per gli scacchi e 20.106 per il tris.
| Transazione | Chi la pubblica | Dimensione (vbyte) |
|---|---|---|
| Claim di assenza | chi contesta | 188 |
| not_timely (3 flag su 5) | chi contesta | 254 |
| Disproof, scacchi (una prova) | chi contesta | circa 4.950 |
| Rebuttal, tris | chi risponde | 20.106 |
| Rebuttal, scacchi | chi risponde | 24.121 |
Secondo il paper, grazie ai depositi nel canale a pagare i costi on-chain aggiuntivi è sempre chi si comporta male. Un venue da 50 membri anziché 5 allungherebbe il rebuttal degli scacchi di circa l’1%, una stima del paper, che indica come limite pratico circa 100 membri e come limite teorico 999 per via di OP_CHECKSIGADD. Nel post Gibson parla invece, in termini realistici, di fino a centinaia di membri.
I limiti dichiarati dallo stesso autore
Il repository su GitHub avverte che il codice non è adatto a «nessun uso in produzione con denaro reale» (nostra traduzione) e che nulla tocca mainnet, testnet o signet: le demo girano in regtest. Nel post, Gibson scrive che il codice è per il 95% generato da un’AI, mentre il paper è opera sua.
Il «trustlessly» del post compare tra virgolette. Il paper spiega che una maggioranza dei membri, d’accordo con una delle due controparti, può prendere la posta del contratto in entrambe le direzioni. Con un venue unico d’accordo con Bob, lo stallo di Bob non verrebbe punito. In compenso il comitato non tiene mai i fondi, e per la sola pubblicazione di una mossa basta che un membro su n sia disponibile.
Pesano anche altri vincoli, descritti nel paper e nel post. Il grafo delle dispute va firmato in anticipo per tutte le mosse, quindi reggono solo giochi di lunghezza finita. La disponibilità online conta molto: secondo il post si perde se si resta offline abbastanza a lungo. E lo Script di Bitcoin ha un limite di 1.000 elementi sullo stack, per cui il costo costante non vale in modo ingenuo per qualsiasi programma.
Oltre gli scacchi: storage, aste e verifiche zero-knowledge
Tra le applicazioni elencate nel paper ci sono il blackjack (gioco a informazione nascosta, con una demo nel browser), un’asta a offerte sigillate e i contratti di storage, definiti «Filecoin senza un altcoin»: se un fornitore non dimostra di conservare un file, perde un deposito a favore dell’utente.
Per programmi più grandi l’autore sposta off-chain la bisezione di BitVMX, con il venue come arbitro dei tempi. Come esempio, nel post cita un verificatore Groth16 che si ferma con successo dopo 478.727.216 passi: una disputa richiederebbe 29 round off-chain, su un contratto da 2.058 transazioni pre-firmate una volta sola. Su regtest il claim pesa 220 vbyte, mentre la prova finale, 58,5 kvB, supera i 20-40 kvB dei giochi; il rebuttal da 24,3 kvB è stato rimisurato su un programma più piccolo, perché dipende dai dati pubblicati con la mossa e non dal programma. Lo stack di picco arriva a 948 elementi su 1.000, e sui bridge verso i rollup l’autore dice di aver solo accennato.
Cosa aspettarsi
Per ora LN-GAP è ricerca: le fonti consultate non parlano di implementazioni sulla rete principale. Per BitcoinLive24 resta un esempio concreto di quanto si può spingere la progettazione off-chain di Bitcoin senza toccare il consenso, anche se con compromessi come la maggioranza onesta del venue e la dipendenza dai PTLC. Sul fronte dello sviluppo, il numero #426 segnalava la bozza di BIP raccontata in BIP324: la proposta di Towns per alias a un byte, e su Eclair, sempre in ambito Lightning, c’è l’articolo Eclair, due falle DoS sui nodi Lightning.
Per seguire le novità tecniche di Bitcoin e Lightning, scarica l’app di BitcoinLive24.
Domande frequenti
Cos’è LN-GAP?
LN-GAP (Lightning Network governed by arbitrary programs) è una proposta per eseguire contratti bilaterali complessi, come una partita a scacchi, dentro un canale Lightning. In caso di disputa servono al massimo tre o quattro transazioni on-chain, secondo l’autore.
LN-GAP richiede un soft fork di Bitcoin?
No: il paper descrive il meccanismo come realizzabile senza alcuna modifica al consenso. Il pagamento delle commissioni al venue richiede però PTLC, e il codice resta un proof of concept non adatto a fondi reali.
A cosa serve il venue in LN-GAP?
Il venue è un comitato che attesta solo se un messaggio firmato è stato pubblicato prima di una scadenza. Non custodisce fondi, ma una maggioranza dei suoi membri d’accordo con una controparte potrebbe prendere la posta del contratto.
