Будущее блокчейна видится в децентрализации, безопасности и масштабируемости, но обычно можно реализовать только два из этих аспектов, что называется проблемой невозможного треугольника блокчейна. На протяжении многих лет люди искали способы решить эту задачу, как повысить пропускную способность и скорость транзакций блокчейна при обеспечении децентрализации и безопасности, то есть решить проблему масштабирования, что является одной из актуальных тем в процессе развития блокчейна.
Определение децентрализации, безопасности и масштабируемости блокчейна:
Децентрализация: любой может стать узлом, участвуя в производстве и верификации блокчейн-системы, чем больше узлов, тем выше степень децентрализации, что обеспечивает независимость сети от контроля со стороны небольшого числа крупных централизованных участников.
Безопасность: Чем выше стоимость получения контроля над блокчейн-системой, тем выше безопасность, и цепочка может противостоять атакам значительной доли участников.
Масштабируемость: способность блокчейна обрабатывать большое количество транзакций.
Первая значительная хард-форк сети Биткойн возникла из-за проблемы масштабирования. С увеличением числа пользователей и объема транзакций сеть Биткойн с ограничением в 1 МБ на каждый блок начала сталкиваться с проблемами перегрузки; с 2015 года в сообществе Биткойн существовали разногласия по поводу масштабирования, одна сторона поддерживала расширение блока, в то время как другая поддерживала использование решения Segwit для малых блоков. 1 августа 2017 года сторонники масштабирования запустили собственную клиентскую систему, разработанную до 8 МБ, что привело к первой значительной хард-форку в истории Биткойна и появлению новой криптовалюты BCH.
Сеть Эфириума также выбрала пожертвовать частью масштабируемости для обеспечения безопасности и децентрализации сети. Хотя сеть Эфириума не ограничивает объем транзакций, как сеть Биткойна, путем ограничения размера блока, она фактически изменила подход, установив верхний предел на топливные сборы, которые может вместить один блок, но цель остается той же — добиться бездоверительного консенсуса и обеспечить широкое распределение узлов.
С 2017 года, начиная с CryptoKitties, лета DeFi, и до последующего роста таких приложений, как GameFi и NFT, рыночный спрос на пропускную способность постоянно увеличивается, но даже у Тьюринг-полноценного Ethereum в секунду может обрабатывать только 15-45 транзакций (TPS), что приводит к постоянному росту стоимости транзакций, увеличению времени расчета, и большинству Dapps трудно нести операционные расходы. Вся сеть становится медленной и дорогой для пользователей, проблема масштабируемости блокчейна требует срочного решения. Идеальное решение для масштабируемости: максимально повысить скорость транзакций и пропускную способность сети блокчейна без ущерба для децентрализованности и безопасности.
2. Категории решений по масштабированию
Мы разделили планы расширения на две большие категории: расширение на блокчейне и вне блокчейна, основываясь на критерии "изменится ли основной сеть".
2.1 Масштабирование на блокчейне
Основная концепция: решение, достигающее эффекта масштабирования путем изменения уровня протокола основной сети, в настоящее время основное решение - это шардирование.
Существует множество решений для масштабирования в блокчейне, в этой статье не будет подробно рассмотрено, кратко перечислим два решения:
Вариант один заключается в расширении пространства блока, то есть увеличении количества транзакций, упакованных в каждый блок, но это повысит требования к высокопроизводительным узлам, увеличит порог входа для узлов и снизит уровень "децентрализованности".
Вариант два — это шардирование, которое делит блокчейн-реестр на несколько частей, не требуя от каждого узла участия во всех записях, а назначая разные шардированные узлы для ведения разных записей. Параллельные вычисления могут одновременно обрабатывать несколько транзакций; это снижает вычислительную нагрузку на узлы и порог для их присоединения, повышая скорость обработки транзакций и уровень декентрализованности; но это означает, что вычислительная мощность всей сети будет распределена, что снизит "безопасность" всей сети.
Изменение кода протокола основной сети может привести к непредсказуемым негативным последствиям, поскольку любые незначительные уязвимости в безопасности на уровне основного кода могут серьезно угрожать безопасности всей сети, и сеть может быть вынуждена провести форк или прервать ремонтные обновления. Например, инцидент с инфляционной уязвимостью Zcash в 2018 году: код Zcash основан на модифицированном коде версии Bitcoin 0.11.2, в 2018 году один инженер обнаружил высокоопасную уязвимость в его основном коде, а именно, токены могли бесконечно эмитироваться, после чего команда потратила 8 месяцев на секретное исправление, и только после устранения уязвимости этот инцидент был обнародован.
2.2 вне блокчейна расширение
Основная концепция: решение по масштабированию, не изменяющее существующий протокол основной сети первого уровня.
вне блокчейна расширения схемы можно дополнительно разделить на Layer2 и другие схемы:
Состояние канала предполагает, что пользователям необходимо взаимодействовать с основной сетью только при открытии, закрытии или разрешении споров, а взаимодействие между пользователями осуществляется вне блокчейна, чтобы снизить временные и денежные затраты на транзакции пользователей и обеспечить неограниченное количество транзакций.
Состояние канала — это простой P2P-протокол, подходящий для "приложений на основе раундов", например, для игры в шахматы между двумя игроками. Каждый канал управляется многосторонним смарт-контрактом, работающим в основной сети, который контролирует активы, внесенные в канал, проверяет обновления состояния и арбитражит споры между участниками ( на основании доказательства мошенничества с подписью и временной меткой ). После развертывания контракта в блокчейн-сети участники вносят средства и блокируют их, после подписания обеими сторонами канал официально открывается. Канал позволяет участникам проводить неограниченное количество бесплатных транзакций вне блокчейна (, при условии, что чистая стоимость их переводов не превышает общую сумму внесенных токенов ). Участники поочередно отправляют обновления состояния друг другу, ожидая подтверждения подписи от другой стороны. Как только другая сторона подтверждает подпись, это обновление состояния считается завершенным. В нормальных условиях обновления состояния, согласованные обеими сторонами, не загружаются в основную сеть, только в случае спора или закрытия канала они полагаются на подтверждение основной сети. Когда необходимо закрыть канал, любой участник может подать запрос на транзакцию в основной сети, и если запрос на выход получает единогласное одобрение подписей, то в цепочке немедленно выполняется, то есть смарт-контракт распределяет оставшиеся заблокированные средства в соответствии с балансом каждого участника на конечном состоянии канала; если другие участники не одобрили подпись, то всем придется дождаться окончания "периода вызова", чтобы получить оставшиеся средства.
Таким образом, решение с использованием канала состояния может значительно сократить объем вычислений в основной сети, повысить скорость транзакций и снизить затраты на транзакции.
3.1.2 Хронология
2015/02, Джозеф Пун и Таддеус Дрэджа опубликовали проект белой книги сети Lightning.
В ноябре 2015 года Джефф Коулман впервые систематически обобщил концепцию State Channel и предложил, что Payment Channel в биткойне является подкатегорией концепции State Channel.
2016/01, Joseph Poon и Thaddeus Dryja официально опубликовали белую книгу "The Bitcoin Lightning Network: Scalable Off-Chain Instant Payments", в которой предложили решение для масштабирования сети Биткойн - Payment Channel(, это решение предназначено исключительно для обработки платежей на сети Биткойн.
Ноябрь 2017 года, были предложены первые спецификации дизайна State Channel на основе фреймворка Payment Channel под названием Sprites.
2018/06, Counterfactual предложил очень подробный дизайн обобщённых каналов состояния, это первый полностью связанный с каналами состояния дизайн.
В октябре 2018 года в статье Generalised State Channel Networks была предложена концепция State Channel Networks и Virtual Channels.
2019/02, концепция канала состояния расширена до N-Party Channels, Nitro является первым протоколом, созданным на основе этой идеи.
2019/10, Pisa расширил концепцию Watchtowers, чтобы решить проблему постоянного онлайн-присутствия всех участников.
Рисунок 1 демонстрирует рабочий процесс на традиционной цепочке: Алиса и Боб взаимодействуют с смарт-контрактом, развернутым в основной сети, пользователи изменяют состояние смарт-контракта, отправляя транзакции в цепочку. Недостатком является возникновение обсуждаемых выше проблем времени и затрат.
! [Подробный исследовательский отчет из 10 000 слов: всесторонний анализ масштабирования вне сети]###https://img-cdn.gateio.im/webp-social/moments-ead28de03be9fc22dcfe3f679ee36bc5.webp(
На рисунке 2 показан общий рабочий процесс, которому следуют большинство протоколов каналов состояния: в оптимистичном случае Алиса и Боб должны выполнить те же операции, что и ранее, но на этот раз они используют каналы состояния, а не взаимодействуют с контрактами в цепочке.
Первый шаг, Алиса и Боб взаимодействуют, переводя средства с их личного EOA на адрес контракта вне блокчейна ), 1,2(, эти средства блокируются в контракте до тех пор, пока канал не будет закрыт, после чего остаток возвращается пользователю; после подтверждения подписей, статус-канал между ними официально открывается.
Второй шаг, Alice и Bob теоретически могут проводить неограниченное количество транзакций вне блокчейна ) с помощью данного канала, участники обмениваются зашифрованными подписанными сообщениями (, а не общаются с сетью блокчейна ). Оба пользователя должны подписывать каждую транзакцию, чтобы предотвратить мошенничество с двойными расходами. С помощью этих сообщений они предлагают обновления состояния своих счетов и принимают предложенные другим обновления состояния.
Третий шаг, если Алиса хочет закрыть канал и завершить сделку с Бобом, Алисе необходимо представить контракту окончательное состояние своего счета ( взаимодействие 3). Если Боб подпишет и одобрит, контракт вернет заблокированные средства соответствующему пользователю в соответствии с окончательным состоянием ( взаимодействие 4,5). Если Боб не ответит на подпись, контракт вернет заблокированные средства соответствующему пользователю по истечении периода оспаривания.
Рисунок 3 демонстрирует рабочий процесс каналов состояния в пессимистичном сценарии: сначала два участника вносят средства ( взаимодействие 1, 2), а затем начинают обмениваться обновлениями состояния ( синяя пунктирная линия ). Предположим, что в какой-то момент Боб не отвечает на подпись обновления состояния, отправленную Алисой ( взаимодействие 3), в этот момент Алиса может инициировать вызов, подав в контракт свое последнее действительное состояние ( взаимодействие 4), это действительное состояние также содержит подпись Боба, ранее полученную, тем самым подтверждая, что последняя транзакция была одобрена Бобом и последнее состояние было подтверждено Бобом. Затем контракт позволяет Бобу ответить в течение определенного времени, предоставив следующее состояние контракту; если Боб отзывается, то оба могут продолжить транзакции в канале состояния; если Боб не отвечает в этот период, контракт автоматически закрывает канал состояния и возвращает средства Алисе ( взаимодействие 5).
Необходимо заранее внести заблокированные средства
)# 3.1.5 Приложение
Биткойн-Лайтнинг Сеть
Обзор:
Сеть Lightning является каналом микроплатежей в сети Биткойн, ее общая техническая эволюция прошла: создание одностороннего платежного канала с 2/2 мультиподписей, после добавления RSMC###Revocable Sequence Maturity Contract### возможно создание двустороннего платежного канала, затем добавление HTLC(Hash Time Lock Contract) позволит расширить платежный канал на многопользовательские платежи, в конечном итоге сформировав платежную сеть, то есть сеть Lightning. Через вне блокчейна каналы микроплатежей, затем с помощью посредников создается торговая сеть, что может решить проблему масштабируемости сети Биткойн. Общая схема использования сети Lightning соблюдает процесс: "депозит(создание канала)→транзакция сети Lightning(обновление состояния канала)→возврат/расчет(закрытие канала)"; теоретически сеть Lightning может обрабатывать миллион транзакций в секунду.
Временная линия:
В феврале 2015 года Джозеф Пун и Таддеус Дрйя опубликовали черновик белой книги сети Lightning;
В январе 2016 года была выпущена официальная версия белой книги и основана компания Lightning Labs;
15 марта 2018 года Lightning Labs выпустила первую версию основной сети сети Lightning Network Daemon (LND) версии 0.4.
В начале 2021 года публичная емкость сети Lightning (TVL) составляла всего около 40 миллионов долларов, и около 100 тысяч пользователей использовали сеть Lightning.
На этой странице может содержаться сторонний контент, который предоставляется исключительно в информационных целях (не в качестве заявлений/гарантий) и не должен рассматриваться как поддержка взглядов компании Gate или как финансовый или профессиональный совет. Подробности смотрите в разделе «Отказ от ответственности» .
7 Лайков
Награда
7
4
Поделиться
комментарий
0/400
PumpStrategist
· 11ч назад
Снова старая ловушка Нечестивая Троица, на техническом уровне все еще нет прорыва.
Посмотреть ОригиналОтветить0
fork_in_the_road
· 11ч назад
Расширение все еще в процессе.
Посмотреть ОригиналОтветить0
TokenTaxonomist
· 11ч назад
статистически говоря, 99.7% решений масштабирования терпят неудачу при оптимизации трилеммы...
вне блокчейна расширение решений Глубина анализа: State Channels и Биткойн Сеть Lighting
Глубина анализа вне блокчейна расширения
Автор: Cobo Ventures
1. Необходимость масштабирования
Будущее блокчейна видится в децентрализации, безопасности и масштабируемости, но обычно можно реализовать только два из этих аспектов, что называется проблемой невозможного треугольника блокчейна. На протяжении многих лет люди искали способы решить эту задачу, как повысить пропускную способность и скорость транзакций блокчейна при обеспечении децентрализации и безопасности, то есть решить проблему масштабирования, что является одной из актуальных тем в процессе развития блокчейна.
Определение децентрализации, безопасности и масштабируемости блокчейна:
Децентрализация: любой может стать узлом, участвуя в производстве и верификации блокчейн-системы, чем больше узлов, тем выше степень децентрализации, что обеспечивает независимость сети от контроля со стороны небольшого числа крупных централизованных участников.
Безопасность: Чем выше стоимость получения контроля над блокчейн-системой, тем выше безопасность, и цепочка может противостоять атакам значительной доли участников.
Масштабируемость: способность блокчейна обрабатывать большое количество транзакций.
! Подробный исследовательский отчет из 10 000 слов: всесторонний анализ расширения вне сети
Первая значительная хард-форк сети Биткойн возникла из-за проблемы масштабирования. С увеличением числа пользователей и объема транзакций сеть Биткойн с ограничением в 1 МБ на каждый блок начала сталкиваться с проблемами перегрузки; с 2015 года в сообществе Биткойн существовали разногласия по поводу масштабирования, одна сторона поддерживала расширение блока, в то время как другая поддерживала использование решения Segwit для малых блоков. 1 августа 2017 года сторонники масштабирования запустили собственную клиентскую систему, разработанную до 8 МБ, что привело к первой значительной хард-форку в истории Биткойна и появлению новой криптовалюты BCH.
Сеть Эфириума также выбрала пожертвовать частью масштабируемости для обеспечения безопасности и децентрализации сети. Хотя сеть Эфириума не ограничивает объем транзакций, как сеть Биткойна, путем ограничения размера блока, она фактически изменила подход, установив верхний предел на топливные сборы, которые может вместить один блок, но цель остается той же — добиться бездоверительного консенсуса и обеспечить широкое распределение узлов.
С 2017 года, начиная с CryptoKitties, лета DeFi, и до последующего роста таких приложений, как GameFi и NFT, рыночный спрос на пропускную способность постоянно увеличивается, но даже у Тьюринг-полноценного Ethereum в секунду может обрабатывать только 15-45 транзакций (TPS), что приводит к постоянному росту стоимости транзакций, увеличению времени расчета, и большинству Dapps трудно нести операционные расходы. Вся сеть становится медленной и дорогой для пользователей, проблема масштабируемости блокчейна требует срочного решения. Идеальное решение для масштабируемости: максимально повысить скорость транзакций и пропускную способность сети блокчейна без ущерба для децентрализованности и безопасности.
2. Категории решений по масштабированию
Мы разделили планы расширения на две большие категории: расширение на блокчейне и вне блокчейна, основываясь на критерии "изменится ли основной сеть".
2.1 Масштабирование на блокчейне
Основная концепция: решение, достигающее эффекта масштабирования путем изменения уровня протокола основной сети, в настоящее время основное решение - это шардирование.
Существует множество решений для масштабирования в блокчейне, в этой статье не будет подробно рассмотрено, кратко перечислим два решения:
Вариант один заключается в расширении пространства блока, то есть увеличении количества транзакций, упакованных в каждый блок, но это повысит требования к высокопроизводительным узлам, увеличит порог входа для узлов и снизит уровень "децентрализованности".
Вариант два — это шардирование, которое делит блокчейн-реестр на несколько частей, не требуя от каждого узла участия во всех записях, а назначая разные шардированные узлы для ведения разных записей. Параллельные вычисления могут одновременно обрабатывать несколько транзакций; это снижает вычислительную нагрузку на узлы и порог для их присоединения, повышая скорость обработки транзакций и уровень декентрализованности; но это означает, что вычислительная мощность всей сети будет распределена, что снизит "безопасность" всей сети.
Изменение кода протокола основной сети может привести к непредсказуемым негативным последствиям, поскольку любые незначительные уязвимости в безопасности на уровне основного кода могут серьезно угрожать безопасности всей сети, и сеть может быть вынуждена провести форк или прервать ремонтные обновления. Например, инцидент с инфляционной уязвимостью Zcash в 2018 году: код Zcash основан на модифицированном коде версии Bitcoin 0.11.2, в 2018 году один инженер обнаружил высокоопасную уязвимость в его основном коде, а именно, токены могли бесконечно эмитироваться, после чего команда потратила 8 месяцев на секретное исправление, и только после устранения уязвимости этот инцидент был обнародован.
2.2 вне блокчейна расширение
Основная концепция: решение по масштабированию, не изменяющее существующий протокол основной сети первого уровня.
вне блокчейна расширения схемы можно дополнительно разделить на Layer2 и другие схемы:
! Подробный исследовательский отчет из 10 000 слов: всесторонний анализ расширения вне сети
3. Вне блокчейна расширение.
3.1 Государственные каналы
3.1.1 Обзор
Состояние канала предполагает, что пользователям необходимо взаимодействовать с основной сетью только при открытии, закрытии или разрешении споров, а взаимодействие между пользователями осуществляется вне блокчейна, чтобы снизить временные и денежные затраты на транзакции пользователей и обеспечить неограниченное количество транзакций.
Состояние канала — это простой P2P-протокол, подходящий для "приложений на основе раундов", например, для игры в шахматы между двумя игроками. Каждый канал управляется многосторонним смарт-контрактом, работающим в основной сети, который контролирует активы, внесенные в канал, проверяет обновления состояния и арбитражит споры между участниками ( на основании доказательства мошенничества с подписью и временной меткой ). После развертывания контракта в блокчейн-сети участники вносят средства и блокируют их, после подписания обеими сторонами канал официально открывается. Канал позволяет участникам проводить неограниченное количество бесплатных транзакций вне блокчейна (, при условии, что чистая стоимость их переводов не превышает общую сумму внесенных токенов ). Участники поочередно отправляют обновления состояния друг другу, ожидая подтверждения подписи от другой стороны. Как только другая сторона подтверждает подпись, это обновление состояния считается завершенным. В нормальных условиях обновления состояния, согласованные обеими сторонами, не загружаются в основную сеть, только в случае спора или закрытия канала они полагаются на подтверждение основной сети. Когда необходимо закрыть канал, любой участник может подать запрос на транзакцию в основной сети, и если запрос на выход получает единогласное одобрение подписей, то в цепочке немедленно выполняется, то есть смарт-контракт распределяет оставшиеся заблокированные средства в соответствии с балансом каждого участника на конечном состоянии канала; если другие участники не одобрили подпись, то всем придется дождаться окончания "периода вызова", чтобы получить оставшиеся средства.
Таким образом, решение с использованием канала состояния может значительно сократить объем вычислений в основной сети, повысить скорость транзакций и снизить затраты на транзакции.
3.1.2 Хронология
2015/02, Джозеф Пун и Таддеус Дрэджа опубликовали проект белой книги сети Lightning.
В ноябре 2015 года Джефф Коулман впервые систематически обобщил концепцию State Channel и предложил, что Payment Channel в биткойне является подкатегорией концепции State Channel.
2016/01, Joseph Poon и Thaddeus Dryja официально опубликовали белую книгу "The Bitcoin Lightning Network: Scalable Off-Chain Instant Payments", в которой предложили решение для масштабирования сети Биткойн - Payment Channel(, это решение предназначено исключительно для обработки платежей на сети Биткойн.
Ноябрь 2017 года, были предложены первые спецификации дизайна State Channel на основе фреймворка Payment Channel под названием Sprites.
2018/06, Counterfactual предложил очень подробный дизайн обобщённых каналов состояния, это первый полностью связанный с каналами состояния дизайн.
В октябре 2018 года в статье Generalised State Channel Networks была предложена концепция State Channel Networks и Virtual Channels.
2019/02, концепция канала состояния расширена до N-Party Channels, Nitro является первым протоколом, созданным на основе этой идеи.
2019/10, Pisa расширил концепцию Watchtowers, чтобы решить проблему постоянного онлайн-присутствия всех участников.
2020/03, Hydra предложила Быстрые Изоморфные Каналы.
)# 3.1.3 Технический принцип
Рисунок 1 демонстрирует рабочий процесс на традиционной цепочке: Алиса и Боб взаимодействуют с смарт-контрактом, развернутым в основной сети, пользователи изменяют состояние смарт-контракта, отправляя транзакции в цепочку. Недостатком является возникновение обсуждаемых выше проблем времени и затрат.
! [Подробный исследовательский отчет из 10 000 слов: всесторонний анализ масштабирования вне сети]###https://img-cdn.gateio.im/webp-social/moments-ead28de03be9fc22dcfe3f679ee36bc5.webp(
На рисунке 2 показан общий рабочий процесс, которому следуют большинство протоколов каналов состояния: в оптимистичном случае Алиса и Боб должны выполнить те же операции, что и ранее, но на этот раз они используют каналы состояния, а не взаимодействуют с контрактами в цепочке.
Первый шаг, Алиса и Боб взаимодействуют, переводя средства с их личного EOA на адрес контракта вне блокчейна ), 1,2(, эти средства блокируются в контракте до тех пор, пока канал не будет закрыт, после чего остаток возвращается пользователю; после подтверждения подписей, статус-канал между ними официально открывается.
Второй шаг, Alice и Bob теоретически могут проводить неограниченное количество транзакций вне блокчейна ) с помощью данного канала, участники обмениваются зашифрованными подписанными сообщениями (, а не общаются с сетью блокчейна ). Оба пользователя должны подписывать каждую транзакцию, чтобы предотвратить мошенничество с двойными расходами. С помощью этих сообщений они предлагают обновления состояния своих счетов и принимают предложенные другим обновления состояния.
Третий шаг, если Алиса хочет закрыть канал и завершить сделку с Бобом, Алисе необходимо представить контракту окончательное состояние своего счета ( взаимодействие 3). Если Боб подпишет и одобрит, контракт вернет заблокированные средства соответствующему пользователю в соответствии с окончательным состоянием ( взаимодействие 4,5). Если Боб не ответит на подпись, контракт вернет заблокированные средства соответствующему пользователю по истечении периода оспаривания.
! Подробный исследовательский отчет на 10 000 слов: всесторонний анализ масштабирования вне сети
Рисунок 3 демонстрирует рабочий процесс каналов состояния в пессимистичном сценарии: сначала два участника вносят средства ( взаимодействие 1, 2), а затем начинают обмениваться обновлениями состояния ( синяя пунктирная линия ). Предположим, что в какой-то момент Боб не отвечает на подпись обновления состояния, отправленную Алисой ( взаимодействие 3), в этот момент Алиса может инициировать вызов, подав в контракт свое последнее действительное состояние ( взаимодействие 4), это действительное состояние также содержит подпись Боба, ранее полученную, тем самым подтверждая, что последняя транзакция была одобрена Бобом и последнее состояние было подтверждено Бобом. Затем контракт позволяет Бобу ответить в течение определенного времени, предоставив следующее состояние контракту; если Боб отзывается, то оба могут продолжить транзакции в канале состояния; если Боб не отвечает в этот период, контракт автоматически закрывает канал состояния и возвращает средства Алисе ( взаимодействие 5).
! Подробный исследовательский отчет на 10 000 слов: всесторонний анализ масштабирования вне сети
(# 3.1.4 Достоинства и недостатки
Преимущества:
Недостатки:
)# 3.1.5 Приложение
Биткойн-Лайтнинг Сеть
Обзор:
Сеть Lightning является каналом микроплатежей в сети Биткойн, ее общая техническая эволюция прошла: создание одностороннего платежного канала с 2/2 мультиподписей, после добавления RSMC###Revocable Sequence Maturity Contract### возможно создание двустороннего платежного канала, затем добавление HTLC(Hash Time Lock Contract) позволит расширить платежный канал на многопользовательские платежи, в конечном итоге сформировав платежную сеть, то есть сеть Lightning. Через вне блокчейна каналы микроплатежей, затем с помощью посредников создается торговая сеть, что может решить проблему масштабируемости сети Биткойн. Общая схема использования сети Lightning соблюдает процесс: "депозит(создание канала)→транзакция сети Lightning(обновление состояния канала)→возврат/расчет(закрытие канала)"; теоретически сеть Lightning может обрабатывать миллион транзакций в секунду.
Временная линия: