By Bitcoin Списание - преди 6 месеца - Време за четене: 6 минути
Постмортем на атаката с велосипед за замяна на мълния
Така че се вдигна много шум около Уязвимост от мълния наскоро разкрито от Антоан Риар. Много хора твърдят, че небето пада, че Светкавицата е фундаментално счупена и нищо не може да бъде по-далеч от истината. Мисля, че част от проблема е, че хората наистина не разбират как работи тази уязвимост, първо, и второ много хора не разбират как тази отделна уязвимост се припокрива с други известни проблеми в Lightning Network, които имат известни решения.
Така че първо, нека преминем и се опитаме да разберем самата уязвимост. Когато Lightning плащане се насочва през мрежата, едно нещо, което е ключово да разберете, е как работят времевите блокировки за възстановяване на неуспешно плащане. Скокът, който е най-близо до получателя, има заключване на времето от „x“, а всеки скок, връщащ се обратно към подателя, има „x+1“, „x+2“ и т.н. Времевите блокировки стават прогресивно по-дълги, докато преминавате всеки скок от получателя обратно към подателя. Причината за това е, че ако плащане достигне до получателя, но някакъв проблем спира предобраза да се разпространи обратно до подателя, хопът, където е спрял, има време да го наложи във веригата и да постави предобраза там, че всички предходните скокове трябва да потвърдят плащането. другиwise някой по средата, където се случва неуспехът, може да накара изходящия му хоп да поиска средствата с предварителното изображение, а хопът, който му го е препратил, да го изиска с техния път за възстановяване, и да остави този човек по средата от късмет, че е загубил финансови средства.
Заместващата циклична атака е сложен начин да се опитате и да постигнете точно този нежелан резултат, целевият възел губи пари, като изходящият хоп изисква средствата с успешна транзакция, а входящият хоп изисква средства чрез транзакцията за възстановяване. Това налага спиране на възела на жертвата и предотвратяване на виждането на предобраза в успешната транзакция от едната страна до изтичането на времето за заключване от другата страна, за да могат да поискат възстановяването там.
Това изисква много целенасочена и сложна игра за манипулиране на мемпула на жертвата. Нека разгледаме действителната структура на транзакцията, включена тук. Имате транзакцията за ангажимент, която е основната транзакция, представяща състоянието на канала Lightning. Той има изход за всяка страна на канала, представляващ средства, напълно контролирани от един или друг член, и изходи за всеки HTLC в процес на маршрутизиране. Тези резултати са тези, които ни интересуват. Всеки HTLC изход може да бъде изразходван незабавно по всяко време с предварителното изображение от приемника или след изтичане на времето за заключване на възстановяването.
Атаката изисква злонамерена страна или две заговорнически страни да имат канал от двете страни на възела на жертвата, насочващ плащане. Така че Боб, жертвата, има канал с Алис и Карол, нападателите, и плащането се насочва от Карол към Боб към Алис. Сега не забравяйте, че пътят за възстановяване на сумата между Алис и Боб ще изтече и ще стане валиден преди възстановяването между Карол и Боб.
Нападателите насочват плащане през Боб и след това Алис ще откаже да изпрати на Боб предобраза, за да финализира плащането, когато го получи. Това, което Боб ще направи сега, е да изчака, докато изтече прозорецът за блокиране на времето между него и Алис, и да премине към излъчване на транзакцията за ангажимент на канала и транзакцията за възстановяване, за да бъде потвърдена, преди да изтече прозорецът за блокиране на времето. Това, което Алиса ще направи, е след това да отиде да изразходва транзакцията с предварително изображение, за да изиска средствата с изход, който не е свързан с канала, и веднага след това да удвои втория вход в транзакцията за успех на предварителното изображение. Целта тук е да изгоните транзакцията за изчакване на Боб от mempool, но също така да изгоните успешната транзакция на предварително изображение, така че Боб да не я види. Ако го направи, той ще научи предобраза и може просто да изиска средствата в своя канал с Карол, преди нейната транзакция за изчакване да е валидна за харчене.
Алис и Карол трябва да правят това на последователна основа, всеки път, когато Боб препредава своята транзакция за изчакване с Алис, докато блоковата височина не премине, когато транзакцията за изчакване на Карол е валидна. След това те могат да изпратят успешната транзакция от страната на Алис и транзакцията за изчакване от страната на Карол и да оставят Боб да държи чантата, тъй като е загубил стойността на плащането, което е насочвал.
Проблемът с това е два пъти. Първо, на жертвата Bitcoin Основният възел трябва да бъде специално насочен, за да се гарантира, че в нито един момент успешната транзакция на предобраза не се разпространява в техния mempool, където техният Lightning възел може да придобие предобраза. Второ, ако втората транзакция, която Алис използва за изгонване на транзакцията предобраз, е потвърдена, Алиса поема разходи (не забравяйте, че идеята е да замените транзакцията за изчакване с предобраза, така че да бъде изхвърлен от mempool, след което да замените транзакцията предобраз с второто двойно изразходване на допълнителния вход в транзакцията с предварително изображение). Това означава, че всеки път, когато Боб излъчи отново своята транзакция за изчакване, Алис трябва да плати по-висока такса, за да я изгони повторно, и когато това се потвърди, тя действително поема разходи.
Така че Боб може да принуди Алис да понесе големи разходи, просто като редовно препредава своята транзакция за изчакване с по-висока такса, което означава, че ако изходът на плащането HTLC не струва значително повече от таксите, които Алис може да понесе, атаката не си струва икономически да бъде извършена . Също така би било възможно да се предотврати напълно атаката, като се промени начина, по който се изграждат HTLC транзакциите за успех и изчакване. Чрез използване на флага SIGHASH_ALL, което означава, че подписът се ангажира с цялата транзакция и става невалиден, ако най-малкият детайл (като добавяне на новия вход в транзакцията на предварително изображение, необходим за тази атака) бъде променен. Това няма да работи с текущата версия на Lightning каналите, използващи анкерни изходи, но това би решило проблема изцяло. Питър Тод също предложи a нова консенсусна функция това би решило изцяло проблема, по същество обратно време за заключване, при което транзакцията ще стане невалидна след определено време или височина на блока, вместо да стане валиден след това. Стигането дотам обаче не е необходимо според мен.
Простото повторно излъчване на вашата транзакция редовно с леко увеличение на таксата е масивно смекчаване на атаката, но има и многобройни динамики, които просто я правят несериозен проблем независимо от това. Първо, ако не сте възел за маршрутизиране, това всъщност не е сериозен проблем. Така че повечето крайни потребители са в безопасност от тази атака. Второ, има много причини, поради които възлите не позволяват на случаен човек да отваря канали към тях. Големите възли са много селективни относно това с кого се свързват, тъй като произволни канали, които не се управляват ефективно или професионално, имат цена под формата на потънал или пропилян капитал в неизползвани канали. Така че всеки голям възел, който би се превърнал в сочна цел за тази атака, не е тривиално дори да се свържете с него на първо място, камо ли да се свържете с него с множество канали, за да издържите атаката на първо място. Накрая, като Писал съм за в миналотодруги несвързани атаки, възможни в мрежата, вече налагат филтри и ограничения в начина, по който възлите избират да обработват HTLC, които биха могли да препращат. Т.е. ограничения за размера на плащанията, които ще препратят, колко ще позволят във всеки един момент и т.н. Така че дори и да можете да отворите канал с възел, който си струва да бъде атакуван, с развитието на мрежата ще има повече обмислени критерии и филтри за вземане на решение дали изобщо да препратите плащане.
Като цяло, това е легитимен проблем и възможна атака, но както по отношение на директните смекчаващи мерки, така и как атаката ще взаимодейства с решенията на други проблеми в дългосрочен план, това не е неразрешим проблем. Това е легитимен проблем и отхвърлянето му като чисто FUD не е точна реакция, но да се твърди, че небето пада и Lightning Network като протокол е обречен, е далеч преувеличено.
Времето ще тече, ще се натъкваме на проблеми и ще ги решаваме, когато се появят. Както винаги сме го правили.
Оригинален източник: Bitcoin Списание