Vai al contenuto
buybitcoinsmart

Glossario / Lightning e layer 2

Onion routing

Noto anche come sphinx.

Che cos'è l'onion routing?
L'onion routing è la crittografia a strati con cui Lightning invia un pagamento attraverso più nodi intermedi, dando a ciascun nodo solo le istruzioni per il proprio inoltro e nient'altro.

Ogni pagamento Lightning viaggia dentro un pacchetto di 1.366 byte di dimensione fissa i cui strati vengono rimossi uno alla volta, così un nodo che inoltra conosce il suo predecessore e il suo successore, nulla di più. Il pacchetto resta della stessa dimensione a ogni salto, nascondendo la lunghezza della rotta e la tua posizione al suo interno. La tua privacy nei confronti degli sconosciuti nel mezzo è solida; quella nei confronti del wallet o dell'exchange a ciascuna estremità non lo è.

Come funziona

L'onion routing cifra la rotta a strati, uno per salto, avvolti in ordine inverso così che rimuovere lo strato più esterno sia l'unica operazione che qualsiasi nodo può compiere.

BOLT 4 chiama Sphinx la costruzione, estesa con un payload per salto. Prima che il pagamento si muova, il tuo wallet conosce la chiave pubblica di ogni nodo sulla rotta e usa ECDH con ciascuno per ricavare un segreto condiviso. Da ogni segreto condiviso escono quattro chiavi: rho genera il flusso di byte che offusca il pacchetto, mu calcola l'HMAC di integrità, um autentica gli errori nel viaggio di ritorno e pad inizializza il riempimento. Quel flusso è ChaCha20 applicato su zeri con un nonce nullo di 96 bit, sicuro qui solo perché nessuna chiave viene mai riutilizzata.

Il pacchetto ha quattro campi e una sola dimensione fissa: un byte di versione, attualmente 0x00, un punto secp256k1 compresso di 33 byte che funge da chiave effimera, 1.300 byte di payload dei salti e un HMAC di 32 byte. Sono 1.366 byte sulla rete, senza bisogno di un prefisso di lunghezza.

L'assemblaggio procede all'indietro. La regione di 1.300 byte parte come byte casuali da un flusso ChaCha20 e, per ogni salto dall'ultimo al primo, viene spostata a destra per fare spazio, spingendo l'estremità più lontana oltre il bordo e scartandola. Per un payload inferiore a 253 byte lo spostamento è pari alla lunghezza di quel payload più 33: un byte di lunghezza e 32 byte di HMAC. Ogni spostamento è seguito da uno XOR con il flusso rho del salto, che rimescola di nuovo gli strati precedenti.

Ciò che un salto legge è un breve elenco di campi tipizzati: il tipo 2 è amt_to_forward in millisatoshi, il tipo 4 è outgoing_cltv_value, il timelock che deve porre sull'HTLC che offre subito dopo, e il tipo 6 è short_channel_id, che indica il canale da usare, sebbene un nodo possa sostituire quel canale con un altro canale verso lo stesso peer. Al posto di quello short channel id il nodo finale riceve il tipo 8, che porta un segreto di pagamento di 32 byte e l'importo totale.

Un altro passaggio tiene i pacchetti consecutivi non collegabili tra loro. Ogni salto modifica la chiave effimera con un fattore di accecamento prima di trasmetterla, così la stessa cipolla appare come byte non correlati su ogni collegamento che attraversa. BOLT 4 è onesto sul limite: l'offuscamento "does not preclude the possibility of packet association by an attacker via traffic analysis."

Perché questo conta quando compri bitcoin

L'onion routing ti protegge dagli sconosciuti nel mezzo di una rotta e da nessuno alle sue due estremità, ed è la cosa più fraintesa sulla privacy di Lightning.

Il primo salto è di solito un servizio con cui hai già un rapporto, e vede molto più di un qualsiasi nodo che inoltra. La nostra recensione di Phoenix cita le FAQ di ACINQ stesse senza ammorbidirle: "The current version of Phoenix offers no advantage regarding privacy over existing, hosted, custodial wallets. We (ACINQ) know the final destination and amount of payments." Phoenix ha qui un punteggio di 4,0 ed è davvero in autocustodia, un nodo reale sullo smartphone protetto da una frase di recupero di 12 parole. Custodia e privacy sono questioni distinte, e Phoenix risponde bene solo a una delle due.

L'estremità ricevente non è migliore. Strike è custodiale finché i fondi restano nell'app e richiede la verifica dell'identità, quindi un prelievo Lightning verso il tuo wallet dice a Strike l'importo, il momento e la fattura pagata, per quanti salti abbia attraversato la cipolla. Wallet of Satoshi ha uno stato di cautela e un punteggio di 2,7 qui, in parte perché la società detiene le chiavi, e ha già ritirato il suo servizio Lightning custodiale dall'Unione europea.

Quindi non leggere l'onion routing come un espediente per aggirare gli obblighi di conformità. Non cambia quale sezione sulla legalità di una guida per paese ti si applica, non nasconde un acquisto all'exchange che te l'ha venduto e non ti dà nulla quando l'operatore del tuo wallet è una delle estremità. Ciò che offre vale comunque la pena di averlo: un nodo di instradamento di cui non hai mai sentito parlare non può costruire un grafo di chi paga chi, non può capire se sei il mittente o un altro salto e non può distinguere una rotta breve da una lunga.

