ZK Summit 14 리뷰: 발표, 주제, 시사점

Introduction ZK Summit은 zero-knowledge 생태계의 주요 정기 행사 중 하나다. 2018년부터 이어져 왔고, ZK를 중심으로 활동하는 cryptographer, protocol engineer, infrastructure team, founder, application builder들이 모이는 자리다. Formal proceedings를 갖춘 academic conference라기보다는, 연구와 실제 적용 사례를 함께 다루는 curated one-day summit에 가깝다. Academic cryptography와 실제 시스템 적용 사이의 접점에 놓인 행사이기 때문에, ZK 생태계에서 실제로 무엇이 만들어지고 있고 어떤 문제가 논의되고 있는지 보기 좋은 지점이 된다. ZK Summit 14는 2026년 5월 7일 로마에서 열렸다. Main stage와 side stage를 합쳐 연구 중심 발표와 응용 중심 발표가 함께 배치된 하루짜리 행사였고, 공식 일정 기준으로 welcome, break, lunch, panel을 제외하면 총 24개의 발표가 있었다. 발표자 구성도 다양했다. Ethereum Foundation, Succinct, Zcash/Project Tachyon, Aztec Labs, Nethermind, Miden, Nokia Bell Labs, Powdr Labs 같은 팀뿐 아니라 EPFL, UCL, NYU, TU Graz, IMDEA, University of Pennsylvania 같은 연구기관과 대학에서도 발표가 있었다. ZK14에서 가장 두드러진 점은 ZK가 실제 시스템 안으로 들어가면서 어떤 요구와 압력을 받는지가 분명하게 드러났다는 점이었다. Privacy, soundness, verifiability는 더 이상 proof system 레벨에서만 이야기할 수 있는 추상적 속성으로 머물지 않는다. 실제 사용자, 데이터 흐름, 계정 모델, 운영 환경, 구현 실수 속에서도 그 속성이 유지되는지가 중요해졌다. 그중 가장 뚜렷한 변화는 security and correctness의 비중이 크게 올라왔다는 점이고, privacy 역시 단일 application category가 아니라 systems design 문제로 다뤄졌다는 점이었다. 이 글에서는 먼저 24개 발표를 몇 가지 주제로 나눠보고, 그 다음 프로그램에서 반복적으로 보인 흐름을 정리한다. Program-Level Theme Table 24개 발표를 다섯 가지 주제로 나누면 아래와 같다. 주제 발표 수 발표 ------------------------------------- -------- --------------------------------------------------------------------------------------- Privacy-preserving systems 7 Zcash Tachyon, Merces, client-side validation, zkID, telemetry, ZK-AntiCheat, eDAS Security / correctness 5 Poseidon, EF zkEVM Security Sprint, Origin Tags, ZK engineering security, Proof of Seed ZK properties and adjacent primitives 5 ZOOK, VEIL, verifiable FHE, witness encryption, resource-sharing permutations Proving infrastructure / zkVMs 5 lambda-vm, Autoprecompiles, Miden ACE, sumcheck trade-offs, non-native arithmetic Broader verifiable applications 2 qedb, Jolt Atlas 과거 ZK Summit과 나란히 놓고 보면 ZK14의 차이는 더 분명해진다. 회차 대표 발표 ZK14와 비교했을 때 ------ ------------------------------------------------------------------------------------------------------------- ------------------------------------------------------------------------------- ZK11 Binius, SNARK proving ASICs, 1 Circuit 5 Rollups, MPC-enabled proof markets Proof system과 infrastructure에 무게중심이 있었고, application experiment는 상대적으로 배경에 있었다. ZK12 zkVMs vs custom circuits, hardware acceleration, Bitcoin constraints, universal setups, games/AI applications Performance, usability, deployment constraint 사이의 긴장이 두드러졌다. ZK13 OpenVM, Lifted FRI, Ligerito, Ligetron ZK Apps zkVM, proof-system design, developer-facing application이 계속 중요한 축이었다. 발표 수로는 privacy가 가장 큰 묶음이었지만, 과거 ZK Summit과 비교했을 때 가장 뚜렷한 변화는 security/correctness의 부상이다. 직전 몇 회에서는 새로운 proof system, zkVM, prover performance, hardware, application experiment가 두드러졌다. ZK14에도 그런 흐름은 남아 있었지만, primitive security margin, zkEVM soundness, Fiat-Shamir bug, ZK engineering practice, 장기적인 migration 문제가 명시적인 발표 주제로 올라왔다. Privacy 역시 고립된 end-user application 묶음이라기보다 payment protocol, identity, data availability, telemetry, validation, anti-cheat 전반의 시스템 설계 문제로 등장했다. Privacy-Preserving Systems Privacy 관련 발표는 ZK14에서 가장 큰 묶음이었다. 이 발표들이 공유한 핵심은 privacy를 공개 경계의 설계 문제로 다뤘다는 점이다. 누가 witness를 보는가, 무엇이 공개 정보가 되는가, 누가 proof 생성이나 유효성 검증에 참여하는가, verifier가 실제로 무엇을 알 권리가 있는가가 반복적으로 등장했다. 결제 관련 발표들은 이 질문을 여러 각도에서 보여줬다. Scaling Zcash with Project Tachyon은 shielded payment를 더 큰 규모로 확장하는 문제를 다뤘다. Merces는 MPC와 CoSNARKs를 이용한 private token transfer를 제안했는데, 여기서는 무엇을 숨길지뿐 아니라 누가 proof 생성에 참여하는지도 설계의 일부가 된다. Client-side Validation in Private Payment Protocols는 모든 거래 세부 사항을 전역적으로 공개하는 대신, 유효성 검증의 일부를 결제 참여자 쪽으로 옮기는 접근을 보여줬다. 세 발표의 구조는 다르지만, 같은 제약을 공유한다. 결제 시스템은 충분히 검증 가능해야 하지만, 모든 정보를 모두에게 공개해서는 안 된다. Identity와 운영 데이터 관련 발표도 같은 질문을 결제 밖으로 확장했다. zkID는 전체 신원을 드러내지 않고 어떤 조건이나 credential을 만족한다는 사실을 증명하는 문제를 다뤘다. Confidential and Verifiable Telemetry는 민감할 수 있는 운영 데이터를 그대로 공개하지 않으면서, 그 데이터에서 나온 주장을 검증 가능하게 만드는 방향을 제시했다. ZK-AntiCheat는 게임 영역에서 비슷한 문제를 다뤘다. 시스템은 사용자 환경이나 행동에 대한 확신을 원하지만, anti-cheat가 전면적인 감시가 되어서는 안 된다. eDAS는 data availability sampling에 privacy와 compliance 제약을 결합하면서 이 논의를 데이터 인프라 쪽으로 옮겼다. Data availability는 흔히 공개 검증 문제로 이야기되지만, 실제 배포 환경에서는 선택적 공개, access control, 지역별 규제 요건이 함께 들어올 수 있다. 따라서 ZK14의 privacy 흐름은 단순히 "ZK가 데이터를 숨긴다"는 이야기로 정리되지 않는다. 핵심은 공개와 검증 사이의 경계를 설계하는 문제였다. 어떤 시스템에서는 proof가 witness를 숨긴다. 다른 시스템에서는 유효성 검증이 위임되거나 분산되거나 다른 참여자에게 이동한다. 반복된 질문은 시스템이 어디서 데이터를 공개하고, 어디서 검증 가능한 주장만 공개하며, 어디서 신뢰와 가시성을 다른 구조로 옮길 것인가였다. Security and Correctness Security and correctness는 이번 프로그램에서 가장 뚜렷하게 부상한 주제였다. 핵심 질문은 단순히 proof가 검증되는지가 아니었다. 검증된 proof가 실제로 무엇을 보장하는가였다. 검증된 증명이 보장하는 것은 해당 primitive와 protocol, circuit, VM, 구현의 가정 아래에서 실제로 인코딩된 관계가 성립한다는 사실이다. 따라서 ZK security는 여러 층위로 나뉜다. Hash assumption, Fiat-Shamir transcript binding, constraint completeness, VM semantics, witness generation, deployment practice가 모두 시스템이 의도한 내용을 증명하는지에 영향을 준다. ZK14는 이 층위별 보안 문제를 매우 선명하게 보여줬다. Poseidon 발표는 primitive 레벨의 문제를 다뤘다. Poseidon과 Poseidon2는 proof system 안에서 효율적으로 쓰기 위해 널리 사용되는 hash function이다. 따라서 이들에 대한 algebraic attack과 security margin을 점검하는 일은 단순한 hash function 연구를 넘어선다. ZK-friendly hash가 여러 시스템의 공유 인프라가 되면, 그 보안 가정도 공유 인프라가 된다. EF zkEVM Security Sprint는 같은 문제를 시스템 레벨에서 보여줬다. zkEVM은 보통 performance, compatibility, real-time proving 관점에서 많이 이야기된다. 하지만 그보다 먼저 필요한 것은 soundness다. 인코딩된 execution semantics가 잘못됐거나 invalid execution이 통과될 수 있다면, 빠른 proving은 잘못된 보장을 더 싸게 만들어낼 뿐이다. 이 발표는 성능 논의보다 soundness 기준을 앞세웠다. Origin Tags와 A Security Guide to ZK Engineering은 구현 실무 쪽으로 시선을 옮긴다. Fiat-Shamir 변환 오류, transcript binding 실수, 누락된 constraint, witness generation과 실제로 강제되는 relation 사이의 불일치는 모두 같은 실패로 이어질 수 있다. proof는 검증되지만, 의도한 statement를 증명하지 못하는 것이다. Proof of Seed는 장기적인 migration에서도 account ownership이라는 보안 불변식을 어떻게 유지할 것인지의 문제를 더했다. Legacy account ownership을 post-quantum credential에 연결하면서 address 변경이나 UX disruption을 줄이는 것이 핵심이다. 이 발표들을 묶어보면 security는 ZK stack의 부가적인 체크리스트가 아니라 핵심 설계 축이다. 이제 질문은 proof system이 충분히 빠른가에만 있지 않다. 그 proof가 어떤 statement와 입력에 묶여 있는지, 어떤