Lightning Network Часть №4: Платёжный канал

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

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

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

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

Рисунок №1: Описание обозначений, используемых в диаграммах.

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

1. Открытие канала: процесс регистрации платежного канала в блокчейне, а также формирование первоначального состояния.
2. Использование канала: процесс использования системы смарт-контрактов для проведения платежей вне блокчейна (off-chain).
3. Закрытие канала: процесс регистрации конечного состояния балансов пользователей в блокчейне.

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

Для того чтобы открыть канал, Алиса и Боб должны:

1. Заблокировать свои деньги в общем сейфе (multisig) посредством создания и отправки в сеть фондирующей транзакции (funding transaction).
2. Сформировать транзакцию (commitment transaction), которая отражает текущее состояние и распределяет деньги из общего сейфа в изначальной пропорции.
3. Сохранить сформированную транзакцию на обеих сторонах, и не отправлять эту транзакцию в сеть на обработку майнерам.

Рисунок №2: Создание общего сейфа, посредством использования multisig смарт-контракта

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

Рисунок №3: Формирование первоначальной транзакции-состояния

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

Рисунок №4: Закрытие канала посредством отправки транзакции-состояния в сеть майнеров

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

Рисунок №5: Вариант траты сейфа Алисы и Боба, прописанные в смарт-контракте транзакции-состояния

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

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

Использование канала

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

Рисунок №6: Проведение платежа от Алисы к Бобу на сумму 1.33 BTC посредством изменения транзакции-состояния

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

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

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

Пример: Допустим вы хотите продать 10 BTC на бирже, но есть следующие требования:

1. Вы не хотите хранить деньги на бирже.
2. Вы хотите, чтобы, когда пришел час X, вы могли быстро передать деньги на биржу и произвести обмен.

Для этого необходимо создать канал с биржей, в который со своей стороны вы вкладываете 10 BTC. Так как у вас есть первоначальная транзакция-состояние, то вы можете не беспокоиться о своих деньгах, так как вы сможете их забрать. Когда приходит время продажи, вы производите изменение состояния и назначаете бирже 1 BTC. Со своей стороны биржа видит, что в новом состоянии у нее есть 1 BTC, теперь она может дать вам право на покупку другого ассета. После того как вы произвели достаточное количество операций на бирже, вы закрываете канал и из общего сейфа бирже достается то количество денег, которые вы перевели.

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

Аннулирование состояния

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

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

Изменение №1: сделаем так, что новый сейф Алисы (3) сможет открыть и Боб. Для открытия сейфа Алисы, Боб должен будет предоставить свою электронную подпись, а также дополнительный ключ, которым первоначально владеет только Алиса. То же самое сделаем и с сейфом Боба. При переходе на новое состояние Алиса и Боб обязаны обменяться ключами, тем самым аннулировав предыдущее состояние.

Рисунок №7: Дополненная схема траты сейфов Алисы и Боба

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

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

Рисунок №8: Хранения различных транзакции-состояния на стороне Алисы и Боба

Если Алиса отправит свою старую транзакцию-состояния, то Боб сможет забрать как свои, так и ее деньги, так как Алиса отдала ключ аннуляции, то же самое верно и для Боба. При такой конфигурации ни одна из сторон не имеет мотивации отправлять свое старое состояние в сеть.

Изменение №3: по-прежнему осталась одна проблема: одна из сторон может воспользоваться тем, что другая сторона находится в офлайне и послать старое состояние, забрав деньги первее. Поэтому необходимо ввести time-lock механизм.

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

Рисунок №9: Транзакция-состояние с механизмом time-lock

Кооперативное закрытие

Проблема: изменения, которые мы сделали в транзакции-состоянии привели к новой проблеме: если Алиса и Боб захотят закрыть канал кооперативно, то никто из них не будет иметь мотивации сделать это первым, потому что в этом случае он не сможет забрать деньги сразу из-за наличия time-lock механизма.

Решение: разделим процесс закрытия на два типа: вынужденный и кооперативный.

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

Все механизмы, которые мы добавили для безопасного аннулирования, нужны только при переходе на новое состояние. В случае кооперативного закрытия платежного канала, стороны могут сгенерировать новое состояние, которое отражает те же самые балансы, но не содержат механизмов аннулирования. Полученная кооперативная транзакция-состояние будет эквивалентна первоначальной версии (Рис. №5). Вышеописанный процесс называется кооперативным закрытием (cooperative close).

Если же одна из сторон ушла в офлайн и возможности кооперативно закрыть канал нет, то другая сторона по-прежнему может получить свои деньги посредством отправки последней транзакции-состояния, но в этом случае деньги она получит по истечению time-lock периода. Отправка последней транзакции-состояния в сеть называется вынужденным закрытием (force close).

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