Предупреждение
Этот ящик был заархивирован. Разработка перенесена в репозиторий zksync-crypto. Пожалуйста, используйте его вместо этого.
zkSync Era — это накопительный пакет уровня 2, который использует доказательства с нулевым разглашением для масштабирования Ethereum без ущерба для безопасности или децентрализации. Поскольку он совместим с EVM (Solidity/Vyper), 99% проектов Ethereum можно повторно развернуть без рефакторинга или повторного аудита ни одной строки кода. zkSync Era также использует компилятор на основе LLVM, который в конечном итоге позволит разработчикам писать смарт-контракты на C++, Rust и других популярных языках.
Целью этой библиотеки является работа с очень специфической арифметизацией с дополнительными предположениями о размере поля. Грубо говоря, мы ожидаем, что у нас будет поле F с |F| ~ 64 бита (размер машинного слова) (предположение о размере поля не важно для стратегии арифметизации и размещения элементов, но оно утверждается в реализациях гаджетов для конкретных функций, которые полагаются на определенный размер поля).
В системе существует иерархия логических функций (гаджетов) — вентилей (сущностей, которые могут вписываться в трассировку) — и оценщиков (отношений между полиномами). Оценщики написаны в виде типажа, который позволяет нам в дальнейшем автоматически составлять функции для проверки выполнимости и вычисления доказательств, а также синтезировать простые и рекурсивные верификаторы. К вентилям прикреплены дополнительные инструменты, которые позволяют самим вентилям отслеживать логику того, где их следует разместить в трассировке. Обратите внимание, что мы полагаемся на ограничения копирования Plonk и работаем над копируемыми логическими объектами «переменных», чтобы составить окончательное доказуемое утверждение. Система не предназначена для арифметизации AIR и не позволяет выражать ограничения, охватывающие несколько строк трассировки.
В общем, трассировка содержит несколько разновидностей столбцов. Основное разделение происходит между:
Кроме того, трассировка позволяет добавить аргумент поиска, который также может использовать специализированные столбцы для размещения записей таблиц поиска или просто использовать столбцы общего назначения. Таблицы на данный момент кодируются только одним набором полиномов, поэтому общая длина трассы должна быть больше общего количества записей в таблицах.
Обратите внимание, что каждый «ворота» (как тип Rust) уникален, поэтому ворота можно помещать только в столбцы специализированного или общего назначения, но не в оба столбца. Если кому-то нужна такая функциональность, то можно сделать обертку newtype.
Логические функции более высокого уровня (такие как логическое разложение, проверки диапазона, проверки нуля и т. д.) используются для того, чтобы заставить схему внутренне вписать себя разными способами в зависимости от того, разрешены или запрещены некоторые элементы в конкретном экземпляре CS. Экземпляры CS с разными наборами вентилей считаются другим типом с точки зрения Rust, и мы полагаемся на некоторую работу встраивания/констант/компилятора, чтобы уменьшить ветвление в статические переходы.
|F| и поэтому нам приходится повторять аргументы), но это будет изменено, и мы перейдем к полю расширения как как можно быстрее после фиксации свидетеля, чтобы избежать довольно «большого» шанса получить нули в знаменателе. Влияние на вычислительные затраты при доказывании весьма незначительно. Мы используем аргумент поиска, реализуемый через отношения sum_i selector(x_i) / (witness(x_i) + beta) == sum_i multiplicity(x_i) / (table(x_i) + beta) , где поиск по специализированному selector(x_i) — это просто личность. Мы также не кодируем таблицы как полиномы меньшей степени, чтобы исключить дополнительные проверки, связанные со степенью, а вместо этого дополняем их нулями. Обратите внимание, что записи таблицы никогда не содержат элемент (0,0,...,0) поскольку мы используем отдельные столбцы идентификаторов для типов таблиц в случае нескольких таблиц (даже в случае использования только одной таблицы) и идентификатора. вот так начинается с 1.
Одна приятная особенность такого аргумента поиска заключается в том, что из-за его аддитивной природы, если мы выполняем поиск по нескольким полиномам- witness в одной и той же таблице, вместо повторения аргумента для каждого (кортежа) полиномов (что потребовало бы отдельный столбец кратности, а также несколько промежуточных полиномов позже), мы можем «сложить» кратности и преобразовать аргумент во что-то вроде sum_i selector_0(x_i) / (witness_0(x_i) + beta) + sum_i selector_1(x_i) / (witness_1(x_i) + beta) == sum_i total_multiplicity(x_i) / (table(x_i) + beta) , так что общая стоимость поиска это всего лишь 1 столбец множественности и 2 (связанный со свидетелем) + 1 (связанный с таблицей) промежуточный полиномы для кодирования левых и правых отношений на корнях из единицы.
Справедливость этого аргумента очевидна. Для корректности мы используем исходный аргумент, как в статье «Кэшированные коэффициенты для быстрого поиска», лемма 2.4. Нам нужно показать, что достаточно принять total_multiplicity а не кратности witness_0 и witness_1 по отдельности.
Предположим sum_i selector_0(x_i) / (witness_0(x_i) + X) + sum_i selector_1(x_i) / (witness_1(x_i) + X) == sum_i total_multiplicity(x_i) / (table(x_i) + X) что уравнение sum_i selector_0(x_i) / (witness_0(x_i) + X) + sum_i selector_1(x_i) / (witness_1(x_i) + X) == sum_i total_multiplicity(x_i) / (table(x_i) + X) держится. Нам нужно показать, что witness_0 и witness_1 содержатся в таблице t . Пусть f = (witness_0 | witness_1) — объединение значений. Из приведенного выше уравнения следует sum_i selector_i / (f_i + X) == sum_i total_multiplicity_i / (t_i + X) (обратите внимание, что длина интервала i в LHS вдвое больше, чем указанная выше). По лемме 2.4 получаем f subset t : «подмножество» в том смысле, что каждая координата вектора f является координатой t . В частности, witness_0, witness_1 subset f subset t .
Обратите внимание, что этот аргумент справедлив и для нескольких witness_i . Остальная часть аргумента обоснованности для выбранного beta следует непосредственно, как в работе выше.
2^-40 получить 0 в знаменателях. Существуют тесты для 8 КБ SHA256 с использованием, по нашему мнению, несколько оптимальной конфигурации вентилей + таблиц для схемы SHA256. Обратите внимание: несмотря на то, что доказательство довольно быстрое, мы не оптимизировали БПФ должным образом и по-прежнему используем Poseidon (а не Poseidon2) для конфигураций, где мы ожидаем, что доказательство будет использоваться для рекурсии. Два скрипта sha256_bench_recursive.sh и sha256_bench_non_recursive.sh позволяют запускать соответствующие тесты (независимо от того, будет ли доказательство использоваться в рекурсии или нет), и вам следует поискать строку Proving is done, taken ... чтобы увидеть время проверки , потому что верификатор, который запускается после него, довольно многословен. В этих тестах используется коэффициент LDE, равный 8, хотя все наши ограничения имеют степень 4 или меньше, однако этот параметр используется в некоторых других общедоступных тестах. Мы также не используем PoW в этих доказательствах, потому что PoW для 20 бит пренебрежимо мал (30 мс), и мы пока не поддерживаем PoW для алгебраических хэшей (однако они лишь примерно в 2 раза медленнее, поэтому тоже незначительны). Уровень безопасности составляет примерно 100 бит, но надежность FRI можно повысить за счет увеличения количества запросов, а увеличение количества запросов не увеличивает время проверки (не путать с изменением скорости FRI). Длина трассировки составляет 2^16 , она использует 60 столбцов общего назначения и 8 аргументов поиска шириной 4.
Примечание: тесты просто пытаются скомпилировать собственную арку, и на данный момент обычно сквозным тестированием обычно занимается только арка AArch64 (читай Apple M1). Реализации арифметики x86-64 были проверены на достоверность, но не были сквозными в полных доказательствах. Обратите внимание, что для максимальной производительности x86-64 требуются дополнительные флаги функций компилятора в дополнение к cpu = native (набор AVX512 не используется компилятором Rust даже на собственных процессорах).
Прувер Boojum распространяется на условиях либо
по вашему выбору.
zkSync Era прошла множество испытаний и проверок. Несмотря на то, что он работает, он все еще находится в состоянии альфа-версии и будет проходить дополнительные проверки и программы вознаграждения за обнаружение ошибок. Мы хотели бы услышать мысли и предложения нашего сообщества по этому поводу! Важно отметить, что его форк сейчас потенциально может привести к отсутствию важных обновлений безопасности, критических функций и улучшений производительности.
Это программное обеспечение включает компоненты третьих сторон. Полный список этих компонентов и их лицензий см. в файле УВЕДОМЛЕНИЯ ТРЕТЬИХ ЛИЦ.
