HTLC

I contratti con blocco temporale e hash sono ciò che rende sicuro inoltrare un pagamento Lightning a più salti. Ogni salto blocca il proprio denaro sullo stesso hash SHA-256, e un canale può trasportarne al massimo 483 per direzione alla volta. Per te, è il motivo per cui un pagamento Lightning o si regola del tutto o fallisce del tutto, e non lascia mai denaro bloccato a metà strada.

Come funziona

Due condizioni proteggono il denaro in un HTLC, e prima o poi una sola di esse sarà vera.

Il destinatario inventa un segreto casuale di 32 byte, chiamato preimmagine, ne calcola l'hash con SHA-256 e inserisce il risultato nella fattura. Ogni nodo lungo la rotta offre poi al nodo successivo un output spendibile in due modi: subito da chiunque sappia mostrare la preimmagine, oppure, dopo un'altezza di blocco concordata, dal nodo che lo ha offerto. Poiché tutti i salti condividono un solo hash, nel momento in cui il destinatario incassa il proprio denaro rivelando la preimmagine, ogni salto precedente la apprende e incassa il suo. Nessuno resta mai nella condizione di aver pagato in avanti senza essere stato ripagato, ed è la proprietà su cui è costruita Lightning.

Le altezze di blocco scendono lungo la rotta. Ogni canale annuncia un valore cltv_expiry_delta, e il pagatore somma questi delta in modo che il salto più vicino al destinatario scada per primo e ogni salto a monte abbia un margine di sicurezza. BOLT 11 indica al pagatore di prevedere almeno 18 blocchi per il salto finale quando la fattura non dice altro. Quel ritardo accumulato è il vero costo di un HTLC: se un pagamento si blocca, il denaro non va perso, ma può restare congelato per ore mentre i timeout si sbloccano.

On-chain questi contratti diventano transazioni reali. In un canale anchor, una transazione HTLC-timeout pesa 666 unità di peso e una transazione HTLC-success pesa 706, e una chiusura forzata con più pagamenti in corso significa trasmettere una di queste transazioni per ciascuno di essi. Gli importi troppo piccoli per valere un output non ne ricevono alcuno; vengono invece aggiunti alla commissione di mining, ed è per questo che un pagamento minuscolo può sparire nelle commissioni se un canale si chiude nel momento sbagliato.

Dove lo vedi

Vedi gli HTLC nei secondi tra il tocco su paga e la fattura che diventa verde, e li rivedi nel calcolo delle commissioni di uno swap on-chain.

I servizi che usano Lightning come base, come Strike, spostano denaro così a ogni pagamento, e i nodi di routing Lightning elencano il numero di HTLC in sospeso come metrica operativa, perché un canale pieno di contratti bloccati non può inoltrare nulla. La stessa costruzione funziona fuori da Lightning: uno swap submarine scambia un HTLC on-chain con un pagamento Lightning bloccato sullo stesso identico hash, e un atomic swap tra catene fa lo stesso tra due registri. In ogni caso l'hash è l'arbitro condiviso e il timeout è il rimborso.

Il limite conta più di quanto sembri. Una transazione di commitment deve restare una transazione bitcoin valida, quindi BOLT 2 vieta più di 483 contratti accettati per direzione, un numero che scende a 114 per il più recente formato di commitment senza commissioni. I grandi canali di routing toccano quel tetto nei periodi di traffico intenso, ed è una ragione onesta per cui un pagamento a volte fallisce e riesce trenta secondi dopo.

HTLC vs PTLC

Un HTLC usa un solo hash per tutta la rotta, mentre un PTLC assegna a ogni salto un vincolo diverso derivato da un punto della curva ellittica. Questa unica differenza è un buco nella privacy: due nodi di routing dello stesso operatore, situati in punti diversi della tua rotta, possono vedere due volte lo stesso hash e ricostruire il tuo pagamento. La rete funziona in realtà con gli HTLC. I PTLC sono la sostituzione prevista, e finché non saranno disponibili devi dare per scontato che qualsiasi grande operatore di routing possa correlare i salti che inoltra.