name: Теоретическое введение в Сеть Молния goal: Изучить Сеть Молния с технической точки зрения objectives:

• Понять принцип работы каналов сети.
• Ознакомиться с терминами HTLC, LNURL и UTXO.
• Усвоить управление ликвидностью и комиссиями LNN.
• Распознать Сеть Молния как сеть.
• Понять теоретическое использование Сети Молния.

Путешествие во второй слой Биткоина

Погрузитесь в сердце Сети Молния, ключевой системы для будущего транзакций Биткоина. LNP201 - это теоретический курс о техническом устройстве Сети Молния. Он раскрывает основы и механизмы этой сети второго уровня, созданной для быстрых, экономичных и масштабируемых платежей в Биткоине.

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

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

Приятного открытия!

Введение

Обзор курса

Добро пожаловать на курс LNP201!

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

Раздел 1: Основы
Мы начнем с общего введения в Lightning Network, установив основные принципы о Биткойне, его адресах, UTXO и функционировании транзакций. Этот обзор основ необходим для понимания того, как Lightning Network использует механизмы блокчейна для безопасной работы.

Раздел 2: Открытие и закрытие каналов
В этом разделе мы рассмотрим процесс открытия каналов, который является основой Lightning Network. Вы узнаете, как создаются транзакции обязательств, какова роль ключей отзыва для обеспечения безопасности и как каналы могут закрываться либо совместно, либо в одностороннем порядке. Каждый этап будет объяснен точно и технически, чтобы вы могли понять все его тонкости.

Раздел 3: Сеть ликвидности
Lightning Network — это не только отдельные каналы; это полноценная платежная сеть. Мы увидим, как транзакции могут направляться через промежуточные узлы с использованием HTLC. В этом разделе также будут рассмотрены вопросы входящей и исходящей ликвидности.

Раздел 4: Инструменты Lightning Network
Этот раздел представляет практические инструменты Lightning Network, такие как Invoices, LNURL и Keysend. Вы также научитесь управлять ликвидностью своих каналов, что важно для обеспечения плавности платежей и максимизации эффективности ваших транзакций в Lightning Network.

Раздел 5: Продолжайте изучение
Наконец, мы подведем итоги рассмотренных концепций и откроем путь к более продвинутым темам для тех, кто хочет углубить свои знания о Lightning Network.

Готовы изучить технические механизмы Lightning Network? Давайте начнем!

Основы

Понимание Сети Молния

df6230ae-ff35-56ea-8651-8e65580730a8 :::video id=ba99951f-81d2-418f-b5e7-4b8c9f8b8cc8:::

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

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

Концепция Платежного Канала

Платежный канал позволяет двум сторонам, здесь Алисе и Бобу, обмениваться средствами через Сеть Молния. Каждый участник имеет узел, символизируемый кругом, а канал между ними представлен отрезком линии.

В нашем примере, Алиса имеет 100,000 сатоши на своей стороне канала, а Боб - 30,000, что в сумме составляет 130,000 сатоши, что и является емкостью канала.

Но что такое сатоши?

Сатоши (или "сат") - это единица счета в Биткоине. Подобно центу для евро, сатоши - это просто доля Биткоина. Один сатоши равен 0.00000001 Биткоина, или одной стомиллионной Биткоина. Использование сатоши становится всё более практичным по мере роста стоимости Биткоина.

Распределение Средств в Канале

Давайте вернемся к платежному каналу. Ключевое понятие здесь - это "сторона канала". У каждого участника есть средства на своей стороне канала: у Алисы 100 000 сатоши, а у Боба 30 000. Как мы видели, сумма этих средств представляет собой общую емкость канала, цифра, установленная при его открытии.

Рассмотрим пример транзакции в сети Lightning. Если Алиса хочет отправить 40 000 сатоши Бобу, это возможно, потому что у нее достаточно средств (100 000 сатоши). После этой транзакции у Алисы будет 60 000 сатоши на ее стороне, а у Боба 70 000.

Емкость канала, равная 130 000 сатоши, остается постоянной. То, что меняется, - это распределение средств. Эта система не позволяет отправлять больше средств, чем есть у кого-либо на счету. Например, если Боб захотел бы отправить обратно 80 000 сатоши Алисе, он не смог бы, потому что у него есть только 70 000.

Другой способ представить распределение средств - это подумать о ползунке, который указывает, где находятся средства в канале. Изначально, с 100 000 сатоши у Алисы и 30 000 у Боба, ползунок логически находится на стороне Алисы. После транзакции на 40 000 сатоши, ползунок немного переместится в сторону Боба, у которого теперь 70 000 сатоши.

Это представление может быть полезным для воображения баланса средств в канале.

Основные правила платежного канала

Первое, что нужно запомнить, это то, что емкость канала фиксирована. Это немного похоже на диаметр трубы: он определяет максимальное количество средств, которые могут быть отправлены через канал за один раз. Давайте рассмотрим пример: если у Алисы на ее стороне 130 000 сатоши, она может отправить максимум 130 000 сатоши Бобу за одну транзакцию. Однако Боб может затем отправить эти средства обратно Алисе, частично или полностью.

Важно понимать, что фиксированная емкость канала ограничивает максимальный объем одной транзакции, но не общее количество возможных транзакций, ни общий объем обмененных средств в рамках канала.

Что вы должны запомнить из этой главы?

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

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

Bitcoin, адреса, UTXO и транзакции

0cfb7e6b-96f0-508b-9210-90bc1e28649d :::video id=75323eef-ea03-45ac-9a6e-46d73ca255de:::

Эта глава немного особенная, поскольку она не будет напрямую посвящена Lightning, а Bitcoin. Действительно, Lightning Network является слоем поверх Bitcoin. Поэтому крайне важно понять некоторые фундаментальные концепции Bitcoin, чтобы правильно уловить принцип работы Lightning в последующих главах. В этой главе мы рассмотрим основы Bitcoin-адресов для получения, UTXO, а также принцип работы Bitcoin-транзакций.

Bitcoin-адреса, Приватные и Публичные Ключи

Bitcoin-адрес представляет собой серию символов, полученных из публичного ключа, который, в свою очередь, вычисляется из приватного ключа. Как вы наверняка знаете, он используется для блокировки биткоинов, что эквивалентно их получению в наш кошелек.

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

• Приватные ключи будут представлены вертикально.
• Публичные ключи будут представлены горизонтально.
• Их цвет указывает, кто ими владеет (Алиса в оранжевом и Боб в черном...).

Bitcoin-транзакции: Отправка средств и Скрипты

В Bitcoin транзакция включает отправку средств с одного адреса на другой. Давайте рассмотрим пример, когда Алиса отправляет 0.002 Bitcoin Бобу. Алиса использует приватный ключ, ассоциированный с ее адресом, чтобы подписать транзакцию, тем самым доказывая, что она действительно может потратить эти средства. Но что именно происходит за кулисами этой транзакции? Средства на Bitcoin-адресе блокируются скриптом, своего рода мини-программой, которая накладывает определенные условия для расходования средств.

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

UTXO: Непотраченные Выходы Транзакций

В Bitcoin то, что мы фактически обмениваем, не прямо биткоины, а UTXO (Unspent Transaction Outputs, непотраченные выходы транзакций).

UTXO - это часть биткоина, которая может иметь любую стоимость, например, 2,000 биткоинов, 8 биткоинов или даже 8,000 сатоши. Каждый UTXO блокируется скриптом, и для его расходования необходимо удовлетворить условиям скрипта, чаще всего подписью приватным ключом, соответствующим данному адресу для получения.

