В самом начале договорились, что в ближайшее время будет запущен конкурс по доработкам DeNS, предложенный Митей на прошлой встрече. Далее поговорили, кто будет судить конкурсы на ZKP-системе, углубились в технические нюансы и внесли предложения по теме на будущее.
Конкурсы на ZKP-системе: а судьи кто?
Петр Королев обещал привести какое-то количество команд, которые будут участвовать в конкурсах ZKP. Решили, что второй конкурс Solidity to TVM Compiler Groth16 zkSNARK Proof Verification Instruction Support Introduction нужно запустить параллельно. На голосование за оба пропоузала отводится 20 дней.
Михаил, представитель NilFoundation — инициаторов конкурсов, считает, что нужен нормальный дизайн: “Должны быть требования к дизайну, какие-то именно формальные доказательства, утверждения. Должна быть отдельная статья, которая не будет нигде публиковаться”. По итогу в драфт конкурса внесены изменения.
Если будут формально участвовать в конкурсах и Митя, и команда NilFoundation, прозвучало предложение попросить побыть в жюри по итогам конкурсов Formal Method SG. Митя: “Нужно описать формат и процесс судейства, дать инструментарий и в конкурсе это прописать, что мы будем судить, используя такие-то инструменты и такой-то критерий, который должны быть более или менее формальным. Это будет очень полезно, причем и для тестирования тоже”.
Михаил пообещал написать подобную инструкцию к двум пропоузалам.
Технические нюансы
Митя предложил, что надо подумать, чтобы была оптимизация под время создания, генерация пруфа. Михаил согласился, что это вполне по их силам: “Для текущей инструкции мы можем притащить то, что сделали для файлкоина. Но это будет турбодорого, потому что откроем приватный код. У нас есть проект, в который мы де-факто поставляем прувер файлкоина (прувер стораджа) майнерам. Код подставляется, ребята его видят, аудируют, у них у всех есть компетенции понять, что там ничего такого. И без лишней скромности скажу, что он один из быстрейших на планете, иначе мы бы давно уже умерли”.
Митя попросил пояснить, что же такое “быстрый” в этом понимании. Михаил не задержался с ответом: “180-гигабайтный серкут прувится на AMD 7542 CPU и RTX 3080 меньше, чем за 8 минут. Суть в чем: IPFS — это просто графовый протокол. Каждый загружаемый файл бьется на кусочки данных по несколько Кбайт, а потом люди этими атомарными кусочками друг другу бросаются. Типа стейкинга.
Я могу привести известные результаты эксперимента на эту тему. 180-гигабайтный серкут — это де-факто пруф сектора на 32 Гб, т.е. 32 Гб этого стейтера припроцессится, развалилось на 180 Гб в виде серкута.
Есть фокусы на тестовой сети, мы отлаживали всю эту историю на секторах 512 Мб, все это разваливалось в серкут в 2 Гб и длилось меньше 30 секунд точно”.
ZKP: предложение на будущее
Павел П внес свое предложение, что нужно хоть и не прямо сейчас, но запустить конкурсы на tooling, чтобы автоматизировать компиляцию серкутов и proof-of-storage.
Михаил отметил, что tooling в процессе, но к нему нужны более формальные требования. Он пообещал показать два варианта: первый из них решает инженерную задачу (взять готовый и портировать), а второй — больше инженерно-исследовательская задача.
Павел П предложил сделать сразу два варианта: “Грубо говоря, просто адаптировать текущий компилятор — это понятная задача с понятными сроками. Одно другому не противоречит”.
Михаил считает, что в любом случае все сведется к адаптации существующих компиляторов.