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

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

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

Multi-hop-платеж

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

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

Допустим, что пользователи А, В и С открыли между собой платежные каналы для проведения операций. Чтобы осуществить передачу средств от пользователя А пользователю С через пользователя В использование предыдущей техники является небезопасным, поскольку пользователь В может отказаться передавать средства пользователю С. Исходя из этого необходимо применить обязательство для передачи средств, в виде которого выступит смарт-контракт htlc. Генерация обязательства производится посредством использования пользователем А значения h, полученного от пользователя С.

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

Сценарий изъятия средств из сейфа htlc может идти по нескольким схемам:

  1. пользователь В может получить свои средства при условии предоставления значения Х при том, что его хэш равен значению h, которым распоряжается пользователь С;
  2. пользователь А получает доступ к своим средствам по прошествии определенного периода времени при условии, что пользователь В не провел операцию.

Для возврата своих активов от пользователя А пользователю В должно быть предоставлено значение Х. Пользователем С будет передано данное значение пользователю В по факту передачи пользователем В средств. Для осуществления платежа пользователем В формируется аналогичное обязательство, как и в случае с пользователем С для оплаты, сформированное пользователем А для него.

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

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

Возможные сценарии

  1. если пользователем В не переданы средства пользователю С, что провоцирует блокировку активов пользователя А – пользователем А может быть отправлена последняя операция-состояние в сеть и после ее обработки средства будут доступны для изъятия из сейфа htlc;
  2. если передача числа Х от пользователя С пользователю В не состоялась – пользователем В может быть отправлена последняя операция-состояние в сеть и после ее обработки, а также по истечению установленного периода времени средства будут доступны к изъятию из сейфа для пользователя В. Если пользователь С опередит пользователя В и потратит активы, то пользователь В, находясь в рамках публичного блокчейна, сможет отследить эти действия. Имея в распоряжении число Х, пользователь В может как передать его пользователю А при условии наличия между участниками платежного канала, так и получить доступ к сейфу;
  3. если у пользователя В недостаточно активов в рамках платежного канала с пользователем С – система сообщит пользователю В о недостаточном количестве средств, а пользователь А будет вынужден воспользоваться услугами другого участника сети для проведения операции;
  4. если пользователь А и пользователь С вступили в сговор и придумали отправить большое количество операций через пользователя В при том, что ему не будет передано число Х пользователем С, что характеризует его операцию невалидной относительно размера – решение данной проблемы предлагается посредством выставления лимита на количество создаваемых сейфов htlc из расчета на каждого пользователя.

Выводы

Посредством использования смарт-контракта разработчики смогли применить узлы промежуточного типа для осуществления операций. Тандем операции-состояния и смарт-контрактов позволяет сделать большинство атак злоумышленников неэффективными и экономически невыгодными. При функционировании в системе Lightning Network это позволяет добиться действенного децентрализованного управления и прозрачности работы сети.

В завершение необходимо также отметить, что система смарт-контрактов сети Lightning Network представляет до 15% базы, на которой функционирует проект. Команда специалистов-разработчиков занимается решением множества технических вопросов, среди которых:

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

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

ОСТАВЬТЕ ОТЗЫВ

Please enter your comment!
Please enter your name here