Lightning Network je najbolj znan po hitrih in poceni plačilih. Toda protokol Layer 2 bi lahko ponudil tudi več zasebnosti kot plačila v verigi, saj transakcije niso objavljene na verigi Bitcoin, analiza blokov je v glavnem nemogoča.

Vendar pa Lightning Network predstavlja svoja tveganja za zasebnost. Plačila se preusmerijo prek mreže uporabnikov in ničesar ne preprečuje vohunom, da sodelujejo v tem postopku posredovanja transakcij, hkrati pa spremljajo pretok sredstev. V Lightning Network lahko analizo omrežja nadomestimo z blockchain analizo.

Obstaja nekaj rešitev za omejitev teh tveganj, na primer usmerjanje čebule v slogu Tor. Ti pomagajo, vendar lahko slabosti ostanejo, odvisno od topologije omrežja in vrst plačil. Razvijalec Bitcoin in Lightning, ki se imenuje psevdonim ZmnSCPxj, ​​je v zadnjih tednih objavil obsežno analizo vztrajajočih tveganj na Dopisni seznam Lightning-dev (1., 2., 3.).

Na podlagi svoje analize je rešitev ponudil tudi ZmnSCPxj. Podobno kot Payswap – njegov predlog za zasebnost v verigi, ki ga je pred dvema tednoma zajela revija Bitcoin – razvijalec meni, da bi lahko bila “samoplačila” pomemben del uganke o zasebnosti.

Razumevanje Samoplačilo

V prejšnjem članku smo razpravljali o Payswap-u, predlogu ZmnSCPxj za izboljšanje zasebnosti v verigi z navideznim invertiranjem odnosa med plačnikom in prejemnikom plačila. ZmnSCPxj je pravzaprav sprva prišel s to idejo v okviru mreže Lightning. Pravzaprav bi bil verjetno še bolje uporaben v omrežju Lightning: Nekateri kompromisi, vgrajeni v alternativno verigo, ne veljajo za protokol Layer 2.

Skratka, za Lightning različico Payswap je samoplačilo del iste plačilne poti.

Da razložimo, kako to deluje, si oglejmo izjemno poenostavljeno različico Lightning Network. A (uši) ima plačilne kanale z B (ob) in C (arol). Bob ima kanale z Alice in D (ave). Carol ima kanale z Alice in Daveom. In Dave ima kanale z Bobom in Carol.

A – – B

| |

| |

C – – D

Če želi Alice plačati Daveu 3 bitcoine, bi običajno plačilo usmerjala bodisi prek Boba bodisi Carol. Bob ali Carol bi za storitev zaračunala majhno plačilo, za preprostost pa bomo v tem primeru prezrli pristojbine. Vendar bo dejstvo, da se v resnici plačujejo pristojbine, nekaj odstavkov manj pomembno, zato ne pozabite.

Za zdaj bomo rekli, da se Alice za plačilo odloči za Bobovo pot. Bobu pošlje 3 kovanca, Bob pa Daveu posreduje 3 kovance. Plačilo je uspelo.

Toda na žalost bi v tem primeru Bob zlahka pravilno domneval, da je Alice Daveu plačala 3 kovance. Znesek pozna, ker ga je posredoval, če pa bi Alice želela plačati Carol ali Carol Daveu, bi to lahko storila neposredno, ne da bi bila odvisna od Boba kot posrednika. Če je Bob vohun, ki spremlja omrežni promet, njegova pravilna predpostavka škodi zasebnosti Alice in Davea.

ZmnSCPxj zato predlaga alternativo. Alice je lahko plačilo usmerila nazaj do sebe … “samoplačilo”, pri čemer je Dave prevzel zelo velik “honorar”. Taksa bi bila dejansko resnično plačilo.

Da bi Daveu plačala kot prej, bi Alice tokrat denimo napotila 5 kovancev. Najprej je 5 kovancev poslala Bobu, ta pa 5 kovancev Daveu. Potem – to je trik – Dave bi nadaljeval plačilo naprej Carol … vendar je posredoval samo 2 kovanca! Nazadnje bi Carol dva kovanca poslala nazaj k Alice. Na koncu je Alice za 3 kovance revnejša, Dave pa za 3 kovancev bogatejši. Zato je Alice Daveu plačala 3 kovance.

To samoplačilo bi zavedlo Boba in Carol. Bob je posredoval 5 kovancev in lahko logično, a napačno domneva, da je Alice Daveu plačala 5 kovancev. Medtem bi bila Carol verjetno še slabša: mislila bi, da je Dave plačal Alice 2 kovanca. Z vidika Carol je smer plačila obrnjena.

Če bi Bob ali Carol skrivaj vohunila za omrežno dejavnostjo, bi bila zavedena glede velikosti in / ali smeri plačila, kar bi koristilo zasebnosti Alice in Dave. Če so vohuni dovolj pogosto zavedeni, bi lahko takšno vohunjenje sploh postalo neuporabno.

PTLC-ji, standardni zneski in še več

Vse v zgornjem primeru je poenostavljeno, od omrežnega grafa do transakcijskih zneskov, medtem ko so bolj subtilna tveganja glede zasebnosti, kot so zneski provizij in časovne zapore, popolnoma prezrta. Medtem se domneva, da tudi če sta Bob in Carol vohuna, ne sodelujeta ali še huje: sta en vohun, ki se pretvarja, da sta dva uporabnika.

V resnici so tveganja za zasebnost in koristi zasebnosti, ki jih ima usmerjanje, hkrati večje in nižje. Obravnavanje vseh teh tankočutnosti presega obseg tega članka; Prispevki ZmnSCPxj na poštni seznam Lightning-dev so boljši vir za bolj poglobljeno analizo. In na splošno raziskave zasebnosti Lightning še potekajo.

Kljub temu je treba poudariti, da predlogi ZmnSCPxj za izboljšanje zasebnosti Lightning presegajo samoplačila – v nekaterih primerih bi bile dodatne spremembe protokola dejansko bolj ali manj potrebne, da bi bila samoplačila učinkovite izboljšave zasebnosti. Dve najpomembnejši spremembi sta prehod z zgoščenih pogodb o časovni zapori (HTLC) na pogodbe o časovni zapori z javnim ključem (PTLC) in sprejetje standardnih zneskov. Torej, poglejmo si to na kratko.

Trenutno se Lightning plačila preusmerjajo s HTLC-ji. Vsi uporabniki na poti v bistvu posredujejo kodo, ki zagotavlja, da lahko zahtevajo sredstva od ene nasprotne stranke, če druga nasprotna stranka od njih zahteva sredstva (tako se sredstva posredujejo prek omrežja). Na žalost, če so sodelujoči vohuni del iste poti, lahko s pomočjo HTLC-jev ugotovijo, da so različni hmelji dejansko del istega plačila, kar v določeni meri izničuje prednosti usmerjanja čebule. PTLC bi izkoristili kriptografske trike, da bi preprečili, da bi vohuni povezali različne hmelje na isto pot.

ZmnSCPxj tudi predlaga, naj uporabniki Lightning sprejmejo standardne zneske. Čeprav neobvezno, bi denarnice spodbujali k razdelitvi plačil na manjša (vendar med seboj povezana) plačila, pri čemer je vsako manjše plačilo sestavljeno iz standardnih zneskov. Če so standardni zneski na primer kovanci 1, 2 in 5, bi Alice v zgornjem primeru namesto enega plačila 3 izvedla dve plačili z 1 kovancem in 2 kovancema (ali če bi izvedla samoplačilo, bi lahko poslala 5 in pot 2 nazaj k sebi).

Če bi dovolj uporabnikov omejilo svoja (delna) plačila na običajne zneske, se vohuni ne morejo zanesti na zneske, da bi različne hmeljeve povezali z istim plačilom. V okviru samoplačil bi lahko uporabniki celo preusmerili nestandardne zneske od prejemnika plačila nazaj k sebi, zaradi česar so ti videti še bolj kot običajna plačila.

Pomanjkljivosti samoplačila

Verzija predloga ZmnSCPxj, ​​verižna različica, Payswap, ima pomembne kompromise. V primerjavi z običajnim plačilom je potrebnih več transakcij, kar pomeni višje provizije. Poleg tega transakcije zamenjave plačil zahtevajo interakcijo med uporabniki zunaj protokola Bitcoin; redne transakcije bitcoinov ne.

V Lightning Network te pomanjkljivosti ne zdržijo – ali pa se držijo v manjši meri. Plačila za strele v obeh primerih zahtevajo interakcijo, zato samoplačilo ne bi poslabšalo stanja. In čeprav je za samoplačilo potrebno nekaj dodatnih transakcijskih poskokov, se ti preskoki zgodijo zunaj verige, zato ne potrebujejo dodatnega prostora.

Kljub temu imajo samoplačila še vedno nekatere pomanjkljivosti, tudi pri Lightningu. Čeprav so cenejši od provizij na verigi, dodatni hmelj stane nekoliko več pri plačilu poti. Poleg tega, ko se plačilu doda več hmelja, se poveča tveganje neuspešnega plačila in poveča tudi tveganje, da je vohun del poti (če bi bila samo Carol v zgornjem primeru vohunka, bi samoplačilo ji dal več informacij, kot bi jih imela preprosta pot skozi Boba).

Nazadnje pa seveda lahko obstajajo tudi drugi (še nepredvideni) kompromisi; samoplačila so razmeroma nov predlog. Kot je v svojih e-poštnih sporočilih zaključil ZmnSCPxj, ​​je »več analiz o uporabi krožnih plačil pri plačilih morda v redu.«