다음 ZK 혁신은 어디서 오는가 | 이더리움 코리아 원 : 제네시스

Transcript

그동안 ZK가 블록체인에서 쓰이면서 굉장히 많은 발전들, 다양한 분야에서 발전이 이뤄졌던 것 같아요. 도 있고, 컴파일러도 있고 하드웨어 실험하는 것들도 있는데, 그래서 이번에는 굉장히 다양한 ZK 분야에서 연구하시고 일하시는 분들을 모셔서 패널토크를 진행해보고자 합니다. 첫 번째 질문은, 그 전에 각자 소개를 먼저 드릴 것 같은데요.

제 소개를 드리면 저는 지금 ZK랑 컴파일러 연구하고 있고, 서울대학교랑 이더리움 재단에서 일하고 있습니다. 저는 석싱트라는 zkVM 만드는 회사인데, 여기서 엔지니어로 일하고 있는 김태훈입니다. 저는 5년 전, 4년 정도 ZK를 계속 해왔고, 태훈이랑 지난 회사에서 같이 을 운영했고, 지금 프랙탈라이즈라는 회사를 창업을 해서 CTO로 활동하고 있고, 저희는 이제 컴파일러 만들어서 올해 ZK로

7월쯤에 계속 이더리움 쪽에서 활동하고 있는 라이언 김원용이라고, 만나서 반갑습니다. 저는 zkSecurity라는 ZK 쪽 전문 오딧을 주로 하는 리서치랑 병행하면서, 그리고 이제 Security Researcher로 일을 하고 있는 박진석이라고 합니다.

네, 세 분 다 ZK의 각자 다른 면에서 일하고 계신데, 지난 몇 년간 이제 Proof System도 많이 발전했고,, 시큐리티에 대한 많은 진전들이 있었는데, 그렇다면 지금 시점에서는 ZK의 가장 큰 병목이 어떤 것인지에 대해서 이야기를 나누고자 합니다. 먼저 태훈님 혹시 얘기해주실까요? 저는 병목은 사실 산업 전체로 봤을 때는 수요에 있는 것 같아요.

사람들이 몇 년 전부터 프라이버시 아니면 스케일링을 목적으로 ZK를 엄청 푸시한 건 사실인데, 실제 저희도 여러 고객사가 있긴 하지만 예상보다는 도입이 많이 늦어진 상황입니다. 그런데 그 병목이 수요일 때 사실 그 근본적인 원인이 뭐냐면 ZK가 진짜 상용화를 할 수 있을 정도로 많이 빨라지고 싸지는 게 지금처럼 여전히 있다고 생각합니다. ZK를 우리 회사에 도입해야겠어, 비용적으로도 할 만한 것 같아, 라고 생각하면 아예 무시할 수 있을 정도의

비용이나 성능 수준이 되는 것과는 진짜 차이가 납니다. TLS 같은 거 생각하면, 웹 애플리케이션 개발할 때 우리가 암호화를 해야 해서 TLS는 암호화 비용이 무시할 수 없을 정도로 컸다면 아직도 저희는 웹앱을 이용하면서 되게 보안적으로 많은 을 쓰고 있어야 할 텐데, 이제 아예 너무 싸고 무시할 정도로 표준이 되면서 자리를 잡고, 이제 더 많은 생태계가, 웹앱이 더 많이 발전하고, 온라인 쇼핑을 되게 안전하게 할 수 있을 것 같은데, ZK도 아마 이런 병목 구간을 지나서 더 빠르고 더 성능이 좋고 더 싸고, 이 단계를 넘어가고 나면 아마 더 많이 생태계가 커질 수 있지 않을까, 이렇게 생각합니다.

아직도 비용과 성능이 병목이잖아요. 추가 질문 한 개만 드리고 싶습니다. 수요에 대해서 말씀해주셨는데, 그러면 잠재적인 시장은 지금보다 훨씬 더 크다고 생각하시는 건가요? 그 중에서 가장 잠재적인 시장 고객들이 도입하지 않는 이유가 말씀하신 속도라든지 그런 것들이 많으신 것 같아요. 기관들이 저는 굉장히 매력적인 시장이라고 생각을 해요.

아직도 구식의 방법으로 돌아가고 있는 금융계 쪽이나 이런 쪽에 일이 많은데 ZK를 통해서 개선할 수 있는 부분이 분명히 많았고 리스크도 훨씬 더 낮아질 수 있고, 되게 좋은 점들이 많았고, 기관이 본인들의 트랜잭션 처리를 풀리 온체인으로 다 증명하겠다고 하면 GPU 100대는 아마 전기도 많이 들고, 인프라비도 많이 들고, 이런 게 아직은 많이 들고, 그래도 이런 엔드유저들이 많이 산업에 들어올 수 있을 만한 건 프라이버시가 가장 큰 때문에 더 써봐야겠다는 생각이 들 수 있을 것 같은데, 아직 많은

모바일 앱들이 ZK로 프로그램을 해서 핸드폰에서 더 할 때 좋은데 아직 무거운 부분도 있고 느린 부분도 있고, 그래서 여전히 그런 부분에서의 차이점이 있습니다. 마지막 추가로 한 개만 더 추가하도록 하겠습니다. 그 이제 속도라고 말씀하셨는데, 그런 속도의 병목은 어디예요? 그러니까 프루프 시스템은 알고리즘일 수도 있고, 아니면 zkVM에서 하시니까 그런 소프트웨어적인 스택이 있을 수도 있고, 컴파일러나 아니면 하드웨어를 잘 사용하는 그런 이 있을 수도 있잖아요.

그런 것들 중에서 뭐가 지금 가장 문제로 생각하시는 건가요? 사실은 다 문제는 많은 것 같아요. 어떻게 보면 가장 low-hanging fruit이 뭐냐고 생각을 해봤을 때는, 저는 프루버 쪽이 아무래도 가장, 지금의 AI를 많이 레버리지해서 최적화를 하고, 만약에 다음 6개월 안에 10배는 할 거면 그런 쪽에다 리소스를 투자를 하면, 저는 프루버 쪽에 아무래도 올인할 것 같고, 이게 저희가 아이겐레이어 라고 해서 하는 것도 있는데, 저희가 이라는 새로운 프루빙 시스템이 되어 있고, 그에 대한 프로그램을 최적화를 하는 뭔가 높은 컴피티션이 될 것 같습니다.

사람들이, 크립토그래피에 대한 전문 지식이 없는 사람들이 AI로 계속 프롬프팅하면서 더 해봐, 더 해봐, 더 해봐 하면서 하니까 거의 한 2-3주 만에 3배 이상 성능을 얻고, 라이터도 오픈 컴피티션을 열었는데, 걔네는 3주간에 6배 했었어요. 만약에 사람이 한 땀 한 땀 엔지니어들 뽑아서 최적화하면 한참 걸릴 만한 기회가 있었어요.

그런 게 AI를 통해서 많은 이 되고 하면서 되지 않나, 그런 부분에서. 그래서 아직도 시큐리티나 컴파일러 이런 거는 사람의 도메인 엑스퍼티즈나 이런 거 많이 필요한 것 같고, 근데 프로그램을 좀 더 많이 좀 더 최적화되고 결정적인 것 같습니다. 같은 질문을 라이언님께도 드리고 싶습니다. 병목을 어떻게 생각하시는지. 저도 태훈님 말씀 들으면서 십분 공감하는 것은 확실히 수요라는 측면이 공감하는 키워드였고, 수요가 있다고 하면 펀딩이 먼저 있고, 펀딩이