UTXO нельзя разделить. Каждый раз, когда они используются для расходования представленной ими суммы в биткоинах, это должно быть сделано целиком. Это немного похоже на купюру: если у вас есть купюра в 10 евро и вы должны пекарю 5 евро, вы не можете просто разрезать купюру пополам. Вы должны дать ему купюру в 10 евро, и он даст вам сдачу в 5 евро. Принцип работы UTXO на Bitcoin точно такой же! Например, когда Алиса разблокирует скрипт своим приватным ключом, она разблокирует весь UTXO. Если она хочет отправить только часть средств, представленных этим UTXO, Бобу, она может "фрагментировать" его на несколько меньших. Затем она отправит 0.0015 BTC Бобу и остаток, 0.0005 BTC, на адрес для сдачи.

Вот пример транзакции с 2 выходами:

• UTXO на 0.0015 BTC для Боба, заблокированный скриптом, требующим подписи приватного ключа Боба.
• UTXO на 0.0005 BTC для Алисы, заблокированный скриптом, требующим её собственной подписи.

Адреса с мультиподписью

Помимо простых адресов, создаваемых из одного публичного ключа, возможно создание адресов с мультиподписью из нескольких публичных ключей. Особенно интересным случаем для Сети Молнии является адрес 2/2 с мультиподписью, созданный из двух публичных ключей:

Для того чтобы потратить средства, заблокированные с этим адресом 2/2 с мультиподписью, необходимо подписать транзакцию двумя приватными ключами, ассоциированными с публичными ключами.

Этот тип адреса является точным представлением платёжных каналов в Сети Молнии на блокчейне Биткоина.

Что важно запомнить из этой главы?

• Адрес Биткоина получается из публичного ключа, который, в свою очередь, производится из приватного ключа.
• Средства в Биткоине блокируются скриптами, и для того чтобы потратить эти средства, необходимо удовлетворить условия скрипта, что обычно включает предоставление подписи соответствующим приватным ключом.
• UTXO - это части биткоинов, заблокированные скриптами, и каждая транзакция в Биткоине состоит из разблокировки UTXO и затем создания одного или нескольких новых взамен.
• Адреса 2/2 с мультиподписью требуют подписи двух приватных ключей для расходования средств. Эти специфические адреса используются в контексте Сети Молнии для создания платёжных каналов.

Эта глава о Биткоине позволила нам рассмотреть некоторые основные понятия для дальнейшего изучения. В следующей главе мы конкретно узнаем, как работает открытие каналов в Сети Молнии.

Открытие и закрытие каналов

Открытие канала

96243eb0-f6b5-5b68-af1f-fffa0cc16bfe :::video id=6098fee1-735e-4d8d-9f57-0faf5fef6d76:::

В этой главе мы более подробно рассмотрим, как открыть платёжный канал в Сети Молнии и поймём связь этой операции с базовой системой Биткоина.

Платёжные каналы

Как мы видели в первой главе, платёжный канал в Сети Молнии можно сравнить с "трубой" для обмена средствами между двумя участниками (Алисой и Бобом в наших примерах). Емкость этого канала соответствует сумме доступных средств с каждой стороны. В нашем примере у Алисы 100,000 сатоши, а у Боба 30,000 сатоши, что дает общую емкость в 130,000 сатоши.

Уровни обмена информацией

Крайне важно чётко различать разные уровни обмена в Сети Молнии:

• Peer-to-peer коммуникации (протокол Lightning): Это сообщения, которые узлы Сети Молнии отправляют друг другу для коммуникации. Мы будем изображать эти сообщения пунктирными чёрными линиями на наших диаграммах.
• Платёжные каналы (протокол Lightning): Это пути для обмена средствами в Сети Молнии, которые мы будем изображать сплошными чёрными линиями.
• Биткоин транзакции (протокол Bitcoin): Это транзакции, совершаемые в блокчейне, которые мы будем изображать оранжевыми линиями.

Стоит отметить, что узел Lightning может общаться по протоколу P2P без открытия канала, но для обмена средствами необходим канал.

Шаги по открытию канала Lightning

• Обмен сообщениями: Алиса хочет открыть канал с Бобом. Она отправляет ему сообщение с суммой, которую она хочет внести в канал (130 000 сатоши) и своим публичным ключом. Боб отвечает, делится своим публичным ключом.

• Создание мультиподписного адреса: Используя эти два публичных ключа, Алиса создает мультиподписной адрес 2/2, что означает, что средства, которые будут позже внесены на этот адрес, потребуют обеих подписей (Алисы и Боба) для расходования.

• Транзакция внесения депозита: Алиса подготавливает биткойн-транзакцию для внесения средств на этот мультиподписной адрес. Например, она может решить отправить 130 000 сатоши на этот мультиподписной адрес. Эта транзакция создана, но еще не опубликована в блокчейне.

• Транзакция вывода средств: Перед публикацией транзакции внесения депозита, Алиса создает транзакцию вывода средств, чтобы она могла вернуть свои средства в случае проблемы с Бобом. Действительно, как только Алиса публикует транзакцию внесения депозита, ее сатоши будут заблокированы на мультиподписном адресе 2/2, который требует подписи как Алисы, так и Боба для разблокировки. Алиса защищается от этого риска потери, создавая транзакцию вывода средств, которая позволяет ей вернуть свои средства.

• Подпись Боба: Алиса отправляет транзакцию внесения депозита Бобу в качестве доказательства и просит его подписать транзакцию вывода средств. Как только подпись Боба получена на транзакции вывода средств, Алиса уверена, что сможет в любое время вернуть свои средства, так как теперь для разблокировки мультиподписного адреса требуется только ее собственная подпись.

• Публикация транзакции внесения депозита: Как только подпись Боба получена, Алиса может опубликовать транзакцию внесения депозита в блокчейне Bitcoin, тем самым официально открыв канал Lightning между двумя пользователями.

Когда канал считается открытым?

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

Что вам следует запомнить из этой главы?

• Открытие канала начинается с обмена сообщениями между двумя сторонами (обмен суммами и публичными ключами).
• Канал формируется путем создания мультиподписного адреса 2/2 и внесения средств на него через биткойн-транзакцию.
• Лицо, открывающее канал, обеспечивает возможность возврата своих средств через транзакцию вывода средств, подписанную другой стороной, до публикации транзакции внесения депозита.

В следующей главе мы рассмотрим техническое функционирование транзакции внутри канала на сети Lightning.

Транзакция обязательств

7d3fd135-129d-5c5a-b306-d5f2f1e63340 :::video id=c17454f3-14c5-47a0-8c9c-42ee12932bd3:::

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

Напоминание о жизненном цикле канала

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

Начальное состояние канала

В момент открытия канала Алиса внесла 130 000 сатоши на мультиподписной адрес канала. Таким образом, в начальном состоянии все средства находятся на стороне Алисы. Перед открытием канала Алиса также заставила Боба подписать транзакцию на вывод средств, которая позволила бы ей вернуть свои средства, если бы она захотела закрыть канал.

Неопубликованные транзакции: Транзакции обязательств

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

Давайте рассмотрим пример, когда Алиса отправляет 30 000 сатоши Бобу:

