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

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

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.

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

• Вариант один - это расширение пространства блоков, то есть увеличение количества транзакций, упакованных в каждый блок, но это повысит требования к высокопроизводительным узлам оборудования, увеличит порог входа для узлов и снизит степень "децентрализации".
• Решение 2 — шардинг, который делит реестр блокчейна на несколько частей, уже не каждый узел участвует во всей бухгалтерии, а разные шарды, то есть разные узлы отвечают за разную бухгалтерию, а параллельные вычисления могут обрабатывать несколько транзакций одновременно; Это может снизить вычислительную нагрузку на узлы и порог для присоединения, а также повысить скорость обработки транзакций и децентрализацию. Однако это означает, что вычислительные мощности всей сети рассредоточены, что снизит «безопасность» всей сети.

Изменение кода протокола основной сети может привести к непредсказуемым негативным последствиям, так как любые незначительные уязвимости в безопасности на уровне основного кода могут серьезно угрожать безопасности всей сети, что может вынудить сеть произвести форк или прервать обновление. Например, инцидент с инфляционной уязвимостью Zcash в 2018 году: код Zcash основан на модифицированном коде версии Bitcoin 0.11.2, в 2018 году инженер обнаружил уязвимость в основном коде, которая позволяла бесконечно эмитировать токены, и команда потратила 8 месяцев на тайное исправление, после чего инцидент был раскрыт.

2.2 вне блокчейна расширение

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

вне блокчейна расширения схемы можно дополнительно разделить на Layer2 и другие схемы:

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

3. Решение по расширению вне блокчейна

3.1 Каналы состояния

3.1.1 Обзор

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

Состояние канала — это простой P2P-протокол, подходящий для "игр с пошаговым режимом", например, для шахмат на двоих. Каждый канал управляется многофункциональным смарт-контрактом, работающим в основной сети, который контролирует активы, внесенные в канал, проверяет обновления состояния и разрешает споры между участниками ( на основе доказательства мошенничества с подписями и временными метками ). После развертывания контракта в блокчейн-сети участники вносят средства и блокируют их, после того как обе стороны подписали подтверждение, канал официально открывается. Канал позволяет участникам совершать неограниченное количество бесплатных транзакций вне блокчейна (, при условии, что их чистая стоимость перевода не превышает общей суммы внесенных токенов ). Участники поочередно отправляют обновления состояния друг другу, ожидая подтверждения подписи от противоположной стороны. Как только другая сторона подтверждает подпись, обновление состояния считается завершенным. В нормальных условиях согласованные обновления состояния не загружаются в основную сеть, они зависят от подтверждения основной сети только в случае спора или закрытия канала. Если необходимо закрыть канал, любой участник может подать запрос на транзакцию в основной сети, и если запрос на выход получит единогласное одобрение подписей, он будет немедленно выполнен на цепочке, то есть смарт-контракт распределит оставшиеся заблокированные средства в зависимости от баланса каждого участника по окончательному состоянию канала; если другие участники не одобрят подпись, то всем придется ждать завершения "периода вызова", прежде чем они получат оставшиеся средства.

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

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

3.1.2 Хронология

• 2015/02, Joseph Poon и Thaddeus Dryja опубликовали проект белой книги сети 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 предложил очень подробный дизайн Generalized State Channels, это первый полностью связанный с состоянием каналов дизайн.
• В октябре 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. Алиса и Боб переводят средства с личного EOA на адрес контракта в блокчейне, эти средства блокируются в контракте до тех пор, пока канал не будет закрыт, после чего остаток возвращается пользователю; после подписания подтверждения обоими, статус-канал между ними официально открывается.

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

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

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

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

3.1.4 Достоинства и недостатки

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

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

Недостатки:

• Низкая эффективность использования средств, необходимо заблокировать средства
• Неудобен для пользователей, требуется постоянный онлайн мониторинг канала
• Создание канала довольно сложно
• Трудно разработать универсальный канал состояний
• Недостаток ликвидности, канал не может гибко перемещать средства

3.1.5 Приложение

Биткойн-Лайтнинг Сеть

Обзор: Сеть Lightning является каналом малых платежей в сети Bitcoin, ее общая техническая эволюция прошла через: 2/2 мультиподписей для создания одностороннего платежного канала, добавление RSMC(Revocable Sequence Maturity Contract) позволяет создать двусторонний платежный канал, а добавление HTLC(Hash Time Lock Contract) позволяет расширить платежный канал до многосоставных платежей, в конечном итоге создавая платежную сеть, то есть сеть Lightning. Через вне блокчейна каналы малых платежей, а затем с помощью посредников формируется сеть транзакций, что может решить проблему расширения сети Bitcoin. Общая процедура использования сети Lightning следует за "депозит(создание канала)→ транзакции сети Lightning(обновление состояния канала)→ возврат/расчет(закрытие канала)"; теоретически сеть Lightning может обрабатывать миллион транзакций в секунду.

Временная линия:

• Февраль 2015 года, Джозеф Пун и Тадеуш Дрйя опубликовали черновик белой книги сети Lightning;
• В январе 2016 года была выпущена официальная версия белой книги и была основана