Системная интерпретация волокна: интеграция Lightning Network с CKB

ПродвинутыйSep 09, 2024
Эта статья представляет глубокий анализ решения Fiber Network Lightning Network на основе CKB, исследуя его технологические инновации в области платежных каналов, WatchTower, многошаговой маршрутизации и междоменных платежей. Она подробно описывает, как Fiber улучшает пользовательский опыт, защиту конфиденциальности и безопасность благодаря технической оптимизации, а также исследует его потенциал для взаимодействия с Bitcoin Lightning Network.
Системная интерпретация волокна: интеграция Lightning Network с CKB

Пересылка оригинального заголовка 'Системное понимание Fiber: грандиозный эксперимент по прививке молниеносной сети на CKB'

23 августа CKB официально выпустила Fiber Network, решение Lightning Network на основе CKB. Эта новость быстро вызвала интенсивную дискуссию в сообществе, что привело к росту цены CKB почти на 30% в течение одного дня. Сильная реакция может быть связана с убедительным повествованием о Lightning Network и тем фактом, что Fiber предлагает обновленное решение по сравнению с традиционной Lightning Network с многочисленными улучшениями. Например, Fiber изначально поддерживает несколько типов активов, включая CKB, BTC и стейблкоины, и извлекает выгоду из более низких комиссий за транзакции CKB и более быстрого времени отклика, что позволяет значительно улучшить UX. Кроме того, Fiber сделал несколько оптимизаций с точки зрения конфиденциальности и безопасности. Кроме того, Fiber и BTC Lightning Network могут соединяться, образуя более крупную сеть P2P. Представители CKB даже упомянули, что они планируют установить 100 000 физических узлов в Fiber и Lightning Network во время офлайн-мероприятий, чтобы улучшить и продвинуть сеть P2P-платежей. Это, несомненно, грандиозная и беспрецедентная история

Если официальное видение CKB будет реализовано в будущем, это будет значительным преимуществом для Lightning Network, CKB и более широкой экосистемы биткойна. Согласно данным пула транзакций, в настоящее время сеть молний BTC удерживает более 300 миллионов долларов, с примерно 12 000 узлами и почти 50 000 платежными каналами, установленными между ними.

На spendmybtc.com мы можем наблюдать, что все большее число продавцов поддерживают платежи Lightning Network. По мере роста узнаваемости BTC рост внесетевых платежных решений, таких как Lightning Network и Fiber, вероятно, будет набирать обороты. Для систематического анализа технического решения Fiber компания "Geek Web3" подготовила этот исследовательский отчет по всему решению Fiber. Как реализация Lightning Network, основанная на CKB, принципы Fiber в значительной степени согласуются с Bitcoin Lightning Network, но включают оптимизацию во многих деталях. Общая архитектура Fiber включает в себя четыре основных компонента: платежные каналы, WatchTower, многоузловую маршрутизацию и междоменные платежи. Начнем с объяснения самой важной составляющей: платежных каналов.

Основа сети Lightning и Fiber: платежные каналы

Платежные каналы, по сути, перемещают транзакции из блокчейна, а окончательное состояние устанавливается в блокчейне через некоторое время. Поскольку транзакции совершаются вне блокчейна, они часто обходят ограничения производительности основной цепочки, такой как BTC. Например, если Алиса и Боб вместе открывают канал, они сначала создают учетную запись с мультиподписью в блокчейне и вносят некоторые средства, скажем, по 100 единиц каждый, в качестве своего баланса в оффчейн-канале. Затем они могут проводить несколько транзакций в канале, а когда они закрывают канал, они синхронизируют окончательные балансы в цепочке, при этом учетная запись с мультиподписью производит платежи обеим сторонам — это и есть «расчет».

Например, если обе стороны начинают со 100 единиц каждая, и Алиса передает 50 единиц Бобу, затем еще одна передача 10 единиц, а затем Боб переводит 30 единиц обратно Алисе, их окончательный баланс будет следующим: Алиса — 70 единиц, Боб — 130 единиц. Общий баланс остается неизменным, как показано на примере с бусинами абакуса. Если одна из сторон выходит из канала, окончательные балансы (Алиса: 70, Боб: 130) синхронизируются в блокчейне, и 200 единиц учетной записи с мультиподписью распределяются в соответствии с этими окончательными балансами для завершения расчета.

Хотя этот процесс кажется прямолинейным, на практике в него вовлечены сложные соображения. Нельзя предсказать, когда другая сторона выберет выйти из канала. Например, Боб может выйти после второй транзакции или даже после первой, так как канал позволяет участникам свободно выходить. Для решения этой проблемы система предполагает, что кто угодно может выйти в любое время, и любая сторона может представить окончательный баланс на цепочку для урегулирования. Это управляется через "транзакции обязательств", которые регистрируют последние балансы в канале. Каждая транзакция генерирует соответствующую транзакцию обязательства. Чтобы выйти из канала, вы представляете на цепочку наиболее последнюю транзакцию обязательства для вывода вашей доли с мультиподписным счетом.

Мы можем заключить, что транзакции обязательства используются для урегулирования балансов обеих сторон в канале on-chain, при этом любая из сторон может представить последнюю транзакцию обязательства для выхода из канала. Однако существует решающий злонамеренный сценарий: Боб может представить устаревший баланс и транзакцию обязательства на цепи. Например, после генерации Commit Tx3 баланс Боба составляет 130 единиц. Но к своему преимуществу Боб может представить устаревший Commit Tx2, который показывает баланс в 160 единиц. Этот устаревший баланс представляет собой классическую атаку "двойного расходования".

