Where the Next ZK Breakthrough Comes From
Ethereum Korea One: Genesis · Day 2 · 2026-09-29 · 1:03:03 · In Korean
ZK technology has advanced quickly, so why is adoption slower than expected? At Ethereum Korea One: Genesis, engineers and researchers from Succinct, Fractalyze, and zkSecurity discuss where the next ZK breakthrough will come from.
Speakers
- Taehoon Kim, Engineer, Succinct
- Ryan Kim, CTO · Co-Founder, Fractalyze
- Jason Park, Security Researcher, zkSecurity
- Wonjae Choi, Researcher, SNU VMO Lab (moderator)
About this session
Moderated by Wonjae Choi of SNU VMO Lab, this panel covers ZK's biggest bottleneck, the push toward abstraction so developers need not know ZK, the problem of perfectly proving a wrong computation and the role of formal verification, and what ZK will be used for after Ethereum's zkEVM. You will hear the realities of ZK from three different seats: zkVM development, compilers, and security auditing.
Key takeaways
- Taehoon Kim (Succinct) named demand as the industry-wide bottleneck. Adoption is slower than expected, and underneath it lie cost and performance. Just as TLS became standard once encryption costs became negligible, ZK must pass that stage, he said, noting that an institution proving all its transaction processing would need around 100 GPUs. If he had to deliver 10x performance in six months, he would go all in on AI-assisted prover optimization, citing an open prover contest where a participant with no cryptography background gained 2 to 3x in three weeks just by prompting AI, and Lighter's contest, which saw about 10x in roughly three weeks.
- Ryan Kim (Fractalyze) divided verification methods into challenge games, TEEs, and ZK, and expected most machine learning agent verification to go to TEEs such as sandboxes and confidential computing because of cost. But for agent payments like UCP and x402, proving that an API provider returned the correct result is a job for ZK, he explained, since a TEE requires trusting the operator who holds the hardware.
- Jason Park (zkSecurity) cautioned against chasing performance alone, noting that bottleneck-reducing techniques like recursion have in practice introduced many bugs. With companies choosing TEEs as an available alternative, he suggested ZK demand could revive if regulation barred processing sensitive personal data in TEEs. He also introduced zkSecurity's approach with Clean, a circuit DSL built on Lean 4 that proves soundness and completeness and then exports to other proving backends.
- On abstraction, Taehoon Kim acknowledged that now that AI writes circuits quickly and even catches bugs and writes tests, a lighter custom stack may beat a zkVM for simple state transitions. Succinct is using AI to optimize its precompile circuits, has been working with Nethermind's formal verification team on RISC-V specifications since its latest version, Hypercube, and aims to make its next-generation prover production-ready by Q1 next year.
- The panel also named the trust assumptions that remain. Ryan Kim said that at minimum we must assume Lean 4, compilation, and hardware are bug-free, while Park pointed to errors in the spec itself, GPU witness generation, and the lack of tools to port Rust and CUDA prover code to Lean. Taehoon Kim noted that a proof showing at most about $7,000 was sent could still pass with a swapped recipient, stressing loss modeling, emergency stops, and E2E tests. Park said zkVM bugs spread to every user, so CVE-style disclosure and evacuation procedures are needed.
- Looking past the zkEVM, Taehoon Kim admitted that the lack of concrete use cases is his team's biggest concern. Spending ZK costs on privacy does not deliver ROI, but scalability with visible numbers, like shorter rollup finality, has demand, and ZK login could be replaced by passkeys. Ryan Kim summarized why Ethereum is moving to ZK: aggregating hash-based signatures, easing bandwidth bottlenecks to shorten finality, and lowering verification costs to reduce issuance. Park said proof of training is still far off but saw promise in identity, such as selective disclosure of ID data.
Chapters
- Opening and panel introductions
- ZK's biggest bottleneck: demand and cost
- Speed bottlenecks and AI-assisted prover optimization
- Verification methods: challenges, TEEs, ZK
- A security view: bugs from performance techniques, and regulation
- Can developers use ZK without knowing it? The push for abstraction
- The SP1 roadmap and next-generation zkVMs
- Proving wrong computations and formal verification
- Loss modeling, trust assumptions, and bug disclosure
- The future of ZK and use cases after the zkEVM