Аннотация: В этой статье получатель гранта BitMEX Глеб Науменко рассказывает о подходах к уменьшению проблемы блокирования (jamming) платежных каналов в сети Lightning Network. Блокирование каналов происходит, когда злоумышленник блокирует ликвидность в сети Lightning Network, отправляя через сторонние каналы платеж самому себе, который он не собирается завершать. Глеб обсуждает потенциальные решения этой проблемы — как краткосрочные, так и долгосрочные (изменения протокола). В заключение он объясняет, что простого универсального решения не существует и что некоторые эффективные системы уменьшения этого явления могут оказаться труднореализуемыми. Поэтому долгосрочное решение этой проблемы требует обширных дополнительных исследований и обсуждений.
Введение
Поскольку Lightning Network (LN) — свободная система, не требующая разрешений (в ней нет центральной точки, которая может ограничить ее использование), она уязвима перед распределенными атаками отказа в обслуживании. Блокирование каналов — одна из разновидностей таких атак.
Защитить каналы от блокирования и при этом сохранить свободный характер LN — непростая задача. В этой статье мы вкратце рассмотрим предлагаемые решения этой проблемы на уровне проектирования сети.
Этот материал появился в результате разговора между группой разработчиков протоколов LN и биткоина, который состоялся осенью 2021 года. Он предназначен для тех, кому интересно узнать о проектировании протокола LN, а также для технически подкованных пользователей и адептов LN.
Что нужно знать о блокировании каналов
Lightning Network — это сеть узлов, которые помогают (обычно за некоторую плату) друг другу осуществлять платежи по платежным каналам: если между Алисой и Бобом нет прямого канала, они могут использовать для пересылки платежа расположенные между ними узлы маршрутизации, что сопровождается корректировкой балансов каналов на этом пути.
Важно, чтобы эти многоузловые платежи осуществлялись как единая неделимая операция, иначе существует риск присвоения средств узлами маршрутизации. Многоузловые платежи происходят в два этапа: блокировка средств на пути от отправителя к получателю и корректировка балансов в результате передачи секретного кода от получателя к отправителю.
Суть блокирования канала в следующем: злоумышленники используют пропускную способность узлов маршрутизации для пересылки поддельных платежей, которые не собираются завершать. На время атаки заблокированные узлы маршрутизации невозможно использовать для пересылки других (честных) платежей.
Чтобы заблокировать определенные каналы, злоумышленник якобы проводит платеж в свою пользу от третьих лиц и никогда не раскрывает секретный код со стороны получателя.
Существует два вида блокирования каналов:
- блокирование суммы: злоумышленник блокирует значительную часть пропускной способности целевого канала;
- блокирование слота: злоумышленник блокирует возможности переадресации целевого канала, так как передает максимально возможное количество платежей (мы объясним это более подробно в разделе «Базовые затраты»).
Больше информации о блокировании каналов можно найти по ссылке https://github.com/t-bast/lightning-docs/blob/master/spam-prevention.md. Чтобы понять нашу статью, необязательно полностью понимать все детали, описанные в статье выше.
Невозможность отмены платежа после истечения времени ожидания
Очевидным решением проблемы блокирования каналов является отмена пересылки платежа на узле маршрутизации после того как станет ясно, что время пересылки платежа превысило допустимое.
К сожалению, после пересылки платежа отменить его невозможно. Информация о сбое может быть передана только в ретроспективном порядке, от последующих узлов маршрута. Это основополагающий аспект протокола LN, который обеспечивает защиту средств узлов маршрутизации.
Как следствие, поскольку последний узел принадлежит злоумышленнику, он не будет передавать информацию о сбое до тех пор, пока не захочет завершить атаку.
В качестве альтернативы узлы маршрутизации могли бы изначально просто договориться о сокращении времени ожидания (тайм-аута) передачи средств. Но это тоже не работает: злоумышленнику просто придется повторять атаку чаще (повторно инициировать ложные платежи раз в минуту, а не раз в час).
Можно ли вообще считать блокирование средств атакой?
В стеке протокола LN прямо не указано, что блокирование средств в процессе их пересылки является нарушением, хотя в настоящее время так и есть, поскольку LN используется в основном для платежей с низкой задержкой.
Но в будущем это может измениться. Блокирование средств в процессе передачи может быть вполне оправданным, например, в контексте DLC в Lightning.
По моим наблюдениям, в сообществе пока нет консенсуса по поводу блокирования средств на протяжении значительного времени (не по поводу ошибочных платежей!), так как существует два мнения:
- Протокол должен бороться с платежами, осуществление которых занимает много времени.
- Протокол должен перейти к более гибкому подходу оплаты за ликвидность, который также будет учитывать время «зависания» средств в процессе передачи.
К счастью, похоже, что оба наиболее реалистичных долгосрочных решения (о которых пойдет речь ниже) в той или иной форме предполагают оплату (либо собственными токенами LN, либо токенами репутации), поэтому они более или менее соответствуют цели (2), т.к. незначительно изменяют протокол, или же просто являются средством достижения цели (1).
При этом не совсем понятно, как реализовать это в текущем протоколе: отправитель платежа может сделать вид, что платеж пройдет быстро, и система никак не сможет его наказать, если платеж будет идти дольше, чем ожидалось, или отменить платеж, осуществление которого превышает ожидаемое время.
Но если мы все же придумаем, как взимать плату за «зависшие» платежи, может оказаться, что отправителю имеет смысл открыть отдельный канал связи с получателем и платить комиссию за транзакции в блокчейне вместо того, чтобы платить за ликвидность. Даже если это приведет к тому, что меньше людей будут использовать функцию платы за резервирование ликвидности, возможно, нам придется реализовать эту функцию хотя бы только для изучения этого явления.
Базовые затраты
В настоящее время уже существует требование обязательства при блокировании средств: злоумышленник должен открыть канал LN, что означает резервирование некоторых средств в блокчейне (альтернативная стоимость) и оплату транзакционных сборов в блокчейне за открытие/закрытие канала.
Соотношение открытия/закрытия канала равно O(1), т.е. затраты одинаковы независимо от того, сколько средств и на какой срок собирается заблокировать злоумышленник, поэтому в случае серьезной атаки эти затраты могут быть для мошенников незначительными (если только атака не предполагает открытие большого количества каналов).
Но альтернативной стоимости может быть достаточно для защиты от блокирования платежей: чтобы заблокировать X сатоши, злоумышленнику придется зарезервировать X сатоши (образование замкнутых путей (looping) может оптимизировать атаку в ~20 раз).
В случае блокирования слотов затраты гораздо ниже. Один канал может одновременно пропустить не более 483 платежей (превышение этого значения небезопасно, поскольку транзакция, закрывающая канал, сможет вместить не более 483 входов).
Таким образом, злоумышленнику достаточно зарезервировать на канале 483 * минимальная сумма платежа в сатоши и заблокировать канал с любой суммой, превышающей 483 минимальных платежа (злоумышленнику также придется выделить несколько сатоши для оплаты маршрутизации, хотя платить их не придется, так как платеж не пройдет, но они должны быть на канале, чтобы узлы маршрутизации могли передавать платеж дальше).
Нерадикальные решения
Увеличение лимитов слотов (автор: @niftynei)
Как мы показали выше, альтернативная стоимость блокирования слота любого платежного канала в сети зависит от лимита слота, который определяется протоколом LN.
Но протокол можно изменить таким образом, чтобы разрешить проведение более 483 одновременных платежей по одному и тому же каналу. Это можно сделать следующим образом:
- изменив структуру транзакций LN в блокчейне (например, канал может закрываться двумя неконфликтующими транзакциями, а не одной, что позволит увеличить лимит вдвое), например, с помощью вложенности;
- изменив базовый уровень биткоина, добавив поддержку связанных с LN транзакций с более чем 483 входами.
Анализ и реализация этих решений требуют значительных усилий со стороны исследователей протокола, а линейное увеличение затрат на атаку может не оправдать такой объем работы.
Разделение лимитов слотов по категориям (автор: @niftynei)
Мы можем ввести два разных лимита/ограничивающих диапазона для многоузловых платежей в зависимости от их величины, т.е. для небольших и крупных платежей.
Лимит на уровне 483*многоузловых платежей на канал* лишен смысла, если платежи слишком маленькие, ведь их все равно нельзя получить в блокчейне (хотя они и разрешены спецификацией). При этом как раз благодаря использованию для одинакового лимита для мелких и крупных платежей блокирование слотов обходится злоумышленникам так дешево.
Таким образом, это ограничение можно наложить только на крупные платежи, а к мелким платежам применить другой лимит.
После этого изменения:
- Невозможно будет заблокировать возможности слота для пропуска крупных платежей, используя мелкие платежи.
- Заблокировать возможности слота для пропуска крупных платежей можно будет, только используя крупные платежи. Иначе говоря, чтобы деактивировать маршрутизацию крупных платежей, злоумышленник должен будет зарезервировать как минимум 483*минимальная сумма платежей, поэтому ему будет дешевле использовать блокирование суммы, а не слота.
- Заблокировать возможности слота для пропуска мелких платежей можно будет, только используя мелкие платежи (в соответствии с новым лимитом для мелких многоузловых платежей).
Таким образом, на практике эта мера ограничивает блокирование только слотов определенного размера.
Наложение ограничений пиром на предыдущем этапе передачи платежа
Еще одно решение проблемы — мониторинг входящих платежей и их ограничение на основе (прямого) пира, от которого они поступают.
Простой реализацией этой идеи является плагин для LND от joost под названием circuitbreaker(). Он действительно может защитить от незатратных и несложных атак, но едва ли способен на большее, т.к. из-за анонимности платежей трудно определить, от кого поступил блокирующий платеж.
Рассмотрим следующий пример.
Допустим, Дейв доверяет Кэрол, основываясь на ее хорошей репутации, поэтому не применяет дополнительный лимит.
Кэрол хочет защитить возможность пересылки платежей через Дэйва, поэтому накладывает ограничение 241 платеж на оба своих входящих канала от Алисы и Боба. Теперь Алиса не может предотвратить пересылку платежей, поступающих по каналу Боба, через Дэйва, и наоборот.
Эта логика распространяется на входящие каналы Боба, но теперь предположим, что Боб хочет открыть много каналов. Чтобы эти каналы не мешали друг другу и Бобу пересылать платежи Кэрол, платежи по ним не должны превышать общий лимит на уровне 241. Обратите внимание: если Боб откажется применить эти ограничения к входящим каналам, один из контрагентов Боба сможет без труда заблокировать канал между Бобом и Кэрол. При этом, несмотря на готовность Кэрол пересылать платежи, поступающие от Боба, она еще больше облегчила возможность DoS-атаки канала между собой и Бобом. Таким образом, это решение будет эффективным, только если его применит и Боб.
Теперь предположим, что лимиты не так уж малы и достаточны для клиентов Боба. В этом случае для блокирования канала между Бобом и Кэрол злоумышленнику придется создать много каналов связи с Бобом, чтобы занять пропускную способность канала (из общего лимита в 241) и уменьшить количество свободных слотов. Как следствие, у злоумышленников появляются новые возможности для еще более мощной DoS-атаки.
Конечно, Боб может скорректировать лимиты слотов на каналах злоумышленников, основываясь на их хорошем поведении (например, если они платят комиссию). Это не поможет, потому что теперь контрагенты Боба могут влиять на динамическую репутацию Боба в отношениях с Кэрол, и Боб не может им в этом помешать. Кроме того, Боб по-прежнему не может превысить общий лимит на уровне 241 платежа, действующий в отношении этих каналов.
В итоге становится очевидно, что эти ограничения эффективны только в том случае, если применяются всеми узлами в сети. При этом распространение ответственности на множество узлов далеко не оптимально.
Фундаментальные решения
Авансовые платежи (авторы: @joost и @t-bast)
Суть этого предложения заключается в том, чтобы взимать плату за все платежи (т.е. попытки осуществить платеж), а не только за успешные. Этого можно достичь, изменив протокол маршрутизации таким образом, чтобы узлы требовали от отправителей платежей предоплату в том или ином виде.
Привлекательность этого решения зависит от уровня незавершенных платежей в LN в целом, поскольку требование платить за незавершенные платежи может показаться пользователям противоречащим здравому смыслу и значительно ухудшить их впечатления от использования LN.
С одной стороны, возможно, для того чтобы этот план удался, процент незавершенных платежей в LN должен быть достаточно низким, чтобы привлечь пользователей беспроблемным исполнением и чрезвычайно низкой задержкой (ведь повторные попытки провести платеж занимают время). Поэтому имеет смысл учитывать это предположение при разработке протоколов.
Однако сохранить низкий процент незавершенных платежей довольно сложно, ведь сведения о балансах каналов не размещаются в открытом доступе. Решить эту проблему можно с помощью увеличения резервов и управления ликвидностью, что приведет к увеличению платы за маршрутизацию.
Это может привести к появлению более дешевых способов маршрутизации с более высоким процентом незавершенных платежей.
Кроме того, чтобы снизить вероятность сбоя на всех этапах маршрута пересылки платежей, нужно снизить вероятность сбоя на каждом этапе (уязвимость всего маршрута определяется уязвимостью его самого слабого компонента), что может быть невозможно для определенной последовательности каналов.
Недостатки:
– реализовать дорогостоящую маршрутизацию с низким уровнем сбоев (незавершенных платежей) может быть трудно;
– если маршрутизация остается малозатратной, но уровень сбоев при этом не низкий, предпочтительнее менее спорное основание для платы, чем трата сатоши на неуспешные платежи (особенно если платеж в итоге даже не был завершен);
– это может побудить узлы маршрутизации намеренно «проваливать» платеж и получать плату незаслуженно (неясно, как будет работать экономика маршрутизации в конечном итоге) или иным образом нарушать условия стимулирования (характер нарушения зависит от конкретного протокола).
Системы репутации для отправителей платежей
Вместо того чтобы перекладывать ответственность за поддержание устойчивости к DoS-атакам на предыдущий узел, узлы маршрутизации могли бы принимать решения, основываясь на репутации отправителя платежа. Эта мера кажется простой, если отправитель платежа известен, но в настоящее время конфиденциальность отправителей защищена т.н. «луковой маршрутизацией», и жертвовать этим неприемлемо.
Сертификаты стейка (авторы: @gleb и @ariard)
Сертификаты стейка (владения) позволяют использовать анонимные учетные данные, основанные на владении средствами в блокчейне. Иначе говоря, для использования ресурсов узла маршрутизации нужно доказать, что отправитель действительно зарезервировал достаточное количество сатоши в канале («достаточность» определяется узлом маршрутизации, например, для отправки 1000 платежей в час нужно зарезервировать 1 BTC).
В частности, узел маршрутизации может каждый раз требовать сертификат и отслеживать активность конкретного владельца сертификата.
Да, злоумышленнику нужно зарезервировать средства, иначе он не сможет даже инициировать платежи, но наличие сертификатов стейка также может:
– позволить узлам маршрутизации связывать платежи из одного источника и таким образом обнаруживать атаки (что также может привести к некоторой потере анонимности и цензуре);
– ограничить платежи из одного источника в зависимости от величины его сертификата.
Токены репутации (автор: @roasbeef)
Другой подход на основе репутации заключается в увеличении отдельными узлами маршрутизации пропускной способности отдельных отправителей в зависимости от их активности и репутации.
Например, узел маршрутизации может выдать специальные токены отправителю платежей, которые в дальнейшем можно использовать для «оплаты» частых платежей через этот узел маршрутизации.
Эти токены могут быть аннулированы выдавшим их узлом маршрутизации, если отправитель совершает слишком много неуспешных (незавершенных) платежей; если отправитель совершает много успешных платежей и платит комиссию, узел выдает ему токены репутации.
Синтез двух решений
Одна из проблем токенов репутации в том, что неясно, как их распределять на начальном этапе.
При этом недостатком сертификатов стейка является та же связь платежей с источником.
Объединение этих двух идей может решить обе этих проблемы. Последовательность может быть следующей:
- Отправитель платежа предъявляет сертификат стейка узлу маршрутизации и получает 10 токенов.
- Отправитель платежа использует токен для осуществления платежа.
2a) Если платеж прошел успешно, отправитель получает еще 1 токен.
2b) Если платеж не прошел, токен аннулируется.
Недостатки:
– сложность в реализации;
– для понимания проблем, которые могут возникнуть в связи со стимулами, могут потребоваться значительные исследования и эксперименты в реальном мире (например, появление вторичных рынков сертификатов и токенов).
Авансовые платежи или репутация отправителей платежей?
Наиболее перспективными решениями кажутся авансовые платежи и системы на основе репутации.
К счастью, нам не придется выбирать одно из двух: узлы маршрутизации могут указать, что хотят получить плату за маршрутизацию, в информации о своем канале (с помощью битовых флагов).
Сравнение показывает, что у этих решений много общего:
- сатоши, зарезервированные в канале при присоединении к сети, представляют собой долю владения (стейк) — как и токены, связанные с сертификатами;
- сатоши тратятся на авансовую оплату платежей — токены, связанные с сертификатом, также используются как комиссия за осуществление платежей.
Главный недостаток репутационных токенов в том, что для их создания требуется более сложный протокол, а для обеспечения их эффективности придется пожертвовать некоторой конфиденциальностью. За эту цену мы получаем потенциально более совместимый со стимулами протокол и несколько улучшенный пользовательский опыт, т.к. сертификаты/токены имеют меньшую ценность (или, по крайней мере, менее ликвидны), чем сатоши.
Заключение
Хотя полностью решить проблему блокирования каналов и при этом сохранить свободный (т.е. не требующий разрешений) характер LN, скорее всего, невозможно, атаки такого рода можно затруднить, и у нас есть идеи, как это сделать.
Нерадикальные решения могут быть реализованы в новых версиях LN или даже операторами узлов самостоятельно уже сегодня, но их эффективность ограничена. Долгосрочные фундаментальные решения требуют дополнительных исследований и более широкого обсуждения, прежде чем можно будет приступить к их реализации.
Надеемся, что эта статья поможет оптимизировать работу над этими идеями, внеся некоторую ясность на уровне проектирования.
Благодарность
Автор выражает благодарность Сергею Тихомирову, Лизе Нейгут, Антуану Риарду, Йосту Ягеру и Кларе Шихельман за рецензирование этой статьи, а также всем разработчикам протокола LN, которые поделились своими идеями и внесли вклад в решение проблемы блокирования каналов.