Для предотвращения таких ситуаций двойных расходов должны быть предусмотрены соответствующие меры наказания. Проектирование этих мер наказания является основой системы одноканальных платежей, и понимание этого является важным для понимания того, как работают платежные каналы. В конструкции канала, если одна из сторон отправляет устаревшее состояние и транзакцию обязательства на цепочку, вместо получения выгоды, они обнаружат, что другая сторона может вывести все средства. Это использует концепции «асимметричных транзакций обязательства» и «ключей отзыва», которые являются критическими. Давайте сначала объясним «асимметричные транзакции обязательства» на примере Commit Tx3.

В этом сценарии Боб создает транзакцию обязательства и отправляет ее Элис для обработки. Как показано, эта транзакция включает передачу биткоинов, заявляя, что 70 единиц из мультиподписного аккаунта выделяются для Элис и 130 единиц для Боба. Однако условия разблокировки «асимметричны», наложение более жестких ограничений на Элис и выгоды Боба.

Когда Алиса получает транзакцию фиксации от Боба, она может добавить свою подпись, чтобы выполнить требование мультиподписи 2/2. Затем Алиса может выбрать отправить эту транзакцию фиксации на цепи для выхода из канала. В противном случае, она может продолжать совершать транзакции внутри канала, если не отправит ее.

Важно отметить, что эту транзакцию обязательства создает Боб и она содержит условия, невыгодные для Элис. Элис может либо принять ее, либо отклонить, но мы должны убедиться, что она сохранит некоторую автономию. При проектировании платежных каналов только Элис может отправить «невыгодную» транзакцию обязательства на цепь, потому что для транзакций обязательства требуется мультиподпись 2/2. После того, как Боб создаст транзакцию локально, она будет содержать только его подпись и не будет содержать подпись Элис.

Алиса может «принять подпись Боба, но утаить свою». Это похоже на контракт, требующий двойной подписи. Если Боб подписывает контракт первым и отправляет его Алисе, она может не ставить свою подпись. Чтобы контракт вступил в силу, Алиса должна была его подписать, а затем отправить; В противном случае она может воздержаться от его подписания или подачи. Таким образом, в данном случае у Алисы есть средства, чтобы ограничить действия Боба.

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

Интересно, что хотя две транзакции обязательств объявляют одинаковую “сумму, получаемую при выходе,” их условия вывода отличаются. Это иллюстрирует концепцию “асимметричных транзакций обязательства”, упомянутую ранее.

Как было объяснено ранее, для каждой транзакции обязательства требуется 2/2 мультиподпись для действительности. Транзакция обязательства, созданная Бобом в его пользу, не соответствует требованию 2/2 мультиподписи, в то время как транзакция обязательства, которая удовлетворяет этому требованию, находится у Элис и может быть подана только ею, создавая механизм контроля и баланса. Та же логика применяется и наоборот.

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

Что касается ранее обсуждаемого сценария «двойных расходов», если кто-то отправляет устаревшую транзакцию о подтверждении в цепочку, вступает в игру концепция «ключей отзыва». Например, если Боб отправляет устаревшую транзакцию Tx2 в цепочку, Алиса может использовать ключ отзыва, связанный с Tx2, чтобы вернуть средства, которые Боб должен был получить.

В примере диаграммы, предполагая, что последняя транзакция фиксации - Commit Tx3, а Tx2 устарела, если Боб отправляет устаревшую Tx2, Алиса может действовать в пределах временной блокировки, используя ключ отзыва Tx2, чтобы вернуть средства Боба.


Относительно последней Tx3 Алиса не обладает ее ключом отзыва и получит его только после создания в будущем Tx4. Это связано с особенностями криптографии на основе открытого и закрытого ключей и свойствами UTXO. В целях краткости здесь не обсуждаются детали реализации ключей отзыва.

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

В этом контексте Fiber, основанный на CKB, предлагает существенные улучшения по сравнению с сетью молний Bitcoin. Он поддерживает нативно транзакции и передачу нескольких типов активов, включая CKB, BTC и стейблкоины RGB++, тогда как сеть молний нативно поддерживает только Bitcoin. Даже с обновлением Taproot Asset, сеть молний Bitcoin все еще не может нативно поддерживать не-BTC активы и может поддерживать стейблкоины только косвенно.


(Источник изображений: Dapangdun) Кроме того, поскольку Fiber основывается на CKB в качестве своей главной цепи первого уровня, комиссии за открытие и закрытие каналов значительно ниже по сравнению с сетью Lightning BTC. Это снижает затраты пользователей на транзакции, что представляет собой явное преимущество с точки зрения пользовательского опыта (UX).

24/7 безопасность: WatchTower

Одна из проблем с ключами отзыва заключается в том, что участники канала должны постоянно контролировать друг друга, чтобы предотвратить отправку устаревших транзакций о обязательствах. Однако никто не может быть онлайн 24/7, так что что происходит, если одна сторона действует злонамеренно, а другая находится в автономном режиме? Обе сети Fiber и Bitcoin Lightning Network решают эту проблему с помощью концепции WatchTowers.

WatchTowers предназначены для мониторинга онлайн-активностей круглосуточно. Если кто-то отправит устаревшую транзакцию обязательства, WatchTower примет своевременные меры для защиты канала и средств. Вот как это работает:

