Nervos Network (CKB) - многоуровневая криптоэкономическая сеть 

Nervos - это многоуровневая криптоэкономическая сеть. Nervos разделяет инфраструктуру криптоэкономики на два уровня: уровень проверки (уровень 1), который служит доверительным корнем и интеллектуальным хранителем, и уровень генерации (уровень 2) для высокопроизводительных транзакций и защиты конфиденциальности.

Мы представляем собой многоуровневую криптоэкономику, и CKB является ее базовым уровнем.

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

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

Nervos CKB (Common Knowledge Base) - это блокчейн уровня 1, децентрализованный и безопасный уровень, который обеспечивает хранение общих знаний в сети. Общие знания относятся к состояниям, подтвержденным глобальным консенсусом. Криптоактивы - это общеизвестный пример.

В Nervos CKB и все протоколы уровня 2 работают вместе, чтобы служить криптоэкономике. CKB (или уровень 1) - это место, где хранится и определяется состояние, а уровень 2 - это уровень генерации (или уровень вычислений, эти два термина взаимозаменяемы), который обрабатывает большинство транзакций и генерирует новые состояния. Участники уровня 2 отправляют новые сгенерированные состояния в CKB в конечном итоге в то время, которое они сочтут необходимым. Если эти состояния проходят соответствующую проверку, выполняемую узлами в глобальной сети, CKB надежно сохраняет их в одноранговом узле.

Многоуровневая архитектура разделяет состояние и вычисления, обеспечивая каждому уровню большую гибкость и масштабируемость. Например, блокчейны на уровне генерации (уровень 2) могут использовать разные консенсусные алгоритмы. CKB - это самый низкий уровень с самым широким консенсусом и обеспечивает самый безопасный консенсус в сети Nervos. Однако разные приложения могут предпочесть разные области действия консенсуса, и принуждение всех приложений к использованию консенсуса CKB будет неэффективным. Приложения могут выбирать подходящие методы генерации в зависимости от своих конкретных потребностей. Единственный раз, когда эти приложения будут нуждаться в отправке состояний в CKB для более широкого согласия, - это когда им необходимо сделать эти состояния общими знаниями, что было подтверждено глобальным консенсусом CKB.

Возможные методы генерации состояния включают в себя (но не ограничиваются ими) следующее:

  • Локальные генераторы на клиенте: генераторы запускаются непосредственно на клиентских устройствах. Разработчики могут реализовать генератор на любом языке программирования.
  • Веб-сервисы: пользователи могут использовать традиционные веб-сервисы для создания новых состояний. Все текущие веб-службы могут работать с CKB таким образом, чтобы получить больше доверия и ликвидности для сгенерированных состояний. Например, игровые компании могут определять внутриигровые предметы как активы в CKB, сама игра функционирует как веб-сервис, который генерирует игровые данные, которые затем проверяются и сохраняются в CKB.
  • Каналы состояний: два или более пользователя могут использовать одноранговую связь для создания новых состояний.
    Цепочки генерации: Цепочка генерации - это цепочка блоков, которая генерирует новые состояния и сохраняет их в CKB. Цепочки генерации могут быть блокчейнами без прав доступа или блокчейнами с разрешениями. В каждой цепочке поколений узлы достигают консенсуса в меньших масштабах, обеспечивая лучшую конфиденциальность и производительность.

Многоуровневая архитектура

CKB состоит из консенсуса на основе Proof-of-Work, виртуальной машины на основе набора команд RISC-V, модели состояний, основанной на ячейках, экономической модели, ориентированной на состояние, и одноранговой сети. Консенсус на основе Proof-of-Work делает CKB публичным и устойчивым к цензуре сервисом. Комбинация виртуальной машины CKB и модели Cell создает для разработчиков полную по Тьюрингу модель программирования с сохранением состояния, что делает создание состояния (или уровень 2) на CKB практичным. Экономическая модель CKB предназначена для хранения общих знаний и долгосрочной устойчивости. Одноранговая сеть CKB обеспечивает безопасную и оптимальную связь между различными типами узлов.

Консенсус

Консенсус CKB - это улучшенный консенсус Накамото, основанный на Proof-of-Work, который направлен на достижение открытости, правильности и высокой производительности в распределенных средах с сетевой задержкой и сбоями византийских узлов.

Блокчейны без разрешений работают в открытых сетях, где узлы могут свободно присоединяться и выходить без каких-либо предположений о жизнеспособности. Это серьезные проблемы, которые необходимо решить традиционным алгоритмам консенсуса BFT. Сатоши Накамото представил экономические стимулы и вероятностный консенсус для решения этих проблем. Консенсус Накамото в Биткойне использует блоки в качестве голосов, что занимает больше времени (от 10 минут до часа) для подтверждения транзакций и приводит к ухудшению пользовательского опыта.

Консенсус CKB - это вариант консенсуса Накамото, что означает, что он позволяет узлам свободно присоединяться и выходить из сети. Каждый узел может участвовать в процессе консенсуса либо путем майнинга (запуск определенного алгоритма для поиска Proof-of-Work) для создания новых блоков, либо путем проверки допустимости новых блоков. CKB использует ASIC-нейтральную функцию Proof-of-Work с целью максимально равномерного распределения токенов и обеспечения максимальной безопасности сети.

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

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

Модель программирования

CKB предоставляет полную по Тьюрингу модель программирования, основанную на модели CKB VM и ячейки.

Модель программирования CKB состоит из трех частей:

  • Генерация состояния (вне сети);
  • Государственная проверка (CKB VM);
  • Хранилище состояний (модель ячейки).

В этой модели логика децентрализованного приложения разделена на две части (генерация и проверка), выполняемые в разных местах. Логика генерации состояний выполняется на стороне клиента вне сети; новые состояния упаковываются в транзакции и транслируются по всей сети. Транзакции CKB имеют структуру на основе входов / выходов, такую ​​как биткойн. Входные данные транзакции - это ссылки на предыдущие выходы вместе с доказательствами для их разблокировки. Клиент включает сгенерированные новые состояния в качестве выходных данных транзакции, которые в CKB называются ячейками. Ячейки являются основными единицами хранения состояний в CKB и являются активами, принадлежащими пользователям, которые должны следовать связанной логике приложения, указанной в сценариях. CKB VM выполняет эти сценарии и проверяет доказательства, включенные во входные данные, чтобы убедиться, что пользователю разрешено использовать ячейки, на которые имеются ссылки, и что переход состояния действителен в соответствии с указанной логикой приложения. Таким образом, все узлы в сети проверяют, что новые состояния действительны, и держат эти состояния под контролем.

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

Генерация состояния и проверка

Децентрализованные приложения на Nervos разделяют генерацию и проверку состояния. Хотя эти процессы происходят в разных местах, CKB обеспечивает дополнительную гибкость для использования различных алгоритмов для генерации и проверки состояния.

Использование одного и того же алгоритма как для генерации, так и для проверки - простой выбор, который работает для общих проблем. В этой модели один и тот же алгоритм имеет две реализации: одна работает вне цепочки в любой среде выполнения, на которую ориентировано приложение, а другая - в цепочке в CKB VM. Новые состояния генерируются вне сети с помощью этого алгоритма (на основе предыдущих состояний и вводимых пользователем данных), упаковываются как транзакция, а затем транслируются в сеть. Узлы CKB запускают тот же алгоритм в цепочке, предоставляют ему те же предыдущие состояния и пользовательские входные данные, а затем проверяют, что результат соответствует выходным данным, указанным в транзакции.

У такого разделения генерации состояния и проверки есть несколько преимуществ:

  • Детерминированные транзакции: уверенность в выполнении транзакции - одно из основных направлений децентрализованных приложений. Если транзакции включают только ввод данных пользователем, а новые состояния являются результатом вычислений на узлах (как показано в Ethereum), создатель транзакции не может быть уверен в контексте вычислений в цепочке, что может привести к неожиданным результатам. В CKB пользователи генерируют новые состояния на стороне клиента. Они могут подтвердить новые состояния перед широковещательной рассылкой своего перехода в сеть. Результат транзакции определен: либо транзакция проходит проверку в цепочке и новое состояние принимается, либо транзакция считается недействительной, и в CKB не происходит никаких изменений состояния.
  • Параллелизм: если транзакции включают только вводимые пользователем данные, а новые состояния генерируются узлами, тогда узлы не будут знать, к какому состоянию будет обращаться процесс проверки, и не смогут определить зависимости между транзакциями. В CKB, поскольку транзакции явно включают предыдущие состояния и новые состояния, узлы могут видеть зависимости между транзакциями до проверки и могут обрабатывать транзакции параллельно.
  • Более высокое использование ресурсов: поскольку логика приложения разделяется и запускается в разных местах, сеть может более равномерно распределять вычислительную нагрузку между узлами и клиентами и, таким образом, более эффективно использовать системные ресурсы.
  • Гибкая генерация состояния: даже когда используются одни и те же алгоритмы, разработчики могут реализовать генерацию и проверку по-разному. На стороне клиента существует возможность выбора языка программирования, который обеспечивает лучшую производительность и быструю разработку.

