By Bitcoin Časopis - prije 6 mjeseca - Vrijeme čitanja: 6 minute
Postmortem na Munjevitom zamjenskom biciklističkom napadu
Tako da se diglo mnogo buke oko Ranjivost na munje nedavno otkrio Antoine Riard. Mnogi ljudi tvrde da nebo pada, da je Lightning fundamentalno pokvaren, a ništa nije dalje od istine. Mislim da je dio problema taj što ljudi zapravo ne razumiju kako ova ranjivost funkcionira, kao prvo, a kao drugo, mnogi ljudi ne razumiju kako se ova pojedinačna ranjivost preklapa s drugim poznatim problemima na Lightning Networku koji imaju poznata rješenja.
Dakle, prvo prođimo i pokušajmo razumjeti samu ranjivost. Kada se Lightning plaćanje usmjerava preko mreže, jedna stvar koju je ključno razumjeti je kako funkcioniraju vremenske blokade za povrat neuspjelog plaćanja. Skok koji je najbliži primatelju ima vremensko zaključavanje 'x', a svaki skok koji se vraća pošiljatelju ima jedan od 'x+1', 'x+2' i tako dalje. Vremenske blokade progresivno se produljuju kako idete svakim skokom od primatelja natrag prema pošiljatelju. Razlog za to je taj što ako uplata stigne do primatelja, ali neki problem zaustavi propagiranje predslike sve do pošiljatelja, skok na kojem se zaustavila ima vremena to primijeniti u lancu i tamo staviti predsliku da sve prethodni skokovi trebaju potvrditi plaćanje. ostalowise netko u sredini, gdje se dogodi neuspjeh, mogao bi zatražiti da njegov odlazni hop zatraži sredstva s predslikom, a hop koji im ga je proslijedio potražiti to svojim putem povrata, i ostaviti tu osobu u sredini bez sreće jer je izgubio fondovi.
Zamjenski ciklički napad kompliciran je način da se pokuša i postigne upravo taj neželjeni ishod, ciljni čvor gubi novac tako što odlazni skok traži sredstva uspješnom transakcijom, a dolazni skok traži sredstva putem transakcije povrata. To zahtijeva odgađanje čvora žrtve i sprječavanje da vide predsliku u uspješnoj transakciji s jedne strane dok ne istekne vremensko zaključavanje s druge strane, kako bi tamo mogli zatražiti povrat novca.
To zahtijeva vrlo ciljanu i kompliciranu igru manipuliranja žrtvinim mempoolom. Pogledajmo stvarnu strukturu transakcije koja je ovdje uključena. Imate transakciju obveze, koja je glavna transakcija koja predstavlja stanje Lightning kanala. Ima izlaz za svaku stranu kanala koji predstavlja sredstva u potpunosti pod kontrolom jednog ili drugog člana i izlaze za svaki HTLC u procesu usmjeravanja. Ovi rezultati su oni koji nas zanimaju. Svaki HTLC izlaz može se potrošiti ili odmah u bilo kojem trenutku s predslikom iz prijemnika ili nakon što istekne vremensko zaključavanje povrata novca.
Napad zahtijeva da zlonamjerna strana, ili dvije zavjereničke strane, imaju kanal s obje strane čvora žrtve koji usmjerava plaćanje. Tako Bob, žrtva, ima kanal s Alice i Carol, napadačima, a plaćanje se preusmjerava od Carol do Boba do Alice. Upamtite, vremenski zaključani put povrata između Alice i Boba će isteći i postati valjan prije povrata između Carol i Boba.
Napadači usmjeravaju plaćanje preko Boba, a zatim će Alice odbiti poslati Bobu predsliku za finalizaciju plaćanja kada je primi. Ono što će Bob sada učiniti jest pričekati dok ne istekne vremenski okvir između njega i Alice i otići na emitiranje transakcije preuzimanja kanala i transakcije povrata novca kako bi se to potvrdilo prije isteka vremenskog okvira. Alice će zatim otići potrošiti transakciju predslike kako bi zatražila sredstva s izlazom koji nije povezan s kanalom, a odmah nakon toga udvostručiti drugi ulaz u transakciji uspjeha predslike. Ovdje je cilj izbaciti Bobovu transakciju isteka vremena iz mempoola, ali također izbaciti uspješnu transakciju predslike tako da je Bob ne vidi. Ako to učini, naučit će predsliku i moći će jednostavno zatražiti sredstva na svom kanalu s Carol prije nego što njezina transakcija isteka vremena postane važeća za trošenje.
Alice i Carol to moraju činiti na dosljednoj osnovi, svaki put kada Bob ponovno emitira svoju transakciju vremenskog ograničenja s Alice, sve dok visina bloka ne prođe gdje je Carolina transakcija vremenskog ograničenja važeća. Zatim mogu poslati uspješnu transakciju na Aliceinoj strani, i transakciju isteka vremena na Carolinoj strani, i ostaviti Boba da drži torbu jer je izgubio vrijednost uplate koju je usmjeravao.
Problem s ovim je dvostruk. Prvo, žrtvin Bitcoin Jezgreni čvor mora biti posebno ciljan kako bi se osiguralo da se uspješna transakcija predslike ni u jednom trenutku ne širi u njihov mempool gdje njihov Lightning čvor može dobiti predsliku. Drugo, ako je potvrđena druga transakcija koju Alice koristi za izbacivanje transakcije predslike, Alice snosi trošak (zapamtite, ideja je zamijeniti transakciju isteka vremena s predslikom, tako da je ona izbačena iz mempoola, a zatim zamijeniti transakciju predslike s drugi dvostruki trošenje dodatnog unosa u transakciji predslike). To znači da svaki put kad Bob ponovno emitira svoju transakciju isteka roka, Alice mora platiti višu naknadu da je ponovno izbaci, a kada se to potvrdi, ona zapravo snosi trošak.
Dakle, Bob može natjerati Alice da podnese veliki trošak jednostavnim redovitim reemitiranjem svoje transakcije isteka vremena uz višu naknadu, što znači da ako isplata HTLC izlaza ne vrijedi znatno više od naknada koje bi Alice mogla imati, napad se ekonomski ne isplati izvesti . Također bi bilo moguće potpuno spriječiti napad promjenom načina na koji se konstruiraju HTLC transakcije uspjeha i isteka vremena. Korištenjem oznake SIGHASH_ALL, što znači da se potpis obvezuje na cjelokupnu transakciju i postaje nevažeći ako se promijeni i najmanji detalj (poput dodavanja novog unosa u transakciju predslike koja je potrebna za ovaj napad). Ovo ne bi funkcioniralo s trenutnom verzijom Lightning kanala sidreni izlazi, ali to bi u potpunosti riješilo problem. Peter Todd također je predložio a nova značajka konsenzusa to bi u potpunosti riješilo problem, u biti obrnuto vremensko zaključavanje, gdje bi transakcija postala nevažeća nakon određeno vrijeme ili visinu bloka umjesto da postane valjan nakon. Međutim, po mom mišljenju nije potrebno ići tako daleko.
Jednostavno ponovno emitiranje vaše transakcije redovito uz neznatno povećanje naknade golemo je ublažavanje napada, ali postoje i brojne dinamike zbog kojih to bez obzira na sve to nije ozbiljan problem. Prvo, ako niste čvor za usmjeravanje, to zapravo i nije ozbiljan problem. Tako je većina krajnjih korisnika sigurna od ovog napada. Drugo, postoji mnogo razloga zašto čvorovi ne dopuštaju nijednoj nasumičnoj osobi da im otvori kanale. Veliki čvorovi vrlo su selektivni u pogledu toga s kim se peeriraju, jer nasumični kanali kojima se ne upravlja učinkovito ili profesionalno imaju trošak u obliku izgubljenog ili izgubljenog kapitala u neiskorištenim kanalima. Dakle, bilo koji veliki čvor koji bi bio sočna meta za ovaj napad uopće nije trivijalan za povezivanje s njim, a kamoli povezivanje s njim s višestrukim kanalima za izvođenje napada. Na kraju, kao Pisao sam o tome u prošlosti, drugi mogući nepovezani napadi na mreži već zahtijevaju filtre i ograničenja u načinu na koji čvorovi biraju rukovanje HTLC-ovima koje bi mogli proslijediti. tj. ograničenja veličine uplata koje će proslijediti, koliko će dopustiti u bilo kojem trenutku, itd. Dakle, čak i ako možete otvoriti kanal s čvorom vrijednim napada, kako se mreža bude razvijala, bit će više promišljenih kriterija i filtara za odlučujući hoće li uopće proslijediti plaćanje.
Sve u svemu, ovo je legitiman problem i mogući napad, ali u smislu izravnih ublažavanja i načina na koji će napad dugoročno utjecati na rješenja drugih problema, ovo nije nerješiv problem. To je legitiman problem, a odbacivanje kao čisto FUD nije točna reakcija, ali tvrditi da se nebo ruši i da je Lightning Network kao protokol osuđen na propast daleko je preuveličavanje problema.
Vrijeme će teći dalje, nailazit ćemo na probleme, a mi ćemo te probleme rješavati kako budu dolazili. Kao što smo uvijek bili.
Izvorni izvor: Bitcoin Časopis