После завершения транзакции обязательства Теда, Алиса или Боб могут заранее подготовить соответствующую транзакцию штрафа (с использованием ключа отзыва для обработки устаревшей транзакции обязательства с указанием себя в качестве бенефициара). Они затем предоставляют открытый текст этой транзакции штрафа WatchTower.

Когда WatchTower обнаруживает устаревшую транзакцию обязательства, поданную в цепь, он также подаст подготовленную транзакцию штрафа, применяя штраф и обеспечивая целостность канала.

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

В плане оптимизации Fiber улучшает подход Lightning Network к механизмам штрафов Биткойн. У механизма LN-Penalty Lightning Network есть существенный недостаток: WatchTowers должны хранить все устаревшие хэши транзакций обязательств и соответствующие ключи отзыва, что создает значительное давление на хранение. В 2018 году сообщество Биткойна предложило решение под названием "eltoo", чтобы решить эту проблему. Eltoo позволил бы последней транзакции обязательств штрафовать устаревшие, уменьшая необходимость хранения всех предыдущих транзакций. Однако для этого решения требуется активация опкода SIGHASH_ANYPREVOUT, который пока не был реализован.

С другой стороны, Fiber использует протокол Daric, который модифицирует конструкцию ключа отзыва, чтобы один ключ отзыва мог применяться к нескольким устаревшим транзакциям с обязательством. Такой подход значительно снижает потребности в хранении для WatchTowers и пользовательских клиентов.

Относительно сетевых систем трафика: Платежные каналы подходят для одноразовых транзакций, но молниеносная сеть поддерживает многоходовые платежи, позволяя совершать транзакции между сторонами, у которых нет прямого канала, маршрутизируя через промежуточные узлы. Например, если у Алисы и Кена нет прямого канала, но у Кена и Боба есть, и у Боба и Алисы тоже, Боб может выступить в качестве посредника для облегчения транзакций между Алисой и Кеном.

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

Для решения проблемы доверия к посредникам: как вы можете гарантировать, что они честны? Например, если Алисе нужно сделать платеж в 100 единиц Кену, но Боб, который является посредником между ними, может задержать средства. HTLC и PTLC используются для предотвращения такого зловредного поведения. Предположим, что Алиса хочет заплатить Даниэлю 100 единиц, но у них нет прямого канала. Алиса обнаруживает, что она может направить платеж через посредников Боба и Кэрол. Вводится HTLC в качестве платежного канала: сначала Алиса инициирует запрос Даниэлю, который затем предоставляет Алисе хэш r, но Алиса не знает преобразование R, соответствующее r.

Затем Алиса строит условия оплаты с Бобом через HTLC: Алиса готова заплатить Бобу 102 единицы, но Боб должен раскрыть ключ R в течение 30 минут; в противном случае Алиса заберет деньги. Точно так же Боб создает HTLC с Кэрол: Боб заплатит Кэрол 101 единицу, но Кэрол должна раскрыть ключ R в течение 25 минут; в противном случае Боб заберет деньги. Кэрол делает то же самое с Даниэлем: Кэрол готова заплатить Даниэлю 100 единиц, но Даниэль должен раскрыть ключ R в течение 20 минут; в противном случае Кэрол заберет деньги.

Даниэль понимает, что ключ R, запрошенный Кэрол, на самом деле является тем, что хочет Алиса, так как только Алиса заинтересована в значении R. Итак, Даниэль сотрудничает с Кэрол и предоставляет ключ R, получая 100 единиц от Кэрол. Таким образом, Алиса достигает своей цели и платит Даниэлю 100 единиц.

Впоследствии Кэрол передает ключ R Бобу и получает 101 единицу. Затем Боб передает ключ R Алисе и получает 102 единицы. Наблюдая за выигрышами и проигрышами для всех, Алиса теряет 102 единицы, Боб и Кэрол зарабатывают по 1 единице чистой прибыли, и Дэниел получает 100 единиц. 1 единица, заработанная Бобом и Кэрол, является их комиссией, извлеченной из Алисы.

Даже если кто-то на пути оплаты, такой как Кэрол, не сможет предоставить ключ R для дальнейшего Боба, это не приведет к убыткам для Боба: после завершения времени ожидания Боб сможет извлечь построенный им HTLC. То же самое относится к Алисе. Тем не менее, в сети Lightning Network есть свои проблемы: пути не должны быть слишком длинными. Если путь слишком длинный слишком многими посредниками, это может снизить надежность оплаты. Некоторые посредники могут быть в автономном режиме или иметь недостаточный баланс для построения конкретного HTLC (например, каждый посредник в предыдущем примере должен удерживать более 100 единиц). Поэтому добавление большего количества посредников увеличивает вероятность ошибок.

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

Предположим, что Боб и Дэниел контролируются одной и той же сущностью и ежедневно получают множество HTLC. Они замечают, что ключ R, запрошенный Элис и Кэрол, всегда один и тот же, и что узел нижнего потока Ив, подключенный к Дэниелу, всегда знает содержание ключа R. Поэтому Дэниел и Боб могут заключить, что между Элис и Ив есть путь оплаты, так как они всегда имеют дело с одним и тем же ключом и могут наблюдать за их отношениями. Чтобы решить эту проблему, Fiber использует PTLC, которые повышают конфиденциальность по сравнению с HTLC, используя разные ключи для разблокировки каждого PTLC в платежном пути. Наблюдение только PTLC не может определить отношения между узлами. Объединяя PTLC с луковой маршрутизацией, Fiber становится идеальным решением для обеспечения конфиденциальности платежей.

Кроме того, традиционная Сеть молний уязвима для атаки «циклической замены», что может привести к краже активов у посредников на пути платежа. Эта проблема привела к тому, что разработчик Антуан Риард отказался от разработки Сети молний. На данный момент Сеть молний Биткоина не имеет фундаментального решения этой проблемы, что является болевой точкой. В настоящее время CKB решает этот сценарий атаки путем улучшения уровня пула транзакций, позволяя Fiber смягчить проблему. Так как атака циклической замены и ее решения довольно сложны, этот статья не будет углубляться в нее. Заинтересованные читатели могут обратиться к соответствующим статьям на BTCStudy и официальным ресурсам CKB, чтобы получить больше информации.

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

С использованием HTLC и PTLC, Fiber может осуществлять кросс-доменные платежи с помощью сети Bitcoin Lightning, обеспечивая «атомарность кросс-доменных действий», то есть все шаги кросс-доменной транзакции либо полностью успешны, либо полностью неудачны, без частичного успеха или неудачи. Благодаря гарантированной атомарности кросс-доменных операций риск потери активов снижается. Это позволяет Fiber взаимодействовать с сетью Bitcoin Lightning, обеспечивая прямые платежи от Fiber к пользователям в сети BTC Lightning (с ограничением получателя на BTC) и позволяя конвертировать CKB.

Преобразование активов B и RGB++ в эквивалент биткойна в сети молний BTC.

Вот упрощенное объяснение процесса: предположим, что Алиса работает узлом в сети Fiber, а Боб работает узлом в сети биткоиновой молнии. Если Алиса хочет перевести некоторые деньги Бобу, она может сделать это через перекрестного доменного посредника, Ингрид. Ингрид будет работать с узлами как в сети Fiber, так и в BTC Lightning Networks, выступая посредником в платежном пути.

Если Боб хочет получить 1 BTC, Алиса может договориться о обменном курсе с Ингрид, установив 1 CKB равным 1 BTC. Затем Алиса отправит 1,1 CKB Ингрид в сети Fiber, и Ингрид отправит 1 BTC Бобу в сети Bitcoin Lightning Network, удерживая 0,1 CKB в качестве комиссии.

Процесс включает в себя установление платежного пути между Алисой, Ингрид и Бобом с использованием HTLC. Боб должен предоставить Ингрид ключ R для получения средств. Как только у Ингрид будет ключ R, она сможет разблокировать средства, которые Алиса заблокировала в HTLC.

Кросс-доменные действия между сетью BTC Lightning и Fiber являются атомарными, что означает, что либо оба HTLC разблокированы, и кросс-доменный платеж успешно выполнен, либо ни один из них не разблокирован, и платеж не проходит. Это гарантирует, что Алиса не потеряет деньги, если Боб их не получит.

Ингрид потенциально может не разблокировать HTLC Алисы после того, как узнала ключ R, но это навредит Ингрид, а не Алисе. Поэтому дизайн Fiber обеспечивает безопасность для пользователей и не требует доверия к третьим сторонам, обеспечивая переводы между различными P2P-сетями с минимальными модификациями.

Другие преимущества Fiber по сравнению с сетью молний BTC

Ранее мы упоминали, что Fiber поддерживает местные активы CKB и активы RGB++ (особенно стабильные монеты), что придает ему значительный потенциал для мгновенных платежей и делает его отлично подходящим для ежедневных небольших транзакций.

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

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

Однако в сети Bitcoin Lightning Network инжекция ликвидности, а также открытие или закрытие каналов, все происходит на блокчейне Bitcoin. Если комиссии сети Bitcoin очень высоки, это негативно сказывается на пользовательском опыте платежных каналов. Например, если вы хотите открыть канал с объемом в $100, но плата за установку составляет $10, это означает, что 10% ваших средств уходят только на установку канала, что неприемлемо для большинства пользователей. Та же проблема относится к инжекции ликвидности.

В отличие от этого, Fiber предлагает значительные преимущества. Во-первых, TPS (транзакций в секунду) CKB намного выше, чем у биткоина, при этом комиссии достигают стоимости в центах. Во-вторых, чтобы решить проблему нехватки ликвидности и обеспечить плавные транзакции, Fiber планирует сотрудничать с Mercury Layer для внедрения новых решений, которые устранят необходимость в операциях на цепи для вливания ликвидности, таким образом решая проблемы UX и затрат.

Теперь мы систематически изложили общую техническую архитектуру Fiber, с краткой сравнительной характеристикой сети Bitcoin Lightning, как показано на изображении выше. Учитывая сложность и широту тем, затронутых как Fiber, так и Lightning Network, одна статья может не охватить все аспекты. В будущем мы опубликуем серию статей, посвященных различным аспектам как Lightning Network, так и Fiber. Следите за обновлениями.

Отказ от ответственности:

  1. Эта статья взята из [Geek web3]. Пересылка оригинального заголовка «Системное понимание Fiber: грандиозный эксперимент по привязке молниеносной сети к CKB». Все авторские права принадлежат автору оригинала [Faust & Nickqiao, гик web3]. Если есть возражения против этой перепечатки, пожалуйста, свяжитесь с Gate Learnкоманда, и они незамедлительно справятся с этим.
  2. Отказ от ответственности: Взгляды и мнения, выраженные в этой статье, являются исключительно точкой зрения автора и не являются инвестиционными советами.
  3. Переводы статьи на другие языки выполняются командой Gate Learn. Если не указано иное, копирование, распространение или плагиат переведенных статей запрещены.

Системная интерпретация волокна: интеграция Lightning Network с CKB