В некоторых сценариях проверка состояния может использовать другой (но связанный) алгоритм, который намного более эффективен, чем тот, который используется для генерации состояния. Наиболее типичный пример можно увидеть в транзакциях Биткойн: построение транзакции Биткойн состоит в основном из процесса поиска для определения подходящих UTXO для использования, а проверка - это добавление чисел и простое сравнение. К другим интересным примерам относятся алгоритмы сортировки и поиска: вычислительная сложность быстрой сортировки, одного из лучших алгоритмов сортировки для среднего случая, составляет O (Nlog (N)), но алгоритм проверки результата составляет всего O (N). Поиск индекса элемента в отсортированном массиве осуществляется за O (log (N)) с двоичным поиском, но его проверка занимает только O (1). Чем сложнее бизнес-правила,

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

Мы называем программы, которые генерируют новые состояния и создают новые ячейки, генераторами. Генераторы работают локально на стороне клиента (вне сети). Они используют вводимые пользователем данные и существующие ячейки в качестве входных данных программы, чтобы создавать новые ячейки с новыми состояниями в качестве выходных данных. Входы, которые используют Генераторы, и выходные данные, которые они производят вместе, образуют транзакцию.

Разделение генерации состояния и проверки Рисунок 2. Разделение генерации состояния и проверки

Ячейка

Ячейки являются первичными единицами состояний в CKB, в них пользователи могут включать произвольные состояния. В ячейке есть следующие поля:

  • capacity- Ограничение размера ячейки. Размер ячейки - это общий размер всех содержащихся в ней полей.
  • data- Данные состояния, хранящиеся в этой ячейке. Он может быть пустым, однако общее количество байтов, используемых ячейкой (включая данные), всегда должно быть меньше или равно ее емкости.
  • type: Скрипт проверки состояния.
  • lock: Скрипт, представляющий владение ячейкой. Владельцы ячеек могут передавать ячейки другим.

Ячейка - это неизменный объект, никто не может изменить его после создания. Каждую ячейку можно использовать только один раз, ее нельзя использовать в качестве ввода для двух разных транзакций. «Обновления» ячеек помечают предыдущие ячейки как историю и создают новые ячейки с такой же емкостью для их замены. Создавая и отправляя транзакции, пользователи предоставляют новые ячейки с новыми состояниями в них и аннулируют предыдущие ячейки, которые хранят старые состояния атомарно. Набор всех текущих (или активных) ячеек представляет собой последнюю версию всех общих знаний в CKB, а набор исторических (или мертвых) ячеек представляет все исторические версии общих знаний.

CKB позволяет пользователям передавать емкость ячейки сразу или передавать только часть емкости ячейки, что, в свою очередь, приведет к созданию большего количества ячеек (например, ячейка с емкостью 10 байтов может стать двумя ячейками с емкостью 5 байта каждый).

В CKB VM выполняются два типа скриптов (тип и блокировка). CKB VM выполняет typeсценарий при создании ячейки в выходных данных транзакции, чтобы гарантировать, что состояние в ячейке является допустимым в соответствии с определенными правилами. CKB VM выполняет сценарий блокировки, принимая доказательства в качестве аргументов, когда на ячейку ссылается ввод транзакции, чтобы убедиться, что у пользователя есть соответствующие разрешения для обновления или передачи ячейки. Если выполнение сценария блокировки возвращает истину, пользователю разрешается передавать ячейку или обновлять ее данные в соответствии с правилами проверки, указанными в typeсценарии.

