Компания Bitlum, которая занимается разработкой приложений поверх Lightning Network, специально для журнала ForkLog создала цикл статей о работе данной сети. В предыдущей статье были рассмотрены типы смарт-контрактов, которые необходимы для понимания концепции Lightning Network: 2×2 multisig, time-lock, htlc.
В четвертой статье будет объяснено понятие платежного канала и его применение для быстрого обмена биткоинами.
Весь цикл статей состоит из следующих частей:
- Lightning Network Часть №1: Введение: описание предпосылок создания концепции Lightning Network, сравнительный анализ с другими платежными системами.
- Lightning Network Часть №2: Области применения: поверхностное описание технологии и примеры использования в различных областях.
- Lightning Network Часть №3: Смарт-контракты: объяснение основных блоков, необходимых для углубления в техническое описание концепции.
- Lightning Network Часть №4: платежный канал: объяснение понятия платежного канала и его применения для быстрого обмена биткоинами.
- Lightning Network Часть №5: решение проблемы масштабирования. Объяснение использования платежных каналов для построения платежной сети и решения проблемы масштабирования.
В данной статье будет дано полноценное определение платежному каналу, объяснено эволюционное развитие смарт-контрактов, которые лежат в его основе.
Рисунок №1: Описание обозначений, используемых в диаграммах
Существует три процесса, которые связаны с работой платежного канала:
Открытие и закрытие канала
Для того чтобы открыть канал, Алиса и Боб должны:
Рисунок №2: Создание общего сейфа, посредством использования multisig смарт-контракта
Назовем транзакцию, которая тратит деньги из общего сейфа, транзакцией-состоянием. С помощью этой транзакции и Алиса, и Боб могут вернуть свои деньги из общего сейфа. В некотором смысле транзакция-состояние — это договор между двумя участниками, который они в любой момент могут исполнить посредством отправки его в сеть майнеров.
Рисунок №3: Формирование первоначальной транзакции-состояния
Отправка транзакции-состояния в сеть и разделение денег из общего сейфа эквивалентно закрытию канала. В данном случае если мы сделаем это, то мы разделим деньги из общего сейфа в изначальной пропорции.
Рисунок №4: Закрытие канала посредством отправки транзакции-состояния в сеть майнеров
Как упоминалось ранее, в транзакции-состояния хранятся смарт-контракты для каждого из сейфов, в которых прописан принцип их дальнейшего открытия. В данном случае сейф под номером три сможет открыть Алиса, под номером четыре — Боб.
Рисунок №5: Вариант траты сейфа Алисы и Боба, прописанные в смарт-контракте транзакции-состояния
Важно отметить, что вследствие того, что мы используем общий сейф (multisig), то для формирования новой транзакции-состояния требуется электронные подписи обеих сторон, поэтому ни одна из сторон не может сформировать новое состояние без ведома другой стороны.
Процесс формирования общего сейфа и первоначальной транзакции-состояния занимает как минимум 10 минут и называется открытием канала. Отправка транзакции-состояния в сеть и разделение денег в обозначенной пропорции называется закрытием канала и занимает так же 10 минут. Рассмотрим, как подобная структура позволяет делать платежи без использованию блокчейна.
Использование канала
Определим оплату как процесс аннулирования старой транзакции-состояния и создание новой, в которой из общего сейфа одному из участников достанется большее, по сравнению с предыдущим состоянием, количество денег.
Рисунок №6: Проведение платежа от Алисы к Бобу на сумму 1.33 BTC посредством изменения транзакции-состояния
Процесс перехода от старого состояния к новому занимает доли секунды, так как это не требует записи в блокчейне и ограничено только скоростью интернет-соединения между узлами. Именно за счет этого достигается скорость в концепции Lightning Network.
Минусом такой концепции является то, что максимальное количество, которое может быть передано другой стороне, не может превышать количества денег, заблокированных в общем сейфе. Данное ограничение может быть частично снижено посредством увеличением сейфа и ребалансировкой каналов.
После того как взаимодействие между участниками закончено, они отсылают конечную транзакцию-состояние в сеть и закрывают канал, тем самым получив деньги обратно, но уже в другой пропорции.
Пример: Допустим вы хотите продать 10 BTC на бирже, но есть некоторые требования:
Для этого необходимо создать канал с биржей, в который со своей стороны вы вкладываете 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 для проведение платежей через несколько каналов.
Источник: forklog.com
