Автор: RGB++ Fans; Источник: ByteDance CKB
В предыдущих информационных статьях мы кратко рассмотрели основные концепции, связанные с платежным каналом, маршрутизацией через несколько узлов, HTLC и другими аспектами Сеть Lighting.
Мы упоминали, что для осуществления транзакций в сети Lighting часто требуется построение маршрута через несколько посредников, причем доступный остаток на этих посредниках обычно ограничен, что в конечном итоге может повлиять на успешность платежей. Для обеспечения достаточного финансирования узлов в маршруте и улучшения пользовательского опыта необходимо регулировать с помощью некоторых схем управления ликвидностью. Однако для более глубокого понимания проблем управления ликвидностью необходимо сначала ввести несколько основных концепций, таких как локальный и удаленный баланс (Local and Remote Balance), входящая и исходящая вместимость (Inbound and Outbound Capacity) и т. д.
![]()
Как мы уже упоминали ранее, основными единицами Сети Lighting являются Узел и каналы, которые представляют собой передаточные средства вне блокчейна 1-to-1, построенные в сети BTC. Во время инициализации канала обе стороны переведут некоторое количество денег в виде начального баланса, баланса на вашей стороне, называемого «локальным балансом», и баланса на стороне вашего контрагента, называемого «удаленным балансом». **Локальный баланс определяет, сколько денег вы можете перечислить контрагенту, ограничивая вашу платежеспособность, т.е. «исходящую емкость», а удаленный баланс определяет, сколько денег контрагент может вам перевести, ограничивая вашу «входящую емкость», т.е. возможность взыскать.
Хотя остатки обеих сторон в процессе закрытия канала могут часто меняться, общая ёмкость канала не может измениться, если вы не перезагрузите весь канал или не внесете средства через ‘соединение каналов’.
![]()
（Этот рисунок показывает ваши и Роберта балансы, ваш локальный баланс - 5, удаленный баланс - 3, общая емкость канала - 8）
После понимания нескольких основных концепций, рассмотрим, какие проблемы решает управление Ликвидностью в сети Lighting. На упрощенной диаграмме подключения Узлов, показанной на рисунке ниже, мы можем видеть, что вы (в левом нижнем углу) подключены только к одному Узлу LNTop, и поскольку ваш удаленный баланс составляет 3, вы можете принимать платежи на сумму не более 3 долларов. А если Софи захочет перевести вам 1 доллар, транзакция потерпит неудачу из-за недостатка свободных средств у промежуточного Узла для LNTop (область красного цвета, выходной лимит данного узла для LNTop составляет 0).
![]()
Можно сказать, что одной из серьезных проблем, с которыми столкнулась Сеть Lighting в ранних стадиях, является емкость канала. Если Ликвидность более равномерно распределена по всей сети, такие проблемы могут быть эффективно смягчены, и решение этой проблемы часто называется «управлением ликвидностью», таким как подключение клиентских приложений к нескольким узлам с достаточной ликвидностью через рынок аренды (Lighting Pool), открытие/закрытие новых каналов по мере необходимости, или использование методов объединения каналов и перебалансировки (Channel Rebalancing) для регулировки баланса в блокчейне или вне блокчейна.
Сейчас некоторые кошельки также предоставляют функцию автоматического управления каналами, которая умно управляет каналами на основе поведения пользователя при оплате и состояния сети, чтобы обеспечить достаточную Ликвидность для перевода денег. Новые пользователи также могут использовать режим «одностороннего финансирования», когда они только что подключились к сети Lighting, то есть позволяют только другой стороне финансировать канал, а не финансируют его при инициализации канала. Это позволяет снизить экономические затраты пользователей, но при этом у них нет возможности выплаты наружу и ограниченная емкость счета при инициализации канала.
Далее мы более детально рассмотрим распространенные методы управления Ликвидностью в Сети Lighting. Во-первых, давайте рассмотрим схему аренды каналов, которая основным образом решает проблему «емкости зачисления» Узла, то есть когда другие люди хотят перевести вам деньги, вы должны гарантировать, что они смогут успешно установить платежный маршрут, для чего требуется установить требования для каждого Узла в пути, например, необходимо иметь достаточный переводимый остаток / емкость списания. Корень проблемы с провалом маршрута, о котором мы говорили ранее, заключается в недостаточной Ликвидности в каналах, установленных некоторыми промежуточными Узлами и другими Узлами.
Создание канала сопряжено с издержками, поскольку участникам часто приходится блокировать часть средств, что влечет за собой альтернативные издержки. Так называемый канальный лизинг, первая идея заключается в том, чтобы позволить операторам Узла напрямую торговать через рыночные средства, а свободные средства Узла взять на себя инициативу по строительству каналов для других Узлов через систему «лизинга». **Например, если вы мерчант, которому нужно в любой момент получить деньги от других людей, у вас высокий спрос на лимит, и ваша «способность к сбору» в день должна превышать 200 BTC.
Таким образом, вы достиглиПротокол с 4 крупнымиУзел через Lighting Pool, и каждый из этихУзел установил с вами канал на 24 часа, заблокировав 50 BTC и предоставив вам отдаленный баланс в 50 BTC, таким образом, ваша способность принимать платежи в каждом канале составляет 50 BTC. Если кто-то передает вам деньги, вы можете использовать любой из этих 4Узел в качествепосредник для построения платежного маршрута.
![]()
（На 1ml.com мы видим несколько известных операторов Lighting Узел, у которых есть избыток средств и установлено несколько каналов с другими Узел, что позволяет получать доход от аренды Ликвидность）
Кроме арендных пулов, есть также Реклама Ликвидности (Liquidity Advertisement), поставщик ликвидности может объявить о своей цене и продолжительности канала с помощью госсип-сообщений Узла молнии, и другой Узел может открыть канал с ним. Такие схемы на основе аренды объединяют систему Маржи, чтобы предотвратить внезапное нарушение одной стороной.
В настоящее время разработчики Сети Lighting, такие как Lighting Labs, и Fiber, пытаются оптимизировать сценарии аренды Ликвидности для односторонних вложений, например, Fiber планирует внедрить Ликвидность代платы на основе функций смарт-контрактов CKB, где будет указанный Узел LSP-сервис-провайдера создавать каналы с пользователями и предоставлять бесплатные входящие мощности пользователям на определенный период времени для удовлетворения их потребностей в приеме платежей. После того как пользователь получит определенную сумму денег, контракт автоматически извлечет из нее затраты, и также обсуждается механизм Ликвидности стейкинга, связанный с такими сценариями.
В целом, аренда каналов обычно используется для решения проблемы установления связи между Узлами, получения Ликвидности для зачисления средств, а нижеприведенная схема сборки каналов (Splicing) будет производить внесение/выведение средств через операции в блокчейне, непосредственно изменяя общий остаток для обеих сторон в канале. В нормальных условиях для открытия и закрытия канала используется двухфакторная аутентификация 2/2, с участием двух сторон для повторного распределения общих активов в блокчейне, а в ранних версиях Сети Lighting после открытия канала общий остаток не может быть изменен, если канал не закрывается и не открывается заново.
И объединение каналов представляет собой новую концепцию, которая позволяет не закрывать существующие каналы, а прямо в блокчейне перестраивать и обновлять общие UTXO, контролируемые обеими сторонами канала. Например, добавлять новые активы на основе существующих активов и общего контроля участников, что изменяет общий баланс в канале. На рисунке приведено простое описание этой идеи, где слева представлены существующие активы в старом канале (UTXO1), контролируемые Alice и Bob с использованием мультиподписи, затем обе стороны запускают объединение каналов, добавляя другой актив (UTXO2) для совместного управления, в результате чего увеличивается сумма активов (UTXO3), доступная обеим сторонам канала, и увеличивается емкость.
![]()
Соединение каналов также может использоваться для сокращения избыточных средств в канале, перевода временно неиспользуемых активов из канала для повышения эффективности использования средств. В сравнении с традиционным закрытием/перезапуском канала, требующим двух операций в блокчейне, соединение каналов требует только одной операции в блокчейне, что значительно снижает стоимость. Несмотря на явные преимущества соединения каналов, из-за исторических причин этот подход еще не полностью реализован, и его широкое использование потребует времени.
После понимания слияния каналов, мы продолжаем представлять идею **балансировки каналов (Channel Rebalancing), что также является средством регулирования баланса вне блокчейна между различными каналами, не закрывая каналы и не изменяя общей емкости каналов (игнорируя комиссию). **Предположим, что вы запустили клиент Сеть Lighting и установили три платежных канала с другими Узлами:
- Канал 1: Соединение с Узлом X, общая емкость - 1 BTC
- Канал 2: Установлено соединение с Узлом Y, общая емкость - 0,5 BTC
- Канал 3: установлен с Узлом Z, общая емкость составляет 0.5 BTC
Распределение средств каждого канала следующее:
- Канал 1: ваш локальный баланс: 0.9 BTC удаленный баланс: 0.1 BTC
- Канал 2: ваш локальный баланс: 0.1 BTC удаленный баланс: 0.4 BTC
- Канал 3: Ваш баланс на месте: 0,1 BTC Удаленный баланс: 0,4 BTC
![]()
Сейчас проблема заключается в том, что у вас недостаточно средств на канале 2 и канале 3, чтобы перевести более 0.1 BTC вашему оппоненту. Это не удовлетворяет требованиям крупных переводов. В то же время, на канале 1 имеется избыток средств в размере 0.9 BTC, но вам в ближайшее время они не понадобятся. Очевидно, лучшим решением будет переместить избыток средств с канала 1 на два других канала. Поэтому вы планируете перевести 0.4 BTC из локального баланса канала 1 на канал 2, и перевести 0.4 BTC на канал 3. Чтобы достичь этой цели, вам нужно выполнить две циклические платежи (circular payment).
![]()
Как показано на рисунке, вы можете непосредственно перевести 0,8 BTC на Узел X, который затем переводит по 0,4 BTC на Y и Z соответственно, а затем Y и Z переводят по 0,4 BTC на вас через каналы 2 и 3, увеличивая ваш локальный баланс. Таким образом, у вас будет достаточно средств для будущих крупных переводов.
Наблюдая указанную выше диаграмму, легко заметить, что сутью циклических платежей является перевод средств себе, перемещение баланса между различными каналами и, в конечном итоге, достижение желаемого распределения общего баланса. Однако таким образом невозможно просто так увеличить общий баланс в любом из каналов, кроме того, для его реализации необходимы следующие предположения: X имеет достаточно средств для перевода в Y и Z, другими словами, циклические платежи часто требуют заранее подготовленных резервов Ликвидности соответствующего Узла.
Маршрутные платежи - это один из способов реализации концепции балансировки каналов, а схемы балансировки могут также сочетаться с другими методами, такими как Submarine Swaps. Давайте рассмотрим Submarine Swaps, основная идея которых заключается в обмене средствами между в блокчейне и вне блокчейна, не закрывая каналы, с использованием методов HTLC и т.д.
Самый простой сценарий обмена подводными лодками в блокчейне - это депозит в канале. Допустим, Алиса и Боб уже установили канал 1 к 1, но спустя некоторое время у Алисы почти закончились локальные средства, и она не может больше платить. В этом случае Алисе нужно внести больше средств, и ей нужно закрыть и снова открыть канал. Однако этот канал арендован, и его закрытие заранее не очень выгодно. Что делать?
Если процесс осуществляется через подводную лодку, он будет довольно простым, но потребует использования HTLC. Сначала Алиса может сгенерировать случайное число R, взять его хеш H®. Затем Алиса может отправить BTC на адрес Боба в блокчейне, условие разблокировки которых ограничено HTLC. Чтобы разблокировать эти BTC в блокчейне, Боб должен знать прообраз R, соответствующий H®.
![]()
Bob в канале вне блокчейна совершает сделку с Alice через HTLC, но наоборот: сначала Alice должна предоставить R, чтобы разблокировать деньги, отправленные Bob. Как только Alice предоставит значение R, Bob сможет разблокировать BTC, заблокированные Alice в блокчейне. Затем локальный баланс Alice в канале увеличится, а активы в блокчейне уменьшатся пропорционально (если не учитывать комиссию), в основном это обмен 1:1 (выше для пояснения принципа не строго соблюдаются обычные операционные процедуры обмена подводной лодки, на самом деле чаще всего одна сторона создает HTLC вне блокчейна, а другая создает симметричный HTLC в блокчейне).
Данный сценарий в основном используется для обмена активами в блокчейне на остаток вне блокчейна. Просто поменяв направление операций между Алисой и Бобом, можно осуществить операцию снятия наличных, превратив остаток вне блокчейна в блокчейн активы. Такой обмен подразумевает использование функционала HTLC и временных блокировок для обеспечения безопасности. Если вдруг партнер откажется от сделки посреди пути, вы не потеряете заблокированные в HTLC деньги, поскольку партнер не знает Секретный ключ для разблокировки HTLC. По истечении временной блокировки вы сможете вернуть свой капитал.
Однако следует обратить внимание, что в указанной выше ситуации, хотя ваш капитал не будет краден, но требуется, чтобы одна из сторон создала блокчейн HTLC для блокировки средств, что неизбежно приведет к износу комиссии. Если другая сторона обманет, это обязательно повлияет на вас. Для решения этих проблем обычно используются некоторые вспомогательные методы, такие как предварительная оплата, система репутации и т. д.
Давайте еще раз кратко рассмотрим, ** основная идея взаимозаменяемости субмарин - это обеспечение гибкого обмена активами в блокчейне / вне блокчейна, ** если мы следуем логике ребалансировки канала, мы можем реализовать более эффективные меры по настройке Ликвидности. Здесь мы приведем простой пример:
Однако, обобщив вышеизложенные знания, легко заметить, что операции по регулированию ликвидности, такие как переключение подводных лодок, соединение каналов и аренда каналов, оставляют следы операций в блокчейне, что влечет за собой комиссию. Если часто выполнять подобные операции, это непременно создаст давление на экономические затраты и пользовательский опыт. В связи с тем, что сеть Lighting зависит от основной сети BTC, частая взаимодействие в блокчейне не является практичным. Однако Fiber, основанный на CKB, сталкивается с этим давлением относительно меньше и обеспечивает более плавное управление ликвидностью. В любом случае, сеть Lighting и Fiber активно исследуют новаторские решения ликвидности и, возможно, совместно с командами проектов, таких как Mercury Layer, найдут более подходящий путь в будущем.