Это type и lock пара скрипт позволяет все виды возможностей, например:

  • Обновляемая криптография - Любой человек может развернуть полезные библиотеки шифрования , написанные на таких языках, как C или C ++ и использовать их в typeи lockсценарии. В CKB VM нет жестко закодированных криптографических примитивов, пользователи могут выбирать любую схему криптографической подписи, которую они хотели бы использовать для подписи транзакций.
  • Multisig - пользователи могут легко создавать M-of-N multisig или более сложные lockсценарии.
  • Кредитование - владельцы ячеек могут одалживать ячейки для использования другими, сохраняя при этом свою собственность на ячейки.

Модель Cell - это более общая модель состояния по сравнению с моделью UTXO или Account. И UTXO, и модель Account могут выражать отношения между активами и их владельцами. Модель UTXO определяет право собственности на активы (с помощью сценария блокировки), а модель учетной записи определяет владение активами владельцем (с балансом на счете). Модель UTXO делает историю реестра более понятной, но отсутствие универсального хранилища состояний затрудняет использование и без того невыразительных сценариев. Модель учетной записи проста для понимания и может хорошо поддерживать авторизацию и идентификацию, но создает проблемы для параллельной обработки транзакций. Модель Cell с lockи typeскрипты берет лучшее из обеих моделей , чтобы обеспечить более общую модель государства.

VM

CKB VM - это виртуальная машина на основе набора инструкций RISC-V для выполнения сценариев типов и блокировки. Он использует только стандартные инструкции RISC-V, чтобы поддерживать стандартную программную реализацию RISC-V, которая может охватывать самую широкую промышленную поддержку. CKB реализует криптографические примитивы как обычную сборку, выполняемую на его виртуальной машине, вместо настраиваемых инструкций. Он поддерживает системный вызов, с помощью которого сценарии могут считывать метаданные, такие как текущая транзакция и общая информация о цепочке блоков, из CKB. CKB VM определяет cyclesкаждую инструкцию и предоставляет общее количество циклов, выполняемых во время проверки транзакции, чтобы помочь майнерам определить комиссию за транзакцию.

Существующие цепочки блоков жестко запрограммировали криптографические примитивы в протоколе. Например, Биткойн имеет специальные криптографические коды операций, такие как OP_CHECK*, а Ethereum использует специальные «предварительно скомпилированные» контракты, расположенные по специальному адресу (например 0000000000000000000000000000000000000001), для поддержки криптографических операций, таких как ecrecover. Чтобы добавить новые криптографические примитивы в эти цепочки блоков, мы можем только софт-форк (поскольку Биткойн повторно использует коды операций для поддержки новых примитивов) или хард-форк.

CKB VM - это крипто-независимая виртуальная машина. В CKB VM нет никаких специальных криптографических инструкций. Новые криптографические примитивы всегда могут быть развернуты и использованы сценариями, как обычная библиотека. Реализация, соответствующая стандарту RISC-V, означает, что существующие криптографические библиотеки, написанные на C или других языках, могут быть легко перенесены на виртуальную машину CKB и использованы в сценариях ячеек. Таким образом CKB даже реализует хэш-функцию по умолчанию и криптографию с открытым ключом, используемую при проверке транзакций. Независимость от криптографии позволяет разработчикам децентрализованных приложений на Nervos использовать любую новую криптографию (например, подписи Шнорра, подписи BLS и zkSNARKs / zkSTARKs), которые они хотели бы, не затрагивая других пользователей, и позволяет пользователям CKB хранить свои активы в безопасности даже в постквантовая эра.

CKB VM выбирает аппаратное обеспечение, нацеленное на ISA, потому что блокчейн - это аппаратное обеспечение. Хотя его создание так же просто, как программное обеспечение, его обновление так же сложно, как и оборудование. Как ISA, предназначенный для микросхем, RISC-V очень стабилен, его базовый набор инструкций вряд ли будет изменен в будущем. Возможность поддерживать совместимость с экосистемой без необходимости хард-форка - ключевая особенность виртуальной машины с цепочкой блоков, такой как CKB VM. Простота RISC-V также упрощает моделирование затрат времени выполнения, что имеет решающее значение для расчета комиссий за транзакции.

Транзакция

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

Транзакция включает в себя следующее:

  • deps: Зависимый набор ячеек, предоставляет ячейки только для чтения, необходимые для проверки транзакции. Это должны быть ссылки на живые клетки.
  • inputs: Ссылки на ячейки и доказательства. Ссылки на ячейки указывают на живые ячейки, которые передаются или обновляются в транзакции. Доказательства (например, подпись) подтверждают, что создатель транзакции имеет разрешение на передачу или обновление указанных ячеек.
  • outputs: Новые ячейки, созданные в этом переходе состояний.

Дизайн модели ячеек и транзакций CKB удобен для легких клиентов. Поскольку все состояния находятся в блоках, синхронизация блоков также выполняет синхронизацию состояний. Легким клиентам требуется только синхронизировать блоки и не требуется дополнительная синхронизация состояний или вычисление переходов между состояниями. Если бы в блоках хранились только события, для синхронизации состояний потребовались бы полные узлы. Синхронизация состояния может быть затруднена в больших сетях из-за слабых стимулов к синхронизации. Это отличается от блочной синхронизации, при которой майнеры заинтересованы в максимально широкой широковещательной рассылке блоков. Без необходимости в дополнительной синхронизации состояний протокол делает легкие узлы и полные узлы более равноправными узлами, что приводит к более надежной и децентрализованной системе.

Параллелизм транзакций и обнаружение конфликтов Рисунок 3. Параллелизм транзакций и обнаружение конфликтов

deps И inputsв CKB транзакциях облегчают узлы для определения зависимостей транзакций и выполнения параллельной обработки транзакций (рисунок 3). Различные типы ячеек могут быть смешаны и включены в одну транзакцию для обеспечения атомарной работы между типами.

 

Государственная стоимость и емкость ячейки

Создание и хранение состояний в ЦКБ связано с расходами. Создание новых состояний должно проверяться полными узлами (что требует вычислительных затрат), а для хранения состояний требуются полные узлы, чтобы предоставлять дисковое пространство на постоянной основе. Текущие блокчейны без разрешения взимают только единовременную комиссию за транзакцию, но позволяют сохранять состояния на всех полных узлах, занимая место для хранения на неопределенный срок.

В CKB ячейки являются базовыми единицами хранения состояния. Владелец ячейки может использовать ячейку для хранения своего состояния или для передачи его другим. Поскольку емкость соты может использоваться только одним пользователем за раз, владелец, использующий емкость, сам откажется от возможности получать проценты путем предоставления емкости в кредит (либо CKB, либо другим пользователям). При такой альтернативной стоимости пользователи платят за хранилище по цене, пропорциональной как пространству, так и времени: чем больше емкость и чем дольше они ее занимают, тем выше альтернативные затраты, которые они несут. Преимущество модели неявной государственной стоимости CKB по сравнению с моделью предоплаты (такой как аренда хранилища, обсуждаемая в сообществе Ethereum),

Метаданные ячеек ( capacity, typeи lock) - это состояния, которые занимают емкость ячейки пользователя и также требуют затрат состояния. Эта мета-стоимость побудит пользователей создавать меньше ячеек, когда это возможно, повышая эффективность использования емкости.

Стоимость вычислений и транзакционные сборы

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

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

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

Сеть Nervos (CKB)

Мы можем разделить узлы CKB на три типа:

  • Узел майнинга: они участвуют в процессе консенсуса CKB. Узлы майнинга собирают новые транзакции, упаковывают их в блоки и создают новые блоки, когда обнаруживают Proof-of-Work. Узлы майнинга не должны хранить всю историю транзакций, только текущий набор ячеек.
  • Полный узел: они проверяют новые блоки и транзакции, ретранслируют блоки и транзакции и выбирают вилку цепочки, с которой они согласны. Полные узлы являются верификаторами сети.
    Легкий узел: они доверяют полным узлам, подписываются и хранят только подмножество ячеек, с которыми они связаны. Они используют минимальные ресурсы. Пользователи все чаще полагаются на мобильные устройства и мобильные приложения для доступа в Интернет, легкий узел предназначен для работы на мобильных устройствах.

Унифицированные сети блокчейнов (в которых каждый узел выполняет одну и ту же роль и выполняет одну и ту же функцию) в настоящее время сталкиваются с серьезными проблемами.

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