Подробное объяснение валидатора блоков Ethereum Zeth: первый zkEVM типа 0

Оригинальное название: Анонс Zeth: первый zkEVM Type Zero

В ролях: Тим Картенс, Виктор Граф, Рами Халил, Стивен Ли, Паркер Томпсон, Вольфганг Вельц, Zeth Collaboration

Сборка: bayemon.eth, ChainCatcher

25 августа был публично выпущен Zeth, валидатор блоков ZK с открытым исходным кодом Ethereum, основанный на RISC Zero zkVM. Zeth выполняет всю работу, необходимую для создания новых блоков в zkVM, не полагаясь на валидаторов или комитеты по синхронизации. Zeth был проверен на нескольких реальных блоках сети Ethereum и прошел все соответствующие тесты официального набора тестов Ethereum. Zeth смогла реализовать поддержку Rust на базе zkVM и надежные платы, включая revm, эфиры и сплавы, в течение 4 недель. Благодаря поддержке zkVM служб непрерывности и проверки бонсай Zeth может создать эти доказательства за считанные минуты. Благодаря поддержке Zeth внутрисетевой проверки каждый может проверить эти доказательства по цепочке по низкой цене. В этом посте мы остановимся более подробно, но если вы хотите углубиться в код, ознакомьтесь с исходным кодом и посетите портал разработчиков RISC Zero.

Краткое содержание

Около года назад Виталик подробно остановился на различных типах zkEVM:

Ethereum изначально не был разработан с учетом совместимости с ZK, поэтому существует множество частей протокола Ethereum, которые требуют больших вычислительных ресурсов для проверки ZK. EVM типа 1 призван полностью копировать Ethereum, поэтому он не может устранить эту неэффективность. В настоящее время проверка блоков Ethereum занимает несколько часов.

Хотя в истории Ethereum были случаи, когда это было возможно, сегодня мы рады сообщить, что проверка блоков Ethereum с использованием сервисов zkVM и Bonsai RISC Zero занимает минуты, а не часы.

Zeth: генерация поддающихся проверке блоков Ethereum

Сегодня мы выпустили Zeth, валидатор блоков ZK с открытым исходным кодом для Ethereum на RISC Zero zkVM.

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

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

После создания нового блока Zeth вычисляет и выводит его хэш. Запустив этот процесс в zkVM, мы можем получить ZK-доказательства того, что новые блоки действительны.

Используя zkVM RISC Zero и популярные крейты Rust, такие как revm, ether и Alloy, мы написали первую версию Zeth менее чем за 4 недели. Благодаря поддержке zkVM непрерывности и сервису проверки Bonsai создание доказательства может быть выполнено за считанные минуты. Благодаря поддержке проверки в сети мы можем проверить эти доказательства в сети по низкой цене.

Zeth был проверен на нескольких реальных блоках сети Ethereum и прошел все соответствующие тесты официального набора тестов Ethereum.

Поскольку Zeth строит стандартные блоки Ethereum, его можно рассматривать как zkEVM 1-го типа. Но это гораздо больше: поскольку Zeth построен с использованием стандартных кодовых плат Rust (тех же кодовых плат, которые используются популярными полными узлами, такими как Reth), мы предпочитаем думать о нем как о zkEVM класса 0: полная совместимость протоколов и большое количество повторного использования кода. . **

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

RISC Zero упрощает создание накопительных пакетов zk, zkEVM, легких клиентов и мостов.

Мы написали Зета по двум причинам:

1. Облегчить другим командам создание собственной инфраструктуры на базе ZK: объединение ZK, zkEVM, легкий клиент ZK, мост ZK и т. д. Zeth предоставляет все необходимое для создания доказательств ZK для блоков на основе EVM. Это ключевой компонент любого zkEVM или моста. Zeth имеет открытый исходный код, основанный на revm, поэтому разработчики проектов могут легко модифицировать или использовать его. Доказательства могут быть проверены в сети (отлично подходит для мостов и L2) или в локальном приложении (отлично подходит для полных узлов и легких клиентов).
2. Провести соответствующие исследования производительности EVM в zkVM Zeth, особенно задач, связанных с Ethereum. (Анализ результатов опроса см. ниже).

Объединение zk и zkEVM

Будучи zkEVM типа 0, Zeth позволяет разработчикам создавать накопительные пакеты zk с полностью встроенной EVM и совместимостью с Ethereum. В сочетании с поддержкой Zeth проверки подлинности в цепочке создание решения для расширения L2 на основе ZK станет чрезвычайно простым.

Существующие накопительные пакеты ZK и схемы zkEVM являются монолитными по своей конструкции и не могут быть обновлены без наличия у разработчика высокого уровня понимания криптографии ZK. Напротив, подход Zeth на основе zkVM позволяет любому разработчику настраивать и модифицировать его в соответствии со своими потребностями.

Zeth — это открытый исходный код, основанный на revm, и настройка для поддержки других цепочек, совместимых с zkEVM и EVM, является относительно простой задачей. Таким образом, Zeth будет относительно быстрее реагировать на будущие обновления EIP. Кроме того, Zeth также обеспечивает модульность, позволяя разработчикам создавать в нем собственную логику построения блоков.

Мы надеемся, что усилия Zeth демократизируют объединение zk и zkEVM, зная, что решения L2 на основе Zk ранее требовали многих лет исследований и разработок и более 100 миллионов долларов США финансирования, а это потребление, которое большинство проектов не могут себе позволить.

Легкий клиент и мост

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

Конечно, весь смысл стейкинга заключается в том, чтобы предоставить узлам экономические стимулы следовать правилам. Однако угроза, которую Slashing накладывает на узлы, не может полностью избежать зла — внешние стимулы всегда будут смещать «баланс» интересов в сторону зла — и очень важно разработать легкий клиент или мост, который сможет должным образом справиться с этим вредоносным поведением. жесткий.

С такими инструментами, как Zeth, риск злонамеренных действий узлов значительно снижается. Легкие клиенты могут интегрироваться с Zeth, просто добавив несколько вызовов в zkVM; ончейн-приложения, такие как мосты, могут интегрироваться с Zeth, используя наш контракт на проверку доказательств в цепочке.

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

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

Хороший фундамент упрощает процесс разработки проекта

Основанный на RISC Zero zkVM и архитектуре набора команд RISC-V, Zeth может предоставить разработчикам знакомый опыт программирования. Но наша zkVM — это больше, чем просто ядро RISC-V. У нас также есть схемы ускорения для общих криптографических задач, таких как хеширование и проверка подписи.

Этот гибридный подход (сочетание ядер ЦП общего назначения со схемами ускорения) дает нам лучшее из обоих миров:

• Поддержка основных языков программирования.
• Производительность критических криптографических операций не снижается.

В результате мы смогли быстро собрать Zeth, используя существующие пакеты кода Rust от revm, ether и сплава. Повторно используя существующие платы, мы завершили первую версию Zeth менее чем за 4 недели. Такая скорость невозможна в менее зрелых экосистемах.

Что касается производительности, Zeth использует наши схемы ускорителя для проверки подписи ECDSA, а также Continuity — новую функцию нашей инфраструктуры ZK, которая позволяет легко использовать кластеры графических процессоров, работающих параллельно (с использованием nVidia CUDA или Apple Metal), чтобы быстро доказывать большие объемы данных. расчеты. Продолжение просто в использовании: эта функциональность прозрачно предоставляется всем гостевым программам, работающим в zkVM, т.е. для ее корректной работы не требуется никаких модификаций кода.

С помощью нашей zkVM мы можем быстро генерировать ZK-доказательства действительности блока Ethereum за считанные минуты, а не часы.

Производительность

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

Когда дело доходит до производительности, следует учитывать несколько факторов:

• Вычислительные ресурсы, необходимые для создания доказательств.
• «Время стены», необходимое для создания доказательства (т. е. как долго пользователю придется ждать, пока доказательство станет доступным).
• Общая стоимость подготовки доказательств (долл. США).

Непрерывность

Производительность zkVM Zeth можно настроить с помощью непрерывной работы. Поэтому нам нужно на минутку остановиться и обсудить, как работает «непрерывная работа».

Наша zkVM реализует стандартные процессоры RISC-V. Поэтому выполнение измеряется в циклах. (В нашей схеме большинство инструкций RISC-V выполняются за 1 такт, хотя есть и исключения). Для выполнения простых программ обычно требуется всего несколько сотен тысяч циклов, но для более сложных программ могут потребоваться миллиарды циклов.

В типичной системе ZK эти циклы выполнения объединяются в доказательство; по мере увеличения количества циклов растут время и память, необходимые для генерации доказательства. Но наша zkVM не следует этим стереотипам, и ранее в этом году мы впервые представили новую функцию непрерывности, которая устраняет недостатки традиционной генерации схемы доказательства.

С точки зрения непрерывности процесс доказательства разделен на три этапа:

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

Эти фрагменты назначаются группе работников по созданию доказательств. Они генерируют доказательства ZK для своих сегментов программы. Важно отметить, что они могут делать это параллельно. Пока имеется достаточное количество работников, все сегменты программы могут быть проверены за время, необходимое для доказательства одного сегмента программы. Из-за небольшого размера сегмента сети требуемое время обычно невелико (десятки секунд).

Когда будут созданы доказательства сегментов, они в конечном итоге объединятся. Каждая операция «свертывания» принимает пару последовательных сегментированных доказательств и создает новое доказательство для комбинации этих сегментов. Например, если сегмент 1 доказывает, что программа перешла из состояния A в состояние B, а сегмент 2 доказывает, что программа перешла из состояния B в состояние C, то объединение доказывает, что программа перешла из состояния A в состояние C. При достаточном количестве рабочих это можно сделать за время log(N), где N — количество фрагментов.

Мы увидим эти этапы в действии, когда углубимся в цифры.

**Насколько сложно создать блок Ethereum? **

Во-первых, давайте посмотрим на сложность создания блока Ethereum. В таблице ниже мы берем несколько реальных блоков Ethereum и реконструируем их с помощью Zeth в zkVM.

Например, блок 17606771 создает 2131 экстент. Каждый сегмент представляет не более 2^20 циклов выполнения, поэтому все вычисления занимают не более 2 234 515 456 циклов выполнения.

В целом мы видим, что на создание типичного блока Ethereum уходит от 2 до 400 миллионов циклов, но иногда и до 9,5 миллиардов циклов. (Сначала мы были удивлены, увидев, что эти различия не были отражены в газе транзакции. Но после дальнейшего размышления это приобрело смысл: газовая система была разработана с учетом регулярного исполнения, а не доказательств ZK).

Благодаря непрерывности этим масштабом легко управлять. Согласно этим цифрам, одноранговой сети из 10 000 узлов, на которых работают валидаторы zkVM, достаточно для достижения высочайшей производительности параллельной проверки для самых больших блоков, что составляет лишь небольшую часть от 700 000 валидаторов, имеющихся в настоящее время в Ethereum.

**Сколько времени занимает создание доказательства? **

Чтобы собрать некоторые базовые данные о производительности, мы запустили тестовый экземпляр Bonsai с 64 рабочими процессорами графического процессора. Затем мы попросили его подтвердить блокировку 17735424 (182 транзакции, 3242 сегмента или около 3,4 млрд циклов) с помощью Zeth.

Чтобы сгенерировать доказательства, zkVM должен сначала разделить выполнение на сегменты. На скриншоте ниже этот процесс запечатлен задачей utor, которая выполнялась 10 минут. (Большая часть этого времени занята работой AWS, например записью в сетевое хранилище). На локальном компьютере выполнение той же задачи занимает менее 6 минут. Мы надеемся значительно сократить это время в течение следующего года).

