1/ Большинство ZK провайдеров созданы для генерации корректных доказательств. Немногие из них созданы для того, чтобы быть быстрыми, подлежащими аудиту и готовыми к производству. Часть I представила доказательства с графическим подходом. Часть II показала цифры. Часть III — это дорожная карта для внедрения Venus в производство. Добро пожаловать в финал трилогии zkVM. 🧵

2/ Этап 1: Производительность. Мы строим с использованием вычислительного графа – а не HAL – в качестве основного интерфейса выполнения с первого дня. Ранняя интеграция cudaGraph уже показывает улучшения на 9–12% на RTX 5090. Цель: 15%+, с последующим тестированием много-GPU. Каждая оптимизация накапливается.

3/ Этап 2: Безопасность Тот же график, который управляет производительностью, также может машинно проверять сам протокол доказательства. Ключевое понимание: типы аргументов ZK малы и исчисляемы – SumCheck распадается всего на два. Создайте конечную доверенную библиотеку, механически проверьте любой протокол.

4/ Этап 3: интеграция rbuilder. Создание блоков не может ждать медленного доказателя. Поэтому мы строим асинхронный конвейер с учетом реорганизации и плавным откатом, когда доказательство затягивается. Цель: ZK-доказательство, которое вписывается в живое производство блоков, не замедляя его.

5/ Этап 4: Экономика. Может ли узел zkEVM существовать самостоятельно? Мы моделируем комиссии за доказательства, долю MEV и стимулы протокола по сравнению с затратами на оборудование и операции для 3 конфигураций GPU (от одного RTX 5090 до 8x), чтобы найти точку безубыточности. Графический подход выигрывает только в том случае, если его жизнеспособно запускать.

6/ Большинство ZK провайдеров созданы для того, чтобы производить корректные доказательства. Корректные доказательства — это базовый уровень. Мы создаем такой, который также будет быстрым, проверяемым, готовым к производству и устойчивым в эксплуатации. Вот что делает возможным подход с графами. Читать Часть III: