Lin Oshitani ( Nethermind Research ) 작성. Matteo , Ahmad , Michal , Conor , Gustavo , Daniel , David , Yuewang, Ignacio 의 토론 및/또는 검토에 감사드립니다. Musa 의 토론 및 벤치마크 실행 지원에도 감사드립니다.
이 연구는 Taiko와 Nethermind 간의 전략적 파트너십 의 일환으로 Taiko 의 자금 지원을 받았습니다.
요약
각 오퍼코드의 개별 검증 비용은 얼마일까요? 이 질문에 답하기 위해, EF의 zkEVM 벤치마킹 도구와 imapp 팀의 Gas Cost Estimator 한계 방법을 기반으로 멀티 GPU 환경에서 개별 이더리움 가상 머신(EVM) 오퍼코드와 프리컴파일의 가스당 검증 시간을 벤치마킹했습니다. 또한 실제 검증 시간 측정값을 사용하여 zk 사이클이 실제 검증 시간을 의미 있게 반영하는지 평가했습니다.
소개
ZK 롤업이 롤업 단계 측면과 시퀀서 및 프로버의 탈중앙화 측면 모두에서 더욱 탈중앙화됨에 따라, 프로버 킬러 블록을 완화하는 것이 보안 및 경제적 지속가능성을 위해 매우 중요해집니다. 이러한 악의적인 블록은 이더리움 가상 머신(EVM) 가스 한도 내에서 증명 시간을 최대화하도록 설계되어 서비스 거부 공격을 유발하거나 증명을 경제적으로 불가능하게 만들 수 있습니다 . 더욱이, 이더리움 L1 자체가 ZK 기반 확장으로 전환됨에 따라 동일한 문제에 직면하게 될 것입니다.
기존 이더리움 가상 머신(EVM) 가스 측정 방식은 CPU 시간, 스토리지 접근, 상태 증가와 같은 실행 비용만 고려하고 증명 비용은 전혀 측정하지 못합니다. 따라서 ZK 롤업에는 추가적인 안전장치가 필요합니다. 대표적인 접근 방식은 증명 비용을 명시적으로 측정하고 이를 기반으로 블록 제한을 적용하는 것입니다. 하지만 이러한 메커니즘을 구축하려면 개별 연산이 전체 증명 시간에 어떻게 기여하는지 정확하게 모델링해야 하며, 악의적인 블록 생성을 방지하면서도 사용성을 과도하게 저해하지 않을 만큼 정밀해야 합니다.
증명 시간을 모델링하기 위해 우리는 다음과 같은 핵심 질문에 집중합니다. 각 이더리움 가상 머신(EVM) 오퍼코드 또는 프리컴파일이 전체 증명 시간에 개별적으로 얼마나 기여하는가? 구체적으로, 다른 모든 조건이 동일하다고 가정할 때, 추가적인 X 가스를 소모하는 특정 오퍼코드 또는 프리컴파일을 추가하면 증명 시간이 얼마나 증가하는가? 이를 통해 각 오퍼코드 또는 프리컴파일에 대한 가스 단위당 한계 증명 시간을 추정합니다.
이더리움 재단에서 수행한 이전 zkEVM 벤치마킹 작업은 특정 오퍼레이션 코드 또는 사전 컴파일을 반복하여 블록을 촘촘하게 구성하는 방식으로 엔드투엔드 측정값을 제공했습니다. 이 접근 방식은 증명 비용이 매우 높은 연산, 즉 대상 연산의 비용이 전체 증명 시간의 대부분을 차지하는 연산을 식별하고 분석하는 데 효과적입니다. 그러나 이러한 벤치마크는 연산별 비용을 주변 오버헤드(예: 스택에 인수 푸시, 반환 값 팝, 제어 흐름)와 명확하게 분리하지 않기 때문에 주변 코드가 측정값에 큰 영향을 미칠 수 있는 저비용 연산에 대해서는 유용한 정보를 제공하지 못합니다. 결과적으로 모든 오퍼레이션 코드와 사전 컴파일에 걸쳐 증명 시간을 포괄적으로 모델링하는 데에는 충분하지 않습니다.
이러한 한계를 극복하기 위해, imapp 팀의 Gas Cost Estimator 프로젝트에서 사용된 한계 측정 방식을 채택했습니다. 이 방식은 실행 컨텍스트의 다른 모든 요소를 고정한 상태에서 목표 연산 횟수만 변경하는 테스트 케이스를 생성하여 각 오퍼코드 또는 사전 컴파일의 기여도를 주변 오버헤드로부터 분리합니다. 그런 다음 선형 회귀 분석을 수행하고 기울기를 계산하여 단위 가스당 검증 시간을 추정합니다.
저희 벤치마크 구현은 이더리움 재단의 zkEVM 벤치마킹 워크로드 툴링을 기반으로 구축되었으며, 이를 통해 구현이 가능해졌습니다. 저희는 gas-cost-estimator의 한계 방법론을 따르는 맞춤형 실행 사양 테스트 모음을 개발했으며, ZK 프로빙 환경에 더 잘 맞도록 확장했습니다(예: 고정된 ZK 프로빙 설정 오버헤드가 측정값을 지배하지 않도록 증폭하는 방법). 이러한 테스트 픽스처는 SP1에 멀티 GPU 지원이 추가된 EF 벤치마킹 툴링의 맞춤형 포크(Fork) 사용하여 실행되었습니다.
또한, 벤치마킹 결과를 사용하여 zk 사이클이 실제 증명 시간을 직접적으로 측정한 값에 대한 의미 있는 대리 변수인지 평가했습니다. 그 결과, 증명 시간과 zk 사이클 간의 관계가 오퍼코드와 사전 컴파일에 따라 크게 달라지므로 zk 사이클 기반 추정치의 정확도가 제한됨을 발견했습니다.
주요 결과
먼저 결과를 제시합니다. 가정 및 실험 설정에 관심 있는 독자는 방법론 섹션 에서 자세한 내용을 확인할 수 있습니다.
이 섹션에서는 아래 환경에서 실행된 벤치마크의 주요 결과를 제시합니다(설정에 대한 자세한 내용은 아래 방법론 섹션을 참조하십시오).
검증 도구 : sp1-v5.2.3 (sp1-cluster 포함) 및 risc0-v3.0.4 (
RISC0_KECCAK_PO2=15플래그를 사용하여 검증 도구의 충돌 방지)GPU : NVIDIA GeForce RTX 4090 4개
실행 클라이언트: reth-v1.9.3
참고: 검증 시간은 실행 구성(예: 검증자 플래그 및 구성, 하드웨어/런타임 설정, 검증 당시 GPU 상태 이더리움 클래식(ETC))에 따라 크게 달라집니다. 따라서 이러한 결과는 구성별 측정값으로 해석해야 합니다.
참고: 이 벤치마크는 블록 헤더 유효성 검사 없이 실행되었습니다. 로컬 테스트 결과 유효성 검사는 대부분의 오퍼레이션 코드에 거의 영향을 미치지 않는 것으로 나타났습니다. 로그 관련 오퍼레이션 코드의 경우 4~5배 증가하지만, 유효성 검사 비용은 상대적으로 저렴합니다.
가스별 검증 시간
아래 표는 SP1과 RISC0 모두에서 각 오퍼코드/프리컴파일에 대한 "가스당 검증 시간"을 나타냅니다. 이 지표는 특정 오퍼코드 또는 프리컴파일에 가스 1단위를 추가로 사용할 때 발생하는 추가 검증 시간을 나타냅니다. R² 값은 선형 회귀의 적합도를 보여줍니다.
더 자세한 데이터(예: 각 오퍼레이션 코드에 대한 회귀 분석 그래프)는 SP1 , RISC0 에서 확인할 수 있습니다.
몇 가지 예비 관찰 결과:
일반적으로 암호화 사전 컴파일(예:
modexp,point_evaluation)은 가스당 증명 시간이 오래 걸립니다.Mod/division 관련 opcode(
mulmod,mod,div,sdiv)는 상대적으로 높은 증명 시간과selfbalance가지고 있습니다.log/create 관련 Opcode(
log1,log2,log3,create,create2)는 SP1과 RISC0 모두에서 가스당 증명 시간이 가장 빠른데, 이는 해당 가스 비용이 계산보다는 데이터 및 스토리지에 의해 좌우되기 때문일 가능성이 높습니다.일반적으로, RISC0과 SP1에서 연산 코드의 증명 시간 순위는 비슷하지만, 몇 가지 주목할 만한 예외가 있습니다(예:
keccak256은 RISC0에서 약 12배 느리고,sha256은 RISC0에서 약 10배 빠릅니다). 이는 특정 연산 코드/사전 컴파일에 대한 zkvm 사전 컴파일이 한쪽에는 존재하지만 다른 쪽에는 존재하지 않기 때문일 가능성이 높습니다(증명기 간의 더 자세한 비교는 부록: SP1/RISC0 비교표를 참조하십시오).
ZK 사이클당 검증 시간
ZKVM은 ZK 사이클 이라는 개념을 가지고 있는데, 이는 기존 컴퓨터의 CPU 사이클과 유사하게 ZKVM이 프로그램을 검증하기 위해 수행하는 계산 단계 수를 나타냅니다. 여기서 자연스럽게 드는 질문은 ZK 사이클이 실제 검증 시간을 얼마나 잘 반영하는가 하는 것입니다. 만약 ZK 사이클이 모든 연산에서 검증 시간과 선형적인 상관관계를 보인다면, ZK 가스 사용량 측정에 있어 더 간단한 지표로 활용될 수 있을 것입니다. 그러나 상관관계가 비선형적이거나 연산 유형에 따라 크게 달라지는 경우, 정확한 DoS 공격 방어를 위해서는 검증 시간을 직접 측정해야 합니다.
이 질문에 답하기 위해 각 오퍼코드/프리컴파일에 대해 증명 시간과 zk 사이클 간의 선형 회귀 분석을 수행했습니다. 결과는 다음과 같습니다.
주어진 작업 내에서 사이클 수와 시간 사이의 관계는 매우 선형적입니다(높은 R² 값). 즉, 사이클 수가 두 배가 되면 검증 시간도 대략 두 배가 됩니다. 하지만 사이클 수를 시간으로 변환하는 비율은 보편적이지 않으며, 작업 종류에 따라 크게 달라집니다.
아래 막대 그래프는 각 연산의 "zk 사이클당 시간"을 보여줍니다. 사이클이 좋은 지표라면 모든 막대가 대체로 일치해야 하지만, 실제로는 넓게 퍼져 있습니다. 이는 일부 연산이 서로 다른 회로(예: 사용자 정의 zkVM 사전 컴파일)에서 구현되었기 때문일 가능성이 높습니다. 예를 들어, SP1에서 bn128_add zk 사이클당 약 930ns가 소요되는 반면 pop 약 63ns만 소요되어 약 15배의 차이가 납니다. 이는 zk 사이클만으로는 검증 시간을 정확하게 측정하기에 불충분함을 시사합니다. 개선 방안은 다음과 같습니다.
(이 게시물에서 설명한 것처럼) 측정된 검증 시간을 사용하는 계량기
검증 시간을 더 정확하게 반영하도록 사이클 회계 방식을 개선하십시오 (예: 서로 다른 회로 간의 zk 사이클 변환 개선).
ZK 사이클을 검증 시간 대용 지표로 사용하되, 보수적으로 접근하십시오. 즉, ZK 사이클 작업당 가장 느린 시간을 기준으로 삼으십시오.
방법론
우리는 개별 운영의 검증 비용을 분리하기 위해, 원래 imapp 팀이 Gas Cost Estimator 프로젝트의 일환으로 L1 가스 재가격 책정을 위해 개발한 한계 비용 접근 방식을 채택합니다.
먼저, 각 오퍼코드/프리컴파일에 대해 연산 횟수가 다양한(0, N, 2N, 3N 이더리움 클래식(ETC)) 4~7개의 블록을 생성하되, 스택 설정, 메모리 초기화, 제어 흐름 및 정리 작업과 같은 다른 모든 요소를 변형 간에 동일하게 유지하여 오버헤드를 일정하게 유지합니다.
아래 표는 ADD 연산 코드에 대한 바이트코드 구조의 예시입니다. 각 변형은 정확히 20개의 PUSH와 10개의 POP으로 구성되어 있으며, ADD 연산의 횟수만 다릅니다.
| op_count | 설정 | 기본 | 대청소 |
|---|---|---|---|
| 0 | 푸시×20 | — | POP×10 |
| 3 | 푸시×20 | ADD + (POP + ADD)×2 | POP×8 |
| 5 | 푸시×20 | ADD + (POP + ADD)×4 | POP×6 |
| 10 | 푸시×20 | ADD + (POP + ADD)×9 | POP×1 |
다음으로, 각 블록 변형을 실행하고 전체 블록 의 증명 시간과 가스 소비량을 기록합니다. 그런 다음 모든 변형에 걸쳐 proving_time = α × gas_used + β 적용합니다. SP1의 ADD 연산 코드에 대한 예시는 다음과 같습니다.
기울기 α 는 고려 중인 오퍼코드 또는 사전 컴파일에 대한 단위 가스당 한계 검증 시간을 나타냅니다. 다른 모든 실행 컨텍스트는 일정하게 유지되고 대상 연산 횟수만 변하기 때문에 α 해당 연산의 기여도를 분리해냅니다. 위 예시에서 α = 3.78µs 이므로 4개의 GPU를 사용하는 SP1 환경에서 ADD 연산에 대한 가스당 검증 시간은 3.78µs .
Opcode/사전 컴파일 인수
오퍼코드/사전 컴파일 인자의 경우, 대표성을 갖도록 고정된 입력값을 사용하며, 가능한 한 최선의 노력을 다해 "최악의 경우"를 고려합니다. 이러한 선택은 기존 벤치마킹 도구 모음 에서 알려진 최악의 경우 패턴을 기반으로 합니다. 최악의 경우 입력값을 사용함으로써 특정 입력값(예: 모든 버퍼가 0인 경우)에서만 발생하는 최적화된 빠른 경로를 의도치 않게 측정하는 것을 방지할 수 있습니다.
우리의 작업 가정은 주어진 연산에 대한 증명 시간이 가스 소비량에 비례하여 선형적으로 증가한다는 것입니다. 이는 연산 횟수가 다를 뿐만 아니라 동일한 연산 내에서 인자 선택이 다를 때도 마찬가지입니다(즉, 가스 소비량이 두 배가 되면 증명 시간도 두 배가 됩니다). 이는 (1) 가스가 계산 복잡성을 정확하게 반영하고, (2) 증명 시간이 해당 복잡성에 비례하여 증가한다는 가정을 전제로 합니다.
실제로는 이러한 가정이 성립하지 않을 수 있습니다. 예를 들어, 가스가 계산 복잡성을 정확하게 반영하지 않거나 ZKVM이 특정 인수에 대해 다른 동작을 보이기 때문입니다. 따라서 본 연구의 측정 결과는 테스트된 입력에 대한 것이며, 다른 입력에 대해서는 근사치로만 해석해야 합니다. 각 연산에 대해 전체 인수 공간에 걸쳐 증명 시간이 어떻게 변하는지 살펴보는 등, 인수에 따른 증명 비용에 대한 보다 세밀한 분석은 향후 연구 과제로 남겨둡니다.
마지막으로, LOG 및 CREATE와 같이 가스 비용이 주로 계산량보다는 데이터 크기와 메모리 확장에 따라 결정되는 작업의 경우, 최악의 경우를 가정한 인수 대신 표준 인수(예: 32바이트 페이로드)를 사용합니다. 대용량 페이로드를 사용하면 증명 작업량이 의미 있게 증가하지 않으면서 가스 비용이 급증하여 가스 단위당 증명에 필요한 계산 오버헤드를 과소평가하게 됩니다.
EF 벤치마킹 툴링과의 통합
저희 벤치마킹 파이프라인은 이더리움 재단의 zkEVM 벤치마킹 워크로드를 기반으로 구축되었으며, 두 가지 주요 확장 기능을 도입했습니다.
사용자 지정 EEST 주변 테스트/픽스처 : 주변 테스트 방법론을 따르는 사용자 지정 실행 사양 테스트 (EEST)를 추가합니다.
멀티 GPU SP1 지원 : EF의 ZKEVM 벤치마크 툴링을 확장하여 SP1 클러스터 실행을 지원함으로써 동일한 워크로드를 4개의 GPU를 사용하여 검증할 수 있게 되었습니다.
이러한 추가 기능을 통해 EEST 픽스처를 생성하고, EF 툴링을 사용하여 zkEVM 위트 입력으로 변환하고, EF 호스트 러너(4개의 GPU 또는 RISC0에서 SP1)를 통해 증명을 실행한 다음, 결과 메트릭(증명 시간, 가스, zk 사이클)을 후처리하여 회귀 분석을 수행하고 가스(또는 zk 사이클)당 한계 증명 시간을 추출합니다.
지원 방법 및 다음 단계
다음은 이러한 측정값의 잠재적인 실제 적용 사례입니다.
ZK 롤업을 위한 ZK 인식 블록 미터링 : 가스별 증명 시간 측정값을 사용하여 블록의 증명 비용을 직접 측정하고 제한할 수 있습니다. 구체적으로, 각 오퍼코드/프리컴파일러가 소비하는 가스에 측정된 가스당 증명 시간에서 파생된 승수를 곱하여 "ZK 가스" 메트릭을 정의할 수 있습니다. 블록 당 총 ZK 가스를 제한함으로써 프로토콜은 최악의 경우 증명 시간을 제한하고 증명자 킬러 블록의 발생을 완화할 수 있습니다.
zkVM 구현자를 위한 지침 : 연산별 분석을 통해 개선이 필요한 연산 코드/사전 컴파일을 파악할 수 있으므로 zkVM 팀이 최적화 우선순위를 정하는 데 도움이 됩니다(예: 특수 회로). 또한 ZK 사이클 계산 방식을 개선하여 다양한 회로 경로에서 검증 시간을 보다 균일하게 추적할 수 있도록 구체적인 방향을 제시합니다.
클라이언트 구현 담당자를 위한 지침 : 클라이언트 팀은 이러한 측정값을 사용하여 ZK 친화적이지 않은 핫스팟을 식별하고 특정 오퍼코드/사전 컴파일 구현 또는 실행 패턴을 최적화하여 검증 오버헤드를 줄일 수 있습니다.
프로젝트의 다음 단계는 다음과 같습니다.
인수 의존적 벤치마킹 : 모든 입력값을 포괄하도록 방법론을 확장합니다.
지속적인 성능 모니터링 : 파이프라인 전체(픽스처 생성 → 위트니스 생성 → 검증 → 회귀 테스트 → 보고)를 자동화하여 오퍼레이션 코드/프리컴파일별 zkVM/클라이언트 성능을 시간에 따라 추적할 수 있습니다.
다차원 계량 : 이러한 측정값을 다차원 가스 계량 에 어떻게 통합할 수 있는지 조사하십시오.
모래밭
벤치마크 결과에 대한 상세 데이터(예: 각 오퍼레이션 코드/사전 컴파일에 대한 회귀 분석 그래프):
벤치마크에 사용된 사용자 지정 실행 사양 테스트: https://github.com/linoscope/execution-specs/pull/1/changes
EF 툴링에서 SP1 클러스터 지원을 위한 PR:
이그나시오가 EF의 ZK 벤치마크 툴링에 대해 이야기하는 좋은 영상입니다: https://youtu.be/D2TpmD62tjQ?si=D4mzEagb2MXX1QXy&t=1510
Jacek의 한계 접근법에 대한 좋은 강연입니다: https://www.youtube.com/watch?v=KmaFpyV9jvM
부록: SP1/RISC0 비교
아래 그래프는 (RISC0 proving_time_per_gas) / (SP1 proving_time_per_gas) 의 관계를 보여줍니다. 여기서 proving_time_per_gas 각 검증기의 해당 오퍼코드에 대한 회귀 기울기입니다. 기준선인 1.0×는 두 검증기의 성능이 동일함을 의미합니다. 1.0×보다 큰 값은 RISC0이 더 느리다는 것(해당 오퍼코드/사전 컴파일에 대해 SP1보다 가스당 검증 시간이 더 오래 걸림)을 나타내고, 1.0×보다 작은 값은 SP1이 더 느리다는 것을 나타냅니다.