ПродвинутыйSep 09, 2024
Эта статья представляет глубокий анализ решения Fiber Network Lightning Network на основе CKB, исследуя его технологические инновации в области платежных каналов, WatchTower, многошаговой маршрутизации и междоменных платежей. Она подробно описывает, как Fiber улучшает пользовательский опыт, защиту конфиденциальности и безопасность благодаря технической оптимизации, а также исследует его потенциал для взаимодействия с Bitcoin Lightning Network.
Системная интерпретация волокна: интеграция Lightning Network с CKB

Пересылка оригинального заголовка 'Системное понимание Fiber: грандиозный эксперимент по прививке молниеносной сети на CKB'

23 августа CKB официально выпустила Fiber Network, решение Lightning Network на основе CKB. Эта новость быстро вызвала интенсивную дискуссию в сообществе, что привело к росту цены CKB почти на 30% в течение одного дня. Сильная реакция может быть связана с убедительным повествованием о Lightning Network и тем фактом, что Fiber предлагает обновленное решение по сравнению с традиционной Lightning Network с многочисленными улучшениями. Например, Fiber изначально поддерживает несколько типов активов, включая CKB, BTC и стейблкоины, и извлекает выгоду из более низких комиссий за транзакции CKB и более быстрого времени отклика, что позволяет значительно улучшить UX. Кроме того, Fiber сделал несколько оптимизаций с точки зрения конфиденциальности и безопасности. Кроме того, Fiber и BTC Lightning Network могут соединяться, образуя более крупную сеть P2P. Представители CKB даже упомянули, что они планируют установить 100 000 физических узлов в Fiber и Lightning Network во время офлайн-мероприятий, чтобы улучшить и продвинуть сеть P2P-платежей. Это, несомненно, грандиозная и беспрецедентная история

Если официальное видение CKB будет реализовано в будущем, это будет значительным преимуществом для Lightning Network, CKB и более широкой экосистемы биткойна. Согласно данным пула транзакций, в настоящее время сеть молний BTC удерживает более 300 миллионов долларов, с примерно 12 000 узлами и почти 50 000 платежными каналами, установленными между ними.

На spendmybtc.com мы можем наблюдать, что все большее число продавцов поддерживают платежи Lightning Network. По мере роста узнаваемости BTC рост внесетевых платежных решений, таких как Lightning Network и Fiber, вероятно, будет набирать обороты. Для систематического анализа технического решения Fiber компания "Geek Web3" подготовила этот исследовательский отчет по всему решению Fiber. Как реализация Lightning Network, основанная на CKB, принципы Fiber в значительной степени согласуются с Bitcoin Lightning Network, но включают оптимизацию во многих деталях. Общая архитектура Fiber включает в себя четыре основных компонента: платежные каналы, WatchTower, многоузловую маршрутизацию и междоменные платежи. Начнем с объяснения самой важной составляющей: платежных каналов.

Основа сети Lightning и Fiber: платежные каналы

Платежные каналы, по сути, перемещают транзакции из блокчейна, а окончательное состояние устанавливается в блокчейне через некоторое время. Поскольку транзакции совершаются вне блокчейна, они часто обходят ограничения производительности основной цепочки, такой как BTC. Например, если Алиса и Боб вместе открывают канал, они сначала создают учетную запись с мультиподписью в блокчейне и вносят некоторые средства, скажем, по 100 единиц каждый, в качестве своего баланса в оффчейн-канале. Затем они могут проводить несколько транзакций в канале, а когда они закрывают канал, они синхронизируют окончательные балансы в цепочке, при этом учетная запись с мультиподписью производит платежи обеим сторонам — это и есть «расчет».

Например, если обе стороны начинают со 100 единиц каждая, и Алиса передает 50 единиц Бобу, затем еще одна передача 10 единиц, а затем Боб переводит 30 единиц обратно Алисе, их окончательный баланс будет следующим: Алиса — 70 единиц, Боб — 130 единиц. Общий баланс остается неизменным, как показано на примере с бусинами абакуса. Если одна из сторон выходит из канала, окончательные балансы (Алиса: 70, Боб: 130) синхронизируются в блокчейне, и 200 единиц учетной записи с мультиподписью распределяются в соответствии с этими окончательными балансами для завершения расчета.

Хотя этот процесс кажется прямолинейным, на практике в него вовлечены сложные соображения. Нельзя предсказать, когда другая сторона выберет выйти из канала. Например, Боб может выйти после второй транзакции или даже после первой, так как канал позволяет участникам свободно выходить. Для решения этой проблемы система предполагает, что кто угодно может выйти в любое время, и любая сторона может представить окончательный баланс на цепочку для урегулирования. Это управляется через "транзакции обязательств", которые регистрируют последние балансы в канале. Каждая транзакция генерирует соответствующую транзакцию обязательства. Чтобы выйти из канала, вы представляете на цепочку наиболее последнюю транзакцию обязательства для вывода вашей доли с мультиподписным счетом.

Мы можем заключить, что транзакции обязательства используются для урегулирования балансов обеих сторон в канале on-chain, при этом любая из сторон может представить последнюю транзакцию обязательства для выхода из канала. Однако существует решающий злонамеренный сценарий: Боб может представить устаревший баланс и транзакцию обязательства на цепи. Например, после генерации Commit Tx3 баланс Боба составляет 130 единиц. Но к своему преимуществу Боб может представить устаревший Commit Tx2, который показывает баланс в 160 единиц. Этот устаревший баланс представляет собой классическую атаку "двойного расходования".

