Обобщенный UTXO как хранилище состояния
При разработке Общей базы знаний Nervos (CKB) мы хотели решить три проблемы:
1.Проблема (хранения) общего пользования и потеря децентрализации, вызванная взрывом состояния;
2.Отсутствие гибкости и масштабируемости из-за совмещения вычислений и проверки;
3.Противоречия, которые существуют между требованиями к пропускной способности транзакций и хранению ценности. Реализации уровня 2 и кроссчейн усугубят эти противоречия и, таким образом, окажут негативное экономическое влияние на уровень 1.
Если вышеуказанные проблемы не будут решены, уровень 1 не сможет работать в долгосрочной перспективе, не говоря уже о том, чтобы выполнить задуманные функции. Эти проблемы исходят из базовой архитектуры и протокола блокчейна, что затрудняет их решение при помощи исправлений. Мы должны пересмотреть суть проблем в базовой структуре данных и найти более подходящую основу. К счастью, эта база удивительно проста и почти готова.
«CKB наследует идеи архитектуры Биткойна и создает модель Cell, обобщая модель UTXO, сохраняя последовательность и простоту Биткойна. В Nervos CKB все состояния хранятся в ячейках, все вычисления выполняются оффчейн, а вся работа по проверке выполняется нодами».
Чему мы научились у Биткойна?
Биткойн разбивает всю книгу на части и сохраняет каждую из них в UTXO. UTXO, сокращение от Unspent Transaction Output, на самом деле является выходом, включенным в транзакцию (CTxOut). CTxOut имеет довольно простую структуру и включает всего два поля:
Каждый CTxOut представляет собой монету с собственным номиналом (Yay bit-"Coin"), который определяется значением nValue. scriptPubKey — это скрипт, который указывает владельца монеты (и обычно относится к открытому ключу владельца). Только человек, который вводит правильные данные, обеспечивающие успешную работу скрипта, может «перевести» монету другому человеку.
Обратите внимание на упомянутый выше «трансфер». Когда монета передается, это означает не просто изменить или заменить в ней scriptPubKey, а удалить ее и создать новую (в цифровом мире это очень дешево). Каждая биткойн-транзакция удаляет некоторые монеты и создает новые, чья стоимость и владелец меняются. Общая стоимость удаленных монет должна быть больше или равна стоимости вновь созданных монет для избежания инфляции. Транзакции отражают изменение состояния реестра.
Такая модель имеет следующие особенности:
1.Монета (Актив) — самый важный элемент в системе;
2.Владелец — атрибут монеты, и у каждой монеты есть только один владелец;
3.Монеты постоянно уничтожаются и создаются;
Разве это не совсем просто? Если вы разбираетесь в биткойнах и UTXO, поздравляем! Теперь вы сможете понять CKB и Cell лучше :)
Cell
Фокус уровня 1 находится на состоянии, поэтому дизайн CKB как уровня 1 также должен делать акцент на состоянии. В Ethereum история транзакций и история состояний — это два разных измерения. Блоки и транзакции представляют собой события, запускающие передачу состояния, а не сами состояния. В протоколе Биткойн транзакции и состояния объединены в одно измерение. Архитектура Биткойна сосредоточена на состояниях.
Состояние, проверенное и хранимое CKB, — это не просто число (nValue), а любые данные, которые считаются ценными и признаются всеми участниками. Очевидно, что модель биткойна UTXO не может этого сделать, но она вдохновила нас. Пока nValue изменено, чтобы быть пространством, которое может хранить не только целые числа, но и любые другие данные, у нас есть более обобщенное «nValue» или Cell:
В ячейке nValue заменяется «емкостью» и «данными». Оба поля объединены, чтобы предоставить пространство для хранения. «Емкость» — это целое число, которое содержит размер пространства (в байтах), а «данные» — это место, где сохраняется состояние, описанное в любой заданной строке байтов. Модель Cell также вводит концепцию сценария блокировки, аналогичного scriptPubKey, для ссылки на владельца Cell. Только человек, который может создать параметры (например, подпись), требуемые сценарием блокировки, может «обновить» состояние ячейки. Байты, занимаемые CellOutput, не должны превышать значение «capacity» ячейки. CKB содержит большое количество Ячеек, совокупность всех этих Ячеек формирует текущее состояние CKB, в котором хранится не просто цифровая валюта, а общие знания.
В CKB транзакция по-прежнему отражает изменение или передачу состояния. Изменение состояния или «обновление» содержимого ячейки выполняется путем удаления ячейки и создания ячейки, это означает, что содержимое исходной ячейки не изменяется напрямую. Каждая транзакция фактически уничтожает некоторые ячейки и создает новые, вновь созданные ячейки будут иметь новых владельцев и хранить новые данные. Однако уничтоженная мощность должна быть больше или равна вновь созданной мощности, чтобы никто не мог создать дополнительную мощность.
Как собственный актив сети CKB, емкость представляет собой пространство для состояния консенсуса, которое может быть выдано только в соответствии с заранее определенной фиксированной формулой. Когда ячейка уничтожается, она просто помечается как «уничтоженная» так же, как UTXO помечается как «израсходованная», вместо того, чтобы удаляться из блокчейна. Каждая ячейка может быть уничтожена только один раз, так же как каждый UTXO может быть потрачен только один раз.
Такая модель имеет следующие особенности:
1.Состояние — самый важный элемент системы;
2.Владелец — это атрибут состояния, поэтому у каждого состояния есть только один владелец;
3.Состояния постоянно разрушаются и создаются;
В целом модель Cell - это обобщенная версия модели UTXO.
Верификация
Только места для хранения любого состояния недостаточно. Причина, по которой Биткойн считается ценным, заключается в том, что каждая транзакция должна быть подтверждена каждым из полных нодов в сети, чтобы все пользователи могли соблюдать правила, записанные в протоколе Биткойн, т.е. предел предложения биткойнов в 21 млн. гарантирован (пользователи знают, что другие знают, что правила соблюдаются). Из этого также вытекает понятие общеизвестности. Если кто-либо гарантирует, что то, что он или она знает, также признается другими, информация, с которой они соглашаются, называется общеизвестной.
В системе блокчейн известно, что данные могут быть проверены независимо и распознаны любым субъектом. Это причина, по которой общие знания могут генерироваться блокчейном. Консенсус достигается путем проверки и подтверждения среди всех участников. Таким же образом создаются общие знания. (Следует отметить, что знание проверяется в соответствии с заранее определенными правилами. Однако подтвержденное знание не всегда верно.)
Как мы можем проверить данные, хранящиеся в ячейке? Это зависит от другого поля в ячейке, сценария типа. Этот сценарий определяет правила передачи состояния и, таким образом, накладывает ограничения на новое состояние. CKB-VM выполнит сценарий типа и проверит, что состояние, сохраненное во вновь созданной ячейке, соответствует правилам, предварительно определенным сценарием типа. Все ячейки, ограниченные сценарием одного типа, хранят данные одного типа.
Например, если мы хотим создать UDT (определяемый пользователем токен) под названием SatoshiCoin, его передача состояния должна соответствовать следующим ограничениям:
1.Пользователь должен доказать, что он или она является владельцем входного токена;
2.Количество входных токенов должно быть больше или равно количеству выходных токенов в каждой транзакции.
Первое ограничение может быть выражено сценарием блокировки, который похож на scriptPubKey в биткойне. Если вы заинтересованы в этом, вы можете просмотреть пример кода здесь. Второе ограничение жестко запрограммировано в базовой архитектуре Биткойна, но в CKB реализовано сценарием типа Cell. Количество SatoshiCoin, представленное каждой ячейкой, является своего рода состоянием со структурой, определяемой типом, в виде строки из 8 байтов, сохраненной в данных ячейки SatoshiCoin, а количество представляет собой сериализованное целое число:
Когда сценарий типа выполняется, ему необходимо прочитать все ячейки одного типа (о чем можно судить по типу поля), а затем проверить, что общая сумма, сохраненная во входных ячейках, больше или равна сохраненной выходных ячейки. Используя сценарии блокировки и ввода, мы создали простой токен.
Скрипты блокировки и ввода могут не только читать состояние, сохраненное в их собственной ячейке, но также ссылаться и читать состояние, сохраненное в других ячейках. Следовательно, CKB представляет собой модель программирования с отслеживанием состояния. Стоит отметить, что именно модель программирования с отслеживанием состояния, а не полнота по Тьюрингу, делает Ethereum таким мощным.
Мы можем сохранить сценарий типа в независимой ячейке и ссылаться на него в типе каждой ячейки SatoshiCoin. Преимущество заключается в том, что скрипт одного и того же типа должен занимать только одно место в хранилище. Ячейка, в которой хранится определение цифрового актива, называется ADC (ячейка определения актива). Еще одна особенность реализации SatoshiCoin заключается в том, что подробный отчет об активах и их владельцах разделен и сохранен в нескольких независимых ячейках, которые разработчики могут предоставить пользователям. Эти ячейки принадлежат самим пользователям и даже могут быть сданы в аренду пользователям. Только когда право собственности на консенсусное пространство четко определено, пользователи могут действительно владеть активами, сохраненными в их ячейках (данные любой ячейки могут быть активами). Поскольку пользователям разрешено владеть консенсусным пространством в CKB, они также могут владеть сохраненным в нем цифровым активом (пример из недвижимости: только когда вы владеете землей, вы действительно можете владеть построенным на ней домом).
Будучи абстрактной моделью проверки состояния, модель Cell предлагает внутренне неструктурированное пространство для хранения (данных) и поддерживает любое правило проверки состояния (тип) и правило проверки владения (блокировка). Мы можем смоделировать работу модели UTXO в модели Cell (как видно из SatoshiCoin) или построить в ней модель Account.
Проверка входов транзакций требует выполнения скрипта блокировки, обеспечивающего право собственности пользователей на входы и их право уничтожать соответствующие ячейки (удалять их из множества живых ячеек); и проверка перехода состояния должна выполнить сценарий типа, гарантируя, что новое состояние, сгенерированное пользователями, соответствует ограничениям сценария типа, а новые ячейки созданы правильно. Модель программирования CKB сильно отличается от модели Ethereum, потому что она использует уникальную модель состояния и отделяет вычисления от проверки. Следовательно, необходимы дальнейшие исследования для поиска лучших практик для модели программирования CKB.
Общая сеть верификации
Биткойн — это сеть верификации. При совершении транзакции пользователю необходимо ввести в кошелек или локального клиента количество переводимых монет и получателя. После получения этой информации кошелек произведет расчет и поиск этого количества монет (UTXO), принадлежащих отправителю (локально), и создаст новые монеты, часть которых будет передана получателю, а часть будет возвращена отправителю в качестве сдачи.
Затем кошелек упаковывает потраченные монеты и вновь созданные монеты в транзакцию и транслирует ее в сеть. Как только транзакция будет проверена сетью, она будет упакована в блок и завершена. При этом узлы сети не заботятся о том, как было найдено предыдущее состояние (уничтоженные монеты) или как генерируется новое состояние (новые монеты). Узлы интересуются только любым изменением общей стоимости этих монет после завершения транзакции. Когда пользователь совершает перевод, вычисления (генерация состояния) выполняются на его (клиентской) стороне. Следовательно, пользователь может сразу же подтвердить результат (новое состояние) при отправке транзакции.
Ethereum — это общая вычислительная сеть. При использовании DApp пользователь должен сообщить кошельку или локальному клиенту, что он хочет сделать. Кошелек упаковывает запрос пользователя в транзакцию и транслирует ее в сеть. Когда транзакция будет принята узлами сети, новое состояние будет вычислено в соответствии с текущим состоянием и запросом, включенным в транзакцию. В процессе вычисления завершаются нодами. Результат (новое состояние) может быть подтвержден только после добавления транзакции в блок. То есть, пользователь не уверен в результате при отправке транзакции.
CKB — это общая сеть проверки. При использовании DApp пользователь должен сообщить кошельку или локальному клиенту, что он хочет сделать. Кошелек вычислит новое состояние в соответствии с текущим состоянием и запросом пользователя. При этом вычисление завершается на стороне пользователя, и его результат (новое состояние) может быть подтвержден пользователем перед отправкой транзакции.
Другими словами, транзакция создается после выполнения вычислений в модели Биткойн или CKB, но до выполнения вычислений в модели Ethereum.
Разделение вычислений и проверки также разделяет уровень 1 и уровень 2. Уровень 1 связан с новыми состояниями, а не с шагами, с помощью которых они генерируются. По сути, все решения уровня 2, включая каналы состояния и Plasma, выполняют вычисления вне цепочки и только передают окончательное состояние на уровень 1 для проверки в определенное время.
Почему CKB лучше?
Теперь у нас есть базовая структура данных, которая сильно отличается от других, и мы разработали на ее основе уникальную экономическую модель. Это действительно лучше? Возможно, нас вдохновили три вопроса, поднятые в самом начале этой статьи.
Проблема хранения и потеря децентрализации, вызванная взрывом состояния
Емкость — это актив, присущий CKB, а его предложение ограничено заранее определенными правилами. Это также единица измерения состояния. Объем емкости определяет, сколько данных может храниться в CKB, т. е. максимальное пространство состояний CKB. Это означает, что состояние, хранящееся в CKB, ограничено общей емкостью. Следовательно, CKB вряд ли пострадает от взрыва состояния. Пока пропускная способность выдается надлежащим образом, сеть может сохранять свои децентрализованные свойства на неопределенный срок. Каждая ячейка независима и имеет определенного владельца. Это приватизирует государственное пространство, которое служило своего рода общественным ресурсом, обеспечивая более эффективное использование драгоценного пространства консенсуса.
Отсутствие гибкости и масштабируемости из-за соединения вычислений и проверки
Являясь общей сетью верификации, CKB разделяет вычисления и проверку, делая каждую из них более гибкой и масштабируемой. Больше вычислений выполняется на стороне пользователя, ближе к его данным, а также к использованию приложений. Данные можно обрабатывать более гибко и с помощью более разнообразных инструментов. Благодаря архитектуре CKB кошельки могут иметь больше мощности и возможностей. На этапе проверки проще анализировать зависимости транзакций и выполнять транзакции параллельно, учитывая, что результаты вычислений уже подтверждены.
Противоречия, существующие между требованиями к пропускной способности транзакций и хранению ценности.
Реализации уровня 2 и кроссчейн усугубят эти противоречия и, таким образом, окажут негативное экономическое влияние на уровень 1.
В экономической модели на основе ячеек стоимость хранения пропорциональна количеству согласованного пространства и требуемому времени. Майнеры могут получать доход, предоставляя пространство консенсуса, а полезность CKB вытекает из его права на безопасное пространство консенсуса. CKB ценен своей безопасностью и устойчивостью к цензуре, а не TPS. CKB дополняет уровень 2, ориентированный на транзакции, и лучше фиксирует стоимость в многоуровневой сети.
CKB не .....
IPFS
Может возникнуть путаница при определении CKB как хранилища. Вы можете спросить: «Разве это не то же самое, что IPFS, Filecoin или [какая-то распределенная система хранения]?»
CKB отличается от распределенного хранилища тем, что последнее хранит данные только без проверки и, следовательно, не может достичь консенсуса по хранящимся в нем данным. Емкость распределенного хранилища может расти пропорционально развитию технологии хранения. Однако возможности CKB ограничены эффективностью достижения глобального консенсуса.
О емкости CKB можно не беспокоиться. По мере развития уровня 2 и других многоуровневых технологий один корень merkle может быть всем, что требуется на уровне 1 в самых экстремальных случаях требований к эффективности уровня 1. Состояние, требуемое уровнем 1 для проверки, также может быть зафиксировано через транзакцию, требующую от узлов проверки меркл-доказательств, чтобы гарантировать достоверность состояния и передачи состояния. Мы активно изучаем это направление.
Qtum
Qtum — один из пионеров, внедривших более мощные смарт-контракты в модель UTXO. Если быть точным, он создает уровень абстракции учетной записи, который поддерживает EVM или виртуальную машину x86 на исходной модели UTXO Биткойн. В Qtum механизм проверки Биткойн служит первым уровнем, а модель вычислений EVM служит вторым уровнем. (Обратите внимание, что это внутреннее разделение в одном протоколе блокчейна, которое отличается от уровня 1 и уровня 2).
Qtum изменяет логику обработки scriptPubKey в UTXO, чтобы передать запрос, включенный в биткойн-транзакцию, в EVM для выполнения после упаковки транзакций. Qtum имеет более сложную архитектуру, потому что он объединил модели исполнения как Биткойн, так и Эфириум. Узлы Qtum сначала проверяют входные данные транзакции (так же, как в биткойне), а затем вызывают смарт-контракты для выполнения вычислений (так же, как в Ethereum), разделяя состояние как в модели UTXO, так и в пространстве хранения EVM.
Узнайте больше о Nervos здесь.