• Изначально: У Алисы есть 130 000 сатоши.
• После транзакции: У Алисы остается 100 000 сатоши, а у Боба 30 000 сатоши. Чтобы подтвердить этот перевод, Алиса и Боб создают новую неопубликованную транзакцию Bitcoin, которая отправит 100 000 сатоши Алисе и 30 000 сатоши Бобу с мультиподписного адреса. Обе стороны конструируют эту транзакцию независимо, но с одинаковыми данными (суммы и адреса). После конструирования каждый подписывает транзакцию и обменивается своей подписью с другой стороной. Это позволяет любой из сторон в любой момент опубликовать транзакцию, если это необходимо, чтобы восстановить свою долю канала на основном блокчейне Bitcoin.

Процесс перевода: Счет на оплату

Когда Боб хочет получить средства, он отправляет Алисе счет на оплату на 30 000 сатоши. Затем Алиса производит оплату этого счета, начиная перевод внутри канала. Как мы видели, этот процесс основан на создании и подписании новой транзакции обязательства.

Каждая транзакция обязательства представляет новое распределение средств в канале после перевода. В этом примере, после транзакции, у Боба 30 000 сатоши, а у Алисы 100 000 сатоши. Если любой из двух участников решит опубликовать эту транзакцию обязательства в блокчейне, это приведет к закрытию канала, и средства будут распределены в соответствии с этим последним распределением.

Новое состояние после второй транзакции

Давайте рассмотрим другой пример: после первой транзакции, где Алиса отправила 30 000 сатоши Бобу, Боб решает отправить 10 000 сатоши обратно Алисе. Это создает новое состояние канала. Новая транзакция обязательства будет представлять это обновленное распределение:

• У Алисы теперь 110 000 сатоши.
• У Боба 20 000 сатоши.

Опять же, эта транзакция не публикуется в блокчейне, но может быть опубликована в любой момент, если канал будет закрыт.

В заключение, когда средства переводятся внутри канала Lightning:

• Алиса и Боб создают новую транзакцию обязательства, которая отражает новое распределение средств. Эта транзакция Bitcoin подписывается обеими сторонами, но не публикуется в блокчейне Bitcoin, пока канал остается открытым.
• Транзакции обязательства гарантируют, что каждый участник может восстановить свои средства в любое время в блокчейне Bitcoin, опубликовав последнюю подписанную транзакцию.

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

Ключ отзыва

f2f61e5b-badb-5947-9a81-7aa530b44e59 :::video id=1d850f23-eff1-4725-b284-ce12456a2c26::: В этой главе мы более подробно рассмотрим, как работают транзакции в сети Lightning, обсудив механизмы защиты от обмана, обеспечивающие соблюдение правил каждой стороной в канале.

Напоминание: Транзакции обязательства

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

Давайте рассмотрим простой пример:

• Исходное состояние: у Алисы 100,000 сатоши, у Боба 30,000 сатоши.
• После транзакции, в которой Алиса отправляет 40,000 сатоши Бобу, новая транзакция обязательства распределяет средства следующим образом:
  • Алиса: 60,000 сатоши
  • Боб: 70,000 сатоши

В любой момент обе стороны могут опубликовать последнюю транзакцию обязательства, подписанную для закрытия канала и восстановления своих средств.

Проблема: Обман путем публикации старой транзакции

Потенциальная проблема возникает, если одна из сторон решает обмануть, опубликовав старую транзакцию обязательства. Например, Алиса может опубликовать более старую транзакцию обязательства, где у нее было 100,000 сатоши, хотя на самом деле у нее сейчас только 60,000. Это позволило бы ей украсть 40,000 сатоши у Боба.

Что еще хуже, Алиса могла бы опубликовать самую первую транзакцию вывода средств, ту, что была до открытия канала, где у нее было 130,000 сатоши, и таким образом украсть все средства канала.

Решение: Ключ отзыва и Таймлок

Чтобы предотвратить такой вид обмана со стороны Алисы, в сети Lightning добавлены механизмы безопасности к транзакциям обязательства:

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

Давайте подробно рассмотрим принцип работы этого механизма.

Процесс обновления транзакции

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

• У Алисы и Боба есть новая транзакция обязательства, представляющая текущее распределение средств после транзакции Lightning.
• Каждый имеет секрет другого для предыдущей транзакции, что позволяет им использовать ключ отзыва только в случае, если один из них пытается обмануть, опубликовав транзакцию со старым состоянием в мемпулах узлов Bitcoin. Действительно, чтобы наказать другую сторону, необходимо иметь оба секрета и транзакцию обязательства другого, которая включает подписанный вход. Без этой транзакции ключ отзыва сам по себе бесполезен. Единственный способ получить эту транзакцию - извлечь ее из мемпулов (в транзакциях, ожидающих подтверждения) или в подтвержденных транзакциях на блокчейне во время таймлока, что доказывает, что другая сторона пытается обмануть, намеренно или нет.

Давайте рассмотрим пример, чтобы хорошо понять этот процесс:

• Исходное состояние: У Алисы 100,000 сатоши, у Боба 30,000 сатоши.

• Боб хочет получить 40,000 сатоши от Алисы через их канал Lightning. Для этого:
  • Он отправляет ей счет, вместе со своим секретом для ключа отзыва его предыдущей транзакции обязательства.
  • В ответ Алиса предоставляет свою подпись для новой транзакции обязательства Боба, а также свой секрет для ключа отзыва ее предыдущей транзакции.
  • Наконец, Боб отправляет свою подпись для новой транзакции обязательства Алисы.
  • Эти обмены позволяют Алисе отправить 40,000 сатоши Бобу через Lightning по их каналу, и новые транзакции обязательства теперь отражают это новое распределение средств.

• Если Алиса попытается опубликовать старую транзакцию обязательства, где она все еще владела 100,000 сатоши, Боб, получив ключ отзыва, может немедленно восстановить средства с помощью этого ключа, в то время как Алиса блокируется таймлоком.

Даже если в данном случае у Боба нет экономического интереса пытаться обмануть, если он все же это делает, Алиса также получает симметричную защиту, предоставляющую ей те же гарантии.

Что вы должны запомнить из этой главы?

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

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

Закрытие канала

29a72223-2249-5400-96f0-3756b1629bc2 :::video id=4d8ad4e6-32ff-46d3-bd17-343929aa863b:::

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

Напоминание о жизненном цикле канала

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

Три типа закрытия канала

Существует три основных способа закрыть этот канал, которые можно назвать хорошим, грубым и хитрым (вдохновлено Андреасом Антонопулосом в Mastering the Lightning Network):

• Хороший: кооперативное закрытие, когда Алиса и Боб соглашаются закрыть канал.
• Плохой: принудительное закрытие, когда одна из сторон решает закрыть канал честно, но без согласия другой стороны.
• Уродливый: закрытие с обманом, когда одна из сторон пытается украсть средства, опубликовав старую транзакцию обязательства (любую, кроме последней, которая отражает актуальное и справедливое распределение средств).

Давайте рассмотрим пример:

• У Алисы есть 100,000 сатоши, а у Боба 30,000 сатоши.
• Это распределение отражено в 2 транзакциях обязательствах (по одной на пользователя), которые не опубликованы, но могут быть в случае закрытия канала.

Хороший: кооперативное закрытие

При кооперативном закрытии Алиса и Боб соглашаются закрыть канал. Вот как это происходит:

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

