Timeout Tree: решение для масштабирования поставщиков Lightning-услуг

Одним из самых больших ограничений, присущих сети Lightning, является ограниченное количество каналов на блок, которые можно открыть или закрыть, учитывая ограничение на размер блока. Независимо от того, сколько транзакций может происходить офчейн и насколько дешево, это проблемная область, ограничивающая количество людей, которые могут реально использовать сеть Lightning. Даже в white paper сети Lightning был сделан вывод о том, что в сценарии, когда все население мира в 7 миллиардов человек начнет использовать Lightning, имея возможность совершить только две внутрисетевые транзакции в год на человека, для работы Lightning потребуются Биткоин-блоки размером 133 МБ. Это не какая-то необычная или непредсказуемая проблема – это изначальное ограничение протокола.

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

Если я закрою свой канал внутри фабрики каналов, я заберу с собой кучу людей с фабрики. Представьте себе, что фабрика – это дерево Меркла: наверху есть один UTXO, который делится пополам вне цепочки, а еще делятся пополам и т. д., пока мы не доберемся до индивидуальных каналов каждого. Как только я вывожу свой канал из фабрики, все участники на моей стороне каждого сплита, который включается в цепочку, теперь отрезаны от всех остальных на фабрике. Они больше не смогут реорганизовать свою ликвидность в эту часть группы, если сотрудничество продолжится.

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

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

Timeout Trees

Недавнее предложение Джона Лоу, Timeout Trees, способно предложить решение одной из основных проблем фабрик каналов. Я бы не назвал Timeout Trees фабрикой каналов, скорее «протофабрикой», но оно может стать потенциальным решением проблемы открытия и закрытия огромного количества каналов без возникновения проблемы некоординированных закрытий, мешающих использованию фабрики другими пользователями. Для функциональной работы требуется CHECKTEMPLATEVERIFY (CTV) и поставщик услуг Lighting (LSP).

Timeout Tree – это, по сути, фабрика каналов, гарантированная соглашениями, без возможности изменить способ реорганизации ликвидности вне цепочки после ее создания, со специальной оговоркой об отказе. LSP, назовем его Бобом, играет роль моста случайных пользователей в более широкую сеть Lightning. Боб может взять монеты, которые он контролирует, и создать дерево CTV, которое создает единый UTXO, открывающий каналы для любого произвольного количества пользователей его сервиса LSP. Преимущество CTV в том, что оно позволяет делать это без одновременного подключения всех пользователей к сети. Боб может просто сделать так, что все подпишут исходное состояние канала по одному и удерживать участников до тех пор, пока все не настроят канал, и просто потратить средства на дерево CTV, когда каналы для каждого пользователя станут активны.

Это решает проблему необходимости одновременного подключения всех пользователей к сети, чтобы настроить «фабрику» и начать использовать Lightning. Используя CTV, как только Боб тратит монеты на дерево, настраивая все каналы Lightning, исчезает возможность отступить и забрать монеты (пока). После того как первый UTXO на CTV был подтвержден в сети, каждый может считать свои каналы открытыми, и нет риска их двойного расходования.

Теперь последняя часть, закрытие каналов. Несмотря на то, что, используя CTV, для их открытия требуется только один UTXO в цепочке, их закрытие все равно потребует развертывания всего дерева CTV в цепочке, чтобы каждый мог отправлять состояния своих каналов, верно? Нет. Это часть тайм-аута в Timeout Trees. В каждой ветке дерева тайм-аутов есть ветка со скриптом, в которой Боб может забрать все средства после блокировки по времени.

Теперь вы думаете: «Что?!» То, как работает это предложение, действительно гениально. Поскольку после блокировки по времени Боб может самостоятельно просматривать UTXO в цепочке, без кого-либо еще, у всех этих каналов есть дата истечения срока действия, если пользователи фактически не развернут все дерево и не подтвердят реальное финансирование канала ончейн. Это позволяет Бобу сделать следующее: когда приближается время блокировки, он может открыть новое Timeout Tree со всеми пользователями текущего, в которое они полностью переместят все свои средства, полностью офчейн на Lightning, а затем переместить единственный ончейн UTXO последнего дерева.

Это позволяет эффективно закрывать все эти каналы ончейн. Единственная проблема, которая осталась, – это обеспечение соблюдения HTLC ончейн, если другая сторона перестанет сотрудничать. Ну… в данном случае это не проблема, или, скорее, это вопрос «все или ничего». Причина, по которой каналы должны быть закрыты для обеспечения соблюдения HTLC, заключается в том, что другая сторона канала перестает отвечать в середине его маршрутизации. В дереве тайм-аутов двойником каждого отдельного пользователя является Боб. Таким образом, если Боб, если он честен, не отвечает на обновление неудачного или успешного HTLC для одного пользователя, он не отвечает и для любого другого пользователя. В этом случае каждый может закрыть свои каналы в цепочке до истечения времени ожидания и прекратить использование LSP Боба.

Подводя итоги

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

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

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