《вне блокчейна расширение Глубина анализа》

Автор: исследовательская группа

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Изменение кода протокола основной сети может привести к непредсказуемым негативным последствиям, поскольку любые незначительные уязвимости в безопасности на нижнем уровне могут серьезно угрожать безопасности всей сети, и сеть может быть вынуждена провести форк или прервать обновление для исправления. Например, инцидент с инфляционной уязвимостью 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 официально опубликовалиWhite Paper «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(, эти средства блокируются в контракте и возвращаются пользователям только после закрытия канала; после подтверждения подписей обе стороны официально открывают состояние канала.
• Второй шаг, Алиса и Боб теоретически могут проводить неограниченное количество транзакций вне блокчейна ) с помощью этого канала, участники общаются друг с другом с помощью зашифрованных подписанных сообщений (, а не общаются с сетью блокчейна ). Оба пользователя должны подписывать каждую транзакцию, чтобы предотвратить двойное расходование. С помощью этих сообщений они предлагают обновления состояния своих аккаунтов и принимают предложенные обновления состояния друг друга.
• Шаг третий, если Алиса хочет закрыть канал и завершить сделку с Бобом, Алисе необходимо представить в контракт окончательное состояние своего счета ( взаимодействие 3), если Боб подпишет и одобрит, контракт освободит заблокированные средства и вернет их соответствующему пользователю ( взаимодействие 4,5). Если Боб не ответит подписью, контракт освободит заблокированные средства и вернет их соответствующему пользователю после окончания периода оспаривания.

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

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

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

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

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

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

Недостатки:

• Необходимо заблокировать средства
• При закрытии канала требуется подтверждение в блокчейне
• Участники должны оставаться в сети
• Не подходит для крупных или редких сделок
• Есть риск кражи средств

)# 3.1.5 Приложение

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

Обзор:

Сеть Lightning является каналом мелких платежей в сети Bitcoin, ее общая техническая эволюция проходит через: 2/2 многоподписная конструкция одностороннего платежного канала, добавление RSMC###Revocable Sequence Maturity Contract### позволяет построить двусторонний платежный канал, затем добавляется