Экспертная оценка уязвимости в Lightning Network

Много шума было поднято вокруг уязвимости Lightning, недавно раскрытой Антуаном Риаром. Многие люди утверждают, что это конец, что Lightning в корне «сломлена», но это далеко от истины. Я думаю, что отчасти проблема состоит в том, что люди, во-первых, не понимают, как работает эта уязвимость, а во-вторых, не понимают, как эта отдельная уязвимость переплетается с другими известными проблемами в сети Lightning, имеющими решения.

Итак, для начала давайте разберемся и попытаемся понять саму уязвимость. Когда платеж Lightning маршрутизируется по сети, важно знать, как работают временные блокировки для возврата средств за неудавшийся платеж. Узел, ближайший к получателю, имеет временную блокировку «x», а каждый переход, возвращающийся к отправителю, имеет один из «x+1», «x+2» и т. д. Временные блокировки становятся все длиннее по мере того, как вы проходите каждый узел от получателя обратно к отправителю. Причина этого в том, что если платеж достигает получателя, но какая-то проблема мешает распространению прообраза обратно к отправителю, узел, на котором он остановился, имеет время применить его в цепочке и поместить туда прообраз, который необходим всем предыдущим узлам для подтверждения платежа. В противном случае кто-то посередине, где происходит сбой, может потребовать, чтобы их исходящий узел запросил средства с помощью прообраза, а узел, который переслал им их, запросил их с помощью своего пути возврата, оставив этого человека, которому не повезло, с потерянными средствами.

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

Атака требует очень целенаправленных и сложных действий по манипулированию мемпулом жертвы. Давайте посмотрим на фактическую структуру транзакции, задействованную здесь. У вас есть основная транзакция, представляющая состояние канала Lightning. Она имеет выходные данные для каждой стороны канала, представляющие средства, полностью находящиеся под контролем того или иного участника, а также выходные данные для каждого HTLC, находящегося в процессе маршрутизации. Именно эти результаты нас и интересуют. Каждый вывод HTLC можно потратить либо сразу в любой момент вместе с прообразом от приёмника, либо после истечения таймлока на возврат.

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

Злоумышленники направляют платеж через Боба, и тогда Элис откажется отправить Бобу прообраз для завершения платежа, когда она его получит. Теперь Боб будет ждать, пока истечет время временной блокировки между ним и Элис, и перейдет к трансляции транзакции фиксации канала и транзакции возврата, чтобы получить ее подтверждение до истечения срока временной блокировки. Затем Элис потратит транзакцию прообраза, чтобы потребовать средства с выходом, не связанным с каналом, и сразу после этого дважды потратит второй вход в успешной транзакции прообраза. Цель здесь – исключить транзакцию тайм-аута Боба из мемпула, а также исключить успешную транзакцию прообраза, чтобы Боб ее не увидел. Если он это сделает, он узнает прообраз и сможет просто потребовать средства в своем канале с Кэрол до того, как ее транзакция по тайм-ауту станет действительной для расходования.

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

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

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

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

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

Время идет, мы сталкиваемся с проблемами, и мы будем решать эти проблемы по мере их поступления. Как и всегда.