Для предотвращения таких ситуаций двойных расходов должны быть предусмотрены соответствующие меры наказания. Проектирование этих мер наказания является основой системы одноканальных платежей, и понимание этого является важным для понимания того, как работают платежные каналы. В конструкции канала, если одна из сторон отправляет устаревшее состояние и транзакцию обязательства на цепочку, вместо получения выгоды, они обнаружат, что другая сторона может вывести все средства. Это использует концепции «асимметричных транзакций обязательства» и «ключей отзыва», которые являются критическими. Давайте сначала объясним «асимметричные транзакции обязательства» на примере Commit Tx3.

В этом сценарии Боб создает транзакцию обязательства и отправляет ее Элис для обработки. Как показано, эта транзакция включает передачу биткоинов, заявляя, что 70 единиц из мультиподписного аккаунта выделяются для Элис и 130 единиц для Боба. Однако условия разблокировки «асимметричны», наложение более жестких ограничений на Элис и выгоды Боба.

Когда Алиса получает транзакцию фиксации от Боба, она может добавить свою подпись, чтобы выполнить требование мультиподписи 2/2. Затем Алиса может выбрать отправить эту транзакцию фиксации на цепи для выхода из канала. В противном случае, она может продолжать совершать транзакции внутри канала, если не отправит ее.

Важно отметить, что эту транзакцию обязательства создает Боб и она содержит условия, невыгодные для Элис. Элис может либо принять ее, либо отклонить, но мы должны убедиться, что она сохранит некоторую автономию. При проектировании платежных каналов только Элис может отправить «невыгодную» транзакцию обязательства на цепь, потому что для транзакций обязательства требуется мультиподпись 2/2. После того, как Боб создаст транзакцию локально, она будет содержать только его подпись и не будет содержать подпись Элис.

Алиса может «принять подпись Боба, но утаить свою». Это похоже на контракт, требующий двойной подписи. Если Боб подписывает контракт первым и отправляет его Алисе, она может не ставить свою подпись. Чтобы контракт вступил в силу, Алиса должна была его подписать, а затем отправить; В противном случае она может воздержаться от его подписания или подачи. Таким образом, в данном случае у Алисы есть средства, чтобы ограничить действия Боба.

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

Интересно, что хотя две транзакции обязательств объявляют одинаковую “сумму, получаемую при выходе,” их условия вывода отличаются. Это иллюстрирует концепцию “асимметричных транзакций обязательства”, упомянутую ранее.

Как было объяснено ранее, для каждой транзакции обязательства требуется 2/2 мультиподпись для действительности. Транзакция обязательства, созданная Бобом в его пользу, не соответствует требованию 2/2 мультиподписи, в то время как транзакция обязательства, которая удовлетворяет этому требованию, находится у Элис и может быть подана только ею, создавая механизм контроля и баланса. Та же логика применяется и наоборот.

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

Что касается ранее обсуждаемого сценария «двойных расходов», если кто-то отправляет устаревшую транзакцию о подтверждении в цепочку, вступает в игру концепция «ключей отзыва». Например, если Боб отправляет устаревшую транзакцию Tx2 в цепочку, Алиса может использовать ключ отзыва, связанный с Tx2, чтобы вернуть средства, которые Боб должен был получить.

В примере диаграммы, предполагая, что последняя транзакция фиксации - Commit Tx3, а Tx2 устарела, если Боб отправляет устаревшую Tx2, Алиса может действовать в пределах временной блокировки, используя ключ отзыва Tx2, чтобы вернуть средства Боба.


Относительно последней Tx3 Алиса не обладает ее ключом отзыва и получит его только после создания в будущем Tx4. Это связано с особенностями криптографии на основе открытого и закрытого ключей и свойствами UTXO. В целях краткости здесь не обсуждаются детали реализации ключей отзыва.

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

В этом контексте Fiber, основанный на CKB, предлагает существенные улучшения по сравнению с сетью молний Bitcoin. Он поддерживает нативно транзакции и передачу нескольких типов активов, включая CKB, BTC и стейблкоины RGB++, тогда как сеть молний нативно поддерживает только Bitcoin. Даже с обновлением Taproot Asset, сеть молний Bitcoin все еще не может нативно поддерживать не-BTC активы и может поддерживать стейблкоины только косвенно.


(Источник изображений: Dapangdun) Кроме того, поскольку Fiber основывается на CKB в качестве своей главной цепи первого уровня, комиссии за открытие и закрытие каналов значительно ниже по сравнению с сетью Lightning BTC. Это снижает затраты пользователей на транзакции, что представляет собой явное преимущество с точки зрения пользовательского опыта (UX).

24/7 безопасность: WatchTower

Одна из проблем с ключами отзыва заключается в том, что участники канала должны постоянно контролировать друг друга, чтобы предотвратить отправку устаревших транзакций о обязательствах. Однако никто не может быть онлайн 24/7, так что что происходит, если одна сторона действует злонамеренно, а другая находится в автономном режиме? Обе сети Fiber и Bitcoin Lightning Network решают эту проблему с помощью концепции WatchTowers.

WatchTowers предназначены для мониторинга онлайн-активностей круглосуточно. Если кто-то отправит устаревшую транзакцию обязательства, WatchTower примет своевременные меры для защиты канала и средств. Вот как это работает:

После завершения транзакции обязательства Теда, Алиса или Боб могут заранее подготовить соответствующую транзакцию штрафа (с использованием ключа отзыва для обработки устаревшей транзакции обязательства с указанием себя в качестве бенефициара). Они затем предоставляют открытый текст этой транзакции штрафа WatchTower.