있다고 하면 개발하시는 인재분들이 모여서 기술도 빠르게 발전할 수 있을 거라고 생각하는데, 생각보다 수요를 찾는 것들이 좀 힘든 게 이 영지식 증명의 병목이라고 공감도 들고, 한편으로는 성능과 비용 말씀하셨는데, 이것도 굉장히 공감가는 키워드이기도 했습니다. 왜냐하면 저희가 Verifiability를 검증할 수 있는 기술은, Verifiability를 제공하는 기술이라고 하면 몇 가지 방법론이 있는 것 같아요. 3가지를 꼽자면, 챌린지로 해서 누가 어떤지 게임을 통해서 하는 방법도 있을 거고, TEE를 통해서 하는 방법도 있을 거고, ZK를 이용해서 하는 방법도 있을 거예요.

그리고 우리가 연산에 대해서 검증을 하려고 하면, 큰 연산을 효율적으로 검증하는 기술이 아무래도 가 될 거잖아요. 그리고 우리는 이런 니즈가 분명히 AI 시대 때, 모델이 우리가 원하는 대로 의도적으로 검증했냐, 어떻게 쓰고 있냐를 본다면, 영지식 증명 또는 암호화 기술은 거기에 쓰이고 있지 않아요. 왜냐면 성능과 비용이 비싸기 때문에. 그들은 샌드박스 같은 기술을 쓴다고 하고, TEE를 활용해서 컨피덴셜 컴퓨팅 같은 기술을 쓴단 말이죠.

이게 약간 성능과 비용의 한계를 단순히 보여주는 예시라고 생각이 듭니다. 이게 제일 중요한 게 있지 않을까 생각합니다. 네, 답변 감사합니다. 진석님께도 같은 질문 드리고 싶은데, 진석님도 그러면 비슷한 생각을 갖고 계신지, 아니면 진석님은 다른 두 분이랑 다르게 거꾸로 시큐리티 쪽 회사에서 일을 하시다 보니까, 사실 속도를 더 늘리려고 하다 보면 그에 따른 시큐리티에서의 문제들도 같이 생기잖아요.

그런 측면에서 혹시 어떻게 보고 계신지, 방법은 어떤 걸 볼 수 있을지 좀 여쭤보고 싶습니다. 그래서 그 이제 병목을 없애기 위한 하나의 방식이 하나가 이제 recursion입니다. proof를 만든 다음에 그거를 verify하는 과정을 여러 번 거쳐가지고 proof size를 줄이려는, 그런 다양한 방식으로 병목을 없애려고 하는데 그 방식들 자체가 어떻게 보면 버그를 유발하는 부분이 있고요.

그런 부분에서 실제로 버그를 많이 봤기 때문에 보안적으로 봤을 때 일단 조심은 해야 해요. 무작정 우리가 만 거쳐서 하는 것 자체는 위험할 수 있다. 일단 그렇게 생각하고 있어요. 그리고 앞서 두 분이 말씀하셨던 병목에 대해서 생각에는 굉장히 느린 것도 있는데, 그러니까 수요가 없는 이유가, 느린 이유는… 이유는 ZK가 필요하지만 다른 대체제를 사람들이 제공해주고 있잖아요.

그래서 어떻게 보면 회사들은 그거를 당연히 선택하게 되는 상황인데, 조금 의견이 분분할 수 있는 부분이고, 제 생각에는 그걸 규제 같은 강제를 하자는 것 같아요. 예를 들어서, 정말 중요한 개인의 정보는 TEE를 통해서 하는 것은 안 된다. 그런 식으로 규제 같은 게 생기게 된다면 이런 것들이 속도나 비용이 있을 경우는 있지만, 좀 더 활성화될 수 있는 계기가 될 것 같습니다.

그런 생각을 하고 있습니다. 그러면 근본적으로는 TEE라든지 Trust Assumption이라는 기술이 없는 ZK 같은 암호화로 해결하는 것이 어떻게 더 안전한 방향으로 보시는 건가요? 그러니까 아무래도 ZK 같은 경우에는 본인이 그런 암호를 가지고 있는 것 같습니다. 좀 더 본인한테 권한과 힘이 있는, 일종의 그런. 그런데 어떻게 보면 TEE 같은 경우는 그거를 Trusted한 파티한테 위임을 하는 겁니다.

그런 면에서 더 안전하다고 볼 수 있을 것 같습니다. 저 제가 피드백 좀 드려도 될까요? 아 알겠습니다. 저도 사실 ZK가 규제로 정해졌을 거라고는 아직 생각은 들지는 않는데, 저는 ZK가 유용한 사용처는 분명히 있을 거라고 생각이 들어요. 특히 또 저희가 AI 에이전트 페이먼트 쪽의 방향을 보면, 이커머스 향으로 발전된 UCP라든지, x402에서 온체인상의 API 마켓. 기존에는 이커머스를 어떻게 효율적으로 하려고 하는 시도가 있고, 기존에 어떤 API 마켓을 열려고 하는 x402 중에 새로운 마켓이 있는데, 저는

x402가 보장하는 것은 결제 friction을 해결해 준다는 생각이 들지만, Bazaar 이런 API extension을 통해서 API가 제공해 주는 디스커버리 역할을 해서, 어떤 에이전트가 내가 원하는 API를 제공해 준다는 걸 찾아줄 수는 있지만, 그 API를 제공해 주는 사람이 실제로 올바른 결과를 나에게 전송을 했어, 그리고 서브 세컨드 안에 정답을 제대로 전송했어 이러한 증명을 저는 ZK가 고 생각이 듭니다. 왜냐하면 블록체인과 TEE는 안 맞거든요.

왜냐하면 TEE라는 건 하드웨어를 컨트롤할 수 없는 사람들이 을 해야지 맞다고 생각합니다. 하드웨어를 내가 들고 있는데, 그 블록체인 컴퓨터가 TEE를 들고 있는데, 내가 언제든 CPU와 메모리 사이에 값을 볼 수 있는데, 그들을 믿고 내 프라이버시 데이터를 넘겨, 그 중의 대상 결과가 의도적으로 동작했다는 것은 안 맞다고 생각합니다. 한편으로는, 이제 아무래도 이 verifiability에 대한 니즈는 어떻게든 발생할 수밖에 없고, 어떻게든 계속 구체적으로 변화할 수 있다고 생각하는데, 대부분의 체인, 대부분의 머신러닝, 대부분의 딥러닝 에이전트들의 액션에 대한 검증은 대부분은 TEE로 가지 않을까 생각이 듭니다.

이미 리눅스 파운데이션에서도 세 단계의 레벨을 제공하고 있고, 미국에서도 정확한 기관을 까먹었는데, 권고상으로 되어 있고, 프랑스의 보안 공식 기관에서도 거기에는 아예 이렇게 하라고 가이드가 되어 있어서, 이런 식으로 흘러가지 않을까 저는 예상을 해봅니다. 네, 좋은 답변 감사합니다. 그러면 이 질문에 대해서 혹시 첨언하실 분 있으면 마지막으로 다음 질문으로 넘어가겠습니다.

다음 질문은, 개발자가 결국에 ZK를 몰라도 쓸 수 있을까? 현재 ZK 기술이 발전하면서 컴파일러 기술도 많이 발전하고, 사실 상위에서 DSL만 잘 써도 그 밑에 이제 시큐리티 툴들도 많이 붙어 있고 컴파일 기술도 되는 것들도 많고 그러다 보니까 하이레벨 로 많이 작성을 하는 거잖아요, ZK의 자세한 내용을 몰라도.

