1/ Більшість перевірок ZK створені для отримання правильних доказів. Мало хто з них створений для швидкості, підлягання аудиту та готовності до виробництва. У першій частині було введено доведення з графіка. Частина II показала цифри. Частина III — це дорожня карта для запуску «Венери» у виробництво. Ласкаво просимо до фіналу трилогії zkVM. 🧵
2/ Фаза 1: Продуктивність. Ми будуємо з використанням обчислювального графа — а не HAL — як основного інтерфейсу виконання з першого дня. Рання інтеграція cudaGraph вже показує 9–12% покращення RTX 5090. Ціль: 15%+, наступним підтверджується мульти-GPU. Кожна оптимізація складається.
3/ Фаза 2: Безпека Той самий графік може також машинно перевіряти сам протокол доказу. Ключове усвідомлення: типи аргументів ZK невеликі та перелічувані — SumCheck розкладається лише на два. Створіть обмежену довірену бібліотеку, перевірте будь-який протокол механічно.
4/ Фаза 3: інтеграція rbuilder. Будівництво блоків не може чекати повільного перевірки. Тож ми будуємо асинхронний конвеєр із реорганізацією преемпції та плавним запасним варіантом, коли доводить, що все закінчується. Мета: щоб ZK довів, що це вписується у виробництво живих блоків, не сповільнюючи його.
5/ Фаза 4: Економіка. Чи може вузол zkEVM підтримувати себе сам? Ми моделюємо комісію за докази, частку MEV та протокольні стимули щодо витрат на апаратне та операційне забезпечення у трьох конфігураціях GPU (від однієї RTX 5090 до 8x), щоб знайти точку беззбитковості. Graph-first перемагає лише якщо його можна запустити.
6/ Більшість перевірок ZK створені для отримання правильних доказів. Правильні докази — це базовий рівень. Ми створюємо таку програму, яка також буде швидкою, аудиторною, готовою до виробництва та стійкою до роботи. Ось що робить можливим графік-першим. Читайте Частину III:
235