Когда WatchTower обнаруживает устаревшую транзакцию обязательства, поданную в цепь, он также подаст подготовленную транзакцию штрафа, применяя штраф и обеспечивая целостность канала.

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

В плане оптимизации Fiber улучшает подход Lightning Network к механизмам штрафов Биткойн. У механизма LN-Penalty Lightning Network есть существенный недостаток: WatchTowers должны хранить все устаревшие хэши транзакций обязательств и соответствующие ключи отзыва, что создает значительное давление на хранение. В 2018 году сообщество Биткойна предложило решение под названием "eltoo", чтобы решить эту проблему. Eltoo позволил бы последней транзакции обязательств штрафовать устаревшие, уменьшая необходимость хранения всех предыдущих транзакций. Однако для этого решения требуется активация опкода SIGHASH_ANYPREVOUT, который пока не был реализован.

С другой стороны, Fiber использует протокол Daric, который модифицирует конструкцию ключа отзыва, чтобы один ключ отзыва мог применяться к нескольким устаревшим транзакциям с обязательством. Такой подход значительно снижает потребности в хранении для WatchTowers и пользовательских клиентов.

Относительно сетевых систем трафика: Платежные каналы подходят для одноразовых транзакций, но молниеносная сеть поддерживает многоходовые платежи, позволяя совершать транзакции между сторонами, у которых нет прямого канала, маршрутизируя через промежуточные узлы. Например, если у Алисы и Кена нет прямого канала, но у Кена и Боба есть, и у Боба и Алисы тоже, Боб может выступить в качестве посредника для облегчения транзакций между Алисой и Кеном.

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

Для решения проблемы доверия к посредникам: как вы можете гарантировать, что они честны? Например, если Алисе нужно сделать платеж в 100 единиц Кену, но Боб, который является посредником между ними, может задержать средства. HTLC и PTLC используются для предотвращения такого зловредного поведения. Предположим, что Алиса хочет заплатить Даниэлю 100 единиц, но у них нет прямого канала. Алиса обнаруживает, что она может направить платеж через посредников Боба и Кэрол. Вводится HTLC в качестве платежного канала: сначала Алиса инициирует запрос Даниэлю, который затем предоставляет Алисе хэш r, но Алиса не знает преобразование R, соответствующее r.

Затем Алиса строит условия оплаты с Бобом через HTLC: Алиса готова заплатить Бобу 102 единицы, но Боб должен раскрыть ключ R в течение 30 минут; в противном случае Алиса заберет деньги. Точно так же Боб создает HTLC с Кэрол: Боб заплатит Кэрол 101 единицу, но Кэрол должна раскрыть ключ R в течение 25 минут; в противном случае Боб заберет деньги. Кэрол делает то же самое с Даниэлем: Кэрол готова заплатить Даниэлю 100 единиц, но Даниэль должен раскрыть ключ R в течение 20 минут; в противном случае Кэрол заберет деньги.

Даниэль понимает, что ключ R, запрошенный Кэрол, на самом деле является тем, что хочет Алиса, так как только Алиса заинтересована в значении R. Итак, Даниэль сотрудничает с Кэрол и предоставляет ключ R, получая 100 единиц от Кэрол. Таким образом, Алиса достигает своей цели и платит Даниэлю 100 единиц.

Впоследствии Кэрол передает ключ R Бобу и получает 101 единицу. Затем Боб передает ключ R Алисе и получает 102 единицы. Наблюдая за выигрышами и проигрышами для всех, Алиса теряет 102 единицы, Боб и Кэрол зарабатывают по 1 единице чистой прибыли, и Дэниел получает 100 единиц. 1 единица, заработанная Бобом и Кэрол, является их комиссией, извлеченной из Алисы.

Даже если кто-то на пути оплаты, такой как Кэрол, не сможет предоставить ключ R для дальнейшего Боба, это не приведет к убыткам для Боба: после завершения времени ожидания Боб сможет извлечь построенный им HTLC. То же самое относится к Алисе. Тем не менее, в сети Lightning Network есть свои проблемы: пути не должны быть слишком длинными. Если путь слишком длинный слишком многими посредниками, это может снизить надежность оплаты. Некоторые посредники могут быть в автономном режиме или иметь недостаточный баланс для построения конкретного HTLC (например, каждый посредник в предыдущем примере должен удерживать более 100 единиц). Поэтому добавление большего количества посредников увеличивает вероятность ошибок.

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

Предположим, что Боб и Дэниел контролируются одной и той же сущностью и ежедневно получают множество HTLC. Они замечают, что ключ R, запрошенный Элис и Кэрол, всегда один и тот же, и что узел нижнего потока Ив, подключенный к Дэниелу, всегда знает содержание ключа R. Поэтому Дэниел и Боб могут заключить, что между Элис и Ив есть путь оплаты, так как они всегда имеют дело с одним и тем же ключом и могут наблюдать за их отношениями. Чтобы решить эту проблему, Fiber использует PTLC, которые повышают конфиденциальность по сравнению с HTLC, используя разные ключи для разблокировки каждого PTLC в платежном пути. Наблюдение только PTLC не может определить отношения между узлами. Объединяя PTLC с луковой маршрутизацией, Fiber становится идеальным решением для обеспечения конфиденциальности платежей.