그리고 SP1같이 zkVM 중에서도 그 중에서도 가장 Rust, C++ 같은, RISC-V로 컴파일되는 코드만 제공할 수 있으면 그걸 자동으로 해주니까, 이런 식으로 ZK 앱을 직접 작성하는 것에 모든 걸 맡기는 것보다 앱스트랙션이 많이 진행되고 있는 것 같은데, 이런 방향에 대해서 어떻게 생각하시는지 궁금하고요. 개발자들이 결국에는 인프라를 믿고 개발자는 좀 더 몰라도 되는 것이라고 생각하시는지, 그래서 인프라에 좀 더 투자를 해야 되는가, 아니면 결국에는 개발자가 그 내용을 알아야 되는지, 이에 대한 생각들을 좀

들어보고 싶습니다. 이번에는 라이언님께서 먼저 답변해 주실 수 있으실까요? 저는 당연히 그렇게 가야 한다고 생각이 들고, AI 시대에는, 최근에 젠슨 황이 이런 인터뷰를 했다고 하더라고요. 요즘의 학생들이 제곱근을 구하는 방법을 모른다. 젠슨 황이 를 알아야 할 필요가 뭐가 있느냐고 해서 사람들을 깜짝 놀라게 했다고 하던데, 이 말의 요점이 뭐냐라고 생각하면, 사실 AI 시대, 그리고 기술이 쉽게 구현할 수 있는 이 시점에서, 기술의 디테일에 대해서 아는 것에 대한 메리트가 점점 사라지고 있는 이 가운데, 사실 기술은 당연히 쉽게 깔려야 한다고, 내가 원하는 어떤 아이디어가 있다고 합니다.

아이디어를 실현할 수 있는 수단의 기술을 쉽게 실현시킬 수 있도록 도와줘야 하는 게 맞다고 생각합니다. 그래서 그렇게 봐야 하는데, 이 기술이 사람의 의도대로 구현이 잘 됐는지 고증해줄 신뢰 조치가 여전히 필요합니다. ZK 같은 것들을 엔드투엔드로 쉽게 구현해주고, 같은 것들은 의미 있는 프레임, 의미 있는 기술이라고 생각이 들고요. 그리고 지금 포멀 베리피케이션 같은 예제도 들어주셨는데, 저는 포멀 베리피케이션 같은 도구 혹은 언어가 그것을 쉽게 검증도 해줄 거라고 생각하지만, 하지만 모든 것을 다 완벽히 검증하기는 불가능하지 않냐는

생각이 드는데, 적어도 우리는 세 가지를 가정을 해야 할 거라고 생각합니다. 첫 번째는 Lean 4로 검증을 할 텐데, Lean 4에는 버그가 없다는 이 가정을 깔고 것 같고, 그리고 Lean 4로 검증하던 프로그램은 또 컴파일을 통해서 실행을 하게 됩니다. 컴파일러에 가 없어도 우리는 믿고 써야 하는 입장이고, 하드웨어 입장에서도 어떤 머신 인스트럭션이 있으면 하드웨어 스펙대로 버그 없이 실행할 거라고 생각해도, 어차피 믿고 써야 하는 세상이라고 생각이 들어요.

모든 걸 다 검증할 수는 없을 거 정도? 하지만 아무튼 기술은 쉽게 해야 하고, 그것을 보장해 줄 신뢰 조치는 필요하다고 결론 지을 수 있습니다. 네, 좋은 답변 감사합니다. 그 formal verification 관련해서는 이제 다음 질문에서 좀 더 깊게 다뤄보면 좋을 것 같고요. 이번에는 태훈님 혹시 답변해주실 수 있을까요? 저도 AI 시대에 너무 학습의 진입장벽이 낮아졌고, 사실 그걸 떠나서 석싱트가 처음에 이제 풀려고 했던 문제가, 아직 ZK가 너무 쓰기 어려운데 이렇게 쓰기 어려워서 수요도 없는 마당에 해서 Rust로 짜기만 하면 ZK를 활용한 프로토콜 만드는 걸 너무 쉽게 했는데,

AI도 도움이 되지만, 어쨌든 모든 기술은 침투가 점점 되면 될수록 도입하기 쉽게 가는 방향으로 발전한다고 생각하고, 저는 요새 조금 더 유연한 사고를 하고 있습니다. 우리 석싱트 SP1을 사람들이 꼭 프로그램을 짤 필요가 있을까, 이런 생각도 하거든요. 옛날에는 내가 뭐, Halo2 같은 걸로 개발하고 싶다, DSL 공부해서 개발하고 싶어, 하면 아무리 지금 진입장벽이 낮아졌다곤 하지만 좀 어려울 것 같아요.

AI 같이 쓰면서, 작년까지만 해도 짜기가 좀 제가 이해하기 어려울 것도 되게 많고, 뭐 이거 그래서 아, 이게 똑바로 짠 게 맞나, 이런 불확실성이 있었는데, 그런 부분이 오히려 AI 기준에 좀 나아지는 것 같기도 하고, 최근에 그냥 옛날 프로젝트 꺼내서 AI한테 짜보라고 시켰어요. 너무 빨리 정확하게 잘 짜고, 짜는 중간에 자기가 버그도 찾고 테스트도 너무 잘 짜고 이래서, 오히려 그런 노가다로 한 땀 한 땀 짜던 구시대의 기술을… 내가 구현하고자 하는 게 그렇게 복잡하지 않더라고요.

굳이 뭐 저희 OP Succinct처럼 OP 스택의 어떤 상태 전이를 표현하고자 하는 정도의 복잡성이 아닌 프로그램이라고요. 내가 단순한, 되게 단순한 상태 전이, 뭐 잔고가 바뀌었음을 증명하는 정도라면 오히려 더 가벼운 스택에 뭔가를 AI랑 같이 활용해서 개발하는 것도 낫지 않을까 해서, 되게 여러 방면으로 열어놓고 기술 자체의 이 낮아지는 것에 주목하면 좋을 것 같아요. 이런 방향이 전체적으로, 저는 라이언이 말씀하신 것처럼 모든 보안을 저희가 완벽하게 다 할 수는 없겠지만 이런 구현적인 부분에 있어서 머리 싸매고 하던 에너지를 조금 덜 쓸 수 있다면, 저희가 산업이 발전하는 방향을 좀 더

보안이나 퀄리티나 이런 부분에 더 많은 에너지를 쓰면서 더 조화롭게 발전할 수 있지 않을까, 이렇게 생각하고 있습니다. 태훈님 말씀하신 거에 대해서 들어보면, 뭔가 SP1의 단점을 얘기를 하신 것처럼, 그런 식으로도 받아들여지기도 하는데, 그러면 이제 하드웨어 추상화 때문에 SP1 같은 ZK 버추얼 머신들은 필연적인 남는 비용이 있잖아요. 그런 비용을 감수하는 것보다, AI가 이제는 굳이 그렇게 쉽게 짜주니까 그냥 그쪽을 쓸 수 있겠다라고 생각을 하셨던 것 같아요. 그러면 SP1은 그럼 어떤 쪽으로