Исполнитель наконец разбивает исполнение на 3242 части. Это большая фрагментация всего лишь для 64 графических процессоров. Следовательно, каждый рабочий узел должен сгенерировать 50 доказательств сегментов. Как показано на рисунке ниже, это занимает 35 минут. Если у нас в 50 раз больше рабочих узлов, это займет всего 42 секунды.

После завершения проверки сегмента начинается объединение. Поскольку имеется 3242 сегмента, нам необходимо выполнить процесс объединения log_2(3242) = 12 раундов. На ранних этапах объединения рабочих больше, чем рабочих; поэтому первый этап занимает 1 минуту, второй этап — 35 секунд, третий этап — 25 секунд и так далее. К седьмому этапу время стабилизировалось на уровне чуть более 5 секунд. Аналогично, если бы у нас было больше рабочих, каждый этап занял бы всего 5 секунд.

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

В результате нам удалось сгенерировать доказательства примерно за 50 минут (эффективная скорость 1,1 МГц) при недостаточном размере кластера. Если размер кластера правильный, по нашим оценкам, генерация доказательств будет быстрее:

В полностью распараллеленном случае этап доказательства может быть выполнен за 42 + 12 * 5 + 60 секунд или 2 минуты 42 секунды.

Если округлить консервативно и включить время исполнителя, то время будет где-то между 9 и 12 минутами (эффективная скорость 4,7 МГц - 6,3 МГц).

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

Потребление ресурсов для создания доказательств

Вышеуказанный тестовый кластер был развернут на AWS. Он состоит из 64 проверочных узлов g5.xlarge и 1 исполнительного узла m5zn.xlarge. По данным Amazon, каждый узел g5.xlarge имеет

• 1 графический процессор с памятью графического процессора 24 ГиБ
• 4 виртуальных ЦП с объемом памяти 16 ГиБ.

На момент написания этой статьи цена по требованию для этих инстансов составляла 1,006 доллара США в час, а для зарезервированных инстансов — 0,402 доллара США в час. Между тем, в спецификации Amazon показано, что наш узел m5zn.xlarge имеет

• 4 виртуальных ЦП, 16 ГБ ОЗУ

На момент написания этой статьи цена по требованию для этого экземпляра составляет 0,3303 доллара США в час.

Мы можем использовать эти цифры, чтобы примерно оценить стоимость доказательства для блока 17735424, описанного выше.

Напомним, что мы развернули 64 узла доказательства, и в этом развертывании создание доказательства заняло 50 минут (сквозь). Если не учитывать время простоя рабочего, 64 узла проверки плюс один узел выполнения стоят 50/60 * (64 * 0,402 + 0,3303) = 21,72 доллара США за 50 минут. Это завышенная оценка, поскольку предполагается, что мы платим простаивающим работникам. Если не принимать во внимание стоимость простоя рабочих (например, их выключение или перевод на другую работу), то стоимость составит около 19,61 доллара.

• В этом блоке 182 транзакции, или 0,11 доллара США за транзакцию.
• Общая стоимость транзакции составляет 1,125045057 Eth, или около $2137,59. Таким образом, каждый доллар доказательства приносит 109,01 доллара пользовательских средств.
• Вознаграждение, выплаченное за тот же блок, составляет 0,117623263003047027 Eth (без учета комиссий за транзакции). На момент написания это около $223,48. Таким образом, наши доказательства стоят примерно 8,7% от награды за блок.
• Комиссия за транзакцию в сумме составляет 0,03277635 Eth, или 62,28 доллара США, что более чем в три раза превышает стоимость нашего доказательства.

Стоит отметить, что эти долларовые оценки не зависят от размера кластера! Важно количество сегментов. Это связано с тем, что 1 машина, выполняющая 2 задания последовательно, стоит столько же, сколько 2 машины, выполняющие 1 задание параллельно. Следовательно, если размер кластера больше, доказательства будут генерироваться быстрее, но не дороже.

