Критика "криптографических эпифеноменов" с доказательством нулевых знаний из технических принципов

[Iphone 0]

Основных критических замечаний в адрес ZK два:

Первая - это длительное время доказательства (отсюда различные эталоны, различные новые протоколы ZK и различные аппаратные оптимизации);

Одна - это то, что безопасность системы и приложений все еще нуждается в проверке.

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

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

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

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

а) Бенчмарк
Прежде чем мы сможем измерить приложения ZK, мы сначала проверим производительность базового обязательства протокола ZK.

Это связано с тем, что, например, FRI приводит к STARK, KZG - к обычному SNARK, а IPA - к Bulletproof. Тестирование производительности базового обязательства не является интуитивно понятным для производительности приложения ZK, но полезно для понимания проблемы длительного времени доказательства ZK.

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

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

Что касается конкретных тестов производительности SNARK, a16z crypto делит их на front-end и back-end:

front-end - это обычно язык Cairo/язык высокого уровня zkVM и т.д., с которым работают разработчики приложений ZK;

back-end ближе к базовым криптографическим операциям, таким как временные обязательства по генерации доказательств SNARK.

Среди прочего, авторы упоминают, что генерация доказательств SNARK имеет вычислительные накладные расходы примерно в 100 раз, и что каждый протокол ZK имеет дополнительные накладные расходы, например:

"В Groth16, P должен работать над группой, дружественной к сопряжению, операции которой обычно по крайней мере в 2 раза медленнее, чем группы В Groth16, P должен работать над группой, дружественной к сопряжению, чьи операции обычно по крайней мере в 2 раза медленнее, чем группы, которые не дружественны к сопряжению. это приводит, по крайней мере, к дополнительному замедлению в 6 раз по отношению к дополнительное замедление в 6 раз по сравнению с оценкой 100-|C| выше".

В целом, можно сказать, что дополнительные накладные расходы на производительность zk-SNARK находятся в диапазоне 200 - 1000 раз.

Кроме того, в статье упоминаются другие ограничения zk-SNARK, такие как доверенные настройки и использование памяти.

В статье Modulus Labs измеряется фактическая производительность некоторых протоколов ZK. Некоторые контрольные показатели касаются количества параметров, что не очень интуитивно понятно для нас. Однако в статье упоминается, что в примере использования Worldcoin, даже при использовании "самого быстрого" Plonky2, все равно требуется несколько минут времени на генерацию доказательств и десятки ГБ памяти, что не может быть выполнено на ПК.

b) Рекурсивная и пакетная обработка
Чтобы сократить время генерации доказательства, мы можем доказывать несколько доказательств параллельно.

Обычно для этого существует два способа: пакетная обработка и рекурсия.

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

Некоторые из наиболее распространенных методов агрегирования включают Halo2, Plonky2. Каждый из них выполняет пакетную проверку и рекурсию по-разному, тем самым сокращая время доказательства.

В дополнение к протокольному уровню ZK, прикладной уровень ZK также может быть направлен и оптимизирован. Например, можно использовать несколько протоколов ZK одновременно (STARK + SNARK), или выполнить настройку на конкретное приложение с помощью рекурсивной стратегии для макроса.

В целом, это фактически сокращает время генерации доказательства с точки зрения распределения протоколов и доказательств. Сокращение времени доказательства является наиболее важным моментом при изучении новых протоколов ZK.

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

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

Paradigm упоминает, что медленная генерация доказательств для ZK в основном связана с большим количеством задействованных MSM и FFT, которые не являются аппаратно дружественными и приводят к медленной генерации окончательного доказательства из-за таких проблем, как произвольный доступ к памяти. Для этих базовых криптографических вычислений протокол ZK должен пойти на некоторые компромиссы в их составе и размере, чтобы сделать их более удобными для аппаратного обеспечения.

Несколько поставщиков аппаратного ускорения ZK утверждают, что графические процессоры на самом деле являются наиболее экономичным и конфигурируемым вариантом аппаратного обеспечения, и что со временем FPGA перейдут на стадию ASIC. По данным zk hardware, их первая версия ASIC может напрямую сократить время генерации ZK-доказательств как минимум на 30%.

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

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

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

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

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