Lightning under panseret: kanaler, HTLC-er, løk

BOLT-er: forpliktelser, tilbakekalling, ruting.

Lightning Network er definert av et sett spesifikasjoner kalt BOLT-er (Basis of Lightning Technology). Her er hva som skjer under panseret.

Å åpne en kanal (BOLT 2 og 3)

To peere lager en funding-transaksjon som betaler til en 2-av-2 multisig-utdata (P2WSH; noen implementasjoner tilbyr også eksperimentelle Taproot-kanaler). Før de kringkaster den, utveksler de signaturer for de første forpliktelsestransaksjonene, så hver kan få pengene sine tilbake hvis den andre forsvinner.

Forpliktelsestransaksjoner

Hver side holder sin egen, signert av den andre siden, som betaler ut nåværende saldo. Hver betaling lager et nytt par. Utdataen som betaler holderen er forsinket av en relativ tidslås (to_self_delay, med CSV).

Tilbakekalling: hvorfor juks mislykkes

Når man går til en ny tilstand, gir hver side fra seg en tilbakekallingshemmelighet for sin gamle forpliktelse. Hvis noen kringkaster en gammel tilstand, har den andre siden et vindu mens forsinkelsen løper til å bruke tilbakekallingsnøkkelen og ta alle kanalens midler. Du må overvåke kjeden, eller bruke et watchtower.

HTLC-er: betalinger over hopp

Mottakeren lager en hemmelig preimage og legger dens SHA-256-hash i fakturaen (BOLT 11). Avsenderens betaling reiser som en kjede av HTLC-er, hver som sier «betal hvis du viser preimagen før blokkhøyde X». Hvert hopp videresender en litt mindre HTLC med tidligere utløp. Forskjellen, cltv_expiry_delta, gir hver node tid til å kreve oppstrøms etter å ha blitt betalt nedstrøms. Når mottakeren avslører preimagen, flyter den tilbake langs ruten og hvert hopp gjøres opp.

Løk-ruting (BOLT 4)

Avsenderen velger hele ruten og pakker instruksjoner inn i lagdelt kryptering (Sphinx). Hvert hopp skreller ett lag og lærer bare forrige og neste hopp. Løk-pakken har fast størrelse på 1 300 byte for hopp-nyttelast, så en node ikke kan vite hvor langt den er fra slutten.

Lukking

En samarbeidende lukking er én transaksjon uten forsinkelser. En tvungen lukking kringkaster siste forpliktelse og venter på tidslåsen, og eventuelle ventende HTLC-er løses on-chain.

Åpne problemer

Likviditetsstyring, gebyrtopper under tvungne lukkinger (adressert med anchor-utdata og package relay), og personverngrenser rundt ruting forblir aktiv forskning.