Q2: Это первое крупное обновление протокола для уровня 1 Nervos, и ваша команда приложила для этого много усилий. Можете ли вы рассказать предысторию этого обновления? Почему Nervos CKB нуждается в серьезном обновлении протокола?
Ян: Во-первых, обновление протокола неизбежно. Обновления часто требуются почти для всех программных проектов, потому что вы не можете предугадать все требования с самого начала. Когда потребности меняются, программное обеспечение также должно адаптироваться. Тоже самое с блокчейном.
Во-вторых, Nervos Network имеет совершенно новый дизайн. В начале были известны только 60% переменных, а остальные 40% был неизвестны. С одной стороны, нам сложно предсказать, как разработчики будут использовать его в будущем. Многие разработчики, создающие приложения в основной сети Nervos после запуска, сообщали нам о неудобствах дизайна. Когда мы получим достаточно отзывов от разработчиков, нам нужно было внести коррективы. Нам также понятно, что запуск основной сети — это только первый шаг. В будущем предстоит сделать еще больше. Эти более продвинутые и сложные функции должны быть реализованы шаг за шагом с помощью основных обновлений протокола.
Q3: Какие проблемы решит это обновление и какие изменения оно принесет? На что следует обратить внимание после обновления?
Ян: Хорошо, я представлю хардфорк CKB. Но прежде всего нам нужно понять, что CKB сильно отличается от многих других блокчейн-проектов.
Nervos CKB — это расширенный биткойн с точки зрения дизайна и концепции. Nervos CKB использует PoW, когда преобладает PoS. Алгоритм консенсуса CKB представляет собой оптимизированный консенсус Накамото вместо консенсуса в стиле BFT. Модель Nervos Cell — это расширенная модель UTXO.
Биткойн сейчас рассматривается большинством в криптоиндустрии как SoV, поэтому он должен быть очень безопасным. Поэтому Биткойн очень консервативен в своем техническом развитии. CKB стремится расширить идею SoV до SoA, где вы можете с уверенностью хранить все виды активов в цепочке. Реализация SoV требует соответствующего выбора и не является естественной вещью.
Между тем, удобство использования Биткойна превосходно. Проще говоря, мы не видели простоя Биткойна, но многие новые блокчейны в настоящее время часто сталкиваются с перебоями из-за ошибки или из-за обновлений. На мой взгляд, эти новые блокчейны — это не то же самое, что Биткойн. Они больше похожи на интернет-сервисы или облачные базы данных. Биткойн совсем не такой. Конечно, никто не может гарантировать, что Биткойн будет функционировать в течение 10 000 лет. В конце концов, он создан людьми, и в нем могут быть ошибки. Но его концепция очень ясна — убедитесь, что он не отключится из-за небольших изменений или обновлений. Биткойн работает отлично уже более десяти лет без каких-либо сбоев, и время является лучшим доказательством дизайна Биткойна. Напротив, многие новые блокчейны пережили несколько сбоев за последние один или два года. Вот почему я говорю, что они отличаются от биткойнов, и их просто называют «общедоступной цепью».
CKB стремится перейти от SoV к SoA на основе биткойнов. Чтобы степень децентрализации оставалась неизменной и чтобы жизнеспособность (поддержание бесперебойной работы сети) была достаточно хорошей, CKB также должен иметь больше, иначе это Litecoin. Однако расширение также должно иметь преемственность, и мы не можем перейти с UTXO на модель учетной записи, такую как Ethereum. Тем не менее, нам все еще нужно сделать уровень 1 более мощным, более гибким. Если Биткойн находится в диапазоне от 0 до 1, то Эфириум — в диапазоне от 1 до 10, а некоторые более поздние блокчейны хотят перейти от 10 к 20 или даже 100. Для CKB он хочет перейти от 1 к 5, что звучит немного нелогично: Ethereum поднялся с 1 до 10, а CKB должен достичь только 5, значит, CKB не так хорош, как Ethereum? Важно понимать, что технологическое развитие может идти по многим направлениям. Если Ethereum перемещается от 1 до 10 по оси X, можно сказать, что Nervos перемещается от 1 до 5 по оси X/Y одновременно. Уровень 1 с моделью PoW и UTXO и уровень 2 с моделью PoS и учетной записи являются аннотациями к тому, что я сказал.
Как многоуровневая сеть, Nervos в целом стремится перейти от 1 к 100, в то время как CKB основного уровня должен оставаться в наиболее упрощенном состоянии. Потому что чем больше функций вы добавите в сеть, тем больше она будет расширятся, и слишком большой код будет уязвим. Но если Nervos CKB не пойдет достаточно далеко, он закончится как Биткойн — трудно внести изменения, невозможно построить сеть уровня 2 и трудно поддерживать другие активы. Нам нужно найти баланс, при котором мы можем создавать сети уровня 2 на уровне 1 и сети уровня 3 на уровне 2. С многоуровневыми сетями Nervos может двигаться от 1 до 100. В этом отличие Nervos от многих других блокчейнов. Таким образом, вы можете думать о CKB как о ядре, которое делает расширения Биткойна. Как и операционная система Windows, она имеет ядро; если вы используете систему Linux, у нее также есть ядро; как и Apple iOS. Ядра очень маленькие. Приложение, которое вы используете, не является ядром. Приложения находятся на верхних уровнях ядра. Также существует промежуточный слой между приложением и ядром, который в системе называется библиотекой.
CKB, по сути, больше ориентирован на ядро. Это позиционирование СKB. Так что с точки зрения позиционирования и дизайна CKB может быть далек от обычных пользователей или даже разработчиков приложений. На самом деле это очень похоже на биткойн. Если вы обратите внимание на разницу между экосистемой Биткойн и Эфириум, вы заметите, что разработчики Эфириума могут создать 100 приложений за короткое время. Для разработчиков биткойнов создание приложения может занять два года, и документ обычно создается до того, как они начнут работать над приложением. Так что эти два сообщества очень разные. CKB ближе к биткойн-сообществу. Создание приложений непосредственно на CKB похоже на программирование на системном уровне, а не на интерфейсное программирование. Это две очень разные платформы с разным позиционированием и дизайном.
Сказать так много — значит ответить на вопрос: «Какая часть этого обновления может быть воспринята пользователями?» Это сложный вопрос.
Само обновление протокола далеко от пользователей. Вы можете не заметить их напрямую. Потому что посередине находятся разработчики первого или второго уровня, внедряющие основные изменения в свои приложения, инструменты и библиотеки. В результате пользователи заметят улучшения при использовании приложений. Обновление протокола можно интерпретировать как обновление операционной системы, а улучшения приложений могут отставать на короткий период времени.
Далее поговорим об особенностях и основных изменениях этого обновления.
-CKB VM
-блочная структура
-правила консенсуса
-P2P-протокол.
Изменения в правилах консенсуса и протоколе P2P не имеют ничего общего с обычными пользователями. Усовершенствования правил консенсуса заключаются в исправлении некоторых правил или багов.
Важная часть правил консенсуса, особенно полезная для разработчиков, содержится в RFC0036.
Если вы хотите сослаться на данные заголовка блока предыдущих блоков в вашем контракте, до этого хардфорка вы можете ссылаться только на блоки 4 эпохи (около 16 часов) назад. После хардфорка вы можете обратиться к данным предыдущего блока или даже к данным любого блока в цепочке. Это огромная разница для разработчиков, которые пишут контракты для многих приложений. Потому что они могут получить самую свежую информацию о цепочке CKB в контракте, когда контракт работает, что улучшит взаимодействие с пользователем.
Как пользователь, вы можете не знать, почему вам приходится так долго ждать при использовании приложения. Когда основной протокол будет завершен, вам, возможно, не придется так долго ждать. Потому что после хардфорка приложению не нужно ждать 16 часов, пока блок станет готовым. UniPass и .bit сталкивались с этой проблемой.
Так почему же он изначально рассчитан на 4 эпохи? Это на самом деле дизайн, который был запутан в течение длительного времени.
Некоторые из вас могут знать время готовности блока. В системе Биткойн вновь добытые монеты должны пройти через 100 блоков, прежде чем вы сможете их потратить. Иными словами, если вы сразу потратите эти монеты, все последующие транзакции, основанные на вновь полученных монетах, придется откатывать, что создаст огромные проблемы для пользователей и приведет к весьма странным последствиям.
По той же причине мы добавили ограничение на вновь добытые монеты CKB. Ограничение связано с балансом между безопасностью и простотой использования. Хотим ли мы быть безопасными или простыми в использовании, и хотим ли мы соответствовать Биткойну или соответствовать Эфириуму? Ethereum и другие блокчейны вообще об этом не думают. С точки зрения дизайна нам сложно найти баланс. У нас была долгая дискуссия, и разработчики сообщества рассказали нам свои требования, когда столкнулись с этой проблемой. Мы снизим ограничение ссылки на заголовок блока, чтобы вам больше не нужно было ждать 4 эпохи, хотя есть еще некоторые другие ограничения.
Это очень типичный пример. Нам нужно найти баланс между Биткойном и Эфириумом. Nervos CKB быть не хочет быть похожим на Ethereum или другие блокчейны; ни стать таким же, как Биткойн.
Наиболее важной частью основного обновления протокола является виртуальная машина (ВМ).
Есть 3 RFC о VM: 0032, 0033, 0034.
Давайте сначала поговорим о RFC0032. Он вводит понятие версии VM. Это очень интересно. Я не видел других блокчейнов, VM которых имеет версии. CKB может быть первым. Ранее Ethereum обсуждали внедрение версии EVM, но обнаружил различные проблемы, поэтому от нее отказались.
Так почему CKB делает это? Есть практические причины.
Прежде всего, VM CKB — это набор инструкций RISC-V. RISC-V — это стандарт инструкций, который широко используется и быстро развивается в отрасли. Мы должны следовать его стандарту. Стандарт RISC-V будет постоянно обновляться, поэтому, если мы не будем ему следовать, он будет несовместим со спецификацией и преимущества совместимости будут потеряны. Следовательно, CKB-VM также должен иметь возможность обновляться и соответствовать новейшему стандарту RISC-V.
Во-вторых,CKB стремится стать средством сбережения (SoV), таким же, как Биткойн. Пользователи должны быть уверены, что активы, которые они хранят в блокчейне сегодня, всегда будут принадлежать им спустя десятилетия или даже столетия. Это очень важно для блокчейна, который хочет быть средством сбережения.
Это звучит несложно, но на самом деле придти к этому не так-то просто. Почему? Как вы можете гарантировать, что обновление блокчейна не изменит предыдущие контракты или логику счетов? Вы уверены, что ваши активы по-прежнему будут принадлежать вам, независимо от будущих обновлений? Это вопрос, который стоит обсудить, потому что значение фрагмента кода или контракта определяется двумя вещами: самим кодом или данными и «контейнером», который интерпретирует код или интерпретирует данные. Блокчейн — это контейнер, который объясняет код, а контракты и активы, хранящиеся в блокчейне, — это все данные. Обновление блокчейна не изменит данные в цепочке, но изменит контейнер, который интерпретирует данные, что может изменить значение определенного фрагмента кода или контракта и, следовательно, может повлиять на владение определенными активами.
Биткойн легко избегает этой проблемы. У него никогда нет хардфорка, так что в какой-то степени проблема не существует. Делать хардфорк или нет, решается консенсусом сообщества. Если требуется хард-форк, как мы уже говорили ранее, нам нужно обновить виртуальную машину, как мы можем гарантировать, что контракт не будет изменен при обновлении?
Мы хотим гарантировать, что даже если CKB продолжит модернизацию, активы, который вы храните в сети сегодня, по-прежнему будет вашим через десятилетия или 100 лет. Это простое описание, и реализация не так проста.
Хорошо известный пример — The DAO в Ethereum. Хардфорк был сделан, чтобы исправить The DAO после голосования и лишить хакера активов. Хакер украл ETH в DAO, поэтому сообщество сформировало консенсус посредством неформального процесса управления и, наконец, решило сделать хард-форк, чтобы напрямую изменить данные в цепочке и вернуть активы. На самом деле это не то же самое, что пример, который я упомянул, потому что в то время Эфириум напрямую менял данные.
На самом деле есть другой (возможно, более разумный) способ сделать это без изменения данных. То есть изменить интерпретатор, который интерпретирует данные.
Итак, еще раз, если мы хотим обновить виртуальную машину, то возникает ряд вопросов. С одной стороны, нам нужно обновить виртуальную машину, а с другой стороны, это может привести к изменению семантики предыдущего кода/контракта. Эта возможность подорвет веру людей в то, что цепочка сможет стать SoV.
Итак, как это сделать?
У CKB есть гениальное решение. В CKB есть функция, о которой большинство пользователей могут не знать, но разработчики очень хорошо о ней знают. При ссылке на смарт-контракт на CKB есть два способа. Один из них — через идентификатор типа, который вы можете рассматривать как адрес смарт-контракта, точно так же, как адрес контракта Ethereum. Другой способ — через хэш кода контракта, то есть мы используем вычисленный кодом хэш для ссылки на этот контракт.
RFC0032 говорит, что если вы обратитесь к контракту по идентификатору типа или адресу, когда контракт работает, он будет автоматически обновлен до VM V1 после хард-форка, и новая VM будет использоваться для реализации. Почему? Поскольку вы используете адрес для ссылки на контракт, такое поведение означает, что вы предоставили право на интерпретацию контракта разработчику контракта, поскольку идентификатор типа совпадает с адресом. В качестве имени тип id не имеет ничего общего с внутренними свойствами самого контракта. Контракты, на которые ссылается имя, могут постоянно меняться, как и вы, продолжая расти, от 3 до 12, в то время как ваше имя остается прежним. Когда вы становитесь старше, в вашем теле происходит много внутренних изменений.
Другой способ — обратиться к нему через хэш кода контракта. В этот момент вы имеете в виду: «Я не хочу, чтобы объект, на который делается ссылка, менялся в любое время, я хочу всегда получать один и тот же результат». Я хочу запустить этот контракт на моей текущей виртуальной машине в соответствии с правилами интерпретации. Я знаю, что вы можете обновиться в будущем, но мне все равно. Даже если вы сделаете 100 обновлений, я все еще надеюсь использовать код и виртуальную машину, которую я пишу, когда я отправляю транзакции для выполнения этого контракта, и я хочу получить тот же результат.
В этом случае вы не используете имя или идентификатор типа, вы очень четко указали фрагмент кода и соответствующую версию среды выполнения, и вы очень четко указали семантику. Если вы ссылаетесь на контракт таким образом, результат исполнения вашего контракта не изменится после хардфорка. Ваш контракт по-прежнему будет выполняться с версией виртуальной машины до хардфорка. Это гарантирует, что независимо от того, как будет сделан хард-форк, ваш контракт останется прежним.
Поэтому CKB дает выбор пользователям и разработчикам:
-Хотите воспользоваться преимуществами автоматических обновлений, но при этом готовы отказаться от некоторых семантических изменений;
-Не желая мириться с тем, что семантика изменилась без вашего согласия, предпочитаете отказываться от преимуществ автоматических обновлений и обновлять их самостоятельно, если это необходимо.
Эту проблему решает RFC0032. Он реализует модель многоверсионных виртуальных машин, которая одновременно решает технические проблемы сосуществования различных многоверсионных виртуальных машин, обеспечивая при этом семантику SoV. Это очень большое изменение. Я не видел, чтобы другие блокчейны реализовывали это. Большинству цепей, вероятно, все равно или у них нет способа решить эту проблему, поскольку они просто обновляют виртуальную машину. Пользователи этих сетей фактически отказываются от некоторых прав, намеренно или непреднамеренно, чего нельзя сказать о CKB. Это первое большое изменение в виртуальной машине.
Второе большое изменение в виртуальной машине написано в RFC0033. В нем указана версия виртуальной машины, которая включает в себя все изменения, исправленные ошибки, переделки внутреннего формата инструкций. Для интерпретации инструкторов RISC-V существует много внутренних подходов.
Также есть некоторые новые изменения, сделанные на уровне VM для удобства отладки для системных разработчиков и разработчиков контрактов на CKB. Также есть изменения для повышения производительности, такие как отложенная память инициализации, MOP.
Наиболее примечательным является то, что для лучшей реализации и улучшения возможности интерпретации криптографических примитивов в новой версии VM впервые представлено расширение RISC-V. RISC-V имеет множество основных наборов инструкций, а также множество пакетов расширений. В новой версии CKB VM впервые представлен пакет расширений, что доказывает осуществимость. Более того, бывает, что он работает с многоверсионными архитектурами виртуальных машин.
Пакет расширений, который мы представили на этот раз, называется B Extension. Это расширенная инструкция для вычисления больших чисел, состоящая всего из 4 инструкций. Конечно, он проверяет, что дизайн и модель выполнимы. Мы также используем расширение B для оптимизации некоторой криптографии, и это действительно приведет к повышению производительности. Более расширенные директивы будут представлены в следующем хардфорке. В этом хардфорке мы сделаем небольшое улучшение, а затем проверим результаты. В случае успеха мы можем внести большее изменение в следующем хардфорке — добавив RVV (RISC-V Vector).
Повышение производительности, которое RISC-V Vector привносит в криптографические примитивы, будет намного больше. Если расширение B обеспечивает улучшение на 10-20%, то RISC-V Vector, скорее всего, многократно улучшит производительность. Разница будет очень большая.
Если версия ВМ в RFC0033 докажет, что все вышеперечисленное возможно, то мы будем следовать предыдущим методам. Будут различия в рабочей нагрузке, так как B Extension имеет только 4 инструкции, а RVV около 200 инструкций.
Это второе крупное изменение в CKB-VM.
Третье крупное изменение в виртуальной машине написано в RFC0034, в котором вводится новый системный вызов и добавляются 3 новых системных вызова, самый важный из которых называется exec. Если вы думаете о CKB как о ядре, exec — это то же самое, что и exec в Unix.
Итак, что означает использование exec в CKB? Фактически, это позволяет контракту ссылаться на другой контракт в процессе исполнения через ссылку на адрес контракта или хэш, а затем выполняться. Другими словами, заменить код, выполняемый текущим процессом, кодом другого контракта.
Почему это полезно? Это повышает комбинируемость контрактов. Теперь у меня есть 3 контракта — A, B и C. Мы можем использовать контракт D для совместного выполнения контрактов A, B и C. Следовательно, мы можем изменить предыдущий сценарий блокировки на модуль, а затем использовать exec для вызова этих модулей, таких как алгоритм подписи A, алгоритм подписи B, счетчик подписей C, а затем добавить некоторую бизнес-логику. Писать такую функцию не очень удобно, но после обновления будет очень просто. Существуют также библиотеки динамической компоновки и другие методы, которым немного не хватает простоты использования и безопасности. Хард-форк сделал возможность комбинирования еще на один шаг вперед. Это результат, которого мы добились благодаря отзывам сообщества за последние два года.
Выше приведены изменения в виртуальной машине.
Еще одним важным изменением этого хардфорка является блочная структура. На самом деле в блочной структуре не так много специфических изменений на уровне кода. В структуру блока введено и добавлено только новое поле с именем extension, что повысит масштабируемость CKB в будущем.
Это расширение является необязательным полем, которое может хранить до 96 байт данных. С помощью этого расширяемого поля мы заложим основу для нода light client. Поскольку протокол легкого узла необходимо добавить к протоколу CKB, производителю блоков необходимо выполнить некоторые дополнительные вычисления во время консенсуса, а затем где-то сохранить результаты вычислений. Если такого поля расширения нет, вспомогательные данные и данные, которые очень полезны для протокола легкого узла, не могут найти место для их хранения.
Прежде чем это решение было реализовано, мы думали о многих способах решения проблемы, включая возможность повторного использования существующих полей, и обнаружили, что ни один из них не работает, поэтому мы добавили к нему поле. Это поле обеспечит лучшую масштабируемость не только для протоколов легких узлов, но и для большего количества улучшений на уровне протокола, которые требуют добавления некоторых данных в блок в будущем. Таким образом, он может удовлетворить потребности следующего протокола легкого нода и удовлетворить дальнейшие потребности.
Мы всегда ищем решение с наименьшими изменениями. Если нам нужно перейти только от 1 к 2, мы никогда не перейдем к 5, потому что больше можно сделать на уровне 2, уровне 3, других более высоких уровнях или прикладных уровнях.
Если мы отложим эту идею, мы действительно сможем изменить ее очень быстро. С годами вы получите очень развернутый дизайн. Типичным примером является C++. C был очень оптимизированным языком, когда мы почувствовали, что C все еще не хватает, мы добавили его, и продолжали добавлять каждый год. Теперь C++ является всеобъемлющим. Поэтому C++ сейчас не так популярен, и это во многом связано с понятием разработки. Разработчики, которые знают основные детали, понимают, что заголовок блока Биткойн по-прежнему составляет 80 байт после 10 лет разработки, а внутренняя структура очень компактна; CKB немного больше, 208 байт. Почему эти детали важны? Чем больше заголовок блока, тем больше данных необходимо синхронизировать с легкими узлами в будущем.
Из-за концепции CKB мы очень осторожны при выборе дизайна хардфорка, и эффект от этого выбора фактически находится на системном уровне. Есть самые маленькие необходимые изменения, которые, по нашему мнению, удовлетворят потребности разработчиков сообщества, разработчиков контрактов, разработчиков приложений и разработчиков систем и решат их проблемы. Какие еще обновления нам нужны после этого хардфорка? Если у вас есть какие-либо вопросы, новые требования, мы можем обсудить их, разработать вместе и спланировать, что мы должны сделать для следующего обновления.
Q4: Какое влияние это окажет на проекты, основанные на Nervos, после крупного обновления протокола?
Ян: Для уровня dApp эти изменения должны быть приняты разработчиками приложений, прежде чем они повлияют на пользователей. Поэтому лучше спросить разработчиков приложений, как они воспользуются этими улучшениями, реализуют новые функции или улучшат взаимодействие с пользователем.
Для кошельков и бирж самым большим изменением является новый формат адреса. Для них очень просто обновить ноду, ведь апгрейд ноды не что иное, как замена файлов. Все происходит автоматически, и SDK завершен. Это легко сделать.
Мы внесли изменения в формат адреса и стандарт. Хардфорк будет выполнен с использованием нового стандарта адресов. Раньше у нас были длинные адреса и короткие адреса. После хардфорка мы установили единый формат адреса по умолчанию, то есть новый длинный адрес. Строго говоря, изменение формата адреса требует не хардфорка, а стандартного изменения прикладного уровня. Для удобства объединяем его в этот хардфорк. Это может оказать относительно большое влияние на проекты, кошельки и биржи DeFi.
Для майнинговых пулов обновление не имеет большого значения.
