💬 Несколько способов улучшить маршрутизацию платежей Lightning Network

Несколько способов улучшить маршрутизацию платежей Lightning Network

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

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

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

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

Цепочки состояний

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

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

Сайдчейны

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

Совершенно новые конструкции

Вот моя собственная случайная идея: многие люди могут собраться вместе в единый мультиподписной адрес m-of-n (т. е. 3-из-5) с несколькими агентами условного депонирования и просто доверить агентам условного депонирования расчеты. вещи должным образом. Каждый человек в адресе и агенты условного депонирования могут отслеживать и обновлять «балансы» на основе маршрутизации платежей; записывать использованные HTLC и информацию о том, были ли они успешно урегулированы или возмещены; и периодически рассчитывайте остатки по цепочке. Вы просто конструируете мультиподпись так, чтобы один участник «маршрутизации» и все агенты условного депонирования — это все, что необходимо потратить с мультиподписи. Вы даже можете создать транзакцию возврата с временной блокировкой, чтобы вернуть деньги всем по истечении определенного периода, недостатком которой будет то, что все деньги, которые кто-либо заработал за время существования конструкции, будут потеряны, если они будут использованы. Это потребует расчетов в сети, прежде чем транзакция возврата станет действительной для траты.

Это потребует доверия к агентам условного депонирования, но преимущество будет заключаться в том, что любой человек в этой "группе UTXO" сможет перевести средства или направить HTLC любому другому лицу в группе UTXO. Это значительно повысит эффективность распределения ликвидности.

Кредитные отношения

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

Одна проблема и преимущества

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

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

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

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

Это гостевой пост Шиноби. Высказанные мнения являются полностью их собственными и не обязательно отражают точку зрения BTC Inc или Bitcoin Magazine.