• Для складних схем (статуси DeFi, ігрова логіка) створення доказів часто триває від сотень мілісекунд до кількох секунд.
• На мобільних пристроях або легкому обладнанні генерація доказів практично недоступна й залишається залежною від хмарних сервісів або вузлів-валідаторів.
• SNARK мають низькі витрати на перевірку, але потребують довіреної ініціалізації.
• STARK не потребують довіреної ініціалізації, але їхні докази більші, а витрати на перевірку перевищують SNARK.
ZK забезпечує конфіденційність, але надмірна конфіденційність може суперечити глобальним вимогам щодо відповідності (AML/KYC/протидія фінансуванню тероризму).
Тому регулятори часто вимагають:
• Вибіркове розкриття даних
• Доступ для регулятора (Regulator Backdoor, не універсальний бекдор)
• Докази аудиту транзакцій
Інженерія ZK суттєво складніша за традиційні смартконтракти через:
• Необхідність експертизи у криптографії, схемотехніці, компіляторах, розподілених системах
• Кожен ZK-фреймворк має власну DSL (Circom, Noir, Leo тощо)
• Високі вимоги до аудиту та дорогі помилки
Результат: розробка дорога, аудити тривають довго, а інструменти не можуть повністю приховати технічну складність.
UX залишається одним із головних бар’єрів для поширення ZK:
• Генерація доказу зазвичай дорожча за стандартні транзакції
• Досвід пакетної обробки залишається непослідовним
Більшість користувачів не знають:
• Що таке схема?
• Як генеруються докази?
• Чому конфіденційність потребує обчислень?
Це спричиняє низьку міграцію та небажання переходити на нові рішення.
• Звичайні користувачі не готові платити за конфіденційність.
• Розробники вагаються через високі витрати на генерацію доказів.
Конфіденційність, стиснення та безпеку складно прямо конвертувати у дохід.
Apple, Samsung і Nvidia інтегрують функції прискорення ZK, що суттєво знизить витрати на ZK.
Більше L1/L2 інтегруватимуть ZK як основний механізм розрахунків.
• Гаманці автоматично генерують докази
• Асинхронна генерація доказів (без очікування завершення)
• Модульне перемикання конфіденційності
ZK еволюціонує від “технічної можливості” до “інфраструктурної можливості”.