💬 Интеграция цепочек состояний с каналами Lightning может обеспечить балансировку вне цепочки и повысить гибкость

Интеграция цепочек состояний с каналами Lightning может обеспечить балансировку вне цепочки и повысить гибкость

В прошлом году я писал о кошельке Mercury Wallet от Commerceblock, который является реализацией как цепочек состояний, так и CoinSwaps. Это одновременно представило новый инструмент микширования, а также первый кошелек для реализации нового решения для масштабирования второго уровня. Команда построила исходное предложение цепочки состояний Рубена Сомсена с некоторыми изменениями, чтобы заставить его работать без необходимого флага вздоха ANYPREVOUT/Eltoo, и интегрировала новый дизайн CoinSwap, позволяющий пользователям смешивать несколько раз без необходимости совершать транзакции в цепочке для каждого смешивания. /p>

Задний план

Подводя итог для тех, кто не читал мою предыдущую статью: цепочка состояний — это офчейн-механизм для свободной передачи между кем-либо, кто находится вне сети. Первоначальный владелец/пользователь сотрудничает с оператором цепочки состояний для создания адреса ECDSA-MPC, в котором закрытый ключ разделяется на части, причем одна половина принадлежит пользователю, а другая половина — оператору, затем создается предварительно подписанная транзакция снятия с временной блокировкой и подписали с оператором перед отправкой средств на новый адрес.

Ни одна из сторон полностью не контролирует закрытый ключ, и у пользователя есть предварительно подписанная транзакция, которая позволяет ему в одностороннем порядке забрать монеты обратно после временной блокировки. Когда пользователь хочет передать цепочку состояний, он уведомляет оператора, который затем сотрудничает с получателем. Получатель и оператор создают новый набор общих ключей, соответствующих одному и тому же адресу, и создают новую предварительно подписанную транзакцию с меньшим временем блокировки, чем предыдущая, а затем оператор удаляет свой старый общий ключ.

Способ работы криптографии заключается в том, что новый общий ключ оператора будет работать только с общим ключом нового пользователя, поэтому, если они удалят старый, они даже не смогут сотрудничать со старым пользователем, чтобы потратить монеты. Кроме того, поскольку более новая транзакция на снятие средств имеет меньшую временную блокировку, эта транзакция всегда может быть подтверждена раньше, чем транзакция предыдущего владельца. Это ограничивает количество переносов цепочки состояний до ее закрытия, но если оператор действует честно, это предотвращает кражу средств старыми владельцами.

Канал Lightning поверх цепочки состояний

Сейчас Commerceblock работает над новым BLIP (предложением по улучшению Bitcoin Lightning), чтобы реализовать дизайн того, что было предложено в первоначальном предложении Сомсена по цепочке состояний: создание канала Lightning поверх цепочки состояний.

Один из недостатков цепочки состояний сам по себе заключается в том, что весь UTXO должен передаваться сразу. Однако, если транзакция вывода средств в цепочке состояний направляется в канал Lightning, а не на адрес одного пользователя, то части цепочки состояний могут быть переданы через начальное распределение баланса в канале, и этот канал можно будет использовать обычным образом для последующих платежей Lightning.< /p>

Сначала процесс начинается с того, что пользователь создает цепочку состояний. Создатель и оператор проходят обычный процесс создания сегментированного ключа и подписания резервной транзакции вывода с временной блокировкой, затем создатель (Алиса) находит контрагента (Боба), который будет принимать цепочки состояний. Алиса и Боб используют тот же протокол, который используется для создания сегментированного ключа, который Алиса сделала с оператором цепочки состояний, и генерируют свой собственный общий ключ. Затем оба они передают как совокупный открытый ключ, так и свои индивидуальные доли открытого ключа оператору цепочки состояний. Это позволяет оператору предложить им обоим лично подписать и доказать, что они согласны с текущим балансом для совместных закрытий, не дожидаясь истечения времени блокировки вывода в цепочке состояний.