나아가야 할까요? 저는 그래서 뭘 재밌는 걸 많이 하냐면, 저희도 사실 RISC-V가 올바르게 명세를 하고 그렇게 구현이 되었는데, 그런 칩이나 서킷 자체도 AI 시켜서 최적화를 많이 하고요. 그리고 저희도 사실 완전 범용인 것 같지만, 저희가 general purpose zkVM을 만든다고 하지만 custom circuit이 없지 않고, 프리컴파일을 걸어서 특정 연산들에 대해서 zkVM에게 불리할 만한 것들을 custom circuit에 짜서 최적화를 해놓은 부분도 있고, 그런 부분도 AI를 시켜서 background에서

엄청나게 지금 어떻게 하면 칩을 덜 쓰면서 뭔가 할까 하는 것을 자동으로 많이 해놓고 있는데, 근데 이게 진짜 너무 다방면으로 AI가 잘 활용되고 발전을 하는 방향이다 보니, 모든 가능성을 열어놓고 봐야 되는데 zkVM이 이제 옳은 방향이라고 단정했기보다는, 쓰임에 맞게 내 프로토콜에서 데이터가 이렇게 움직이고, 내가 이런 걸 프루빙하려고 하는데 근데 꼭 제 선택지가 맞을까? 저 선택지가 맞을까?

오히려 맞을 수도 있지 않을까 해서. 뭐 장난인 것 같아요. 어쨌든 리더빌리티는 Rust로 작성된 프로그램이 더 좋긴 할 거라, 내가 정말 코드를 이해하는 게 더 중요하고 하다면 SP1을 선택할 수도 있고 근데 비용이 비슷하고, 어차피 거고, 오히려 이게 퍼포먼스 검증해 봤을 때 조금 더 싼 것 같아요, 하면 이제 진짜 커스텀 서킷 잘 짜고 하는 것도 좋은 답이 될 수 있을 것 같습니다. 제가 최근에 EthProofs 영상에서 타미르님이 발표한 걸 봤을 때 SP1 로드맵이 4단계 이렇게 나눠져 있더라고요.

zkVM이 걸어온 길: RISC Zero가 zkVM을 열었어요. 그 다음에 두 번째가 뭐냐면, 쓰루풋을 달성한 거예요. 어떤 기간 내에 최대한 많은 proof를 주어진 시간 내에 달성할 수 있을 것을 달성했을. 2세대에서 3세대가 뭘 했냐면, 리얼타임 proof 시대가 열리면서 이제는 레이턴시까지도 줄인 거예요. 여기서 우리는 12초 블록 타임보다 더 짧은 P99, 이제는 심지어 4개의 GPU로도 P99 달성했다, 이런 것을 최근에 4세대의 zkVM이 뭐냐면, 석싱트 원래 하고 싶었던 것은, 나는 프리컴파일로만 구성된 서킷이 있고, 그리고 유저가 쉽게 프리컴파일로 조합을

해서 나만의 서킷에 프루프를 만들 수 있는 프레임워크를 만들고 싶어 했는데, 그 당시에는 뭐가 없었어요. 프리컴파일을 쉽게 작성할 수 있는 도구는 없었고, 프리컴파일이 내가 올바르게 작성되는지 확인할 수 있는 방법이 없었어요. 지금은 이 시대에 뭐가 잘 생겼냐 하면, 하나, AI가 프리컴파일을 너무 쉽게 작성하는 데 도움을 줄 수 있고, 두 번째, 이 작성된 서킷이 올바르게 작성됐는지 검증할 수 있는 도구도 있는 거예요. 그래서 석싱트팀 같은 경우에 제가 이거로 옛날에 우리가 꿈꾸었던 zkVM을 이제는 되면, 이제는 넥스트 제너레이션 zkVM에는 프리컴파일 서킷을 내가 구현한, 내가 쓰고 싶은 로 조합해서 프루프를 만들고 싶어

이런 걸 하고 싶어 하는 걸로 알고 있어서, 아까 제가 답변을 드리면서 생각했던 게, 석싱트팀이 잘 가고 있는 방향이지 않을까 하는 생각이 들었어요. 로드맵은 그렇긴 한데, 지금 당면한, 지금 현재 버전에서 풀어야 할 문제들도 있고, 그런 부분 같은 경우에는 AI가 좀 해주기 어려운데, 그런 추상적인 디자인을 인간이 냈음에도 실제 구현 레벨에 들어가서의 큰 그림을 보는 게 아직 많이 부족해서, 그거는 아직 좀 먼 얘기로 저희 팀에서 논의하고 있긴 합니다.

28년 한 이쯤에 이제 좀 시도를 해볼까. 내년 Q1 정도까지 저희 프루버 버전을 쓸 수 있을 정도면 되고, 그 뒤에 아마 좀 저희가 병행해서 많이 디자인을 논의하고 하는데, 좀 챌린징한 게 많이 있는 것 같아요. 하나하나 컴파일을 너무 잘 짜줬는데, 빨리 그런 부분을 어떻게 해서 실제 GPU에 실어서 뭔가 엔드투엔드로 가는 프로세스에 있어서는, 저희가 매를, 그동안 버전을 6개 거치면서 많이 맞아봤어요. 같은 실수를 반복하지 않고 적은 기회비용과 코스트로 잘 만들고 그런 거 같습니다.

다 열어주고 있어요. 진짜 다양한 디자인이 있는 거 아니에요. 약간 약간 약간 이어서 진석님께도 같은 질문 여쭤보고 싶습니다. 앱스트랙션에 대해서 어떻게 생각하시는지도 궁금하고, 또 시큐리티 측면에서는 그러면 앱스트랙션이 된다고 그냥 마법처럼 되는 게 아니라 컴플렉시티가 그러면 인프라 스택으로 넘어간 거잖아요. 그런 측면에서 그러면 오디팅하는 대상은 과거에는 서킷 오디팅이 많았던 것 같은데 요새는 인프라 쪽 오디팅도 많이 하는

추세인지, 그런 쪽은 어떻게 되는지도 여쭤보고 싶습니다. 저희는 아무래도 프로덕트 회사는 아니라, 다른 분들이 하는 것처럼 커버하는 스케일이 크진 않거든요. 저희가 지금 만드신 쪽으로 됐는데, 근데 Clean이라고 Lean 4를 사용해서, 래퍼라고 생각하시면 되는데 그거를 사용해서 서킷을 쓸 수 있는 DSL이라고 생각하시면 될 것 같고, 걔 같은 경우는 저희가 흔히 ZK proof라고 생각했을 때 soundness나 completeness 그런 것을 만족하는 서킷을 Lean 그 랭귀지로 쓰는 거죠.

그래서 사실 애플리케이션, 디테일로 쓰려고 하는 애플리케이션이 복잡해지면, 저희가 지금 만들어놓은 건 절대로 서포트는 못할 거예요. 공수가 많이 들어가니까. 그래서 못하는데, 어쨌든 저희가 봤을 때 갈 수 있는 하나의 가능성, 미래로 갈 수 있는 가능성이 하나가 이 Clean이라는 프레임워크를 써가지고 아까 말씀하셨듯이 커스텀 서킷을 다들 쓰고, 그러면 거기에서 보안적인 문제가 있을 수 있는 부분은 바뀌는 거죠.

라이언님이 말씀하셨던 것처럼 Lean 4 컴파일러 같은 것 자체에 문제가 있을 수 있어요. 또 내지는 애플리케이션에서 스펙이라는 걸 작성하게 되는데, 스펙 자체가 문제가 있는 거예요. 대충 그 정도로 줄일 수 있는데, 그러면 스펙은 누군가가 를 해야 될 것이죠. 그래서 그런 관점에서 저희가 그런 서비스를 제공해 줄 수 있지 않을까, Lean 4 스펙을 오디트하는 그런 걸 볼 수 있을 것 같아요. 그렇다고 해서 아예 기존에 있던 low level circuit DSL이 없어졌냐, Circom을 쓴 사람이 없냐 했을 때 아직

