Lightning Network (LN), вероятно, одно из самых ожидаемых нововведений для биткойн-блокчейна. Идея, впервые предложенная Джозефом Пуном (Joseph Poon) и Таджем Дрийа (Tadge Dryja) около двух лет назад. Lightning Network обещает поддержку неограниченного количества транзакций между пользователями, выполняемых в сети платежных каналов, развернутой поверх блокчейна. При этом система наследует надежность биткойн-блокчейна.

Над реализацией LN-протокола работают сразу несколько компаний, среди которых Lightning Labs, Blockstream, ACINQ, а также Bitfury. Эта технология позволит производить микроплатежи с использованием биткойнов, что существенно расширит возможности и сферу применимости криптовалюты. В этом материале мы поговорим, на чем строится концепция Lightning Network и как работает эта сеть.

/ изображение Iraia Mart'inez CC

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

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

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


Высокоуровневая схема сети Lightning

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

Установление двунаправленного канала

Чтобы настроить двунаправленный платежный канал, два участника определяют фундирующую транзакцию — то есть депонируют некоторое количество средств на один 2-of-2 multisig адрес. Биткойны на этом адресе могут быть потрачены (отправлены на другие биткойн адреса) только в том случае, если транзакцию подпишут оба создателя канала (будем называть их Алиса и Боб) своими приватными ключами. Каждый участник платежного канала имеет ровно один приватный ключ. Кроме того, участники генерируют секреты — случайные последовательности битов — и обмениваются их хешами.

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

Также биткойны по этому адресу могут быть разблокированы Алисой, но только если она приложит секрет, хеш которого ей переслал Боб в момент установления канала (она не знает секрет, поэтому не может разблокировать биткойны незамедлительно). Затем Алиса подписывает транзакцию обязательство, но отправляет её не в блокчейн, а напрямую к Бобу. Эта транзакция позволит Бобу в любой момент закрыть канал путем ее публикации в блокчейн, что приведет к тому что Алиса получит свои деньги моментально, а Боб сможет забрать свои биткойны с задержкой в 1 тыс. блоков. В свою очередь Боб создает такую же, но симметричную транзакцию, затем подписывает её и отправляет Алисе.

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

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

Если Алиса и Боб захотят закрыть канал по обоюдному согласию, они могут просто создать транзакцию, переопределяющую все, что произошло после открывающей транзакции. После её подписания и отправки канал считается закрытым. Таким образом, в биткойн-сеть передадутся лишь открывающая и закрывающая транзакции, даже если между ними Алиса и Боб совершили миллионы платежей друг другу. Именно эта особенность и позволяет значительно разгрузить блокчейн.

Работа в сети и трехсторонний обмен

Если кто-то из участников двустороннего канала захочет передать биткойны третьей стороне, он сможет использовать своего «партнера» в качестве гаранта сделки (в том случае, если у последнего уже установлен платежный канал с третьей стороной). Допустим, Алиса хочет переслать один биткойн третьему участнику, скажем Карлосу. Она может отправить этот биткойн Бобу, после чего Боб отправит его Карлосу как посредник.

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

В этом сценарии посредник (Боб) не должен доверять Карлосу и Алисе. Для обеспечения его безопасности используются так называемые контракты с хешированием и временной блокировкой (HTLC). При создании HTLC в канале Алиса-Боб, биткойны отправляются на новый адрес с мультиподписью, разблокировать который можно двумя способами: либо Боб указывает адрес и секрет, или Алиса указывает только подпись — однако в последнем случае сработает CLTV-блокировка: Алиса сможет отправить транзакцию в сеть только по прошествии определенного (длительного) времени. За это время Боб должен успеть создать транзакцию с подписью и значением, чтобы получить заблокированные средства. Таким образом, как только Боб отдает средства Карлосу, он узнает секрет, а значит гарантированно сможет забрать свои деньги из канала с Алисой. Эта идея обобщается на число посредников больше одного.

Маршрутизация в Lightning Network

Технология Lightning Network считается одним из лучших решений для увеличения пропускной способности биткойн-сети, предлагая, как уже было отмечено, способ выполнения большинства транзакций вне блокчейна. Одной из определяющих особенностей LN является способность отправлять платежи любому участнику сети через цепочку платежных каналов между пользователями. Благодаря этому, участники сети могут не создавать новые платежные каналы каждый раз, когда нужно провести транзакцию с участником сети, с которым отсутсвует платежный канал. Однако построение маршрута платежных каналов от получателя к отправителю является достаточно сложной задачей — необходимо выделить оптимальный путь (по разным критериям, например, по времени или издержкам), который бы позволил «провести» биткойны от отправителя к получателю.

Биткойн-сообщество предлагало несколько алгоритмов маршрутизации для LN. Одним из самых первых решений стало предложение разделить узлы на два класса: узлы-кошельки и узлы маршрутизации (хабы), получающие вознаграждение за свои услуги. Первые могли только совершать платежи, а вторые — их перенаправлять. Эта схема показала себя достаточно эффективной, поскольку знание всех хабов позволяет точно выстроить маршрут к любому узлу. В то же время такой подход наносил ущерб концепции децентрализации — одному из принципов биткойн-сети.

Поэтому была предложена другая идея. Несколько узлов ежедневно и случайным образом получали статус «маяков». Все узлы пытались проложить маршруты к этим маякам и использовать выстроенные «дорожки» для отправки платежей. Эта схема оказалась более децентрализованной, чем предыдущая, однако открытой для проведения атак Сибиллы (поскольку находиться в статусе маяка выгодно для узла). Более того, большинство из простроенных маршрутов становились бесполезными после смены кластера маяков.

Поэтому компанией Bitfury был предложен новый (гибридный) вариант алгоритма маршрутизации, получивший название Flare. Алгоритм состоит из двух этапов. Первый — это проактивное обновление схемы подмножества существующих каналов, в которой хранится информация об общей топологии сети. Второй этап — реактивное построение маршрута на основании запроса о поиске пути к конкретному получателю, а также сбор динамической информации о LN-сети — размер комиссий, надежность узлов, время задержек и т. д.


Схема алгоритма маршрутизации Flare

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

Каждый узел обновляет свою информацию о сети, регулярно заполняя таблицу маршрутизации. Когда узел решает отправить биткойны с помощью LN, он просматривает собственную таблицу маршрутизации и таблицы ближайших соседей, находящихся ближе всего к получателю в адресном пространстве, чтобы найти вероятные маршруты в сети. Таблица определяет подсистему открытых каналов и помогает найти получателя средств (или, если найти его не удалось, определяет те маяки, которые могут в этом «помочь»).

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

Использовав эту спецификацию, команде исследователей из ACINQ удалось реализовать и проверить алгоритм на 2,5 тыс. узлах AWS. Правда, часть, которая была протестирована, являлась лишь первым из двух этапов маршрутизации Lightning. Однако по результатам тестирования удалось установить, что алгоритм Flare способен определить путь платежа за 5 секунд с вероятностью его реализации в 80%. И это уже очень хороший шаг к коммерческой реализации сети Lightning.

https://habrahabr.ru/post/331268/