Pagare una fattura di Strike attraverso due nodi di cui non hai mai sentito parlare

Pagare una fattura di Strike su Lightning mostra ciò che ogni nodo di una rotta apprende e non apprende.

Supponi che il tuo wallet scelga un percorso di quattro nodi: il tuo peer, due nodi di instradamento pubblici e poi Strike. Il pacchetto è costruito partendo da Strike all'indietro. Il payload di Strike riceve l'importo finale e il segreto di pagamento. Ogni payload intermedio riceve un amt_to_forward che contiene ancora le commissioni di tutti i nodi a valle, un outgoing_cltv_value abbassato del delta annunciato da quel nodo e lo short_channel_id del collegamento da usare.

Il secondo nodo di instradamento legge esattamente un payload. Apprende che il nodo precedente gli ha consegnato un HTLC e che deve offrirne uno leggermente più piccolo più avanti. Non apprende che Strike è in fondo, non apprende che tu sei all'inizio e non può capire se il percorso è di quattro salti o di otto, perché la regione che trasmette è la stessa di 1.300 byte che ha ricevuto.

Se quel nodo non ha liquidità per l'inoltro, costruisce un pacchetto di ritorno: un HMAC con la sua chiave um, un codice di errore, un riempimento scelto in modo che il messaggio di errore più il riempimento arrivi ad almeno 256 byte, e il risultato combinato in XOR con un flusso da una chiave ammag. Ogni salto lo offusca di nuovo nel viaggio di ritorno. Il tuo wallet rimuove gli strati e poi continua a decifrare finché il ciclo non è stato eseguito 27 volte, la rotta più lunga consentita dal formato di payload TLV, così il nodo che fallisce non può dedurre la propria posizione misurando il tempo di un tentativo ripetuto. I nodi più recenti allegano anche dati di attribuzione: HMAC troncati a 4 byte, 210 di essi per una rotta dimensionata al massimo di 20 salti, e tempi di trattenuta in unità di 100 millisecondi.

Onion routing vs percorso cieco

L'onion routing nasconde la rotta ai nodi che trasportano un pagamento, mentre un percorso cieco nasconde la parte finale della rotta a chi paga.

Il semplice onion routing richiede che il mittente conosca la chiave pubblica reale di ogni nodo, perché i segreti condivisi derivano da ECDH con quelle chiavi. L'accecamento delle rotte inverte questo per l'ultimo tratto: il destinatario costruisce una catena di ID di nodo modificati, trasformando Bob in Bob primo e Carol in Carol primo nell'esempio stesso di BOLT 4, poi consegna al mittente un punto di introduzione più un blob cifrato per salto. Il mittente avvolge in una cipolla i blob che non può leggere. I due si compongono invece di competere: BOLT 4 richiede che ogni messaggio cipolla usi l'accecamento delle rotte, e un messaggio cipolla usa la stessa forma di pacchetto della cipolla di un pagamento.

Onion routing vs HTLC

L'onion routing porta le istruzioni e l'HTLC porta il denaro, e un pagamento Lightning ha bisogno di entrambi perché ciascuno verifica l'altro.

La cipolla dice a un salto dove inoltrare e quanto. L'HTLC è il pagamento condizionale effettivamente offerto sul canale. Poiché la regione dei payload è coperta da un HMAC sull'intero pacchetto che solo il mittente e quel salto possono produrre, un nodo confronta l'HTLC che gli è stato offerto con l'amt_to_forward e l'outgoing_cltv_value scritti per lui e fallisce quando non coincidono, il che smaschera un nodo a monte che ha ridotto l'importo di nascosto. Si separano anche: un messaggio cipolla, di tipo 513, è la stessa costruzione che non porta denaro, e per esso nessun errore torna mai indietro da un salto intermedio.

Da non confondere con

Domande frequenti

L'onion routing di Lightning è la stessa cosa di Tor?

No, anche se entrambi riprendono la stessa idea di cifratura a strati. Lightning avvolge un singolo pagamento in un pacchetto di 1.366 byte di dimensioni fisse, instradato sul proprio grafo di canali, dove la rotta più lunga ammessa dalla specifica è di 20 salti, mentre Tor trasporta traffico internet generico su una rete di volontari separata. Eseguire il tuo nodo Lightning tramite Tor è un ulteriore e indipendente passo per la privacy.

L'onion routing nasconde il mio acquisto all'exchange su cui l'ho effettuato?

No. Un exchange o un fornitore di wallet è un punto terminale e non un salto intermedio, quindi vede l'importo, il momento e la fattura indipendentemente da quanti nodi ha attraversato il pacchetto onion. L'onion routing rende ciechi solo i nodi tra i due estremi di una rotta.

Perché il mio wallet sa quale salto ha fallito se i nodi non possono vedere la rotta?

Perché i fallimenti devono essere attribuibili al mittente e a nessun altro. Il nodo che fallisce cifra un errore con una chiave condivisa solo da lui e dal tuo wallet, ogni salto lo offusca di nuovo al ritorno, e il tuo wallet continua a decifrare finché il ciclo non è stato eseguito 27 volte, la rotta più lunga consentita dal formato del payload, così il nodo che fallisce non può dedurre la propria posizione.

Leggi anche

Fonti

Ultima revisione: 6 settembre 2026.

Termini correlati

Altro in Lightning e layer 2

Leggi questa pagina in inglese