Одним из самых больших ограничений, присущих сети Lightning Network, является ограниченное количество каналов, которые можно открыть или закрыть на блок, учитывая ограничение на размер блока. Независимо от того, сколько транзакций может происходить вне цепочки и насколько дешево, это фундаментальное узкое место, ограничивающее количество людей, которые могут реально использовать сеть Lightning. Даже в официальном документе Lightning Network был сделан вывод о том, что в сценарии, когда все население мира в 7 миллиардов человек использует Lightning, имея только две внутрисетевые транзакции в год на человека, Биткойну потребуется 133 МБ блоков для работы Lightning. Это не какая-то необычная или непредсказуемая проблема, это было ограничение конструкции протокола, полностью понятное с первого дня.
Частью плана по решению этой проблемы всегда была идея фабрик каналов, то есть типа канала, в котором участвовали более двух пользователей. Это всегда было то направление, в котором нужно было двигаться, чтобы масштабировать Lightning и Биткойн без размера блока. увеличивается, но проблема в том, что решение проблемы следов в цепочке порождает целый ряд других проблем. Прежде всего, ничего фундаментального не меняется в требовании обеспечить соблюдение промежуточных положений, если контрагент перестанет отвечать. Это влияет на добавленную стоимость. Вся суть фабрики каналов в том, что, например, двадцать человек могут разделить один UTXO и перераспределять ликвидность внутри с другими двадцатью людьми, как они захотят. Как только кто-то закрывает сеть без сотрудничества, это начинает мешать достижению этой цели.
Если я закрою свой канал внутри фабрики каналов, я утащу за собой кучу людей с фабрики. Представьте себе фабрику как дерево Меркла: наверху есть один UTXO, который делится пополам вне цепочки, а остальные делятся пополам и т. д., пока мы не доберемся до индивидуальных каналов каждого. Как только я вывожу свой канал из фабрики, все на моей стороне каждого сплита, который включается в цепочку, теперь отрезаны от всех остальных на фабрике. Они больше не смогут реорганизовать свою ликвидность в эту часть группы, если все будут сотрудничать.
Еще одна большая проблема заключается в том, что даже для того, чтобы запустить его, вам нужно, чтобы все были онлайн в начале, чтобы предварительно подписать все транзакции. Если вы хотите, чтобы на фабрике работало двадцать человек, каждый должен быть онлайн, чтобы запустить ее. Если вам нужна тысяча человек, тысяча человек должна быть онлайн и т. д.
Это превращает фабрики каналов в большое пространство для проектирования, полное множества проблем, которые необходимо решить. Итак, мы решаем существующую проблему для Lightning, но создаем кучу новых. Для меня это звучит как инженерия.
Деревья тайм-аутов
Недавнее предложение Джона Лоу, Timeout Trees, пытается предложить решение одной из основных проблем фабрик каналов. Я бы не назвал дерево тайм-аутов фабрикой каналов, скорее «протофабрикой», но оно предлагает потенциальное решение проблемы открытия и закрытия огромного количества каналов без возникновения проблемы несовместных закрытий, разрушающих использование фабрики другими пользователями. Для функциональной работы требуется CHECKTEMPLATEVERIFY (CTV) и поставщик услуг освещения (LSP).
Дерево тайм-аутов — это, по сути, фабрика каналов, гарантированная ковенантами, без возможности изменить способ реорганизации ликвидности вне цепочки после ее создания, со специальной оговоркой об отказе. LSP, мы назовем его Бобом, играет роль моста случайных пользователей в более широкую сеть Lightning. Боб может взять монеты, которые он контролирует, и создать дерево CTV, которое создаст единый UTXO, открывающий каналы для любого произвольного количества пользователей его сервиса LSP. Преимущество CTV в том, что оно позволяет делать это без одновременного подключения всех пользователей к сети. Боб может просто заставить всех подписать исходное состояние канала по одному и удерживать их, пока все не настроят канал, и просто тратить средства на дерево CTV, когда у него будут настроены каналы для каждого пользователя.
Это решает проблему необходимости одновременного подключения всех пользователей к сети, чтобы настроить «фабрику» и начать использовать Lightning. Из-за CTV, как только Боб тратит монеты на дерево, настраивая все каналы Lightning, у него нет возможности отступить и забрать монеты (пока). После того, как первый UTXO на CTV был подтвержден в сети, каждый может считать свои каналы открытыми, и нет риска их двойного расходования.
Теперь последняя часть, закрытие каналов. Несмотря на то, что для их открытия требуется только один UTXO в цепочке из-за CTV, их закрытие все равно потребует развертывания всего дерева CTV в цепочке, чтобы каждый мог отправлять состояния своих каналов, верно? Неправильный. Это часть Timeout Trees. В каждой ветке дерева тайм-аутов есть ветвь сценария, в которой Боб может забрать все средства после блокировки по времени.
Теперь я уверен, что вы думаете: «Что!?» Это настоящая гениальность того, как работает это предложение. Поскольку после блокировки по времени Боб может самостоятельно просматривать UTXO в цепочке, без кого-либо еще, у всех этих каналов есть дата истечения срока действия, если пользователи фактически не развернут все дерево и не подтвердят реальное финансирование канала в цепочке. Это позволяет Бобу сделать кое-что изящное: когда приближается этот временной замок, он может открыть новое дерево тайм-аутов со всеми пользователями текущего и полностью переместить все свои средства из дерева с истекающим сроком действия в новое. -цепочка на Lightning, а затем очистите одиночный UTXO в цепочке последнего дерева.
Это позволяет эффективно закрывать все эти каналы в цепочке. Единственная проблема, которая осталась сейчас, — это обеспечение соблюдения HTLC в цепочке, если другая сторона перестанет сотрудничать. Ну… в данном случае это не проблема, или, скорее, это вопрос «все или ничего». Причина, по которой каналы должны быть закрыты для обеспечения соблюдения HTLC, заключается в том, что другая сторона канала перестает отвечать в середине его маршрутизации. В дереве тайм-аутов двойником каждого отдельного пользователя является Боб. Таким образом, если Боб, если он честен, не отвечает на обновление неудачного или успешного HTLC для одного пользователя, он не отвечает и для любого другого пользователя. В этом случае каждый может закрыть свои каналы в цепочке до истечения времени ожидания и прекратить использование LSP Боба.
Подведение итогов
Пользователям по-прежнему придется платить комиссию за взаимодействие внутри цепочки, обойти это невозможно, и закрытие всего дерева тайм-аутов в цепочке без сотрудничества будет большим и дорогостоящим воздействием в цепочке, но в конечном итоге это проблема. любая многопартийная канальная система должна будет решить эту проблему. Однако у деревьев таймаутов есть убедительные решения для совместного открытия и закрытия огромного многостороннего канала без ухудшения модели доверия системы до чего-то кастодиального.
Джон даже в своей последней версии статьи предложил схему, в которой пользователи могут быть наказаны за некооперативные замыкания, достаточные для того, чтобы покрыть затраты Боба, которые в конечном итоге очистят кучу фрагментированных древовидных UTXO после тайм-аута. Потенциально существуют способы сделать обратное, если бездействие или нечестность Боба являются причиной того, что пользователям приходится закрывать свою часть дерева без сотрудничества.
В конце концов, это очень конкретное и конкретное предложение по проекту фабрики каналов, которое на самом деле пытается решить реальные проблемы использования и реализации, а не полуопределенную и расплывчатую концепцию. Это огромный прогресс с точки зрения устранения долгосрочных ограничений масштабирования Lightning.
