Інтеграція Statechains може підвищити гнучкість Lightning

Інтеграція Statechains може підвищити гнучкість Lightning

Commerceblock BLIP підтримує канали Lightning, побудовані на statechains Біткоїна, підвищуючи гнучкість протоколу другого рівня.

Торік я писав про гаманець Mercury Wallet від Commerceblock, реалізацію як statechains, так і CoinSwaps. Це одночасно новий інструмент мікшування, а також перший гаманець для реалізації нового рішення для масштабування другого рівня. Команда відштовхувалася від початкової пропозиції Рубена Сомсена щодо statechains із деякими змінами, щоб він працював без необхідного прапора хешу підпису ANYPREVOUT/Eltoo, і інтегрувала новий дизайн CoinSwap, що дозволяє користувачам змішувати кілька разів без необхідності здійснювати транзакції в ланцюжку.

Передісторія

Коротко для тих, хто не в курсі: statechain – це офчейн-механізм для вільної передачі між користувачами, хто повністю офчейн. Початковий власник/користувач співпрацює з оператором statechain для створення адреси ECDSA-MPC, в якій закритий ключ поділяється на частини, причому одна половина належить користувачеві, а інша половина – оператору. Потім створюється заблокована за часом, попередньо підписана транзакція на зняття коштів, яка підписується оператором перед переказом коштів на нову адресу.

Жодна зі сторін повністю не контролює закритий ключ, і користувач має попередньо підписану транзакцію, яка дозволяє йому в односторонньому порядку забрати монети після тимчасового блокування. Коли користувач хоче передати statechain, він повідомляє оператора, який потім співпрацює з одержувачем. Отримувач і оператор генерують новий набір спільних ключів, які відносяться до тієї ж адреси, і генерують нову попередньо підписану транзакцію з меншим часом блокування, ніж попередня, а потім оператор видаляє свій старий ключ.

Принцип роботи криптографії полягає в тому, що новий спільний ключ оператора буде працювати тільки із загальним ключем нового користувача, тому якщо він видалить старий, то навіть не зможе співпрацювати зі старим користувачем, щоб витрачати монети. Крім того, оскільки нова транзакція на зняття коштів має менше тимчасове блокування, ця транзакція завжди може бути підтверджена раніше, ніж транзакція попереднього власника. Це обмежує кількість разів, коли statechain може бути переданий, перш ніж його доведеться закрити, але якщо оператор діє чесно, це запобігає крадіжці коштів старими власниками.

Канал Lightning поверх Statechain

В цей час Commerceblock працює над новим BLIP (пропозицією щодо покращення Bitcoin Lightning), щоб реалізувати дизайн того, що було запропоновано в початковій пропозиції statechain Сомсена: створення каналу Lightning поверх statechain.

Один із недоліків statechain сам по собі полягає в тому, що весь UTXO повинен передаватися одразу. Однак якщо транзакція виведення коштів у statechain направляється в канал Lightning, а не на адресу одного користувача, то частини statechain можуть бути передані через початковий розподіл балансу каналу, і цей канал можна буде використовувати звичайним чином для наступних платежів Lightning.

Процес починається з того, що користувач створює statechain. Творець та оператор проходять звичайний процес створення сегментованого ключа та підписання резервної транзакції виведення з тимчасовим блокуванням; потім творець (Еліс) знаходить контрагента (Боба), який прийматиме statechain. Еліс та Боб використовують той самий протокол, який використовується для створення сегментованого ключа, який Еліс створила з оператором statechain, та генерують свій власний спільний ключ. Потім вони передають як свій сукупний відкритий ключ, так і свої індивідуальні частки відкритого ключа оператору statechain. Це дозволяє оператору звернутися до них за індивідуальним підписом та доказом, що вони згодні з поточним балансом для спільного закриття, не чекаючи закінчення часу блокування statechain.

Далі, з дозволу Боба, Еліс та оператор statechain підписують транзакцію, безпосередньо проводячи statechain у мультипідпис каналу Lightning, та обробляють створення транзакції каналу Lightning. На цей час адреса statechain, як і раніше, контролюється тільки Еліс і оператором, але транзакція, яка відкриває канал Lightning, тепер перебуває у володінні Боба з меншим часом блокування, ніж початковий statechain, що гарантує його підтвердження до того, як Еліс зможе в односторонньому порядку закрити statechain для себе. Потім Еліс та Боб завершують роботу над протоколом, виконуючи останнє оновлення statechain, створюючи остаточну транзакцію statechain з подальшим зменшенням тимчасового блокування, використовуючи їхній комбінований ключ із ключем оператора, щоб виконати транзакцію зняття, яка переказує кошти в канал Lightning. Тепер обидва можуть оголосити канал Lightning відкритим, і протокол завершено.

Поліпшення корисності Statechains