Есть несколько способов дальнейшего снижения затрат. Помимо дальнейшего улучшения производительности zkVM, возможно, добавив ускоритель Keccak, мы также можем поискать более дешевые экземпляры. Важно отметить, что, учитывая, что мы используем машины с низкими характеристиками (а наша zkVM поддерживает nVidia Cuda и Apple Metal), эту работу можно легко выполнить через p2p-сеть обычных потребительских ПК и компьютеров Mac.

Верификация в сети

Как упоминалось выше, мы проверили доказательства Zeth на Sepolia с помощью валидатора RISC Zero Groth16. Это относительно новая часть стека протоколов RISC Zero, выпущенная ранее в этом месяце. Он работает за счет использования Bonsai для преобразования собственного доказательства STARK zkVM в эквивалентное доказательство SNARK и отправки этого доказательства внутрисетевому валидатору SNARK.

Если мы рассмотрим ввод транзакции как данные UTF-8, мы увидим, что доказательство соответствует блоку 17735424.

При использовании Bonsai преобразование из STARK в SNARK занимает около 40 секунд. Проверка сети SNARK стоила 245 129 газа (~ 5,90 долларов США на момент написания).

Конечно, одним из преимуществ zkVM является то, что он может объединять несколько доказательств в одно. Благодаря этой функции целый набор доказательств можно проверить в сети без использования дополнительного газа. Таким образом, стоимость проверки в сети может быть распределена по всему набору доказательств, что снижает затраты для всех.

Что это значит для Ethereum

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

Хотя эти изменения действительно улучшили производительность, мы все равно смогли добиться стабильной производительности и без этих изменений. Когда Виталик писал о различных типах zkEVM в прошлом году, потребовалось несколько часов, чтобы доказать валидность блока Ethereum; теперь мы можем сделать это за считанные минуты. Показатели ZK быстро улучшаются, и у нас есть основания полагать, что эта тенденция сохранится в ближайшие несколько лет.

Приложение: Как работает Zeth

Этот раздел для разработчиков.

Грубо говоря, Zeth строит блоки так же, как и полный узел: мы начинаем с родительского блока, списка транзакций и автора блока, затем выполняем множество вычислений (проверяем подписи, запускаем транзакции, обновляем глобальное состояние и т. д.), и, наконец, верните новое хеш-значение блока.

Но в отличие от полных узлов, мы делаем это в zkVM. Это означает, что мы получаем ZK-доказательство того, что блок с данным хешем действителен.

Конечно, здесь не обошлось без проблем. В этом разделе мы представляем эти проблемы и способы их решения.

Криптография

Первая проблема — криптография. Создание блока Ethereum требует большой работы, наиболее важными из которых являются хеширование (Keccak-256) и проверка подписи (ECDSA и secp256k1).

В нашем zkVM есть ускоренная поддержка эллиптических кривых, поэтому проверка подписи ECDSA не представляет сложности.

Но когда дело доходит до хеширования, нам не так повезло. В нашем zkVM ускорена поддержка Sha2-256, но нет (на момент написания статьи) Keccak-256. Поэтому в настоящее время мы используем только реализацию Keccak в крейте sha3 Rust. Благодаря профилированию мы знаем, что это занимает много циклов. Это не оптимально, но наша zkVM справится с этим, и мы сможем переработать и добавить ускорители Keccak позже.

Аккаунты и хранилище: производительность и безопасность

В Ethereum учетные записи и хранилище отслеживаются глобальной системой Merkle Patricia Trie (MPT).

По данным Etherscan, на момент написания статьи дерево содержало состояние почти 250 000 000 уникальных адресов Ethereum. В целом это не так уж и много данных, но этого достаточно, чтобы заставить нас быть осторожными в том, как мы их храним и используем. В частности, решающее значение имеет производительность MPT.

