Июль 2019 · 6 минут чтения

Сюэцзе Сяо, блокчейн-инженер, работающий над Nervos CKB и ​​главный разработчик CKB VM.

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

Возможно, вы заметили, что я называю код, работающий на CKB, ascript, а не asmart contract. Это потому, что я хочу выделить и выделить уникальную программируемость CKB. Сценарий в понимании CKB не должен быть просто сценарием - мы видим в таких языках сценариев, как Ruby, JS - на самом деле он относится к двоичному файлу формата RISC-V, который вы запускаете на виртуальной машине CKB.

Эта первая статья посвящена новой модели верификации, представленной в CKB v0.14.0. [Я обещаю вам, что это последний пост без реальных примеров, с которыми можно поиграть: P]

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

Обзор

Ниже показана реальная транзакция в CKB:

На этом графике происходит много вещей, и мы снова обратимся к нему в следующих статьях. Для начала мы сосредоточимся на двух сущностях в структуре данных ячейки: lock и type.

pub struct CellOutput {
    pub capacity: Capacity,
    pub data: Bytes,
    pub lock: Script,
    #[serde(rename = "type")]
    pub type_: Option<Script>,
}

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

  • lock является обязательным, а type - необязательным
  • Мысленно они используются для выявления различных вариантов использования.

Сначала мы начнем со сценария type.

Тип скрипт

Примечание: название здесь просто совпадение, оно не имеет отношения к столь любимому языку программирования.

Если задуматься, транзакция в CKB (или большинстве блокчейнов на основе UTXO) просто преобразует один набор ячеек (или UTXO) в другой набор ячеек. Что интересно, так это настоящая трансформация. Здесь мы начинаем проектировать модель проверки CKB - как мы можем построить модель, чтобы лучше проверять трансформации ячеек?

Вот где в игру вступает type скрипт: типовой скрипт используется для проверки определенных правил на этапе преобразования ячеек. Несколько примеров:

  • Проверка баланса UDT (определяемого пользователем токена), чтобы убедиться, что новый токен не выпущен недействительно.
  • Обеспечение присвоения уникального имени ячейке, которая может быть видоизменена. Это весело, ожидайте, что в будущем выйдет статья, полностью посвященная этой теме.
  • Реализация экономических конструкций. Фактически, NervosDAO полностью реализован как типовой скрипт с минимальной поддержкой уровня консенсуса.
  • Биткойн-виртуальная машина может быть скомпилирована в двоичный файл RISC-V, который может преобразовать CKB в альтернативную реализацию Биткойн :)
  • Имейте в виду, что в дополнение к данным ячейки могут использоваться для хранения кода, поэтому типовой скрипт также можно использовать для запуска тестов кода в ячейках, чтобы гарантировать определенное поведение.

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

Сценарий блокировки

Типовой скрипт фиксирует логику преобразования ячеек, но есть еще один важный компонент - как я могу защитить свою ячейку от кого-то еще? Другими словами, как я могу гарантировать, что мои токены останутся моими?

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

Как правило, можно ожидать, что сценарий блокировки содержит этап проверки подписи, как и все другие цепочки блоков, но есть также совершенно новые варианты использования, разблокированные CKB:

  • Фактический алгоритм подписи полностью определяется сценарием блокировки, и вы можете использовать любой сценарий блокировки. Это означает, что вы можете использовать любые алгоритмы подписи, которые соответствуют вашим потребностям. В официальный дистрибутив CKB мы включаем алгоритм secp256k1 в качестве скрипта блокировки по умолчанию. Но использовать это необязательно. Например, если кто-то реализует сценарий блокировки с использованием подписи Шнорра, это можно использовать.
  • Помимо проверки подписи, сценарий блокировки может также включать другие правила для разблокировки ячейки. Я могу настроить свой сценарий блокировки для передачи, если транзакция содержит выходную ячейку, которая использует мой сценарий блокировки, но имеет большую емкость, чем моя потребляемая ячейка. Таким образом, когда кто-то отправляет мне емкость, они могут использовать мою существующую ячейку и создать для меня новую ячейку.

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

Модель исполнения

Вернуться к примеру

Вот транзакция, использованная ранее:

Последовательность выполнения выглядит следующим образом:

  1. Lock Script 1 выполняется один раз.
  2. Lock Script 2 выполняется один раз.
  3. Type Script 1 выполняется один раз.
  4. Type Script 2 выполняется один раз.

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

Стоит упомянуть несколько моментов:

  • Несмотря на то, что есть 2 входные ячейки с Lock Script 1, он выполняется только один раз, сам скрипт блокировки должен найти все входные ячейки с одним и тем же скриптом блокировки и проверить обе подписи.
  • В этой транзакции выполняются только сценарии блокировки во входных ячейках, например, Lock Script 3 здесь не выполняется.
  • Несмотря на то, что входная и выходная ячейки содержат Type Script 1, он выполняется только один раз.
  • Сценарии типов выполняются как во входных, так и в выходных ячейках, включая Type Script 1 и Type Script 2.
  • В некоторых ячейках нет скриптов типов, и в этом случае мы просто опускаем выполнение.

Правила

Резюмируя правила:

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

Что дальше

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

Будьте в курсе новостей Nervos: Форум, Twitter, Reddit, Youtube, Telegram, Github