Lightning Network: решение проблемы масштабирования

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

Весь цикл статей состоит из следующих частей:

• Lightning Network Часть №1: Введение: описание предпосылок создания концепции Lightning Network, сравнительный анализ с другими платежными системами.
• Lightning Network Часть №2: Области применения: поверхностное описание технологии и примеры использования в различных областях.
• Lightning Network Часть №3: Смарт-контракты: объяснение основных блоков, необходимых для углубления в техническое описание концепции.
• Lightning Network Часть №4: платежный канал: объяснение понятия платежного канала и его применения для быстрого обмена биткоинами.
• Lightning Network Часть №5: решение проблемы масштабирования. Объяснение использования платежных каналов для построения платежной сети и решения проблемы масштабирования.

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

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

Платеж multi-hop

Платеж, который проходит через несколько узлов в концепции Lightning Network, называется multi-hop payment. Кратко рассмотрим этапы, которые происходят при платеже через сторонний узел:

1. Кэрол: Формирование платежа секретного числа x и вычисление числа h = H(x), где H — это необратимая хеш-функция, то есть узнать число x, обладая числом h, нельзя.
2. Кэрол: Формирование инвойса, который содержит число h, а также дополнительную информацию о количестве передаваемых денег, адресе получателя и т. д.
3. Кэрол: Передача инвойса к отправителю платежа.
4. Алиса: Формирование обязательства об оплате в платежном канале с Бобом посредством использования htlc-смарт-контракта.
5. Повторение шага 4, до получателя.
6. Кэрол: Возврат числа x к Бобу, удаление обязательства и увеличение баланса Кэрол.
7. Повторение шага 6 до отправителя.

Пусть Алиса, Боб и Кэрол создали платежные каналы между собой (Рис. №1). Для проведения платежа от Алисы к Кэрол через Боба небезопасно использовать предыдущую технику, потому Боб может не передать деньги Кэрол. По этой причине используется обязательство передачи в виде htlc-смарт-контракта. Для того чтобы сформировать обязательство, Алисе необходимо число h, которое оно получает от Кэрол.

Рисунок №1: Передача числа h от Кэрол к Алисе

Получив число h от Кэрол, Алиса формирует отдельный htlc-сейф (7) для Боба, в который она кладет сумму платежа (Рис. №2). По сути, Алиса говорит: “Боб, я отдам тебе деньги только в том случае, если ты предоставишь мне доказательство, что ты передал деньги Кэрол”. Доказательством передачи платежа является число x, которое есть только у Кэрол.

Рисунок №2: Формирование обязательства заплатить Бобу, если он предоставит число x

Забрать деньги из htlc-сейфа (7) можно несколькими путями (Рис. №3):

1. Боб сможет получить деньги, если предоставит число x, хеш от которого равен h, которое есть только у Кэрол.
2. Алиса сможет получить деньги обратно по истечению некоторого времени, если Боб отказался проводить платеж.

Рисунок №3: Варианты траты htlc-сейфа

Для того, чтобы получить деньги от Алисы, Боб должен получить число x. Кэрол отдаст число x, если будет уверена, что Боб передал ей деньги. Для этого Боб формирует точно такое же обязательство с Кэрол об оплате, как Алиса сформировала для него (Рис. №4).

Рисунок №4: Формирование обязательства об оплате между Бобом и Кэрол

После того, как Боб сформировал обязательство и Кэрол увидела его, она отдает секретное число x (Рис. №4). Когда Боб получает секретное число, необходимости в обязательстве между Бобом и Кэрол больше нет, потому что Боб всегда сможет получить деньги от Алисы, если она вдруг закроет канал (это прописано в их транзакции-состояние, рис. №2,3), поэтому Боб и Кэрол удаляют обязательство, при этом увеличивая баланс Кэрол.

После того, как Боб и Кэрол удалили обязательство и обновили балансы, Боб передает число x Алисе (Рис №5). Она видит число x и понимает, что это число Боб мог получить только от Кэрол, поэтому они могут также убрать обязательство и обновить балансы. На этом процесс платежа закончен.

Рисунок №5: Удаление обязательства и увеличение баланса Кэрол

Дополнительные ситуации

Вопрос: Что, если Боб не передает платеж Кэрол, тем самым блокируя деньги Алисы?
Ответ: Алиса может послать последнюю транзакцию-состояние в сеть, и после того как транзакция будет обработана Алиса сможет забрать деньги из htlc-сейфа через некоторое время (Рис. №2).

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

Вопрос: Что если у Боба не хватает денег в платежном канале с Кэрол?
Ответ: Бобу сообщат о том, что в его канале недостаточно денег, и Алисе придется провести платеж через кого-нибудь другого.

Вопрос: Что если Алиса и Кэрол сговорились таким образом, что Алиса отправляет множество платежей через Боба, а Кэрол не отдает число x, тем самым делая транзакцию Боба невалидной по размеру?
Ответ: Эту проблему предлагается решать ограничением количества созданных htlc-сейфов для одного пользователя.

Заключение

Использовав htlc-смарт-контракт, создателям концепции удалось использовать промежуточные узлы для передачи платежей. Система смарт-контрактов и транзакции-состояния делает множество атак экономически невыгодными. В совокупности все это ведет к свойствам децентрализованности и открытости, описанным в первой статье.

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

• Как узлы находят друг друга и обмениваются информацией о топологии сети (discovery)?
• Как достигается анонимность (onion routing)?
• Как шифруется передача данных между узлами (brontide)?
• Как не скачивать весь блокчейн для полноценной работы узла (neutrino)?
• Какова структура инвойса (payment-encoding)?
• Как сжато хранить ключи для аннуляции состояния (shachain, elkrem)?
• Какие алгоритмы используются для поиска пути платежа (routing)?

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

Подписывайтесь на новости ForkLog в Telegram: ForkLog Live — вся лента новостей, ForkLog — самые важные новости и опросы.