Ця пропозиція значно підвищить корисність statechain, послабивши строгу динаміку ліквідності їхньої роботи. Щоразу, коли хтось готовий прийняти statechain, але номінал не відповідає платежу, відправник може просто відкрити між ними канал Lightning і почекати, поки не знадобиться витратити кошти, що залишилися (або отримати те, що було відправлено назад), щоб завершити передачу всього балансу statechain. Така можливість не тільки збільшує корисність statechain, але також збільшує корисність мережі Lightning, якщо вона підтримується належним чином.

Ребалансування каналів необхідне для вузлів мережі, як для вузлів маршрутизації, так і граничних вузлів, які просто відправляють і отримують транзакції. Коли кошти повністю перетікають в один бік каналу, це робить канал непридатним для проходження платежів в одну сторону (якщо всі гроші на вашій стороні, то ви не можете приймати платежі; якщо вони в іншої сторони, то ви не можете надіслати платежі). Це вимагає перетасовування грошей з одного каналу до іншого, що також сприяє розбалансуванню каналів на шляху до перебалансування вашого власного. Зрештою ця динаміка доходить до точки, коли все має бути фактично перебалансовано шляхом обміну коштами між Lightning та базовим рівнем у мережі.

Statechains дозволяють переміщати ліквідність із тією самою свободою, що й усередині ланцюжка, без необхідності створювати слід у ланцюжку чи сплачувати комісію. Припустимо, у вас вичерпано канал, і вся ліквідність зосереджена в іншої сторони не дає вам можливості витрачати – але у вас також є statechain. Цей ланцюжок може бути вільно передано будь-кому, хто його прийме, і поверх нього може навіть існувати канал Lightning, якщо ви не відправляєте всі кошти. Його можна використовувати для ребалансування коштів у звичайному каналі на вашій стороні.

Це забезпечує набагато більшу ефективність з точки зору того, скільки каналів вам потрібно маршрутизувати, щоб перебалансувати ваш канал (пам'ятайте, ви сприяєте зміщенню балансу кожного іншого каналу, через який ви маршрутизуєте), у кращому випадку буквально відправляючи його безпосередньо до того ж вузла, з яким у вас відкрито канал для перебалансування. Якщо ви хочете закрити канал з одним вузлом і відкрити його з іншим, ви навіть можете провести перебалансування, щоб у вас був весь баланс каналу, і перемістити його повністю поза ланцюжком до нового вузла, якщо він побудований поверх statechain.

Майбутнє Statechains та Lightning

Розповідаючи про свої плани, Ніколас Грегорі з Commerceblock зауважив: «Наша мета – встановити стандартизований підхід до об'єднання statechain та технології Lightning, щоб полегшити балансування каналів Lightning поза ланцюжком внаслідок використання каналів станів. Ця специфікація стане основою для досягнення цієї мети».

З самого початку statechains завжди пропонувалося взаємодіяти з Lightning, щоб вирішити питання їхнього використання самих по собі: ви повинні передати всю цінність всього UTXO. Вони також забезпечують ступінь гнучкості Lightning, якою вона не має сама по собі, з точки зору того, як ліквідність управляється та передається мережею.

Тепер, коли Lightning знаходиться на здоровій стадії свого раннього зростання, а конкретна реалізація statechains існує вже понад рік, настав час подумати, як ці дві технології можуть взаємодіяти разом. Lightning як мережа – це система атомарного депонування перекладів між двома сторонами, які пов'язані безпосередньо у графі мережі. Те, як працює кожне з'єднання на цьому графіку, строго кажучи, не повинно мати значення для відправників та одержувачів платежів, поки воно працює.

Statechains і Lightning-канали можуть багато чого запропонувати один одному з погляду переваг, і все, що потрібно зробити – це розробити стандартизацію їхньої взаємодії один з одним.

Це гостьовий пост Шинобі. Висловлені погляди є його власними і не обов’язково збігаються з точкою зору BTC Inc. або Bitcoin Magazine.

Після важкого 2022 року публічні майнінгові компанії хочуть відвоювати позиції Після важкого 2022 року публічні майнінгові компанії хочуть відвоювати позиції Після невдалого року, акції публічних майнінгових компаній укріпилися в січні через сильне ралі біткоїна. Зак Воелл 09 лютого 2023
Стосовно Ordinals Стосовно Ordinals Об'єктивний погляд на технічні проблеми, пов'язані з Ordinals, та їхні наслідки для мережі Біткоїна. Марк Гудвін 08 лютого 2023
Помаранчева пігулка для біткоїнерів Помаранчева пігулка для біткоїнерів У той час як Біткоїн все ще знаходиться на ранній стадії прийняття, схоже, що завзятим біткоїнерам потрібна власна помаранчева пігулка. Остін Герберт 08 лютого 2023