Кроме того, традиционная Сеть молний уязвима для атаки «циклической замены», что может привести к краже активов у посредников на пути платежа. Эта проблема привела к тому, что разработчик Антуан Риард отказался от разработки Сети молний. На данный момент Сеть молний Биткоина не имеет фундаментального решения этой проблемы, что является болевой точкой. В настоящее время CKB решает этот сценарий атаки путем улучшения уровня пула транзакций, позволяя Fiber смягчить проблему. Так как атака циклической замены и ее решения довольно сложны, этот статья не будет углубляться в нее. Заинтересованные читатели могут обратиться к соответствующим статьям на BTCStudy и официальным ресурсам CKB, чтобы получить больше информации.

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

С использованием HTLC и PTLC, Fiber может осуществлять кросс-доменные платежи с помощью сети Bitcoin Lightning, обеспечивая «атомарность кросс-доменных действий», то есть все шаги кросс-доменной транзакции либо полностью успешны, либо полностью неудачны, без частичного успеха или неудачи. Благодаря гарантированной атомарности кросс-доменных операций риск потери активов снижается. Это позволяет Fiber взаимодействовать с сетью Bitcoin Lightning, обеспечивая прямые платежи от Fiber к пользователям в сети BTC Lightning (с ограничением получателя на BTC) и позволяя конвертировать CKB.

Преобразование активов B и RGB++ в эквивалент биткойна в сети молний BTC.

Вот упрощенное объяснение процесса: предположим, что Алиса работает узлом в сети Fiber, а Боб работает узлом в сети биткоиновой молнии. Если Алиса хочет перевести некоторые деньги Бобу, она может сделать это через перекрестного доменного посредника, Ингрид. Ингрид будет работать с узлами как в сети Fiber, так и в BTC Lightning Networks, выступая посредником в платежном пути.

Если Боб хочет получить 1 BTC, Алиса может договориться о обменном курсе с Ингрид, установив 1 CKB равным 1 BTC. Затем Алиса отправит 1,1 CKB Ингрид в сети Fiber, и Ингрид отправит 1 BTC Бобу в сети Bitcoin Lightning Network, удерживая 0,1 CKB в качестве комиссии.

Процесс включает в себя установление платежного пути между Алисой, Ингрид и Бобом с использованием HTLC. Боб должен предоставить Ингрид ключ R для получения средств. Как только у Ингрид будет ключ R, она сможет разблокировать средства, которые Алиса заблокировала в HTLC.

Кросс-доменные действия между сетью BTC Lightning и Fiber являются атомарными, что означает, что либо оба HTLC разблокированы, и кросс-доменный платеж успешно выполнен, либо ни один из них не разблокирован, и платеж не проходит. Это гарантирует, что Алиса не потеряет деньги, если Боб их не получит.

Ингрид потенциально может не разблокировать HTLC Алисы после того, как узнала ключ R, но это навредит Ингрид, а не Алисе. Поэтому дизайн Fiber обеспечивает безопасность для пользователей и не требует доверия к третьим сторонам, обеспечивая переводы между различными P2P-сетями с минимальными модификациями.

Другие преимущества Fiber по сравнению с сетью молний BTC

Ранее мы упоминали, что Fiber поддерживает местные активы CKB и активы RGB++ (особенно стабильные монеты), что придает ему значительный потенциал для мгновенных платежей и делает его отлично подходящим для ежедневных небольших транзакций.

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

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

Однако в сети Bitcoin Lightning Network инжекция ликвидности, а также открытие или закрытие каналов, все происходит на блокчейне Bitcoin. Если комиссии сети Bitcoin очень высоки, это негативно сказывается на пользовательском опыте платежных каналов. Например, если вы хотите открыть канал с объемом в $100, но плата за установку составляет $10, это означает, что 10% ваших средств уходят только на установку канала, что неприемлемо для большинства пользователей. Та же проблема относится к инжекции ликвидности.

В отличие от этого, Fiber предлагает значительные преимущества. Во-первых, TPS (транзакций в секунду) CKB намного выше, чем у биткоина, при этом комиссии достигают стоимости в центах. Во-вторых, чтобы решить проблему нехватки ликвидности и обеспечить плавные транзакции, Fiber планирует сотрудничать с Mercury Layer для внедрения новых решений, которые устранят необходимость в операциях на цепи для вливания ликвидности, таким образом решая проблемы UX и затрат.

Теперь мы систематически изложили общую техническую архитектуру Fiber, с краткой сравнительной характеристикой сети Bitcoin Lightning, как показано на изображении выше. Учитывая сложность и широту тем, затронутых как Fiber, так и Lightning Network, одна статья может не охватить все аспекты. В будущем мы опубликуем серию статей, посвященных различным аспектам как Lightning Network, так и Fiber. Следите за обновлениями.

Отказ от ответственности:

  1. Эта статья взята из [Geek web3]. Пересылка оригинального заголовка «Системное понимание Fiber: грандиозный эксперимент по привязке молниеносной сети к CKB». Все авторские права принадлежат автору оригинала [Faust & Nickqiao, гик web3]. Если есть возражения против этой перепечатки, пожалуйста, свяжитесь с Gate Learnкоманда, и они незамедлительно справятся с этим.
  2. Отказ от ответственности: Взгляды и мнения, выраженные в этой статье, являются исключительно точкой зрения автора и не являются инвестиционными советами.
  3. Переводы статьи на другие языки выполняются командой Gate Learn. Если не указано иное, копирование, распространение или плагиат переведенных статей запрещены.
Начните торговать сейчас
Зарегистрируйтесь сейчас и получите ваучер на
$100
!