Но производительность — не единственный фактор, мы также должны учитывать безопасность.

Генератор блоков Zeth работает как клиент в zkVM. Это означает, что он не может напрямую получить доступ к p2p-сети Ethereum или другим провайдерам RPC. Вместо этого он должен полагаться на данные, предоставляемые отдельными программами, работающими вне zkVM.

Анализируя безопасность приложения ZK, мы должны предположить, что внешние программы являются вредоносными и, следовательно, могут передавать вредоносные данные. Чтобы предотвратить это, приложения ZK должны проверять достоверность предоставленных им данных.

Для генераторов блоков Zeth это означает проверку состояния всех соответствующих учетных записей и хранилищ (т. е. учетных записей и хранилищ, необходимых для выполнения заданного списка транзакций).

К счастью, такой механизм предусмотрен EIP-1186, который определяет стандартный способ подтверждения состояния данной учетной записи (и ее хранилища) посредством включения Меркла.

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

Вместо этого лучше использовать данные доказательства включения EIP-1186 для построения частичного MPT. Это тип MPT, который включает только те узлы, которые имеют отношение к данному списку транзакций; несвязанные ветви просто представлены соответствующими хэшами. Вы можете думать о частичных MPT как о своего рода «объединении» доказательств включения Меркла или, если хотите, как о доказательствах подмножества Меркла.

Процесс проверки частичного MPT в основном аналогичен проверке обычного доказательства EIP-1186: корневой хэш вычисляется и сравнивается с корнем состояния родительского блока. Если они равны, можно доверять целостности учетных записей и хранилища внутри них.

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

1. Перед запуском генератора блоков Zeth мы запускаем список транзакций в песочнице, чтобы определить, какие учетные записи и хранилища актуальны. (Этот процесс также позволяет нам определить самый старый связанный блок-предшественник, который необходим для поддержки запросов Blockhash()).
2. Мы получаем подтверждение включения EIP-1186 для каждой соответствующей учетной записи и хранилища. (Мы также получаем соответствующие блоки-предшественники).
3. Мы используем эти доказательства включения для построения частичного MPT, включающего все соответствующие данные.
4. Мы запускаем zkVM, позволяем ему запустить генератор блоков Zeth и предоставляем некоторые MPT и другие входные данные (родительский блок, список транзакций и т. д.).

В zkVM генератор блоков Zeth:

1. Убедитесь, что частичный корень MPT соответствует корню состояния родительского блока.
2. Проверьте хеш-цепочку предыдущего блока до родительского блока.
3. Транзакции приложений.
4. Обновите некоторые MPT.
5. Используйте новый корневой хэш частичного MPT в качестве корня состояния нового блока.

После завершения работы генератора блоков Zeth он выведет хэш-значение нового блока.

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

Другими словами: если родительский блок действителен, то новый блок, сгенерированный Zeth, также действителен.

Поэтому, если кто-то дает вам новый блок и доказательство ZK, сгенерированное Zeth, вы можете проверить достоверность блока, проверив следующие три вещи:

1. Убедитесь, что доказательство ZK действительно и получено от Зета. Для автономных приложений для проверки можно использовать функции, предоставляемые zkVM Rust crate. Для сетевых приложений это можно проверить с помощью нашего онлайнового валидатора.
2. Убедитесь, что ZK доказывает, что хэш нового блока был зафиксирован.
3. Убедитесь, что родительский блок имеет ожидаемый хэш.

Если они проверены, то новый блок действителен.

Ограничения и будущие улучшения

Цель нашего проекта – исследование эффективности блочного строительства. По этой причине мы решили ограничить область действия объединенными блоками.

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

Наконец, Zeth — это новое программное обеспечение. Хотя мы провели некоторое тестирование (включая набор тестов Ethereum и различные реальные блоки), Zeth все еще может содержать некоторые ошибки. На момент написания этой статьи его следует считать экспериментальным программным обеспечением.