By Bitcoin Журнал - 1 год назад - Время чтения: 7 минуты
Несколько способов улучшить маршрутизацию платежей Lightning Network
Чтобы превратиться в протокол, пригодный для использования во всем мире, необходимо рассмотреть некоторые улучшения масштабирования для Lightning.
Lightning Network — это хорошо разработанное, быстрорастущее решение для транзакций 2-го уровня на Bitcoin сеть. Все больше и больше сервисов и бирж интегрируют его, ликвидность, доступная для маршрутизации платежей, растет, и с каждым годом разрабатывается все больше приложений и способов взаимодействия пользователей с ним. У него также есть много проблем, которые необходимо преодолеть в долгосрочной перспективе:
Масштабируемость ограничивает количество каналов, которые могут быть открыты или закрыты в цепочке одновременно. Проблема с минимальным размером Контракт с блокировкой времени хеширования (HTLC) увеличивается, так как комиссионные сборы также увеличиваются, потому что расчеты должны быть экономичными. Существует также множество проблем с конфиденциальностью.Одним из основных вопросов, который часто обсуждается, являются требования к ликвидности для маршрутизации платежей. Чтобы успешно направить платеж, должна быть связь каналов от отправителя до получателя, которая имеет достаточную ликвидность на правой стороне канала, чтобы иметь возможность передать платеж. Это делает решение о том, где разместить ваши монеты в сети, очень важным. Это также означает, что общий объем ликвидности, который люди готовы использовать, является своего рода верхним пределом того, сколько ценности может обрабатывать сеть.
В конечном счете, это сводится к тому, что когда вы открываете канал, вы решаете заблокировать эти деньги, чтобы их можно было использовать только для маршрутизации платежей этому партнеру по каналу и тому, к кому они подключены на графике. Да, в конечном счете, идея Lightning Network заключается в том, что, сделав достаточное количество переходов, вы можете найти соединение практически с любым местом. Однако реальность такова, что если кто-то еще может выполнить маршрутизацию платежа к месту назначения с использованием меньшего количества переходов, чем вы, скорее всего, для маршрутизации платежа будет выбран именно этот путь. Lightning уже в значительной степени требует избыточного обеспечения, т. е. для маршрутизации платежа в 1 BTC через 10 прыжков требуется 10 BTC залога, которые должны быть заблокированы в платежных каналах на этом маршруте. Конкуренция за наличие хороших соединений для получения дохода от маршрутизации усугубляет ситуацию, стимулируя еще более избыточное обеспечение.
Это проблема, возникающая из-за того, что каналы Lightning являются двусторонними «трубками», которые могут просто перемещать ценность туда и обратно в этих двух направлениях. Но вот в чем дело: проблема является своего рода воображаемой. Платежи по Lightning используют HTLC, скрипт в Bitcoin вывод, в котором говорится, что один человек может потребовать вывод и потратить его, открыв прообраз хэшу, или другой человек может потребовать вывод и потратить его, дождавшись истечения временной блокировки. Это общий сценарий, который можно применять внутри сети, в каналах Lightning, поверх цепочек состояний, на сайдчейнах и т. д. Теоретически, если вы можете использовать HTLC, все может участвовать в маршрутизации платежа Lightning.
Цепочки состояний
A цепочка состояний фактически является чем-то вроде канала Lightning, за исключением того, что вы можете передать право собственности на весь канал полностью вне сети. Их модель доверия зависит от оператора (который может быть федерацией) цепочки состояний, который отказывается вступать в сговор с прошлыми владельцами и красть цепочку состояний у текущего владельца. Это не так надежно, как канал Lightning, но он гораздо более гибкий, поскольку право собственности можно передавать без необходимости выполнять транзакцию в цепочке. Учитывая, что цепочки состояний основаны на предварительно подписанных транзакциях вне цепочки, вы можете добавить к ним HTLC.
Это позволяет использовать их для оптимизации эффективности маршрутизации платежей в Lightning, позволяя операторам узлов перераспределять ликвидность на лету вне цепочки. Вместо того, чтобы открывать каналы и накапливать в них ликвидность, чтобы быть хорошо подключенными заранее, их средства могут быть динамически перераспределены на лету вне сети в ответ на смещение спроса в места, к которым они не подключены (или недостаточно хорошо подключены, чтобы ). Единственное требование состоит в том, что другая сторона хочет перевести ликвидность на доверие оператору цепочки состояний.
боковые цепи
Сайдчейны могут реализовывать любые произвольные правила, которые они хотят. Время блоков может быть разным, размеры блоков могут быть разными, все можно изменить. Единственная загвоздка в настоящее время заключается в том, чтобы переместить Bitcoin для сайдчейна вы должны доверять федерации, которая хранит средства в основной цепочке. Вы можете применять HTLC к сайдчейну, который использует Bitcoinскриптовая система; у вас может быть система сценариев, более похожая на Ethereum, которая позволяет десяткам людей совместно использовать учетную запись, которая разделяет балансы и обновляет их в зависимости от того, успешен или нет HTLC; ты можешь делать что угодно. Пока блокчейн поддерживает условное предоставление денег одной стороне, если они производят хэш, и другой стороне после истечения срока блокировки, они могут помочь маршрутизировать платежи Lightning. Другие блокчейны могут экспериментировать со способами сделать распределение ликвидности более эффективным, чем основной. Bitcoin блокчейн. Вы даже можете просто сделать что-то простое, например, построить еще одну сеть Lightning в цепочке, в которой дешевле открывать и закрывать каналы. Воображение — это предел.
Совершенно новые конструкции
Вот моя собственная случайная идея: многие люди могут собраться вместе в одну m-of-n (т. е. 3-из-5) мультиподписного адреса с несколькими агентами условного депонирования и просто доверьтесь агентам условного депонирования, чтобы уладить все должным образом. Каждый человек в адресе и агенты условного депонирования могут отслеживать и обновлять «балансы» на основе маршрутизации платежей; записывать использованные HTLC и информацию о том, были ли они успешно урегулированы или возмещены; и периодически рассчитывайте остатки по цепочке. Вы просто строите мультиподпись так, чтобы один участник «маршрутизации» и все агенты условного депонирования — это все, что необходимо потратить с мультиподписи. Вы даже можете создать транзакцию возврата с временной блокировкой, чтобы вернуть деньги всем по истечении определенного периода, недостатком которой будет то, что все деньги, которые кто-либо заработал за время существования конструкции, будут потеряны, если они будут использованы. Это потребует расчетов в сети, прежде чем транзакция возврата станет действительной для траты.
Это потребует доверия к агентам условного депонирования, но преимущество будет заключаться в том, что любой человек в этой «группе UTXO» может перевести средства или направить HTLC на любой другой человек в группе UTXO. Это было бы огромным повышением эффективности в распределении ликвидности.
Кредитные отношения
Самый простой способ добиться эффективности — просто доверять людям. Если вы можете зарабатывать деньги, направляя платеж через сеть для кого-то, но у вас нет открытого канала для узла, необходимого для маршрутизации этого платежа, тогда вы можете просто пообещать заплатить им позже если они тебе доверяют. Если бы вы были особенно заслуживающим доверия лицом или организацией, и многие люди в сети были бы готовы доверять вам таким образом, тогда вы могли бы направлять платежи с огромной степенью гибкости и не вкладывать капитал в платежные каналы по всей сети. Просто рассчитайтесь честно в конце дня, и люди будут продолжать доверять вам платежи за вас на основе системы чести.
Одна проблема и преимущества
Основное преимущество всех этих возможностей заключается в том, что, несмотря на огромные различия в модели доверия (большинство из них на самом деле прямо требуют, чтобы вы доверяли людям, с которыми взаимодействуете, если вы решите их использовать), это не имеет значения для отправителя и получателя. Если у меня есть обычный ненадежный канал Lightning и я хочу заплатить кому-то, у кого также есть ненадежный обычный канал Lightning, то, как этот платеж будет туда получен, ни для кого из нас не имеет значения. Когда я отправляю деньги, этот платеж обновляется и применяется в моем канале Lightning с моим партнером без доверия, как обычно. Когда получатель действительно получает деньги, этот платеж обновляется и применяется в его канале Lightning с его партнером без доверия, как обычно. Тот факт, что кто-то посередине просто верит обещанию своего коллеги заплатить ему позже, совершенно не имеет значения для нас обоих. Я отправил свои деньги и больше не контролирую их, а получатель действительно получил свои деньги и теперь безнадежно контролирует их.
Проблема в том, как я, как отправитель, узнаю об этих отношениях? В Lightning отправитель — это тот, кто выбирает маршрут для платежа после просмотра таблицы маршрутизации общедоступных каналов в сети, желающих пересылать платежи. Чтобы рекламировать возможность маршрутизации платежа, необходимо указать UTXO в сети, который финансировал ваш канал Lightning, и доказать, что это реальный канал. В чем здесь проблема, ни одна из приведенных выше идей не сможет этого обеспечить, поэтому отправитель платежа может знать об этих других вариантах маршрутизации платежа. Если бы протокол сплетен и структура таблицы маршрутизации были обновлены, чтобы разрешить эти другие вещи, они могли бы быть осведомлены о других вариантах.
Единственное реальное требование — убедиться, что реклама других «неканальных» способов маршрутизации платежей не открывает векторов отказа в обслуживании. Нынешняя схема, требующая совместного использования UTXO, которая финансирует канал, предназначена для защиты от людей, рекламирующих каналы, которые не существуют, что может перегрузить узлы бесполезными данными сплетен, а также привести к тому, что пользователи будут постоянно пытаться совершать платежи, которые никогда не проводились. шанс добиться успеха в первую очередь.
В конце концов, есть проблемы, которые необходимо решить, чтобы повысить гибкость маршрутизации платежей в сети, но это решаемые проблемы. Думать, что Lightning должен продолжать функционировать так, как он работает в настоящее время, чтобы работать как платежная сеть, — очень узкое мышление и, грубо говоря, придумывание проблем, которые в основном являются воображаемыми.
Это гостевой пост Шиноби. Выраженные мнения являются полностью их собственными и не обязательно отражают мнение BTC Inc или Bitcoin Журнал.
Исходный источник: Bitcoin Журнал