Глубина анализа вне блокчейна

1. Необходимость масштабирования

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

Определение децентрализации, безопасности и масштабируемости блокчейна:

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

• Безопасность: Чем выше стоимость получения контроля над системой, тем выше безопасность, цепочка может сопротивляться атакам значительного числа участников.

• Масштабируемость: способность блокчейна обрабатывать большое количество транзакций.

Первая значительная хард-форк в сети Биткойн возникла из-за проблемы масштабирования. С увеличением числа пользователей и объема транзакций сеть Биткойн с ограничением в 1 МБ на блок начала сталкиваться с проблемой перегрузки; с 2015 года в сообществе Биткойн существовали разногласия по поводу масштабирования: одна сторона поддерживала увеличение размера блока, другая считала, что следует использовать решение Segwit для оптимизации структуры основной цепи. 1 августа 2017 года Bitcoin ABC, поддерживающий увеличение блока, самостоятельно разработал и запустил клиентскую систему на 8 МБ, что привело к первой значительной хард-форк в истории Биткойн и появлению новой криптовалюты BCH.

Сеть Эфириум также выбирает жертву некоторой масштабируемости ради обеспечения безопасности сети и децентрализации. Хотя сеть Эфириум не ограничивает объем транзакций, как сеть Биткойн, путем ограничения размера блока, она косвенно преобразуется в установление предела на топливные сборы, которые могут быть приняты в одном блоке, но цель все та же — достичь бездоверительного консенсуса и гарантировать широкое распределение узлов.

С 2017 года с появлением CryptoKitties, лето DeFi, а затем GameFi и NFT, спрос на пропускную способность на рынке постоянно растет. Однако даже Эфириум с полной Тьюрингом может обрабатывать всего 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/11, Джефф Коулман впервые систематически обобщил концепцию State Channel и предложил, что Payment Channel биткойна является подкатегорией концепции State Channel.
• 2016/01, Джозеф Пун и Таддеус Дрйя официально опубликовали белую книгу «Сеть мгновенных платежей Bitcoin Lightning: Масштабируемые вне блокчейна мгновенные платежи», предложившую решение по масштабированию сети Bitcoin, каналы платежей (, этот план предназначен только для обработки переводов на сети Bitcoin.
• Ноябрь 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-087d35594a04d33375b8199b93eb355e.webp(

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

• Первый шаг, Алиса и Боб взаимодействуют, переводя средства со своих личных EOA на адрес контракта вне блокчейна ), 1,2(, эти средства блокируются в контракте и возвращаются пользователю только после закрытия канала; после подтверждения подписей между ними статус канала официально открывается.
• Второй шаг: теоретически, Алиса и Боб могут проводить неограниченное количество сделок вне блокчейна через этот канал ) синяя пунктирная линия (, участники обмениваются зашифрованными сообщениями с подписями ), а не общаются с сетью блокчейна (. Оба пользователя должны подписывать каждую сделку, чтобы предотвратить злоупотребления с двойными расходами. С помощью этих сообщений они предлагают обновления состояния своих счетов и принимают обновления состояния, предложенные другой стороной.
• Третий шаг, если Алиса хочет закрыть канал и завершить сделку с Бобом, Алиса должна предоставить контракту окончательное состояние своего счета ) взаимодействие 3(. Если Боб подпишет и одобрит, контракт вернет заблокированные средства соответствующему пользователю ) взаимодействие 4,5( на основании окончательного состояния. Если Боб не ответит подписью, контракт вернет заблокированные средства соответствующему пользователю по истечении срока оспаривания.

! [Подробный исследовательский отчет из 10 000 слов: всесторонний анализ масштабирования вне сети])https://img-cdn.gateio.im/webp-social/moments-ead28de03be9fc22dcfe3f679ee36bc5.webp(

Рисунок 3 показывает рабочий процесс канала состояния в пессимистичном сценарии: изначально два участника вносят средства ) взаимодействие 1, 2(, а затем начинают обмениваться обновлениями состояния ) синей пунктирной линией (. Предположим, что в какой-то момент времени Боб не отвечает на отправленный Элис обновление состояния с подписью ) взаимодействие 3(, в этот момент Элис может инициировать вызов, подав контракту свое последнее действительное состояние ) взаимодействие 4(, это действительное состояние также включает подпись Боба, тем самым доказывая, что последняя транзакция была одобрена Бобом, и окончательное состояние было подтверждено Бобом. Затем контракт позволяет Бобу в течение определенного времени ответить, предоставив следующее состояние контракту; если Боб отвечает, оба могут продолжать совершать сделки в канале состояния; если Боб не ответит в течение этого периода, контракт автоматически закроет канал состояния и вернет средства Элис ) взаимодействие 5(.

! [Подробный исследовательский отчет на 10 000 слов: всесторонний анализ масштабирования вне сети])https://img-cdn.gateio.im/webp-social/moments-ad088ac016d75b1ae0b0eda699e74709.webp(

)# 3.1.4 Плюсы и минусы

Преимущества:

• Высокая масштабируемость: неограниченные транзакции
• Низкая задержка: торговля завершается мгновенно
• Низкая стоимость: вне блокчейна торговля практически не имеет затрат
• Приватность: вне блокчейна транзакции не будут записываться в главной цепочке
• Доступность: даже если основная цепь имеет проблемы, каналы состояния все равно будут доступны.

Недостатки:

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

3.1.5 Приложение

Биткойн сеть Lightning

Обзор:

Сеть 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 миллионов долларов.