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

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

ЛНД

LND, управляемый Lightning Labs, является наиболее широко распространенной реализацией Lightning в сети, в настоящее время являющейся серверной частью для популярных кошельков, таких как Breez, Blixt, Zap и собственного приложения Lightning от Lightning Lab, прежде чем оно прекратило разработку. Он также поддерживает крупные предприятия, такие как Bitrefill и Hodl Hodl. Одним из самых больших недостатков LND была огромная скорость роста его базы данных состояний каналов (которая оптимизируется в следующем выпуске), но в настоящее время он по-прежнему является лидером пакета в сети.

Команда Lightning Labs, как правило, сосредоточилась на предоставлении собственных монетизированных услуг, чтобы помочь устранить недостатки, присущие протоколу Lightning как основе его бизнес-модели. Что касается текущей дорожной карты, в ближайшем будущем LND определила две разные вещи в качестве основных приоритетов своих усилий по развитию.

Во-первых, это реализация Taproot, позволяющая использовать новую структуру транзакций для каналов (помните, что канал — это набор предварительно подписанных транзакций), чтобы заложить основу для будущих улучшений конфиденциальности. Одним из них является переход от хеш-контрактов с временной блокировкой (HTLC) к точечным контрактам с временной блокировкой (PTLC). В настоящее время HTLC — это то, что гарантирует, что платеж будет успешным или неудачным для каждого прыжка на маршруте платежа; прообраз хэшлока высвобождается и гарантирует, что платеж пройдет для всех или нет, и будет возмещен для всех. PTLC выполняют то же самое, используя подписи адаптера вместо хэшей, что означает, что каждый прыжок на пути не имеет одного и того же хэша, который может идентифицировать один платеж через несколько прыжков, если один человек управляет несколькими узлами на пути оплаты.

Следующим шагом после реализации каналов Taproot для Lightning является обновление каналов в сети для их использования. На момент написания этой статьи существует 82 697 общедоступных каналов Lightning. При максимально эффективном использовании блочного пространства, содержащего около 3300 транзакций, потребуется 25 блоков только закрытия каналов, чтобы закрыть их все, и еще 25, чтобы снова открыть их как каналы Taproot.

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

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

КЛН

CLN (ранее c-lightning) была, несмотря на многочисленные сообщения об обратном в то время, первой реализацией Lightning, запущенной в основной сети в 2018 году. Вся архитектура CLN была построена на идее модульности, так что различные части узел (например, ключи обработки частей и подпись) можно было легко заменить и настроить. Существует даже система плагинов, разработанная для того, чтобы пользователи могли написать свое собственное поведение для взаимодействия с CLN и изменить то, как узел работает в определенных ситуациях или в ответ на определенные события.

Ярким примером этого является функция оплаты, которая даже реализована в виде плагина для поведения оплаты по умолчанию, поставляемого с CLN. Это часть узла, которая занимается определением маршрутов платежей и их отправкой. Существует большой каталог доступных плагинов, от автоматизированного управления узлами с помощью CLBOSS, плагинов сторожевой башни и автоматизированной логики зондирования до динамической обрезки Bitcoin Core, чтобы гарантировать, что CLN всегда имеет блоки, необходимые для синхронизации. Большой список плагинов можно найти здесь.

Основной целью CLN всегда была модульность и гибкость, и команда планирует вывести это на новый уровень с помощью своего программного стека Greenlight. Greenlight дополнительно разделит функциональность различных частей узла до такой степени, что пользователи смогут хранить и управлять своими ключами и операциями подписи на разных (и даже нескольких) устройствах, откуда могут работать фактические каналы обработки серверной части узла и другие данные. где-то еще, либо в облаке, либо даже на домашнем устройстве. Breez Wallet даже планирует перейти на использование CLN/Greenlight и разбить различные функции своего кошелька на отдельные приложения, чтобы воспользоваться свободой, обеспечиваемой этой архитектурой. Отдельные приложения для потоковой передачи подкастов, общего использования кошелька, систем PoS, подключенных к одному и тому же узлу. Это даже открывает двери для приема платежей, когда ваш мобильный кошелек находится в автономном режиме, что является серьезной проблемой во многих случаях использования Lightning. Отдельное подписывающее устройство можно постоянно оставлять дома в сети и запрограммировать на подписание обновлений канала только тогда, когда они увеличивают баланс вашего канала. Проблема решена, вам больше не нужно беспокоиться о том, чтобы ваш телефон был постоянно открыт для получения средств.

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

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

ЛДК

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

Blue Wallet работает над реализацией на основе LDK, и новая реализация Lightning Sensei также строится на основе LDK. Cash App даже создал узел с нуля. Когда компания начала рассматривать интеграцию с Lightning, она хотела глубоко интегрировать поведение своих узлов Lightning с серверной частью, обрабатывающей балансы пользователей Cash App. Ни одна из существующих реализаций не позволяла бы легко интегрироваться в такой степени, поэтому они настроили свою собственную с помощью LDK.

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

Дорога впереди

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

Работа была проделана LND, CLN и LDK для решения этой проблемы. Веб-сборка (WASM) — это новый язык и двоичный формат, упрощающие запуск более эффективных и легких программ в веб-браузере. У LND и LDK есть двоичные файлы WASM для своих узлов, и CLN планирует внедрить инструменты управления ключами для работы в WASM, которые могут удаленно подключаться к узлу Lightning, основываясь на своей работе Greenlight. Несмотря на то, что при управлении ключами в веб-браузере необходимо учитывать проблемы безопасности, приближаются дни бесшовной интеграции Lightning в Интернете.

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

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

Источник