Давайте продовжимо розгортати графовий zkVM, але спершу хочемо запитати: чому архітектури PROVER у стилі HAL досягають стелі? Ми бачимо три фундаментальні вади, які обмежують продуктивність, безпеку та майбутню підтримку апаратного забезпечення. 🧵

Дефект #1: Немає глобальної оптимізації HAL запускає ядра по одному, приховуючи повний обчислення. Це блокує: - Ефективний перенесення даних на хост-пристрої↔ - Пакування ядер у графи CUDA - Істинний мульти-GPU-паралелізм на рівні даних Результат: сильна синхронізація GPU та CPU та низьке навантаження.

Дефект #2: Погана безпека та аудит Потужні системи ZK потребують чіткої видимості до: - Взаємодії транскриптів Fiat–Shamir - Доведення зобов'язань і скорочення IOP Обчислювальний граф може містити цю інформацію. HAL ховає його всередині функції «чорного скриньки» dove().

Дефект #3: Обмежує майбутнє спільне проєктування апаратного забезпечення Нові прискорювачі можуть нативно підтримувати елементи доказування (Fiat–Shamir, генерація слідів тощо). Графи можна скомпілювати на нове апаратне забезпечення, тоді як непрозорі функції prove() — ні.

HAL був практичним мостом між CPU і GPU. Але в довгостроковій перспективі ZK-перевірки та zkVM мають бути нативними для графів, щоб досягти глобальної оптимізації, високої аудиторності та справжнього спільного проєктування апаратного та програмного забезпечення. ⚡️