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

Платежный канал через посредника​

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

Но как убедиться, что Витя, получив деньги, действительно передаст их дальше Бобу?

На самом деле идея немного похожа на предыдущий трюк, только вместо одноразовых ключей используется некоторое секретное число.
  1. Боб генерирует секретное число S, хэш от этого секретного ключа HS и передает эту информацию Алисе. HS при этом может использоваться как виртуальный чек.
  2. Алиса создает транзакцию AV, которая передает деньги Вите, но только в случае, если Витя предоставит секретное число S. Для этого она использует скрипт, который проверяет равенство хэша предоставленного числа и значения HS (тут как раз и используются операции OP_SHA256 и OP_EqualVerify).
  3. Витя создает аналогичную транзакцию VB, которая передает деньги Бобу, но только в случае, если Боб предоставит секретное число.
  4. Боб видит, что он может получить деньги от Вити, и показывает ему секретное число S.
  5. Витя теперь может доказать, что он передал деньги Бобу, и соответственно он может обналичить транзакцию AV.
Тут есть несколько вариантов развития событий.
  1. Во-первых, Вите не имеет смысла обманывать Алису. Он не может не передать деньги Бобу, потому что иначе Витя все равно не получит деньги от Алисы.
  2. Но Боб может решит обмануть Витю и не передать ему секретное число. При этом он может закрыть канал с Витей и записать транзакцию VB в блокчейн. Но для вывода денег ему все равно придется показать свое секретное число, и тут-то Витя его и узнает.
Тут есть пара нетривиальных нюансов с тем, как выбрать время, в течении которого Алиса, Боб и Витя могут разрешить конфликты. Но эти более технические подробности выходят за рамки этой вводной статьи. Если интересно — гуглите Hash Time-Locked Contracts (HTLCs).

Маршрутизация​

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

Экономика комиссий​

Остается два очевидных вопроса.

Вопрос номер 1: зачем посредникам обрабатывать чужие платежи?

Во-первых, потому что им самим так проще пользоваться LN. Во-вторых, потому что они получают с этого очень маленькую, но все-таки комиссию.

На данный момент сеть поддерживают в основном энтузиасты и комиссия практически нулевая: 1 сатоши, или ~0.01 цента за каждого посредника.

Вопрос номер 2: а как же комиссия за открытие/закрытие канала?

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

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

Пример: я открываю канал, зачисляю туда 1000 долларов, и использую канал только для исходящих платежей. Оборот в канале составит 1000 долларов, примерно 20 долларов уйдет на открытие и закрытие канала. То есть суммарно комиссии составят 2%. Немного лучше, чем виза и мастеркард, но явно больше, чем хотелось бы.

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