By Bitcoin Списание - преди 6 месеца - Време за четене: 6 минути
Дървета за изчакване: Решение за мащабиране на LSP на Lightning Network
Едно от най-големите присъщи ограничения на Lightning Network е ограниченият брой канали, които могат да бъдат отворени или затворени на блок, предвид ограничението за размера на блока. Независимо от това колко транзакции могат да се извършат извън веригата колко евтино, това е фундаментално тясно място, ограничаващо колко хора реалистично биха могли да използват Lightning Network. Дори бялата книга на Lightning Network премина в заключението, че в сценарий, при който цялото население на света от 7 милиарда използва Lightning, само с две транзакции във веригата годишно на човек, Bitcoin ще изисква 133 MB блокове, за да работи Lightning. Това не е някакъв проблем извън лявото поле или непредвидим проблем, това беше ограничение на дизайна на протокола, напълно разбран от първия ден.
Част от плана за справяне с този проблем винаги е била идеята за канални фабрики, т.е. тип канал, в който участват повече от двама потребители. Това винаги е била посоката, в която нещата трябва да вървят, за да мащабират Lightning и Bitcoin без увеличаване на размера на блока, но проблемът е, че решаването на проблема с отпечатъците във веригата въвежда цял набор от други проблеми. На първо място, нищо фундаментално не се променя относно изискването за налагане на междинни състояния, ако контрагент не реагира. Това има отражение върху добавената стойност. Целият смисъл на фабриката за канали е, че например двадесет души могат да споделят един UTXO и да пренаредят ликвидността вътре с останалите двадесет души, както искат. След като някой затвори веригата без сътрудничество, това започва да пречи на тази цел.
Ако затворя канала си във фабрика за канали, извличам куп хора с мен от фабриката. Помислете за фабрика като мерклево дърво, има един UTXO на върха, който се разделя наполовина извън веригата, а тези се разделят наполовина и т.н., докато стигнем до отделните канали на всеки. След като извадя канала си от фабриката, всички от моята страна на всеки сплит, който преминава във веригата, вече са отрязани от всички останали във фабриката. Те вече не могат да реорганизират своята ликвидност в тази част от групата, ако всички си сътрудничат.
Друг голям проблем е, че дори за да започнете, трябва всички да са онлайн в началото, за да подпишат предварително всички транзакции. Ако искате двадесет души във фабрика, всеки трябва да е онлайн, за да я стартира. Ако искате хиляда души, хиляда души трябва да са онлайн и т.н.
Това прави фабриките за канали голямо дизайнерско пространство, пълно с много проблеми за решаване. Така че решаваме съществуващ проблем за Lightning, но създаваме куп нови. Звучи ми като инженерство.
Дървета за изчакване
Скорошното предложение на Джон Лоу, Дървета за изчакване, се опитва да предложи решение на основния проблем с каналните фабрики. Не бих нарекъл дървото за изчакване канална фабрика, по-скоро „протофабрика“, но предлага потенциално решение на проблема с отварянето и затварянето на огромни количества канали, без да въвежда проблема с некооперативните затваряния, съсипващи използване на фабриката за други потребители. Изисква CHECKTEMPLATEVERIFY (CTV) и доставчик на услуги за осветление (LSP), за да работи функционално.
Timeout Tree е по същество канална фабрика, гарантирана от споразумения, без възможност за промяна на начина, по който ликвидността се реорганизира извън веригата, след като е направена, със специална клауза за освобождаване. LSP, ще ги наречем Bob, играе ролята на свързване на случайни потребители към по-широката Lightning Network. Боб може да вземе монети, които контролира, и да създаде CTV дърво, което създава единичен UTXO разгръщане, за да отвори канали за произволен брой потребители на неговата LSP услуга. Хубавото на CTV е, че позволява това да се направи, без всички да са онлайн едновременно. Боб може просто да накара всеки да подпише първоначалното си състояние на канала един по един и да ги задържи, докато всички настроят канала, и просто да изразходва средствата в CTV дървото, когато има канали, настроени с всеки потребител.
Това решава проблема с това, че всички трябва да са онлайн едновременно, за да настроят „фабриката“ и да започнат да използват Lightning. Поради CTV, след като Боб похарчи монети в дървото, настройвайки Lightning каналите на всички, няма начин той да се оттегли и да вземе монетите (все още). С този първи UTXO в CTV, потвърден във веригата, всеки може да третира своите канали като отворени и няма риск те да бъдат двойно похарчени.
Сега последната част, затваряне на каналите. Въпреки че отварянето им изисква само един UTXO във веригата поради CTV, затварянето им все пак ще изисква цялото CTV дърво да се разгъне във веригата, така че всеки да може да изпрати своите състояния на канала, нали? погрешно Това е частта Timeout на Timeout Trees. Всеки клон в дървото на времето за изчакване има клон на скрипт, където Боб може да изчисти всички средства след заключване на времето.
Диаграма на дърво за изчакване.Сега съм сигурен, че си мислите "какво!?" Това е истинският гений на това как работи това предложение. Тъй като Боб може сам да изчисти UTXO във веригата без никой друг след заключването на времето, всички тези канали имат дата на изтичане, освен ако потребителите действително не разгънат цялото дърво и потвърдят реалното финансиране на канала във веригата. Това позволява на Боб да направи нещо спретнато: когато този timelock наближава, той може да отвори чисто ново дърво за изчакване с всички потребители на текущото и да ги накара да преместят всичките си средства от изтичащото дърво в новото, изцяло изключено -верига на Lightning и след това почистете единичния UTXO във веригата на последното дърво.
Това позволява ефективно затваряне на всички тези канали във веригата. Единственият останал проблем сега е налагането на HTLC във веригата, ако другата страна спре да сътрудничи. Е… това всъщност не е проблем в този случай, или по-скоро е въпрос на всичко или нищо. Причината, поради която каналите трябва да бъдат затворени, за да се наложи HTLC, е ако другата страна на канала спре да отговаря по време на маршрутизирането му. В дървото на времето за изчакване всеки отделен потребител е Боб. Така че, ако Боб, стига да е честен, не отговаря за актуализиране на неуспешен или успешен HTLC за един потребител, той не отговаря и за друг потребител. В този случай всеки все още може да затвори своите канали във веригата преди изтичането на времето за изчакване и да спре да използва LSP на Bob.
Завършвайки
Потребителите все още ще трябва да плащат такси за взаимодействия във веригата, няма начин да се заобиколи това и цялостно дърво на изчакване, затварящо във веригата без сътрудничество, би било голям и скъп отпечатък във веригата, но това в крайна сметка е проблем всяка многопартийна канална система ще трябва да се справи. Timeout Trees обаче има завладяващи решения за съвместния случай както на отваряне, така и на затваряне на масивен многопартиен канал, без да се влошава моделът на доверие на системата до нещо попечителско.
Джон дори в най-новата си версия на статията предложи схема, при която потребителите биха могли да бъдат санкционирани за некооперативни затваряния, достатъчно да покрият разходите на Боб за евентуално премахване на куп фрагментирани дървета UTXO след изтичането на времето. Потенциално има начини да се направи обратното, ако бездействието или нечестността на Боб е причината потребителите да трябва да затворят своята част от дървото без сътрудничество.
В крайна сметка обаче това е много конкретно и специфично предложение за дизайн на фабрика за канали, което всъщност се опитва да се справи с реалните проблеми на употребата и внедряването, вместо с полудефинирана и неясна концепция. Това е огромен напредък по отношение на справянето с дългосрочните ограничения на мащабирането на Lightning.
Оригинален източник: Bitcoin Списание