a16z: Jolt zkVM 관련 사고와 설명
글: 저스틴 탈러(Justin Thaler), a16z 리서치 펠로우
번역: 샤오쭈(xiaozou), 금색재경(金色财经)
지난 여름 주제 논문과 Lasso 배포를 시작으로 지난달 완전히 오픈소스화된 Jolt 구현 출시에 이르기까지, 우리는 Lasso+Jolt(새롭고 쉬운 고성능 룩업 아규먼트 및 zkVM) 기술 연구에서 꾸준한 진전을 이루어왔다.
기존 기술과 비교할 때 이러한 구현은 Jolt의 밝은 전망을 보여주며 SNARK 설계에서 통용되던 많은 기존 지식들에 도전하고 있다. 출시 이후 우리는 지속적으로 업데이트를 진행하여 Rust 표준 라이브러리 지원을 추가했고, 10명 이상의 기여자들이 제공한 개선 사항을 통합했으며, 거의 50개의 풀 리퀘스트를 병합했고, 코드베이스의 모듈화 성능과 확장성을 개선했다.
Jolt를 계속해서 강화해 나가면서, 외부의 의문과 혼란에 응답하고 오해를 바로잡으며 핵심적인 문제들에 대한 나의 견해를 공유하고자 한다. 본문에서 다룰 네 가지 주제는 다음과 같다. (1) sum-check 프로토콜과 Binius 커밋먼트 스킴 간의 관계, (2) Jolt 내에서 sum-check와 lookups의 역할, (3) 타원 곡선과 해시, (4) zkVM 관련 사전 컴파일(precompiles).
1. Sum-check 프로토콜과 Binius 커밋먼트 스킴
커밋먼트 스킴(commitment schemes)은 일반적으로 SNARK의 핵심 구성 요소로 간주된다. 하지만 마찬가지로 중요한 또 다른 구성 요소인 다항식 IOP(polynomial IOP)도 주목해야 한다. 예를 들어, 다중선형 다항식 위에서 작동하는 Binius 커밋먼트 스킴은 중대한 발전이지만, 제출된 데이터가 실제로 증명자의 주장에 대해 유효함을 검증한다는 것을 증명하기 위해선 다항식 상호작용형 오라클 증명(polynomial interactive oracle proof, PIOP)과 결합되어야 한다.
Binius의 커밋먼트 스킴은 sum-check 프로토콜을 사용하는 PIOP와 매우 잘 맞는다. 이유는 명확하다(sum-check는 단일 변수 다항식보다는 다중선형 다항식에 의존하며, FRI-Binius조차 내부적으로 sum-check를 사용한다). 또한 미묘한 이유도 있다(sum-check PIOP는 자연스럽게 임의의 특성 필드에서 동작하므로 Binius의 새로운 성능을 최대한 활용하는 데 중요하다). 반면 Binius 커밋먼트 스킴은 현재 가장 흔한 PIOP들과 호환되지 않는데, 안타깝게도 그 PIOP들은 sum-check를 사용하지 않는다.
빠른 PIOP를 설계하기 위해서는 단순히 "sum-check 적용"이라는 말 이상의 더 깊은 통찰이 필요하다. Binius는 효율적인 다항식 IOP를 구현하기 위해 sum-check 프로토콜을 사용한다. Binius 논문의 4장과 5장은 커밋먼트 스킴과 결합될 수 있는 새로운 고효율의 sum-check 기반 PIOP를 설계하는 데 집중하고 있다.
Binius 커밋먼트와 Jolt의 조합은 땅콩버터와 젤리처럼 잘 어울린다. 왜냐하면 Jolt는 현재 유일하게 sum-check 프로토콜에만 전적으로 기반한 zkVM이기 때문이다. 현재 Jolt는 타원 곡선 암호 기반의 커밋먼트 스킴을 사용하고 있지만, Binius 커밋먼트를 Jolt에 통합하는 것이 우리 연구의 최우선 과제이다.
2. Sum-check, lookups, 성능 및 간결성
무엇이 Jolt를 돋보이게 하는가? Jolt가 첫 번째이자 유일한 sum-check 기반 다항식 IOP를 사용하는 zkVM이기 때문인가, 아니면 거의 모든 작업을 제약(constraint) 시스템이나 회로 대신 lookup을 통해 수행하는 'lookup 특이점'을 달성했기 때문인가? 정답은 둘 다이다. 기존의 zkVM들과 비교할 때 Jolt의 대부분의 간결성 장점은 lookup에서 비롯되며, 성능 장점은 lookup과 sum-check의 사용에서 비롯된다.
순수한 lookup 접근 방식은 특정 명령어(매우 작은 회로가 없는 명령어)에는 더 좋지만, 매우 작은 회로를 가진 다른 명령어에는 오히려 성능이 낮을 수 있다. 그러나 전체적으로 보면 순수 lookup 접근은 성능 측면에서 이익만 있고 손실은 없으며, 적어도 256비트 필드를 처리할 때는 그렇다. 현재 Jolt 증명자는 '명령 실행' lookup에 시간의 20%를, 제약 정보 검증에 40%를 소요한다. lookup 수를 줄이기 위해 더 많은 제약을 추가하는 것은 전혀 도움이 되지 않는다.
대략적으로 말해, Jolt는 CPU fetch-decode-execute 사이클의 'fetch'와 'execute' 부분을 구현하기 위해 lookup을 사용한다. 이러한 lookup은 충분히 빠르기 때문에 증명자의 대부분의 시간은 전통적인 제약을 통해 처리되는 'decode' 단계를 증명하는 데 소요된다.
순수 lookup 접근은 더 간결하고 감사하기 쉬운 구현을 촉진한다. 이러한 이점들은 정량화하기 어렵고 시간이 지나야 인식되고 인정받을 수 있다. 그러나 코드 행 수(Jolt 코드베이스는 약 2만 5천 줄로 기존 RISC-V zkVM보다 2~4배 적음)와 개발 시간 측면에서 Jolt는 우수한 성과를 보여준다. 이런 개선은 성능 개선보다 훨씬 어렵다. 나는 앞으로 몇 달 안에 zkVM 증명자가 2023년 8월 대비 약 100배 빨라질 것으로 예상하지만, zkVM의 코드 행 수가 언제 10배 줄어들 수 있을지는 상상하기 어렵다.
3. 타원 곡선
공적 담론은 타원 곡선용 빠른 zkVM의 이점을 과소평가하고 있는데, 이는 부분적으로 Binius와 같은 해시 기반 커밋먼트 스킴에 대한 광범위한 열정 때문이기도 하다.
타원 곡선 암호화에 관한 진술을 증명할 때, 타원 곡선 기반 zkVM은 비자연 필드 알고리즘(non-native field algorithms)을 피할 수 있으며, 이는 증명 시간에 수백에서 수천 배의 오버헤드를 초래할 수 있다. 이러한 응용 분야에는 블록체인 라이트 클라이언트 및 SNARK 기반 브릿지와 관련된 주요 작업인 다양한 디지털 서명의 증명, Plonk/Groth16/Nova/Honk 증명의 집계, Verkle 트리 인증 경로의 증명 등이 포함된다.
나는 커뮤니티가 sum-check 기반 PIOP와 FRI-Binius 커밋먼트 스킴의 조합을 많은 응용 분야에서 SNARK를 수행하는 올바른 방법으로 주목하길 기대한다. 그런 일이 발생하더라도, 세상이 타원 곡선 암호화를 완전히 폐기하지 않는 한(예: 사회가 양자 안전하지 않은 암호 체계로부터 완전히 전환한 후에도), 타원 곡선 기반의 빠른 SNARK는 여전히 유용하다.
요약:
타원 곡선 기반 커밋먼트는 현재 존재하는 다른 모든 zkVM들과 경쟁한다(모든 기존 zkVM은 이미 작은 필드를 처리하기 위해 해시 기반 커밋먼트를 사용하고 있음).
타원 곡선에 관한 진술을 증명할 때(적어도 비자연 필드 알고리즘에 큰 진전이 없는 한), 사람들은 타원 곡선과 결합된 Jolt를 사용하려 할 것이다.
순수한 zkVM로서 Jolt와 Binius 커밋먼트를 결합하면 다른 대안보다 훨씬 빠를 것이며, 타원 곡선에 관한 진술 또는 작은 필드 증명을 제외한 경우(이 경우에는 타원 곡선이 결합된 Jolt를 사용함) 사람들은 Jolt와 Binius 커밋먼트 조합을 사용할 것이다.
체인에 증명을 게시하기 전에 증명 크기와 검증자 비용을 줄이기 위해 타원 곡선 기반 SNARK는 계속 사용될 것이다. 이 경우 큰 필드를 처리하는 zkVM이 역할을 하게 된다. 오늘날에도 해시 기반 zkVM 프로젝트는 실제로 BN254 곡선 위에 정의된 zkVM을 재귀 과정의 일부로 사용하고 있다고 생각한다.
4. 사전 컴파일 및 zkVM 벤치마크
사전 컴파일과 그것이 zkVM 및 벤치마킹에서의 역할에 대해 일부 논의가 있었다. 설명에 앞서 '사전 컴파일'이 무엇인지 설명하는 것이 도움이 될 것이다. 왜냐하면 '사전 컴파일'이라는 용어는 서로 다른 맥락에서 다른 의미를 가질 수 있기 때문이다.
(1) 이더리움의 '사전 컴파일'
이더리움 가상 머신(EVM)에서 사전 컴파일은 자주 실행되는 연산이며, 효율성을 높이기 위해 원시적으로 지원된다. 이를 통해 길고 번거로운 EVM 오퍼코드 시퀀스를 통해 이러한 연산을 실행함으로써 발생하는 막대한 오버헤드와 과도한 가스 비용을 피할 수 있다.
'EVM 사전 컴파일'과 '기본 명령어'(오퍼코드) 간의 차이는 주로 의미론적 차이이다. 예를 들어 Keccak 해시 함수는 EVM 오퍼코드이며, SHA-2는 EVM 사전 컴파일이다. 사전 컴파일과 오퍼코드 모두 자주 실행되는 연산이며, 이더리움은 효율성과 가스 비용을 최적화하기 위한 동일한 목적을 위해 원시적으로 지원한다. 부정할 수 없이 사전 컴파일은 EVM의 일부이며, EVM은 종종 오퍼코드를 넘어서는 이더리움 실행 환경을 포괄적으로 설명하는 데 사용된다.
EVM 기능이 오퍼코드와 기본적으로 동일하다면 왜 사전 컴파일이 필요한가? 주로 관례 때문일 것이다. 또 다른 가능한 이유는 사전 컴파일이 미래에 변경이 필요한 암호 원시(primitives)처럼 비교적 복잡한 연산으로 구성되기 때문에 오퍼코드를 할당하지 않으면 미래에 변경하기가 더 쉬워질 수 있다는 점이다.
(2) zkVM 설계에서의 '사전 컴파일'
zkVM 설계에서 사전 컴파일은 특정 함수(Keccak 또는 SHA 해시) 또는 특정 타원 곡선 연산 세트에 대해 특별히 설계된 SNARK를 의미한다. 오늘날의 SNARK 사전 컴파일은 일반적으로 수작업으로 최적화된 제약 시스템을 통해 구현되지만(커뮤니티가 sum-check 기반 SNARK로 전환함에 따라 이러한 제약 시스템의 성격과 증명 방식이 바뀔 것이다).
EVM 사전 컴파일과 zkVM 사전 컴파일 사이에는 깊은 유사성이 있다. Jolt 출시 이전에는 zkVM이 각각의 명령어마다 수작업으로 최적화된 제약 시스템을 통해 기본 명령어를 구현했는데, 마치 사전 컴파일을 구현하는 것과 마찬가지였다.所谓 zkVM 사전 컴파일과所谓 기본 명령어 사이의 차이는 순전히 의미론적이다. 실질적인 차이는 없다.
Jolt에서는 전통적인 제약이 아닌 lookup을 사용하여 기본 명령어를 구현한다. 그러나 일부 기본 명령어를 제약을 통해 구현하는 선택은 큰 문제가 아니다.(사실 lookup 자체도 일종의 제약으로 간주될 수 있다.) 실제로 내가 이전에 말했듯이, 우리가 Binius 커밋먼트 스킴으로 전환하면 RISC-V의 덧셈과 곱셈을 전통적인 제약을 통해 구현해야 할 수도 있다.
5. zkVM 벤치마크
이러한 배경을 바탕으로, 이제 사전 컴파일에 대한 내 견해를 zkVM 및 벤치마크와 관련하여 설명하겠다.
첫째, 사전 컴파일 없이 다양한 RISC-V zkVM들을 벤치마킹하는 것은 바로 RISC-V zkVM을 벤치마킹하는 본래의 의미이다. 'zkVM'이라는 용어는 비공식적인 명칭이므로 불가피하게 해석의 차이가 생기겠지만, 내 관점에서 하나 이상의 사전 컴파일을 갖춘 RISC-V zkVM은 더 이상 RISC-V zkVM이 아니다. 그것은 각 사전 컴파일을 기본 명령어로 추가한 RISC-V 기반의 새로운 명령어 세트를 가진 zkVM이다. 적어도 각 사전 컴파일이 추가될 때마다 zkVM 패러다임의 가치 제안이 약화된다—회로가 추가될수록 잠재적인 버그 영역이 늘어나며 기존 프로그램은 이러한 새로운 사전 컴파일을 즉시 활용할 수 없다.
또한 일부 사람들은 zkEVM의 EVM 사전 컴파일 개념을 zkVM의 사전 컴파일 개념과 혼동하기도 한다. 그러나 이것은 완전히 다른 두 가지이다. zkEVM의 일부 핵심 연산—예를 들어 Merkle 해시 및 디지털 서명 검증—이 초기 RISC-V 명령어보다 훨씬 복잡할 수 있지만, 이는 EVM 사전 컴파일과 초기 EVM 명령어 사이에 기능적 차이가 없다는 사실을 바꾸지 못한다. zkEVM은 EVM과 동등하다고 주장하기 위해 EVM 사전 컴파일을 반드시 지원해야 한다. 즉, EVM 사전 컴파일을 지원하지 않는 zkEVM은 Jolt와 같은 RISC-V zkVM과 다르다. 후자는 사전 컴파일을 통해 RISC-V를 넘어선 명령어 세트를 확장한다.
또 다른 문제는 어떤 '공정한' 함수 세트를 선택하여 zkVM을 벤치마킹할 것인지이다. 그러나 RISC-V zkVM의 경우 어떤 함수 세트라도 공정하다. 증명자(prover) 시간은 거의 전적으로 RISC-V CPU가 실행하는 사이클 수에 의해 결정되는데, 그 이유는 두 가지이다. 첫째, 증명자는 'fetch-decode-execute' 사이클의 'execute' 부분에 소요되는 시간이 극히 짧다. 둘째, 다양한 RISC-V 명령어 및 메모리 접근의 증명 시간은 매우 유사하다.(Jolt에서는 모두 오프라인 메모리 검사 기술로 처리된다.)
마지막으로, 사전 컴파일을 사용한다면 Jolt의 성능이 다른 대안보다 나쁠 가능성은 거의 없다. 실제로 나는 Jolt가 더 나을 것이라고 예상한다. 왜냐하면 sum-check 기반 사전 컴파일이 가장 빠를 것이며, Jolt는 sum-check 기반 PIOP만 사용하기 때문에 오버헤드 없이 통합될 수 있기 때문이다. 여기서 일부 사람들은 타원 곡선 커밋먼트 스킴을 사용하는 사전 컴파일이 해시 기반 스킴을 사용하는 것보다 훨씬 성능이 낮을까 걱정한다. 현재 Jolt는 타원 곡선을 사용하지만 이것이 필수는 아니며, 우리는 항상 Binius로 전환하는 계획에 열려 있다.
6. 벤치마크에 대한 광범위한 사색
벤치마킹의 주요 목표는 서로 다른 증명 시스템의 내재적 성능을 파악하는 것이며, 어느 정도는 구현과 분리할 수 있다. 이러한 접근법은 커뮤니티가 고효율이면서 안전한 SNARK를 설계하기 위한 올바른 기술을 이해하고 집중할 수 있도록 한다. 그러나 두 개의 서로 다른 SNARK를 비교하려 할 때 무수한 혼란 요인이 존재하여 정밀한 비교가 불가능하게 만든다.
엔지니어링 노력도 이러한 혼란 요인 중 하나인데, 커뮤니티의 많은 사람들이 반대되는 입장을 취하고 있는 것처럼 보인다. 생각은 다음과 같다. 만약 어떤 프로젝트가 특정 하드웨어용 사전 컴파일이나 최적화를 추가하는 등의 '기능'을 추가했다면, 어떤 벤치마크에서도 '명예'를 가져야 한다는 것이다.
두 가지 관점 모두 장점이 있다. 그러나 장기적으로 보면 후자의 관점은 분명히 설득력이 없다. 새로운 방법은 언제나 기존 프로젝트와 비교할 수 있는 시간이 부족하기 때문에 어떤 벤치마크에서도 영원히 열세에 처할 것이다. 이러한 관점은 진보를 저해하는 것이다.
시간이 지남에 따라 벤치마크 관련 혼란 요인이 줄어들 것으로 기대한다. SNARK 개발 도구가 성숙함에 따라 좋은 성능을 내기 위해 필요한 엔지니어링 노력의 양은 줄어들 것이다. zkVM의 비용은 특정 애플리케이션의 특성보다 사이클 수에 주로 좌우되는데, 이는 작은 기적이라 할 수 있다(적어도 RISC-V의 경우 그렇다). 사람들이 제약 시스템의 선택(R1CS, AIR, Plonkish 등 현재의 단편화 상태 대신)에 주목한다면 제약 시스템 기반 SNARK에서도 사이클 수를 대체하는 간단한 측정 방법을 통해 유사한 상황이 나타날 수 있다.
그 전까지는 혼란 요인을 너무 적게 혹은 지나치게 통제하는 사이에서 적절한 균형을 이루기 어렵다. 의견 차이는 불가피하며, 건설자들은 커뮤니티가 이해하고 논의할 수 있도록 각 벤치마크 뒤에 있는 전체 맥락, 세부 정보 및 근거를 제공해야 할 것이다.
TechFlow 공식 커뮤니티에 오신 것을 환영합니다
Telegram 구독 그룹:https://t.me/TechFlowDaily
트위터 공식 계정:https://x.com/TechFlowPost
트위터 영어 계정:https://x.com/BlockFlow_News
a16z