그렇지는 않습니다. 여전히 그걸 쓰는 사람들은 있고, 그게 아무래도 완전 완전 low level이다 보니까 그걸 더 신뢰하고, 더 옵티마이징을 갖다 두는 경우도 있는 것 같아요. 좋은 답변 감사합니다. 다음 질문으로 넘어가서, 다음 질문은 이제 잘못된 계산을 완벽하게 증명하는 문제에 대해서 얘기를 해볼 건데, ZK에서는 증명이라는 것을 만들어 내는데, 그 증명이 수학적으로 프로토콜 단에서는 완전하다고 믿는다고 쳐도, 서킷

레벨에서 그 공식을 잘못 적었을 수도 있고, 거꾸로 프로토콜 레벨에서 사운드니스가 잘못됐을 수도 있고, 여러 부분, 사실 ZK 스택이 굉장히 길어지면서 너무 많은 부분에서 시큐리티, 그런 바운더리에서 문제들이 많이 발생을 하잖아요. 그런 점에서 이제 특히 포멀 베리피케이션이 ZK에서 가장 요즘에는 저는 많이 연구가 되고 있는 분야인 것 같아요. 그래서 그쪽 관련해서 이쪽에 관한 어떤 인사이트나 생각들, 아니면 지금 하고 계시는 가 어떻게 관련되는지 한번 이야기를 해주셨으면 좋겠는데, 아까 Clean 얘기를 좀 해주셨으니까

진석님께 먼저 질문 드리고 싶은데, 사실 Clean은 저도 봤었는데 굉장히 좋은 프로젝트인 것 같거든요. 그래서 Clean을 조금만 더 쉽게 설명해주실 수 있는지, 그리고 유저 입장에서, Clean을 사용하는 입장에서는 그러면 를 어떻게 사용하게 되는지, 사용자 경험도 궁금합니다. 일단 Clean이라는 것은 아까 말씀드렸듯이, Lean 4에는 Proof Theorem 랭귀지, 그거에 대한 래퍼라고 보시면 됩니다.

ZK proof를, 결국 그 Lean 4가 하는 것은 가장 베이직한 수학적인 로 모든 것을 증명을 한다고 보시면 됩니다. 근데 그게 자동적으로 컴파일이 되면, 거기서 명시된 것들은 다 수학적으로 검증이 된다, 라는 건데 기본적으로 저희가 만든 프레임워크는 좀 생소한 랭귀지나 입장에서 봤을 때 Rust나 보다는 좀 더 Functional 프로그래밍이 있는 게 좋고 그런 면에서 조금 러닝 커브가 있을 수 있는데,

어쨌든 최대한 러닝 커브가 적도록, 최대한 zkVM을 사용했을 때 이런 데의 유저들과 비슷하도록 설계를 하려고 하는 게 하나입니다. 그리고 이제 유저 입장에서 봤을 때 이 코드를 짜면, 코드를 다른 백엔드, 여기서 백엔드라고 말하는 것은 Plonky2라든지 AIR라는 이름으로, 나중에 이거를 가지고 실제로 proof를 만드는 과정이 필요한데, 그거를 export를 할 수 있는 그 과정을 말하는 거고.

그러면 이제 결국 circuit을 이 Clean이라는 거로 쓰고, export를 한 번 하고, 그걸 다른 같은 거에서 돌려가지고 프루프를 만들게 됩니다. 대충 이런 유저 플로우라고 보시면 됩니다. 네, 좋은 답변 감사합니다. 그리고 이제 Lean 관련해서 얘기가 많이 나올 수밖에 없을 것 같은데, 사실 Lean은 그 Lean 세상 안에서, Lean 커널이 완전하다는 가정에서는, 그래서 Lean은 세상 안에서의 사실에 맞게 쓰였다면 우리가 믿을 수 있는데, 문제는 Lean 언어란 실제로 동작하는 코드가 아니잖아요.

Lean을 우리가 실제로 동작할 수는 있지만 너무 느리니까 안 하고, 얘랑 대응되는 코드를 Lean으로 작성하는 건데, 그거에 대한 믿음은 어떻게 가져와야 할까? 어떻게 해결해야 할까? 진석님 말고도 감사하겠습니다. 다른 문의 주셨나요? 지금이고요. Lean이랑 우리가 실제 실행하는 코드랑 같다는 걸 어떻게 믿어야 할지, 어떻게 그걸 해야 할지. 아, 그 부분이 정말 저도 의문점이 있는 부분이긴 해요.

왜냐하면 Lean으로 검증하려고 하는 부분은 실행 관점에서 보면 witness 생성이라고 해서, 증명하고자 하는 친구를 서킷으로부터 받아야 할 거잖아요. 사실 이 부분이 Lean이 검증해주는 영역이랑 다를 수도 있단 말이에요. 저희가 빠르게 하기 위해서 GPU로 이걸 하고 싶을 때도 있는데 에서 GPU로 변환시키는 이 부분은 두 가지로 변화시켜서는 또 가정의 영역일 수도 있을 것 같아요.

그래서 저는 완벽한 방패는 없는데, 조금 더 사람에게 안심감을 주게 하는 장치로 활용할 것 같고, 또 프루버의 영역도 다르다고 생각합니다. 그 증명할 대상이 있고, 생성하는 친구 관점에서도 우리는 지금 Lean 얘기를 해주셨고, 다른 저희가 또 도구가 있긴 하죠. 도 있긴 하겠지만, 증명 생성하는 로직에 대해서는 또 포멀 베리피케이션 하는 툴은 또 다른 걸 써야 되고, 쓰더라도 그 친구를, 예를 들어서 우리가 보통은 블록체인에서 Rust를 많이 쓰니까 Rust에서 Lean으로 어떻게 변환해서 그걸, Rust에서 Lean으로 어떻게 변환해서

으로 증명할까, 이런 것도 다 뭔가 missing piece이긴 한 것 같아요. 이런 것들은 다만, 해킹 방어라고 했을 때도 사실 해커가 귀찮게 하듯이 사람에게 안정감을 주는 장치로서 하드웨어도, 우리가 프루프를 생산하는 로직도 어떤 때는 CUDA를 쓸 때도 있고 Rust를 쓸 때도 있고, 이런 이 있기 때문에, 근데 가정이 어느 정도 것 같다는 생각이 들어요.

네, 말씀해주신 대로 완전한 건 없으니까 어느 정도까지 믿어야 할지 그걸 잘 생각해주는 게 중요한 것 같은데, 생각하시기에는 어떤 그런 트러스티드한 컴퓨팅 베이스가 어디까지가 적절하다고 생각하시는지. 뭔가… 아, 좋은 질문 같고, 저는 적어도 아까 제가 앞서 말씀드렸듯이 Lean에는 절대 버그가 없다고 가정하는 게 좀 속이 편할 것 같고, 실제 이거를 executable 코드로 바꾸는 거에도 버그가 없다고 가정은 하는 게 좀 편할 것 같고, 마지막 하드웨어도

