CKB联创Jan：что такое проблема голода L1 и как следует проектировать L2 и L1

Компиляция: Misty & Байдинг, Гик web3

Этот текст - выступление сооснователя Nervos Джана на конференции HBS Blockchain+Crypto Club 2019 года. Тема выступления - взаимоотношения между Layer2 и Layer1, ясно указывая, что модульный блокчейн будет правильным направлением, а также затрагивает вопросы механизма хранения данных в блокчейне. В то же время, Джан бросает интересную тему: что делать, если восход Layer2 приведет к голоданию Layer1.

Как одна из первых команд, поддерживающих Layer2 и модульный блокчейн, идеи Nervos были прогнозными в 18-19 годах, когда сообщество ETH все еще восхищалось Шардингом, несбыточной мечтой, а идея высокопроизводительной одиночной цепи была еще не полностью оправдана.

Но сегодня, в 2024 году, при взгляде на проблемы, выявленные в практике ETH Layer2, а также недостатки “высокопроизводительных общественных цепочек”, представленных Solana, в Децентрализация и проблемы доверия, нельзя не сказать, что у Jan было предчувствие 5 лет назад. Из интереса к самому Layer2, “гик web3” составил текстовую версию лекции Яна, опубликованную здесь, и приглашает любителей Layer2 из сообществ Nervos, ETH и BTC присоединиться к обучению и обсуждению.

Ниже приведен оригинальный текст лекции Джана.

Определение Layer1 и Layer2

Это моё определение L1 и L2 (сети второго уровня), как показано на рисунке.

Прежде всего следует подчеркнуть, что Nerovs - это просто блокчейн-сеть, которая стремится удовлетворить потребности децентрализованной экономики, и не несет ответственности за решение “всех проблем”. На наш взгляд, ключевой разницей между Layer1 и Layer2 является сила Соглашения. L1-сеть должна иметь наиболее широкое Соглашение, то есть “глобальное соглашение”. Через глобальное Соглашение без разрешения любой человек в мире может участвовать в процессе Соглашения L1, и в конечном итоге Layer1 может служить “якорем” децентрализованной экономики. С этой точки зрения мы можем назвать L1 “уровнем соглашения”.

В отличие от них, сети L2 имеют меньший охват, и их участники могут быть из страны, или отрасли, или даже компании, или учреждения, или небольшого сообщества. Жертва L2 в линейке Соглашений достигается за счет других улучшений, таких как более высокий TPS, меньшая задержка и лучшая масштабируемость. Мы можем назвать L2 “уровнем протокола”, а L1 и L2 часто соединяются кроссчейн мост.

Необходимо подчеркнуть, что наша цель при построении сети L2 заключается не только в решении проблемы масштабируемости блокчейна, а в том, что именно слоями делается самым удобным способом внедрения “Модульный блокчейн”. Под “Модульный блокчейн” подразумевается размещение различных типов задач в разные модули для их решения.

Многие люди всегда говорят о вопросах соответствия и регулирования блокчейна, так как мы можем включить BTC или ETH в существующую регулирующую рамку? Возможно, слоистая архитектура является одним из ответов на этот вопрос. Прямое добавление бизнес-логики, соответствующей требованиям регулирования, на уровне Layer1 может нарушить его децентрализацию и нейтральность, поэтому логика, связанная с соответствием, может быть реализована отдельно на Layer2.

Layer2 можно настраивать в соответствии с определенными правилами или стандартами, такими как создание маленькой блокчейн-сети на основе лицензирования или состояние каналов и т.д. Это позволяет обеспечить соблюдение требований и не влиять на децентрализацию и нейтральность Layer1.

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

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

Вышеперечисленное естественным образом приводит к вопросу: может ли любая блокчейн-сеть быть использована как Layer1?

Ответ отрицательный. Прежде всего, мы должны понять, что Децентрализация и безопасность сети Layer1 превыше всего, потому что нам нужна Децентрализация для обеспечения защиты от цензуры. Преследование безопасности Layer1 в своей сути является следствием того, что L1 является корнем всей сети блокчейн и является якорем всей экономической системы шифрования.

По таким критериям **BTC и Ethereum, безусловно, являются самыми классическими сетями L1, у них сильный диапазон Биткойн. За исключением этих двух, большинство блокчейнов не соответствует стандартам L1, уровень Соглашение ниже. Например, у EOS Соглашение не соответствует стандартам, она может действовать только как сеть L2, к тому же некоторые её правила применимы только к самой себе.

Проблемы текущей сети Layer1

После четкого определения Layer1 мы должны указать, что существуют три проблемы в некоторых существующих L1-сетях, которые, в определенной степени, присутствуют даже в сетях BTC и ETH:

1. Проблема трагедии общинного характера при хранении данных

При использовании Блокчейна нам нужно платить определенную плату, но в экономической модели BTC структура комиссий учитывает только стоимость вычислений и стоимость пропускной способности сети, но не учитывает зрелую стоимость хранения данных.

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

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

Фонд Ethereum осознал вышеупомянутую проблему и в связи с этим в EIP-103 был добавлен дизайн для системы аренды хранилища, но мы считаем, что это не является наилучшим решением.

