Глубина анализа масштабирования вне блокчейна

Автор: Эллейн Сюй, Хетти Цзян, Джун Ван, Уалон Лин, Ийлю Лин

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

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

Давайте сначала обобщенно определим децентрализацию, безопасность и масштабируемость блокчейна:

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

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

Таким образом, сеть Ethereum также выбрала пожертвовать частью масштабируемости ради обеспечения безопасности и децентрализации сети; хотя сеть Ethereum не ограничивает объем транзакций, как сеть Bitcoin, ограничивая размер блока, она косвенно изменила подход, установив верхний предел на плату за газ, которую может содержать один блок, но цель остается той же – достижение Trustless Consensus и обеспечение широкого распределения узлов (, независимо от того, отменяется ли предел или он увеличивается, это приведет к исключению многих мелких узлов с недостаточной пропускной способностью, хранилищем и вычислительными ресурсами ).

С 2017 года, начиная с CryptoKitties, через лето DeFi, и затем ростом приложений GameFi и NFT, рынок испытывает растущий спрос на пропускную способность. Однако даже полностью функциональный Ethereum может обрабатывать всего 15–45 транзакций в секунду (TPS), что приводит к тому, что стоимость транзакций постоянно растет, время расчета увеличивается, и большинству Dapps становится трудно выдерживать операционные расходы. Вся сеть становится медленной и дорогой для пользователей, и проблему масштабируемости блокчейна необходимо срочно решать. Идеальное решение для масштабируемости: повысить скорость транзакций блокчейн-сети ( более короткое время окончательной обработки ) и пропускную способность транзакций ( более высокий TPS), не жертвуя децентрализацией и безопасностью.

! Подробный исследовательский отчет из 10 000 слов: всесторонний анализ расширения вне сети

2. Категории решений по расширению

Мы разделили планы расширения на две основные категории: расширение на блокчейне и вне блокчейна, основываясь на критерии "изменится ли один уровень основной сети".

2.1 Масштабирование в блокчейне

Основная концепция: решение, достигающее эффекта масштабирования путем изменения одного уровня протокола основной сети, в настоящее время основным решением является шarding.

На цепи существует множество решений для масштабирования, в этой статье не будет рассмотрено подробно, ниже кратко перечислены два решения:

• Вариант 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, 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 предложила Быстрые Изоморфные Каналы.

! Подробный исследовательский отчет из 10 000 слов: всесторонний анализ масштабирования вне сети

3.1.3 Технические принципы

Общий рабочий процесс состояния канала выглядит следующим образом:

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

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

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

! Подробный исследовательский отчет на 10 000 слов: всесторонний анализ масштабирования вне сети

3.1.4 Преимущества и недостатки

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

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

Недостаток:

• Необходимо заблокировать средства
• Все участники должны оставаться онлайн.
• Ограниченная емкость канала
• Установление и закрытие канала требует плату за транзакцию
• Сложные смарт-контракты трудно реализовать
• Проблема ликвидности

3.1.5 Приложение

Биткойн Сеть Молний

Обзор: Сеть Lightning — это канал для мелких платежей в сети Биткойн, который прошел эволюцию технологий: 2/2 многоподписный однонаправленный платежный канал, после добавления RSMC можно создать двунаправленный платежный канал, затем с добавлением HTLC можно расширить платежный канал на множество участников и, в конечном итоге, создать платежную сеть, то есть сеть 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.
• В июне 2021 года Сальвадор объявил о принятии биткойна в качестве законного платежного средства, в сентябре был выпущен кошелек Chivo на основе сети Lightning.
• В 2022 году Cash App и 26 криптовалютных платформ, включая OKX, Kraken и Bitfinex, объявили о поддержке сети Lightning, что позволяет осуществлять мгновенные и дешевые депозиты и снятие средств в BTC.
• В октябре 2022 года Lightning Labs выпустила новый протокол на основе Taproot — Taro protocol(alpha версия), который в настоящее время проходит тестирование в тестовой сети и в будущем будет доступен для создания, отправки и получения активов в сети Биткойн и через сеть Lightning.