없다고, 이 정도를 미니멈으로 깔고, 그 위에 아까 Rust랑 뭐 해서 Lean으로 변환하는 거는 조금 더 스트릭하게 검증 가능한 툴이 있으면 좋을 것 같긴 해요. 물론 그 부분도 가정으로 삼을 수도 있긴 한데, 너무 가정이 많으면 안심을 하기 위한 장치일 뿐 전혀 도움이 안 될 수도 있으니까, 그거는 한 번 좀 더 심각하게 해서 논의를 하면 좋겠습니다.

마지막 태훈님으로부터 포멀 베리피케이션에 대해서 생각을 해보겠습니다. 이더리움 재단이 이제 을 로드맵에 넣기 시작하면서 에 좀 가시화가 많이 되다 보니까 이런 스탠다드를 많이 끌고 올라온 것 자체가 저는 중요한 것 같습니다. 2년 전만 해도 학교에서는 포멀 베리피케이션 당연히 해야지, 뭐 얘기는 하지만 실제로 하는 게 없었거든요. 근데 저희는 최신 버전 Hypercube부터는 이제 Nethermind에 있는 포멀 베리피케이션 팀이랑 해서, 그런 RISC-V에 관련된 명세가 얼마나 구현되어 있는지, 이런 것도 점차 단계적으로

그런 서페이스를 넓혀가면 되는데 이제 불가능한 도 없으니까요. 사실 이런 것도 너무 중요한데, 방법론들이 새로 계속 나오고, 더 많이 추가되고, 이런 것도 좋은데, 기본적인 건 잘 해야 하는 것 같아요. 아무리 해도, 만약에 제가 프로토콜을 개발하고 싶은데, 제가 원재님한테 돈을 보내는데 천만 원 이내의 한도만 보냈음을 증명해주길 바라는데, 제가 만약에 제가 짠 프로그램에 이 원재님에게 빠져버리면, 만약에 한테 갔는데 그냥 프루프 검증이 통과되고, 그냥 아 괜찮네 하고 넘어갔다가 사고가

그대로 날 수 있거든요. 기본적인 이제 프로토콜 전체적으로 를 보면서, 만약에 이 과정이 깨졌을 때 어느 정도의 손해가 발생할 수 있는지, 우리 프로토콜이 어느 정도까지 방어가 될지 안 될지, 아 그러면 프로토콜 레벨에서 만약에 이런 비상 상황이 발생했을 때 뭔가 중단을 한다던가, 아니고 뭔가 이제 그런 프로토콜 레벨에서도 많이 디자인을 하다 보면, 그런 뭔가 기저에 깔린 그런 보안에 관련된 가정들에서 오는 불안들을 많이 해소할 수 있잖아요.

생각해서. 그래서 저는 요새 애플리케이션 쪽으로 많이 보다 보니까 그런 부분을 좀 더 많이 신경 쓰려고 하는 것 같아요. 테스트 하네스도 좀 많이 했죠. 엔드투엔드로 이제 proof가, 만약에 진짜 잘못된 입력 수준인데 유효한 proof가 나와서 통과됐을 때, 이 프로토콜은 어떤 손해가 발생할 수 있지? 그런 이제 리스크가 어느 정도 발생할 수 있지? 모델링도 하고 하면서 좀 가는 것 같아요. 포멀 베리피케이션 당연히 할 수 있는 만큼은 다 하고 기본적으로 원래 하던 프로그램 오딧도 받고, 테스트도 많이 짜고, 테스트 템플릿도 많이 만들고 하는, 그런 같은 경우는 실행의 비용이 워낙

점점 싸지더라고요. 더 많이 테스트를 하듯이 해서 많이 방어를 할 수 있는 부분인 것 같아요. 저는 이게 좋은 포인트라고 생각이 들고, 제가 만약에 검증할 때 어떤 걸 쓸 거야, 라고 했을 때 저는 두 가지 기술이 있을 것 같아요. 너 이거 만약 검증 실패할 때 너가 잃는 가치가 얼마나 커. 너 이거 책임져줄 신뢰 조치가 필요해, 하는 순간부터 6가지가 있다고 생각해요. 첫 번째, 사람이 대신 책임을, 책임을 줄 형태가 될 수도 있을 것 같고, 두 번째 같은 경우에는 만약에 autonomous한 상황이, 사람이 매번 체킹을 할 수 없는 사람도 있을 수 있잖아요.

그러면 autonomous한 상황에서도 어떻게든 스텝을 만들어야 되고, 그거는 얼마나 내가 손해를 겪을 수 있는지 이런 trade-off를 계산하면서 하겠지만, 그래서 ZK를 쓰고 쓴다고 했을 때 저는 이때 포멀 베리피케이션 이런 것도 도입을 할 수도 있겠지만, 저는 중간 단계로 프루프를 중앙화된 파티만 생성되게 를 할 것 같아요. 왜냐면 서킷이라고 하는 거는 더 구분되어 있고, 포멀 베리피케이션은 모든 걸 다 막아줄 수는 없죠.

왜냐면 가정을 다 알고 있잖아요. 그래서 그렇다고 하면 만약에, 왜냐면 Zcash도 최근에 관련 사운드니스 버그가 있었는데, 지금 느낀 게 버그로 털렸는지 안 털렸는지 확인도 되지 않잖아요. 그게 반증하는 이유는 서킷을 어쨌든 공개를 해야 할 거예요. 왜냐면 이 서킷으로 작성한 게 Verify Script로 온체인에 올라가 있을 거고, 이게 만약에 오픈되어 있기 때문에 누구나 AI를 통해서 뚫을 수 있는 공격수단 를 확인할 텐데 그걸로 외부에게 공격수단을 제공한 것 같아요. 프루버를 생성하게 해준다는 방법을 제공한다고 했을 때, 두 가지 중간 단위로 프루버를 신뢰하는 주체만 생성하게, 그러면 어떤 환경에서도 되니까. 그런데 이마저도 워킹하지 않는 시나리오가 있을

수 있어요. 그때는 최대한 포멀 베리피케이션 같은 툴을 많이 담아서 ZK 같은 케이스 같은 경우에는 클라이언트 사이드도 상당한 책임이거든요. 내가 서버 사이드에 프라이버시를 제공하려면 어떻게 를 쓰거나 데이터는 같은 프라이버시 트랜스퍼들에 국한되지 않는 것입니다. 특히 한국 같은 경우에는 에어갭, SME, 외국 일부 기관들 같은 경우에는 절대 데이터가 밖에 나갈 수 없는 금융, 의료, 국방 이런 영역들이 있을 때, 그런 경우에선, autonomous and 24-7 working 하는 검증 가능한 시스템을 필요하다고 하면

어쩔 수 없이, 같은 모든 수단을 다 다 때려박아서 어떻게든 뚫리는 시스템을 만들어야 할 것 같습니다. 어쨌든 이, zkVM이나 이런 프레임워크를 만드는 팀들, 그 위에서 사람들이 빌딩을 하잖아요. 그래서 그 프레임워크 자체에 버그가 있으면 사실 모두가 다 어펙트 되는 것 같아요. 그게 되게 무서운 것 같아요.

그게 이제 어쨌든 다 돈이 걸려 있는 거고, 그런 것들이 인상되면. 그리고 이게 팀이라는 게, 프레임워크라는 게 없어도 팀을 꾸려가지고 뭔가 만드는데, 그게 잘 안 되면은 메인테인이 잘 안 되고, 결국 나중에는 이거를 누가 어떻게 쓰는지도 그 트래킹을 하는 사람이 없는 거죠. 그래서 AI가 프레임워크의 버그를 찾았는데, 팀한테 연락을 했는데, 원래 에스컬레이트 돼가지고 이걸 사용하는 사람들을 다 파악해서 알린 다음에, 안전하게 대피한 다음에, 그 다음에 퍼블릭하게 공개가 되어야 하는 절차들이 있는데,