Мы предложили новую модель состояния в Nervos, называемую “Cell”, которую можно рассматривать как расширение UTXO. В состоянии BTC UTXO вы можете хранить только остаточное значение BTC, в то время как в Cell можно хранить данные любого типа, и обобщить amount и integer value BTC UTXO как “Capacity”, чтобы указать максимальную хранящуюся в Cell емкость.

Таким образом, мы связываем количество и состояние оригинальных активов на CKB с их размером. Пространство, занимаемое каждой ячейкой, не может превышать ее емкость, поэтому общий объем данных будет оставаться в определенных пределах.

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

2. Проблема голода в Layer1

Если мы расширяемся на Layer2 и переносим большую часть торговой активности на Layer2, это неизбежно приведет к снижению количества транзакций на Layer1, что также приведет к соответствующему снижению экономической награды для майнеров/узлов Layer1. Это может привести к снижению мотивации майнеров/узлов Layer1 и, в конечном итоге, к снижению безопасности Layer1. Это и есть так называемая проблема голода Layer1.

Приведем крайний пример: если мы перенесем все торговые операции на L2, то L1 в качестве его основы станет неустойчивым. Так что, как решить эту проблему?

Для этого нам нужно различать, какие типы пользователей присутствуют в сети блокчейн, в общем можно выделить пользователей Store of Value (SoV) (пользователи сохранения стоимости) и пользователей Utility (пользователи приложений).

Возьмем, например, CKB, пользователи SoV используют местные активы CKB в качестве средства сохранения стоимости, в то время как пользователи утилиты используют Cell для хранения состояния. Пользователи SoV отрицают разбавление цены, вызванное инфляцией токенов CKB, в то время как пользователи утилиты должны оплатить Майнеру плату за хранение состояния, которая пропорциональна продолжительности и занимаемому месту для хранения данных.

Мы будем продолжать выпускать новые токены CKB в сети, чтобы создать фиксированную инфляцию и распределить их майнерам. Это эквивалентно размытию стоимости токенов в руках пользователей-пользователей (это одна из трех вариантов выпуска в экономической модели CKB, известная как «вторичный выпуск», с фиксированным выпуском 1.344 миллиарда токенов CKB ежегодно. Подробнее можно узнать в статье «Декодирование Stable++: RGB++ Layer First Stable Coin Protocol Sets Sail»).

В этом процессе также размывается активы пользователей SoV, поэтому мы можем предоставить им определенную компенсацию для компенсации потерь от инфляции (что впоследствии станет NervosDAO). Другими словами, доход, получаемый Майнером от инфляции CKB, на самом деле покрывается только пользователем Utility. В скором времени мы выпустим Токен эфира CKB, в котором эти вопросы будут подробно описаны.

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

3.Отсутствие базового шифрования

Пользователям необходимо использовать различные шифровальные примитивы для использования различных способов шифрования или различных алгоритмов подписи, таких как Schnorr, BLS и т. д.

Для того, чтобы стать блокчейном уровня Layer1, необходимо рассмотреть вопрос взаимодействия с Layer2. Некоторые члены сообщества Ethereum предлагают использовать ZK или Plasma для реализации Layer2, но если нет соответствующих примитивов ZK, как можно выполнить проверку на уровне Layer1?

Кроме того, Layer1 также должен учитывать взаимодействие с другими Layer1. Возьмем в качестве примера Ethereum: кто-то запросил у команды Ethereum предварительную компиляцию хэш-функции Blake2b в операционный код, совместимый с EVM. Цель этого предложения - создать мост между Zcash и Ethereum, чтобы пользователи могли проводить транзакции между ними. Хотя данное предложение было сделано два года назад, до сих пор оно не было реализовано из-за отсутствия соответствующей криптографической примитивы, что серьезно затрудняет развитие Layer1.

Для решения этой проблемы CKB создал высокоуровневую Виртуальную машину, называемую CKB-VM, которая существенно отличается от Виртуальной машины BTC и EVM. Например, BTC имеет специальный операционный код OP_CHECKSIG, который используется для проверки подписи secp256k1 в BTC-транзакциях. В CKB-VM подпись secp256k1 не требует особой обработки, ее можно проверить с помощью пользовательских скриптов или смарт-контрактов.

CKB также использует secp256k1 в качестве своего Алгоритм подписи по умолчанию, только в CKB-VM, а не встроенный шифрования примитив.

Основная цель CKB - создание Виртуальная машина. В других Виртуальная машинах, таких как EVM, шифрование крайне медленно, что требует улучшения. Для проверки единичной подписи secp256k1 в EVM требуется около 9 миллисекунд, однако при использовании того же Алгоритма в CKB-VM этот процесс занимает всего 1 миллисекунду, что означает увеличение эффективности в почти десять раз.

Таким образом, ценность CKB-VM заключается в том, что пользователь теперь может настраивать собственные примитивы шифрования, и большинство из них совместимы с CKB-VM, поскольку CKB-VM использует набор команд RISC-V, и любой язык, скомпилированный с помощью GCC (GNU Compiler Collection, широко используемая коллекция компиляторов), может выполняться на CKB.

Кроме того, высокая совместимость CKB-VM также повышает безопасность CKB. Как разработчики всегда говорят: “Не реализуйте свою собственную версию криптографических алгоритмов, вы всегда будете делать это неправильно”, самостоятельное определение Алгоритм шифрования часто несет в себе непредвиденные риски безопасности.

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