• Алиса и Боб вместе договариваются о комиссии за транзакцию закрытия. Эти комиссии обычно рассчитываются на основе рынка комиссий Bitcoin на момент закрытия. Важно отметить, что всегда тот, кто открыл канал (Алиса в нашем примере), платит комиссии за закрытие.
• Они создают новую транзакцию закрытия. Эта транзакция похожа на транзакцию обязательства, но без временных замков или механизмов отзыва, поскольку обе стороны сотрудничают и нет риска обмана. Таким образом, кооперативная транзакция закрытия отличается от транзакций обязательств. Например, если у Алисы есть 100,000 сатоши, а у Боба 30,000 сатоши, то в заключительной транзакции 100,000 сатоши будут отправлены на адрес Алисы, а 30,000 сатоши - на адрес Боба, без ограничений по времени. Как только эта транзакция подписана обеими сторонами, она публикуется Алисой. После подтверждения транзакции в блокчейне Bitcoin, канал Lightning будет официально закрыт.

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

Плохой вариант: принудительное закрытие

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

Эта транзакция включает временную блокировку для средств Алисы, что делает закрытие медленнее.

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

В итоге, принудительное закрытие является крайней мерой, когда пир больше не отвечает. Оно медленнее и менее экономично, чем кооперативное закрытие. Поэтому его следует избегать по возможности.

Обман: мошенничество

Наконец, закрытие с мошенничеством происходит, когда одна из сторон пытается опубликовать старую транзакцию обязательств, где она имела больше средств, чем должна была. Например, Алиса может опубликовать старую транзакцию, где у неё было 120,000 сатоши, в то время как сейчас у неё только 100,000.

Боб, чтобы предотвратить это мошенничество, отслеживает блокчейн Bitcoin и его мемпул, чтобы убедиться, что Алиса не опубликует старую транзакцию. Если Боб обнаруживает попытку обмана, он может использовать ключ отзыва для восстановления средств Алисы и наказать её, забрав все средства канала. Поскольку Алиса блокируется временной блокировкой на её выходе, у Боба есть время потратить его без временной блокировки с его стороны, чтобы восстановить всю сумму на адрес, который он контролирует.

Очевидно, мошенничество может потенциально увенчаться успехом, если Боб не действует в течение времени, наложенного временной блокировкой на выходе Алисы. В этом случае выход Алисы разблокируется, позволяя ей использовать его для создания нового выхода на адрес, который она контролирует.

Что вы должны запомнить из этой главы?

Существует три способа закрытия канала:

• Кооперативное закрытие: Быстрое и менее дорогое, где обе стороны соглашаются закрыть канал и публикуют специально подготовленную заключительную транзакцию.
• Принудительное закрытие: Менее желательно, так как оно основано на публикации транзакции обязательств с потенциально несоответствующими комиссиями и временной блокировкой, что замедляет закрытие.
• Мошенничество: Если одна из сторон пытается украсть средства, опубликовав старую транзакцию, другая может использовать ключ отзыва, чтобы наказать за это мошенничество. В следующих главах мы рассмотрим Сеть Молний с более широкой перспективы, сосредоточив внимание на том, как работает её сеть.

Сеть Ликвидности

Сеть Молний

45a7252c-fa4f-554b-b8bb-47449532918e :::video id=38419c23-5592-4573-b0a7-84824a5bfb77:::

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

Сеть Платёжных Каналов

В Сети Молний транзакция соответствует переводу средств между двумя узлами. Как было показано в предыдущих главах, для выполнения транзакций Молний необходимо открыть канал с кем-то. Этот канал позволяет проводить почти бесконечное количество транзакций вне блокчейна до его закрытия для возврата баланса в блокчейне. Однако этот метод имеет недостаток, заключающийся в необходимости иметь прямой канал с другим человеком для получения или отправки средств, что подразумевает открытие транзакции и закрытие транзакции для каждого канала. Если я планирую совершить много платежей с этим человеком, открытие и закрытие канала становится экономически выгодным. Напротив, если мне нужно выполнить лишь несколько транзакций Молний, открытие прямого канала не выгодно, так как это будет стоить мне 2 транзакции в блокчейне для ограниченного числа транзакций вне блокчейна. Такая ситуация может возникнуть, например, когда хочется оплатить покупку в магазине через Сеть Молний, не планируя возвращаться.

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

Например, представьте, что:

• Алиса (в оранжевом) имеет канал с Сьюзи (в сером) с 100,000 сатоши с её стороны и 30,000 сатоши со стороны Сьюзи.
• Сьюзи имеет канал с Бобом, в котором она владеет 250,000 сатоши, а у Боба нет сатоши.

Если Алиса хочет отправить средства Бобу, не открывая с ним прямой канал, ей придётся воспользоваться каналом через Сьюзи, и каждый канал должен будет скорректировать ликвидность с каждой стороны. Отправленные сатоши остаются в пределах своих соответствующих каналов; они фактически не "пересекают" каналы, но перевод осуществляется через корректировку внутренней ликвидности в каждом канале.

Предположим, Алиса хочет отправить 50,000 сатоши Бобу:

• Алиса отправляет 50,000 сатоши Сьюзи в их общем канале.
• Сьюзи повторяет этот перевод, отправляя 50,000 сатоши Бобу в их канале.

Таким образом, платеж направляется Бобу через перемещение ликвидности в каждом канале. В конце операции Алиса остается с 50 000 сатоши. Она действительно перевела 50 000 сатоши, поскольку изначально у нее было 100 000. Боб, с его стороны, получает дополнительные 50 000 сатоши. Для Сюзи (промежуточного узла) эта операция нейтральна: изначально у нее было 30 000 сатоши в ее канале с Алисой и 250 000 сатоши в ее канале с Бобом, всего 280 000 сатоши. После операции она имеет 80 000 сатоши в своем канале с Алисой и 200 000 сатоши в своем канале с Бобом, что составляет ту же сумму, что и в начале. Таким образом, этот перевод ограничен доступной ликвидностью в направлении перевода.

Расчет маршрута и лимитов ликвидности

Давайте рассмотрим теоретический пример другой сети с:

• 130 000 сатоши со стороны Алисы (в оранжевом) в ее канале с Сюзи (в сером).
• 90 000 сатоши со стороны Сюзи и 200 000 сатоши со стороны Кэрол (в розовом).
• 150 000 сатоши со стороны Кэрол и 100 000 сатоши со стороны Боба.

Максимальная сумма, которую Алиса может отправить Бобу в этой конфигурации, составляет 90 000 сатоши, поскольку она ограничена наименьшей доступной ликвидностью в канале от Сюзи к Кэрол. В противоположном направлении (от Боба к Алисе) платеж невозможен, потому что со стороны Сюзи в канале с Алисой нет сатоши. Следовательно, нет маршрута, который можно было бы использовать для перевода в этом направлении. Алиса отправляет 40 000 сатоши Бобу через каналы:

• Алиса переводит 40 000 сатоши в свой канал с Сюзи.
• Сюзи переводит 40 000 сатоши Кэрол в их общем канале.
• Кэрол, наконец, переводит 40 000 сатоши Бобу.

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

Как и в предыдущем примере, после транзакции исходный узел (Алиса) имеет на 40 000 сатоши меньше. Промежуточные узлы (Сюзи и Кэрол) сохраняют ту же общую сумму, делая операцию нейтральной для них. Наконец, конечный узел (Боб) получает дополнительные 40 000 сатоши.

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

Комиссии за маршрутизацию

Промежуточные узлы применяют комиссии за возможность прохождения платежей через их каналы. Эти комиссии устанавливаются каждым узлом для каждого канала. Комиссии состоят из 2 элементов:

• "Базовая комиссия": фиксированная сумма за канал, часто 1 сат по умолчанию, но настраиваемая.
• "Переменная комиссия": процент от переведенной суммы, рассчитываемый в частях на миллион (ppm). По умолчанию она составляет 1 ppm (1 сатоши на миллион переведенных сатоши), но может быть скорректирована. Комиссии также различаются в зависимости от направления перевода. Например, при переводе от Алисы к Сьюзи применяются комиссии Алисы. Наоборот, от Сьюзи к Алисе используются комиссии Сьюзи.

Например, для канала между Алисой и Сьюзи, у нас может быть:

• Алиса: базовая комиссия 1 сатоши и 1 ppm для переменных комиссий.
• Сьюзи: базовая комиссия 0.5 сатоши и 10 ppm для переменных комиссий.

Чтобы лучше понять, как работают комиссии, давайте изучим ту же сеть Lightning, но теперь с следующими комиссиями за маршрутизацию:

• Канал Алиса - Сьюзи: базовая комиссия 1 сатоши и 1 ppm для Алисы.
• Канал Сьюзи - Кэрол: базовая комиссия 0 сатоши и 200 ppm для Сьюзи.
• Канал Кэрол - Боб: базовая комиссия 1 сатоши и 1 ppm для Сьюзи 2.

Для того же платежа в 40,000 сатоши Бобу, Алисе придется отправить немного больше, так как каждый промежуточный узел будет вычитать свои комиссии:

• Кэрол вычитает 1.04 сатоши на канале с Бобом: f*{\text{Кэрол-Боб}} = \text{базовая комиссия} + \left(\frac{\text{ppm} \times \text{сумма}}{10^6}\right) f*{\text{Кэрол-Боб}} = 1 + \frac{1 \times 40000}{10^6} = 1 + 0.04 = 1.04 \text{ сат}

• Сьюзи вычитает 8 сатоши в виде комиссий на канале с Кэрол: f*{\text{Сьюзи-Кэрол}} = \text{базовая комиссия} + \left(\frac{\text{ppm} \times \text{сумма}}{10^6}\right) f*{\text{Сьюзи-Кэрол}} = 0 + \frac{200 \times 40001.04}{10^6} = 0 + 8.0002 \approx 8 \text{ сат}

Таким образом, общие комиссии за этот платеж на данном пути составляют 9.04 сатоши. Следовательно, Алисе необходимо отправить 40,009.04 сатоши, чтобы Боб получил ровно 40,000 сатоши.

Таким образом, ликвидность обновляется:

Маршрутизация через "луковицу"

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

• Отправляющий узел рассчитывает весь маршрут: Алиса, например, определяет, что ее платеж должен пройти через Сьюзи и Кэрол, прежде чем достичь Боба.

• Каждый промежуточный узел знает только своего непосредственного соседа: Сьюзи знает только, что она получила средства от Алисы и что она должна передать их Кэрол. Однако Сьюзи не знает, является ли Алиса источником или промежуточным узлом, и она также не знает, является ли Кэрол получателем или просто ещё одним промежуточным узлом. Этот принцип также применим к Кэрол и всем другим узлам на пути. Таким образом, маршрутизация через луковицу (onion routing) сохраняет конфиденциальность транзакций, маскируя идентичность отправителя и конечного получателя. Чтобы обеспечить возможность передающего узла рассчитать полный маршрут к получателю в маршрутизации через луковицу, он должен поддерживать граф сети, чтобы знать её топологию и определять возможные маршруты. Что вы должны запомнить из этой главы?

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

• Промежуточные узлы получают комиссию за свою услугу, состоящую из фиксированных и переменных сборов.

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

В этой главе мы исследовали маршрутизацию платежей в сети Lightning. Но возникает вопрос: что мешает промежуточным узлам принять входящий платеж, не перенаправляя его к следующему пункту назначения, с целью перехвата транзакции? Именно это и является ролью HTLC, которую мы изучим в следующей главе.

HTLC – Hashed Time Locked Contract (Хэшированный контракт с временной блокировкой)

4369b85a-1365-55d8-99e1-509088210116 :::video id=6f204b92-55a5-4939-9440-7c5b96a297bf:::

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

Проблема, возникающая при маршрутизации платежей, заключается в необходимости доверия к промежуточным узлам и между самими промежуточными узлами. Чтобы проиллюстрировать это, давайте вернемся к нашему упрощенному примеру сети Lightning с 3 узлами и 2 каналами:

• У Алисы есть канал с Сьюзи.
• У Сьюзи есть канал с Бобом.

Алиса хочет отправить 40 000 сатоши Бобу, но у неё нет прямого канала с ним и она не хочет его открывать. Она ищет маршрут и решает воспользоваться узлом Сьюзи.

Если Алиса наивно отправит 40 000 сатоши Сьюзи, надеясь, что Сьюзи переведет эту сумму Бобу, Сьюзи может оставить средства себе и не передать ничего Бобу.

Чтобы избежать этой ситуации, в сети Lightning используются HTLC (Хэшированные контракты с временной блокировкой), которые делают платеж промежуточному узлу условным, то есть Сьюзи должна выполнить определенные условия, чтобы получить доступ к средствам Алисы и перевести их Бобу.

Как работают HTLC

HTLC — это специальный контракт, основанный на двух принципах:

• Условие доступа: Получатель должен раскрыть секрет, чтобы разблокировать причитающийся ему платеж.
• Истечение срока: Если платеж не будет полностью завершен в определенный период, он отменяется, и средства возвращаются отправителю.

Вот как работает этот процесс на нашем примере с Алисой, Сьюзи и Бобом:

Создание секрета: Боб генерирует случайный секрет, обозначенный как s (прообраз), и вычисляет его хеш, обозначенный как r, с использованием хеш-функции, обозначенной как h. У нас получается:

r = h(s)

Использование хеш-функции делает невозможным нахождение s, зная только h(s), но если s предоставлен, легко проверить, что он соответствует h(s).

Отправка запроса на платеж: Боб отправляет Алисе счет с просьбой о платеже. В этот счет, в частности, включен хеш r.

Отправка условного платежа: Алиса отправляет Сьюзи HTLC на 40 000 сатоши. Условием для получения этих средств Сьюзи является предоставление Алисе секрета s', удовлетворяющего следующему уравнению:

h(s') = r

Передача HTLC конечному получателю: Сьюзи, чтобы получить 40 000 сатоши от Алисы, должна передать аналогичный HTLC на 40 000 сатоши Бобу, который имеет то же условие, а именно, что он должен предоставить Сьюзи секрет s', удовлетворяющий уравнению:

h(s') = r

Подтверждение секретом s: Боб предоставляет s Сьюзи для получения обещанных в HTLC 40 000 сатоши. С этим секретом Сьюзи может затем разблокировать HTLC Алисы и получить 40 000 сатоши от Алисы. Платеж затем корректно направляется Бобу.

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

Истечение срока действия и управление HTLC в случае проблем

Если в процессе платежа один из промежуточных узлов или узел-получатель перестает отвечать, особенно в случае отключения интернета или электроэнергии, то платеж не может быть завершен, поскольку секрет, необходимый для разблокировки HTLC, не передается. Возьмем наш пример с Алисой, Сьюзи и Бобом, эта проблема возникает, например, если Боб не передает секрет s Сьюзи. В этом случае все HTLC вверх по пути блокируются, и также блокируются обеспеченные ими средства.

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

Затем истекает срок действия HTLC от Алисы к Сьюзи.

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

Представление HTLC в транзакциях обязательств

Транзакции обязательств представляют HTLC таким образом, что условия, которые они накладывают на Lightning, могут быть перенесены на Bitcoin в случае принудительного закрытия канала во время срока действия HTLC. Напомним, транзакции обязательств представляют текущее состояние канала между двумя пользователями и позволяют односторонне принудительно закрыть его в случае проблем. С каждым новым состоянием канала создаются 2 транзакции обязательств: по одной для каждой стороны. Давайте вернемся к нашему примеру с Алисой, Сьюзи и Бобом, но более внимательно посмотрим, что происходит на уровне канала между Алисой и Сьюзи, когда создается HTLC.

Перед началом платежа в 40 000 сатоши между Алисой и Бобом, Алиса имеет 100 000 сатоши в своем канале с Сьюзи, в то время как Сьюзи держит 30 000. Их транзакции обязательств выглядят следующим образом:

Алиса только что получила счет от Боба, который, в частности, содержит r, хеш секрета. Таким образом, она может создать HTLC на 40 000 сатоши с Сьюзи. Этот HTLC представлен в последних транзакциях обязательств как выход, называемый "HTLC Out" со стороны Алисы, поскольку средства исходящие, и "HTLC In" со стороны Сьюзи, поскольку средства входящие.

Эти выходы, связанные с HTLC, имеют точно такие же условия, а именно:

• Если Сьюзи может предоставить секрет s, она может немедленно разблокировать этот выход и перевести его на адрес, который она контролирует.
• Если Сьюзи не обладает секретом s, она не может разблокировать этот выход, и Алиса сможет разблокировать его после временной блокировки, чтобы отправить его на адрес, который она контролирует. Таким образом, временная блокировка предоставляет Сьюзи период для реакции, если она получит s.

Эти условия применяются только в случае закрытия канала (т.е., транзакция обязательств публикуется в блокчейне) в то время, как HTLC все еще активен в Lightning, что означает, что платеж между Алисой и Бобом еще не был окончательно завершен, и HTLC еще не истекли. Благодаря этим условиям, Сьюзи может восстановить 40 000 сатоши HTLC, причитающиеся ей, предоставив s. В противном случае, Алиса восстанавливает средства после истечения временной блокировки, потому что если Сьюзи не знает s, это означает, что она не перевела 40 000 сатоши Бобу, и, следовательно, средства Алисы ей не причитаются.

Кроме того, если канал закрывается, пока несколько HTLC находятся в ожидании, будет создано столько дополнительных выходов, сколько HTLC находится в процессе.

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

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

Что вы должны запомнить из этой главы?

HTLC позволяют осуществлять маршрутизацию платежей Lightning через несколько узлов без необходимости доверять им. Вот ключевые моменты, которые следует запомнить:

• HTLC обеспечивают безопасность платежей через секрет (предварительное изображение) и время истечения.
• Решение или истечение срока действия HTLC следует определенному порядку: затем от пункта назначения к источнику, чтобы защитить каждый узел.
• Пока HTLC не разрешен и не истек, он поддерживается как выход в самых последних транзакциях обязательств.

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

Нахождение своего пути

7e2ae959-c2a1-512e-b5d6-8fd962e819da :::video id=e5baa834-111d-46f5-a28b-3538bed2bbb0:::

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

Проблема маршрутизации в Lightning

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

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

Обновление карты сети

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

2 основных сообщения, обмениваемых между узлами Lightning, следующие:

• "Объявления о каналах": сообщения, сигнализирующие об открытии нового канала.
• "Обновления канала": сообщения об обновлении состояния канала, особенно об изменении комиссий (но не о распределении ликвидности). Узлы Lightning также отслеживают блокчейн Bitcoin, чтобы обнаруживать транзакции закрытия каналов. Закрытый канал затем удаляется из карты, поскольку он больше не может быть использован для маршрутизации наших платежей.

Маршрутизация платежа

Давайте рассмотрим пример небольшой сети Lightning с 7 узлами: Алиса, Боб, 1, 2, 3, 4 и 5. Представим, что Алиса хочет отправить платеж Бобу, но должна пройти через промежуточные узлы.

Вот фактическое распределение средств в этих каналах:

• Канал между Алисой и 1: 250 000 сатоши на стороне Алисы, 80 000 на стороне 1 (общая вместимость 330 000 сатоши).
• Канал между 1 и 2: 300 000 сатоши на стороне 1, 200 000 на стороне 2 (общая вместимость 500 000 сатоши).
• Канал между 2 и 3: 50 000 сатоши на стороне 2, 60 000 на стороне 3 (общая вместимость 110 000 сатоши).
• Канал между 2 и 5: 90 000 сатоши на стороне 2, 160 000 на стороне 5 (общая вместимость 250 000 сатоши).
• Канал между 2 и 4: 180 000 сатоши на стороне 2, 110 000 на стороне 4 (общая вместимость 290 000 сатоши).
• Канал между 4 и 5: 200 000 сатоши на стороне 4, 10 000 на стороне 5 (общая вместимость 210 000 сатоши).
• Канал между 3 и Бобом: 50 000 сатоши на стороне 3, 250 000 на стороне Боба (общая вместимость 300 000 сатоши).
• Канал между 5 и Бобом: 260 000 сатоши на стороне 5, 100 000 на стороне Боба (общая вместимость 360 000 сатоши).

Чтобы совершить платеж в 100 000 сатоши от Алисы к Бобу, варианты маршрутизации ограничены доступной ликвидностью в каждом канале. Оптимальный маршрут для Алисы, исходя из известного распределения ликвидности, может быть последовательность Алиса → 1 → 2 → 4 → 5 → Боб:

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

• Вероятность успеха: канал с большей общей вместимостью более вероятно содержит достаточную ликвидность. Например, канал между узлом 2 и узлом 3 имеет общую вместимость 110 000 сатоши, поэтому маловероятно, что на стороне узла 2 найдется 100 000 сатоши или больше, хотя это остается возможным.

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

• Истечение срока действия HTLC: чтобы избежать заблокированных платежей, время истечения срока действия HTLC также является параметром, который следует учитывать.

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

• Алиса → 1 → 2 → 5 → Боб, потому что это самый короткий маршрут с наибольшей пропускной способностью.

• Алиса → 1 → 2 → 4 → 5 → Боб, потому что этот маршрут предлагает хорошие пропускные способности, хотя и длиннее первого.

• Алиса → 1 → 2 → 3 → Боб, потому что этот маршрут включает канал 2 → 3, который имеет очень ограниченную пропускную способность, но остается потенциально используемым.

Выполнение платежа

Алиса решает протестировать свой первый маршрут (Алиса → 1 → 2 → 5 → Боб). Поэтому она отправляет HTLC на 100 000 сатоши узлу 1. Этот узел проверяет, что у него достаточно ликвидности с узлом 2, и продолжает передачу. Узел 2 затем получает HTLC от узла 1, но понимает, что у него недостаточно ликвидности в его канале с узлом 5 для маршрутизации платежа в 100 000 сатоши. Затем он отправляет сообщение об ошибке обратно узлу 1, который передает его Алисе. Этот маршрут потерпел неудачу.

Затем Алиса пытается маршрутизировать свой платеж, используя свой второй маршрут (Алиса → 1 → 2 → 4 → 5 → Боб). Она отправляет HTLC на 100 000 сатоши узлу 1, который передает его узлу 2, затем узлу 4, узлу 5, и, наконец, Бобу. На этот раз ликвидности достаточно, и маршрут функционирует. Каждый узел поочередно разблокирует свой HTLC, используя предварительное изображение, предоставленное Бобом (секрет s), что позволяет успешно завершить платеж Алисы Бобу.

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

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

Что вы должны запомнить из этой главы?

• Узлы поддерживают карту топологии сети через объявления и отслеживая закрытие каналов на блокчейне Bitcoin.
• Поиск оптимального маршрута для платежа остается вероятностным и зависит от многих критериев.
• Боб может предоставить указания в счете, чтобы направить маршрутизацию Алисы и избавить ее от тестирования маловероятных маршрутов.

В следующей главе мы конкретно изучим функционирование счетов, а также некоторые другие инструменты, используемые в сети Lightning.

Инструменты сети Lightning

Счет, LNURL и Keysend

e34c7ecd-2327-52e3-b61e-c837d9e5e8b0 :::video id=309c3412-506e-4189-ad46-5e5088c55008::: В этой главе мы более внимательно рассмотрим работу счетов-фактур Lightning, то есть запросов на оплату, отправляемых получающим узлом отправляющему узлу. Цель состоит в том, чтобы понять, как осуществлять платежи и получать платежи в сети Lightning. Мы также обсудим 2 альтернативы классическим счетам-фактурам: LNURL и Keysend.

Структура счетов-фактур Lightning

Как было объяснено в главе о HTLC, каждый платеж начинается с генерации счета-фактуры получателем. Затем этот счет передается плательщику (через QR-код или путем копирования и вставки) для инициации платежа. Счет-фактура состоит из двух основных частей:

• Часть, читаемая человеком: этот раздел содержит явно видимые метаданные для улучшения пользовательского опыта.
• Полезная нагрузка: этот раздел включает информацию, предназначенную для обработки платежа машинами.

Типичная структура счета-фактуры начинается с идентификатора ln для "Lightning", за которым следует bc для Bitcoin, затем сумма счета. Разделитель 1 отличает часть, читаемую человеком, от части данных (полезной нагрузки).

Давайте рассмотрим следующий счет-фактуру в качестве примера:

lnbc100u1p0x7x7dpp5l7r9y50wrzz0lwnsqgxdks50lxtwkl0mhd9lslr4rcgdtt2n6lssp5l3pkhdx0cmc9gfsqvw5xjhph84my2frzjqxqyz5vq9qsp5k4mkzv5jd8u5n89d2yc50x7ptkl0zprx0dfjh3km7g0x98g70hsqq7sqqqgqqyqqqqlgqqvnv2k5ehwnylq3rhpd9g2y0sq9ujyxsqqypjqqyqqqqqqqqqqqsqqqqq9qsq3vql5f6e45xztgj7y6xw6ghrcz3vmh8msrz8myvhsarxg42ce9yyn53lgnryx0m6qqld8fql

Мы уже можем разделить его на 2 части. Сначала идет часть, читаемая человеком:

lnbc100u

Затем часть, предназначенная для полезной нагрузки:

p0x7x7dpp5l7r9y50wrzz0lwnsqgxdks50lxtwkl0mhd9lslr4rcgdtt2n6lssp5l3pkhdx0cmc9gfsqvw5xjhph84my2frzjqxqyz5vq9qsp5k4mkzv5jd8u5n89d2yc50x7ptkl0zprx0dfjh3km7g0x98g70hsqq7sqqqgqqyqqqqlgqqvnv2k5ehwnylq3rhpd9g2y0sq9ujyxsqqypjqqyqqqqqqqqqqqsqqqqq9qsq3vql5f6e45xztgj7y6xw6ghrcz3vmh8msrz8myvhsarxg42ce9yyn53lgnryx0m6qqld8fql

Две части разделены символом 1. В качестве разделителя был выбран не специальный символ, чтобы облегчить копирование всего счета-фактуры двойным кликом. В первой части мы видим, что:

• ln указывает, что это транзакция Lightning.
• bc указывает, что сеть Lightning работает на блокчейне Bitcoin (а не на тестнете или на Litecoin).
• 100u указывает сумму счета, выраженную в микробиткоинах (u означает "микро"), что здесь эквивалентно 10 000 сатоши.

Для обозначения суммы платежа она выражается в подединицах биткоина. Вот используемые единицы:

• Миллибиткоин (обозначается m): Представляет одну тысячную биткоина.

  1 \, \text{mBTC} = 10^{-3} \, \text{BTC} = 10^5 \, \text{сатоши}

• Микробиткоин (обозначается u): Иногда называемый "бит", представляет одну миллионную биткоина.

  1 \, \mu\text{BTC} = 10^{-6} \, \text{BTC} = 100 \, \text{сатоши}

• Нанобиткоин (обозначается n): Представляет одну миллиардную биткоина.

  1 \, \text{nBTC} = 10^{-9} \, \text{BTC} = 0.1 \, \text{сатоши}

• Пикобиткоин (обозначается p): Представляет одну триллионную биткоина.

  1 \, \text{pBTC} = 10^{-12} \, \text{BTC} = 0.0001 \, \text{сатоши}

Содержимое счета-фактуры

Содержимое счета-фактуры включает в себя несколько элементов информации, необходимых для обработки платежа:

• Временная метка: Момент создания счета-фактуры, выраженный в Unix Timestamp (количество секунд, прошедших с 1 января 1970 года).
• Хеширование секрета: Как мы видели в разделе о HTLC, принимающий узел должен предоставить отправляющему узлу хеш предварительного изображения. Это используется в HTLC для обеспечения безопасности транзакции. Мы называли это "r".
• Платежный секрет: Еще один секрет генерируется получателем, но на этот раз он передается отправляющему узлу. Он используется в маршрутизации через луковицу (onion routing) для предотвращения угадывания промежуточными узлами, является ли следующий узел конечным получателем или нет. Таким образом, это поддерживает форму конфиденциальности для получателя по отношению к последнему промежуточному узлу на маршруте.
• Публичный ключ получателя: Указывает плательщику идентификатор лица, которому должен быть произведен платеж.
• Срок действия: Максимальное время для оплаты счета-фактуры (по умолчанию 1 час).
• Подсказки для маршрутизации: Дополнительная информация, предоставляемая получателем для помощи отправителю в оптимизации маршрута платежа.
• Подпись: Гарантирует целостность счета-фактуры, аутентифицируя всю информацию.

Счета-фактуры затем кодируются в bech32, том же формате, что и для адресов Bitcoin SegWit (формат, начинающийся с bc1).

LNURL Вывод средств

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

LNURL — это протокол коммуникации, который определяет набор функциональных возможностей, предназначенных для упрощения взаимодействия между узлами Lightning и клиентами, а также сторонними приложениями. Таким образом, вывод средств через LNURL, как мы только что видели, является лишь одним из примеров других функциональностей. Этот протокол основан на HTTP и позволяет создавать ссылки для различных операций, таких как запрос на платеж, запрос на вывод средств или другие функциональности, улучшающие пользовательский опыт. Каждый LNURL представляет собой URL, закодированный в bech32 с префиксом lnurl, который, будучи отсканированным, запускает серию автоматических действий в кошельке Lightning. Например, функция LNURL-withdraw (LUD-03) позволяет выводить средства из сервиса, сканируя QR-код, без необходимости вручную генерировать счет. Аналогично, LNURL-auth (LUD-04) позволяет входить в онлайн-сервисы, используя приватный ключ в кошельке Lightning вместо пароля.

Отправка платежа по Lightning без счета: Keysend

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

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

Что вы должны запомнить из этой главы?

• Lightning Invoice — это запрос на платеж, состоящий из части, читаемой человеком, и части с данными для машины.
• Счет кодируется в bech32, с разделителем 1 для упрощения копирования и частью данных, содержащей всю необходимую информацию для обработки платежа.
• В Lightning существуют и другие процессы платежа, в частности, LNURL-Withdraw для упрощения вывода средств и Keysend для прямых переводов без счета.

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

Управление вашей ликвидностью

cc76d0c4-d958-57f5-84bf-177e21393f48 :::video id=96096aef-e4ce-4c44-a022-57e27082232a:::

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

Потребности в ликвидности

На Lightning существуют три основных типа пользовательских профилей, каждый из которых имеет специфические потребности в ликвидности:

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

Эти профили, очевидно, не являются фиксированными; пользователь может переключаться между ролями плательщика и получателя в зависимости от транзакций. Например, Боб может получать свою зарплату на Lightning от своего работодателя, что ставит его в позицию "продавца", требующего входящей ликвидности. Затем, если он хочет использовать свою зарплату для покупки еды, он становится "плательщиком" и должен иметь исходящую ликвидность.

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

Представьте, что покупатель хочет отправить 30 000 сатоши продавцу, и что платеж проходит через узел маршрутизатора. Каждая сторона должна иметь минимальное количество ликвидности в направлении платежа:

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

Стратегии управления ликвидностью

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

• Привлечение каналов: Торговец получает преимущество из-за объема ожидаемых входящих платежей на свой узел. Учитывая это, они могут попытаться привлечь маршрутизирующие узлы, которые ищут доход от комиссионных за транзакции и которые могут открыть каналы в их сторону, надеясь маршрутизировать их платежи и собирать связанные с этим комиссии.
• Перемещение ликвидности: Продавец также может открыть канал и перевести часть средств на противоположную сторону, совершая фиктивные платежи другому узлу, который вернет деньги другим способом. В следующей части мы увидим, как выполнить эту операцию.
• Треугольное открытие: Существуют платформы для узлов, желающих совместно открыть каналы, позволяя каждому из них получить немедленную входящую и исходящую ликвидность. Например, LightningNetwork+ предлагает такую услугу. Если Алиса, Боб и Сьюзи хотят открыть канал на 100,000 сатоши, они могут договориться на этой платформе, чтобы Алиса открыла канал в сторону Боба, Боб в сторону Сьюзи, а Сьюзи в сторону Алисы. Таким образом, каждый из них имеет 100,000 сатоши исходящей ликвидности и 100,000 сатоши входящей ликвидности, при этом заблокировав только 100,000 сатоши.

• Покупка каналов: Также существуют услуги по аренде каналов Lightning для получения входящей ликвидности, например, Bitrefill Thor или Lightning Labs Pool. Например, Алиса может купить канал на один миллион сатоши в сторону своего узла, чтобы иметь возможность получать платежи.

Наконец, для маршрутизаторов, чья цель - максимизировать количество обработанных платежей и собранные комиссии, они должны:

• Открывать хорошо финансируемые каналы со стратегическими узлами.
• Регулярно корректировать распределение средств в каналах в соответствии с потребностями сети.

Сервис Loop Out

Сервис Loop Out, предлагаемый Lightning Labs, позволяет перемещать ликвидность на противоположную сторону канала, возвращая средства на блокчейн Bitcoin. Например, Алиса отправляет 1 миллион сатоши через Lightning на узел loop, который затем возвращает эти средства ей в виде биткоинов в блокчейне. Это балансирует ее канал с 1 миллионом сатоши с каждой стороны, оптимизируя ее способность получать платежи.

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

Что вы должны запомнить из этой главы?

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

В следующей главе я предлагаю рассмотреть наиболее важные концепции этого обучения.

Дальше

Резюме обучения

a65a571c-561b-5e1c-87bf-494644653c22 :::video id=5f4f4344-ef27-4765-8f09-8262e6833bde:::

В этой заключительной главе, которая отмечает окончание обучения LNP201, я предлагаю повторно рассмотреть важные концепции, которые мы изучали вместе. Цель этого обучения заключалась в том, чтобы предоставить вам всестороннее и техническое понимание Lightning Network. Мы узнали, как Lightning Network использует блокчейн Bitcoin для выполнения транзакций вне цепочки, сохраняя при этом фундаментальные характеристики Bitcoin, в частности, отсутствие необходимости доверять другим узлам.

Платежные каналы

В первых главах мы исследовали, как две стороны, открыв платежный канал, могут проводить транзакции вне блокчейна Bitcoin. Вот шаги, которые были рассмотрены:

• Открытие канала: Создание канала происходит через транзакцию Bitcoin, которая блокирует средства на 2/2 мультиподписном адресе. Этот депозит представляет собой канал Lightning в блокчейне.

2. Транзакции в канале: В этом канале затем можно провести множество транзакций без необходимости публиковать их в блокчейне. Каждая транзакция Lightning создает новое состояние канала, отраженное в транзакции обязательства.

• Обеспечение безопасности и закрытие: Участники соглашаются с новым состоянием канала, обмениваясь ключами отзыва для обеспечения безопасности средств и предотвращения мошенничества. Обе стороны могут закрыть канал совместно, совершив новую транзакцию в блокчейне Bitcoin, или, в качестве крайней меры, через принудительное закрытие. Этот последний вариант, хотя и менее эффективен из-за большей длительности и иногда плохой оценки в плане комиссий, все же позволяет восстановить средства. В случае мошенничества, жертва может наказать обманщика, восстановив все средства с канала в блокчейне.

Сеть каналов

После изучения изолированных каналов мы расширили наш анализ до сети каналов:

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

• HTLC: Платежи, проходящие через промежуточные узлы, защищены "Hash Time-Locked Contracts" (HTLC), которые позволяют заблокировать средства до завершения платежа от начала до конца.

• Маршрутизация Onion: Для обеспечения конфиденциальности платежа маршрутизация Onion скрывает конечный пункт назначения для промежуточных узлов. Отправляющему узлу, таким образом, необходимо рассчитать весь маршрут, но в отсутствие полной информации о ликвидности каналов, он проходит через последовательные попытки для маршрутизации платежа.

Управление ликвидностью

Мы видели, что управление ликвидностью является вызовом в Lightning для обеспечения бесперебойного потока платежей. Отправка платежей относительно проста: это просто требует открытия канала. Однако, для получения платежей требуется наличие ликвидности на противоположной стороне своих каналов. Вот некоторые обсуждаемые стратегии:

• Привлечение каналов: Поощряя другие узлы открывать каналы в свою сторону, пользователь получает входящую ликвидность.

• Перемещение ликвидности: Отправляя платежи в другие каналы, ликвидность перемещается на противоположную сторону.

• Использование услуг вроде Loop и Pool: Эти услуги позволяют перебалансировать или купить каналы с ликвидностью на противоположной стороне.
• Совместные открытия: Также доступны платформы для соединения с целью выполнения треугольных открытий и получения входящей ликвидности.

Заключительный раздел

Отзывы & Оценки

38814c99-eb7b-5772-af49-4386ee2ce9b0 true

Финальный экзамен

7ed33400-aef7-5f3e-bfb1-7867e445d708 true

Заключение

afc0d72b-4fbc-5893-90b2-e27fb519ad02 true