그게 힘들 수 있겠다는 생각이 들어요. 그런 면에서도 플랫폼 입장에서는 힘들 것 같아요. 그런 걸 다 고려해야 하고 비용을 다 지불해야 합니다. 플랫폼에서 화이트 해킹에 보상을 주고 버그를 수 있는 시스템이 필요한데, 그 시스템을 메인테인하는 게 어려우니까, 어떤 문제인가요?

그것보다는 예를 들어서 CVE라고 했을 때, 여기 버그가 있으니까 이거를 메인테이너한테 알리고, 예를 들어서 에 문제가 있다라고 했을 때 거기 팀에다가 알리고, 그럼 되면 이제 그거를 자기들의 프레임워크를 사용하는 다른 팀들한테 알릴, 어떻게 보면 이제 그 리소스를 사용해야 되고, 그걸 다 어떻게 보면 파악을 하고 있어야만, 버그가 있었을 때 자기네들도 영향을 받잖아요.

그런 것들을 안 할 수가 없는 것 같아요. 그러면 다음 질문으로 넘어가도록 하겠습니다. 다음 질문은 ZK의 미래에 대해서 이야기를 해보고 싶은데, 지금은 사실 ZK라는 기술 자체가 블록체인이랑 이더리움이라는 특정 주체에 의해서 캐리되고 있는 상태잖아요. 그런데 이더리움은 어느 정도 zkEVM을 달성하고 나면

zkEVM에 뭐가 필요할지, 그런 의문이 연구자 입장으로서 들기도 하는데, 제 입장에서는 이제 연구를 하다 보니까 ZK가 어디에 또 쓸 수 있을지 그런 것들을 많이 생각 안 하는 편이거든요. ZK가 어떻게 잘 될지 생각을 하다 보니까. 그래서 세 분은 이제 실제 업계에서 좀 더 일을 하고 계시니까 ZK가 예를 들어서 2년, 3년 뒤에 이더리움에서 완전 프로덕션으로 다 완벽히 된다라는 가정을 한번 해보면, 그 이후에 ZK가 뭘 해야 할지, 어떤 쓰임새가 또 있는지, 그런 것들에 대해서 좀 여쭤보고 싶습니다.

먼저 얘기해주실 분 있으신가요? 제가 구체적인 유스케이스가 없는 게 사실 요즘 저희 팀의 제일 큰 고민이기도 해요. 지금 주로 저희는 스케일러빌리티 문제를 ZK로 많이 풀고 있는데 그 외에 프라이버시가 매력적이라고 생각해서 유스케이스를 정말 많이 찾고 있는데, 이게 좀 애매하다. 제가 생각하는 것은, 제일 경계해야 되는 게 ZK가 진짜 싸지고 빨라지고 쓰임새가 좋다고 해서 모든… 뭔가…

모든 애플리케이션에 기본으로 깔릴 필요는 없다는 생각은 하고, ZK 로그인 같은 경우에도, 그리고 뭐… 요즘에 패스키도 있고, 충분히 대체 가능한 다른 더 좋은 게 있을 수 있어요. 이렇게 생각하는 건 좀 아니죠, 그런 건. 그래서 결국에 수요가 어디서 나올까? 근데 왜 프라이버시 유스케이스가 그렇게 크립토 네이티브한 사람들한테는 매력적이었는데, 왜 석싱트같이 롤업들을 스케일하고 하는 데에서 수요가 더 많이 보이고, 프라이버시는 왜 이렇게 하지, 라고 생각하면 저는 결국에 눈으로 보여지는 숫자, 누가

결국에 돈을 내냐에 대해서 생각합니다. 제가 이제 회사 입장에서 고객들한테 프라이버시 피처를 제공하고 싶어서 ZK 인프라 비용을 태우는 거는 ROI가 잘 안 나옵니다. 반면에 롤업이 파이널리티가 빨랐으면 좋겠어 노드를 돌릴 바에 ZK proof로 검증하는 게 훨씬 싸, 하면 그건 숫자로 돌아가죠. 배가 싸졌다, 배 빨라졌다, 이런 게 눈에 띄는데 그런 건 또 아닌데. 아마 지금으로서는 저는 아직 스케일러빌리티 쪽에서도 많이 풀 만한 문제가 많은 것 같아요. 라이언이 아까 말씀해주신 AI 쪽에서도 Verifiability를 활용하는 유스케이스가 있을 것 같고, 그것도 뭔가 흥미롭지 않을까?

그래서 크립토 밖에서 많이 찾으려고 하는데, 뭐… 계속 쉽지 않을까? 지금은 혹시 실제로 이야기를 하고 있거나 뭔가 관계를 되시는 부분이 있나요? 크립토 밖에서? 크립토 밖 같은 건 아닌 것 같아요. TradFi 쪽에서 오긴 하지만 결국에도 지금 자체 롤업을 하고 싶어서, 결국에 아직까지는 스케일링을 하고 베리파이어빌리티를 위해서 ZK를 활용하는 경우가 있는데, 아무리 TradFi에서 와도 체인 관련된 문제로 ZK를 하려고 하는 것이 많습니다.

ZK 미래에 관련된 질문은? 이더리움은 ZK로 변환한다는 것은 맞고, 그 이유는 짧게 요약하자면 서명이 해시로, 해시는 같이 합쳐지지 않는다는 거죠. ZK로 써야 해요. 그리고 두 번째, 우리 파이널리티를 줄이고 싶어. 근데 지금, 밴드위스가 딸려. 왜냐하면 내가 이더리움 블록 검증을 하는데 모든 트랜잭션과 스테이트를 해야 돼요.

밴드위스가 많아. 그래서 이 전송되는 양을 무조건 줄여야 돼요. 세 번째는 이더리움 이코노믹스 상에서 인플레이션이 너무 많으니까 얘를 안 하고 싶어요. 왜 안 하고 싶냐면 지금 그것 때문에 가격이 있다. 요인이 하나가 있다면. 그런데 이걸 하기 위해서는 검증 비용을 싸게 해야 돼요. 그런데 검증 방법을 아까 소개한 것이 약간 재실행도 있단 말이에요. 그렇게 할 수도 있고, 도 있고 그런데 ZK로 전환하면 이렇게 검증이 싸지기 때문에, 그렇게 많이 코인을 인플레이션하지 않아도 되는, 그런 이유 때문에 이더리움을 ZK로 전환하게 되고, 모든 블록체인은 이더리움의 성공적인 ZK 전환을 보게 된다면은 따로 ZK 전환을 하게 되고, ZK에 대한 연산량이 상대적으로 올라갈 거라고 생각이

들긴 하는데, 그런데 AI처럼 연산량이 많을 거냐는 조금 의구심이 있긴 한데, 이거는 트랜잭션당, 당 프루프 생성을 하나 하고, 여기에 마진이 크게 줄 수 있다는 주의해야 할 점이 있는 것 같아요. 한편으로는 저는 여전히 A2A, Agent to Agent를 하고 할 때 액션 를 해서 API를 이용하면서 어떤 경제적 활동을 하게 됐는데, 그런데 API를 제공해주는 대가로 어떤 결과를 받을 텐데, 이 결과를 꼭 검증할 수 있는 건데 없는 건데, 예를 들어서 프레딕션 마켓에서도 재밌는 사례가 있었잖아요. 젤렌스키가 어느 행사장에 양복 정장을 입고 오냐 말 거냐, 양복이란 무엇인가, 이렇게 애매한 결…

