By Bitcoin Списание - преди 6 месеца - Време за четене: 5 минути
Разделяне и превключване на плащания: Подобряване на поверителността и успеха на плащането едновременно
Едно от основните ограничения на протокола Lightning е как се обработва и осъществява маршрутизирането на плащанията. Той е изцяло насочен към източника, което означава, че подателят на плащане е този, който конструира целия маршрут от себе си до получателя, за да улесни плащането. Това представлява проблем, когато става въпрос за променящите се баланси на каналите с течение на времето, тъй като те маршрутизират плащания между множество различни потребители в мрежата, след като подателят се „заключи“ и вземе решение за конкретен маршрут, този маршрут не може да бъде променен до повреда съобщението се връща обратно към подателя, което му позволява да изгради изцяло нов маршрут, обикалящ точката, където първоначалният опит е неуспешен.
Това налага или работа с тромав и досаден потребителски интерфейс, или използване на проверка на плащането, умишлено изработване на плащания, които ще провалите нарочно, само за да видите дали маршрутът, който искате да използвате, ще работи, преди да опитате отново с действителното плащане. Първото е просто лошо потребителско изживяване, а не това, което искате, когато се опитвате да изработите нещо, което да бъде жизнеспособно решение за плащане за хора в мащаб, а второто поставя неоправдана тежест върху мрежата като цяло, тъй като маршрутизиращите възли трябва да се справят с мрежата трафик и ликвидни усложнения на постоянни плащания, направени без намерение да се финализират, само за да се тества жизнеспособността на даден маршрут.
Крайната причина за тези проблеми е невъзможността маршрутът да промени междинното плащане без участието на подателя. Тъй като целият маршрут на плащане е onion криптиран, това наистина не е възможно да се направи. Всеки скок знае само за скока преди него и за скока след него, те нямат информация за крайната дестинация, която да им позволи да изградят алтернативен маршрут от тях до приемника.
Въпреки че това представлява огромна бариера за преминаване от базирано на източника маршрутизиране, то не го предотвратява напълно. Като междинен възел, въпреки че не можете напълно да реконструирате нов маршрут от вас до дестинацията, можете да пренасочите плащането от себе си към следващия хоп, дефиниран в пътя, избран от подателя. Така че, ако Боб получи плащане, което трябва да насочи към Карол, и каналът, през който трябва да го насочи, няма необходимия капацитет да го препрати, той може да изпрати каквото може през този канал и да насочи останалата част сумата на плащането по други пътища, които може да намери от себе си до Карол.
Миналия месец Гийс ван Дам написа a плъгин за доказателство на концепцията за CLN (на разположение тук), който прави точно това, надграждайки многопътни плащания които позволяват едно плащане да се раздели и да поеме по множество маршрути към получателя. Ако и Боб, и Карол изпълняват плъгина, те могат, в подходящите ситуации, да си съобщят, че плащане, препращано по един канал, всъщност е частично пренасочено, така че Карол да не го изпусне веднага, когато види какво прави изпратеното е по-малко от това, което се очаква да препрати. По този начин, ако са налични алтернативни маршрути между Боб и Карол, когато маршрутът, определен от подателя, не е жизнеспособен, те могат просто да пренасочат необходимата сума и плащането може да успее, без да се налага напълно да се провали, да се разпространи обратно към подателя и да бъде пренасочено от тях.
Ако бъде широко възприето като стандартизирано поведение в мрежата, това може да има огромно положително въздействие върху степента на успеваемост на плащанията, драстично подобрявайки UX на потребителите на Lightning, които търсят прост механизъм за плащане, който просто работи. Това е невероятно просто и логично поведение, което може значително да подобри добре известен недостатък. Това обаче не е всичко, което може да направи.
Една от големите причини, поради които Gijs van Dam се заинтересува от справянето с този проблем, всъщност няма нищо общо с простото подобряване на степента на успешни плащания и потребителския интерфейс за потребителите, а всъщност се дължи на недостатък в поверителността. Един от добре известните проблеми с поверителността, към които Lightning е уязвим, е сондиране на канала, това е проблемът, с който Гийс се интересуваше.
Както споменах по-горе, тя се използва от някои портфейли, за да се гарантира, че плащането ще успее, преди действително да се опита истинското плащане, но тази техника може да се използва и за да се установи разпределението на средствата от двете страни на канала. Правено многократно и с внимателно подбрани суми, успехът или неуспехът на всеки опит за проучване може да заключи как средствата се разпределят от всяка страна на канала. Взета още по-далеч и извършвана систематично през многобройни канали на регулярна основа, тази техника може дори да деанонимизира плащанията, като наблюдава ефективно в реално време как се променят балансите по каналите.
Светкавицата постоянно се представя като инструмент за поверителност за използване при транзакции, но в действителност се дават техники като канално сондиране на поверителността в много случаи в най-добрия случай може да бъде слабо, без потребителят да е усъвършенстван в начина, по който взаимодейства с мрежата. Един от интересните странични ефекти от разделянето и превключването на плащанията е, че подкопава сондиращите атаки. Причината, поради която сондиращата атака работи, е, че можете да продължите да търсите с различни суми, докато плащането се провали. Ако се направи правилно, това ви дава много малък диапазон между последния успешен опит за плащане и неуспешния, което е разпределението на баланса на канала.
В свят, в който Lightning възлите могат в движение да пренасочват частични плащания, които биха били другиwise се провалят, така че да успеят, това напълно нарушава присъщото предположение, на което разчита сондирането на баланса на канала. Че опитът ви за плащане ще бъде неуспешен, когато конкретният канал, през който сте решили да пренасочите, няма ликвидността да го препрати. С разделянето на плащанията и превключването това предположение вече не е вярно и колкото повече възли в мрежата поддържат превключване, толкова по-податливо на грешки прави това предположение (с до 62% според симулация, използваща данни от мрежата Lightning от реалния свят от Gijs).
Така че не само, че това предложение е сравнително просто, не само осигурява начин за подобряване на процента на успеваемост на опитите за плащане, но също така помага за справяне с един от най-големите недостатъци на поверителността на Lightning Network. Мисля, че особено след скорошното Уязвимост от мълния, това предложение показва, че въпреки че Lightning не е лишен от проблеми, те не са невъзможни за разрешаване или смекчаване. Дори ще бъде много често решенията на един проблем да помагат при друг проблем.
Рим не е построен за един ден и решения, които всъщност запазват BitcoinОсновните свойства на 's по мащабируем и устойчив начин също няма да бъдат.
Оригинален източник: Bitcoin Списание