Отсюда, с разрешения Боба, Алиса и оператор цепочки состояний подписывают транзакцию, напрямую проводя цепочку состояний в мультиподпись канала Lightning, и обрабатывают создание транзакции канала Lightning. На данный момент адрес цепочки состояний по-прежнему контролируется только Алисой и оператором, но транзакция, открывающая канал Lightning, теперь находится во владении Боба с меньшим временем блокировки, чем первоначальный вывод цепочки состояний, что гарантирует его подтверждение до того, как Алиса сможет в одностороннем порядке закрыть цепочку состояний. себе. Затем Алиса и Боб завершают работу над протоколом, выполняя последнее обновление с сущностью цепочки состояний, создавая окончательную транзакцию цепочки состояний с дальнейшим уменьшением временной блокировки, используя их комбинированный ключ с ключом оператора, чтобы выполнить транзакцию снятия, которая тратит средства на канал Lightning. Теперь они оба могут объявлять канал Lightning открытым, и протокол завершен.

Улучшение полезности цепочек состояний

Это предложение значительно повысит полезность цепочки состояний, ослабив строгую динамику ликвидности их работы. Всякий раз, когда кто-то готов принять цепочку состояний, но номинал не соответствует платежу, отправитель может просто открыть между ними канал Lightning и подождать, пока ему не понадобится потратить остальные средства (или получить то, что они отправили). назад), чтобы завершить передачу всего баланса цепочки состояний. Такая возможность не только увеличивает полезность цепочки состояний, но также увеличивает полезность сети Lightning, если она правильно поддерживается.

Перебалансировка каналов необходима для узлов в сети, как узлов маршрутизации, так и пограничных узлов, которые просто отправляют и получают транзакции. Когда средства полностью перетекают в одну сторону канала, это делает канал бесполезным для прохождения платежей в одну сторону (если все деньги на вашей стороне, то вы не можете принимать платежи, если на другой стороне, то вы не могу отправить платеж). Это требует перетасовки денег из одного канала в другой, что также способствует разбалансировке каналов на пути к перебалансировке ваших собственных. В конце концов эта динамика доходит до точки, когда все должно быть фактически перебалансировано путем обмена средствами между Lightning и базовым уровнем в сети.

Связи состояний позволяют перемещать ликвидность с той же свободой, что и при работе в сети, без необходимости создавать отпечаток в сети или платить за это комиссию. Допустим, у вас исчерпан канал, и вся ликвидность на другой стороне оставляет вас, нет платежеспособности, и у вас также есть цепочка состояний. Эта цепочка состояний может быть свободно передана любому, кто ее примет, и она может даже иметь канал Lightning поверх нее, если вы не отправляете все значение, и ее можно использовать для ребалансировки средств в вашем обычном канале на вашей стороне. .

Это позволяет значительно повысить эффективность с точки зрения того, сколько каналов вам нужно перенаправить, чтобы сбалансировать ваш канал (помните, что вы способствуете смещению баланса каждого другого канала, через который вы перенаправляете), в лучшем случае буквально отправив его непосредственно тому же узлу, с которым у вас открыт канал, с которым вы перебалансируете. Если вы хотите закрыть канал с одним узлом и открыть его с другим, вы даже можете перебалансировать вещи, чтобы у вас был весь баланс канала, и переместить его полностью вне цепочки к новому узлу, если он построен поверх цепочка состояний.

Будущее Statechains и Lightning

Обсуждая их планы на будущее, Николас Грегори из Commerceblock сказал: «Наша цель – разработать стандартизированный подход к объединению цепочек состояний и технологии Lightning, чтобы упростить балансировку каналов Lightning вне цепочки за счет использования каналов состояний. Эта спецификация послужит основой для достижения этой цели."

С самого начала всегда предлагалось, чтобы statechains взаимодействовали с Lightning, чтобы решить вопрос их использования сами по себе: что вы должны передать всю ценность всего UTXO. Они также обеспечивают для Lightning определенную степень гибкости, которой у него нет в плане управления ликвидностью и ее передачи по сети.

Теперь, когда Lightning находится на здоровом этапе своего раннего роста, а конкретная реализация цепочек состояний существует уже более года, пришло время подумать о том, как эти две технологии могут взаимодействовать друг с другом. Lightning как сеть — это система атомарного депонирования переводов между двумя сторонами, которые не связаны напрямую в графе сети. То, как работает каждое соединение на этом графике, строго говоря, не должно иметь значения для отправителей и получателей платежей, если оно работает.

Каналы Statechain и Lightning могут многое предложить друг другу с точки зрения преимуществ, и все, что нужно сделать, — это стандартизировать их взаимодействие друг с другом.