그… 검증 불가능한 사례도 있긴 있겠지만, 어떤 것들은 검증 가능한 거예요. 예를 들어서 내가 항공권을 구매하고 싶어요. 항공권이라고 하는 것은 항공사에서 연산을 돌리고 나서 결과가 보여요. 내가 T플러스 5초 후에 나온 티켓과 T플러스 0초에 나온 티켓, 가격은 다 알 수 있어요. 그러면 이 서버로 계산된 게 맞느냐는 사실 ZK의 영역이라고 생각합니다. A2A에서 어떻게 시장이 연결이 되어서, 어떻게 ZK 수요가 많아져서, 거기에 마진을 많이 붙일 수 있는 연산량이 많으면 사실 수익이 나와서 그거로부터 다시 비용도 줄이고 더 큰 마켓을

창출해낼 수 있을 거라고 생각하는데, 그게 좀 전망하는 거 같고 봐야 되는 것 같습니다. 질문을 한 가지만 추가하고 싶은데, ZK가 지금은 저희가 필요한 목적이 있잖아요. 이더리움 블록도 하려면 ZK가 더 발전해야 되고, 포멀 베리피케이션도 아직 ZK가 완전하지 않으니까 연구할 거리들이 아직 많이 남아있는데, 그런데 TLS라든지 Security Protocol들을 보면 이것을 더 발전시킬 만한 새로운 수학적인 것이 나오는

것이 아니라, 계속해서 발전시키는 것은 아니잖아요. 우리가 필요한 만큼 달성하고 나면, 그 이후에도 ZK가 더 발전을 해야 되는지, ZK 인프라 회사들이나 리서치 회사들, 그런 시점이 왔다고 가정해보면, 그 이후에 그런 회사들이 있을 이유가 있을지. 예를 들어 AI는 올라갈수록 더 좋아지잖아요. ZK는 마이너스적이고 방어적이기 때문에, 막을 수 있는 곳까지 가면 여기서 더 발전해야 할 이유가 무엇인지, 그런 부분이 있었는데, 혹시 어떤 게 생각하시나요? 그래서 재미있게 볼 수 있는 게, 올해 ZK에서 투자된 회사가

많이 없는데 Attestable이라고 20밀리언 투자 받은 팀이 있어요. 거기가 하려고 하는 게 LLM을 Verify를 한다고 해서 서비스를 하려고 해서 투자 받은 회사가 있어요. 거기서 실제로 어떻게 했을 때 공개된 검증 가능한 방법은 없긴 하겠지만 이게 무슨 말이냐고 하려면, 왜냐하면 Verifiability를 제공하는 것은 TEE라고 하는 거, 챌린지가 있고, 재생산을 하고, ZK가 있는데, 왜냐하면 우리가 아무 과정을 보고 싶지 않고 ZK로만 이걸 해결하고 싶다고 한다고 하면 숙명적으로 발전할 수밖에 없는 거예요.

왜냐하면 우리가 궁극적으로 검증하고 싶은 대상이 LLM이거든요. 궁극적으로 검토하고 싶은 것은, 완전 LLM은 아니겠지만, 온체인의 도 있고, 증명을 하고 ML을 돌릴 수 있고, 돌릴 기회가 분명히 있을 것 같아요. 예를 들어서, x402가 나온 저는 2025년도에, 재밌는 게 에이전트 페이먼트 5월달부터 이 됐더라고요. 8월에 에 한국팀으로 유일하게 가서, 그때 에이전트 이런 걸 하는구나를 처음 들어서 x402 을 했고, 그때 Cloudflare가 어떻게 말했느냐 하면 Human Web is dying이라고

말을 했어요. 왜 그런가 하면, 이미 그때부터 AI가… AI 트래픽이 이 human의 트래픽과, 글의 생산량이 human을 뛰어넘기 시작한다고 얘기를 했단 말이에요. 그게 무슨 말이냐면, human은 글을 쓰는 이유가 광고를 거쳐서, 그 글을 쓰는 대신에 광고가 와서 수익을 내가 얻고 싶어서 글을 쓰는 건데, AI는 광고가 없고 글만 따라서 재생산을 하는 문제라고 한다고 해요. 문제는 x402가 하려고 하는 거 아니야. 너 지금 글을 읽을 때, 너 이걸 학습할 때 너네가 x402의 실제 메인 이슈라고 생각을 할 거라면 이걸 온체인, x402는 온체인에서 보는 경제 활동인데,

글을 어떤, 내가 토큰 하나 생성될 때, 입력한 소스들이 8개가 있잖아. 근데 8개 다 1 8 8 할 수가 없잖아요. 어떤 글에서 더 많이 입력을 했을 거라고 보면 가중치가 있는데, 저는 이걸 같은 친구가 와서 얘한테 더 많이 줘야 할 것 같다고 생각해요. 그 는 누가 검증할 거야가 당연히 풀어야 하는 문제로 생각하고, 그 친구는 또 제가 하고 싶은, 너무 길게 왔는데, 말씀드리고 싶은 거는 증명해야 할 연산이 점점 복잡하고 비싸지니, 그걸 검증해야 하는 ZK도 따라서 같이 발전해야 한다는 말씀을 드리고 싶었어요.

저는 연구자로서 설득이 된 것 같습니다. 시간이 많이 없어서 마지막으로 진석님의 말씀 들어보고 하겠습니다. 라이언님이 얘기해주신 거 보다 새로운 아이디어가 많아서 좋게 되었습니다. 저는 LLM 관련해서도, 제가 그쪽을 파고든 건 아니지만, 인퍼런스 자체는 어느 정도 ZK가 지금 조금씩 많이 올라왔다고 하시는데, 트레이닝 같은 경우는 많아야 된다고,.

그런 식으로 생각합니다. 정말 유스케이스는 여전히 있는 것 같고, 만약에 인간과 인간 사이에 트러스트가 필요한 인터랙션들이, 이제 에이전트와 에이전트, 머신과 머신, 휴먼과 머신, 그 외에 더 많아지더라도, 하는, 그냥 자연스럽게 그런 어테스테이션, 밸리데이션 그런 것들이 중요해질 것 같다는 생각을 합니다. 그리고 이제 저희 쪽에서 봤을 때는 아이덴티티 쪽이 아무래도 어느 정도 기업들이, 하려고 하는 기업들이 있지 않을까.

기업일 수도 있고 아니면 정부일 수도 있고, 그런 단체들이 봤을 때 ZK의 privacy가, 예를 들어서 selective하게 특정한 ID에서 특정한 정보들을 공개하는, 단체 그런 것들은 혹시 가 있는 것 같고 근데 유저 입장에서 봤을 때 그게 보이지는 않는 거죠. 이게 ZK를 썼다라는 건 전혀 모르겠지만, 어쨌든 기관들이나 정부 입장에서 봤을 때는, 우리는 이런 식으로 안전하게 서비스를 제공한다고 얘기를 할 수 있는데, 그렇지, 문제가 있는 것 같습니다.

네, 답변 감사드리고, 이제 저희 시간이 다 돼서 마무리하도록 하겠습니다. 감사합니다. 저희 패널 세션을 진행해주신 박수 한 번 부탁드립니다.