이더리움의 Lean Execution: EVM에서 RISC-V로의 전환

[이더리움의 Lean Execution: EVM에서 RISC-V로의 전환] 최근 이더리움 L1의 ZK 개발에 대한 것들을 논의하는 ethproof 콜에서, 이더리움의 RISC-V 도입에 대한 논의가 길게 이어졌습니다. 이는 비탈릭 부테린의 Simplifying L1 글, 저스틴 드레이크의 Lean Ethereum 등으로 이 방에서도 여러번 다루었던 주제입니다. 이 제안의 요점과, 장단점을 설명하면 다음과 같습니다. 이더리움의 스마트 컨트랙트 실행 및 상태 관리를 맡았던 EVM은 10년 넘게 이더리움의 핵심이었지만, 단순한 컨트랙트 실행만을 위해 설계되었다는 단점이 존재합니다. 이는 특히 현재 ZK에 포커스를 맞춘 이더리움에 큰 문제로 다가올 수 있습니다. 현재 대부분의 zkVM들은 RISC-V를 기반으로 하는 범용적인 구조를 갖추고 있습니다. 때문에 EVM에 대한 증명을 생성할 때, zkVM 기반 프루버들은 EVM을 직접 증명하는 것이 아니라, "EVM을 RISC-V로 컴파일하는 인터프리터 프로그램”의 실행을 증명합니다. zkVM이 이해할 수 있는 언어로 EVM의 로직을 바꿔주는 중간 과정이 추가되는 것이죠. 이는 증명 비용과 시간에 약 50 800배의 오버헤드를 추가합니다. EVM을 RISC-V로 전환하면 이러한 오버헤드를 줄여 ZK 증명의 효율을 뽑을 수 있습니다. 이더리움 L1이 요구하는 ‘실시간 블록 증명’을 달성하려면 현재는 수백 개의 GPU가 필요한데, 이러한 비용을 이론적으로는 몇십 혹은 몇백 배까지 줄일 수 있는 것이죠. 더 나아가, RISC-V는 블록체인 특화 ISA가 아닌 범용 CPU 아키텍처이기 때문에 기존 소프트웨어 생태계와의 연계성이 매우 높습니다. 특히 LLVM과 같은 컴파일러 인프라를 활용하면, Go, Rust, C/C++ 등 범용 언어로 스마트컨트랙트를 직접 컴파일할 수 있는 길이 열립니다. 이는 단순한 성능 향상을 넘어, 블록체인 개발을 주류 프로그래밍 언어 생태계와 한 단계 더 밀접하게 연결할 수 있도록 합니다. 무엇보다도, RISC-V는 47개로 구성된 매우 단순한 명령어 집합이기 때문에, VM 전반이 더 단순해진다는 장점도 존재합니다. 비탈릭이 RISC-V로의 전환을 제안한 메인 이유이기도 하죠. 그러나 RISC-V로의 전환이 장점만 존재하는 건 아니며, 여러 가지 해결해야 하는 문제들이 있습니다. 우선, 호환성 이슈로 인해 RISC-V로의 급진적인 전환은 불가능하며, 기존 EVM 컨트랙트들이 RISC-V 전환 이후로도 동작함을 보장해야 합니다. 이를 위해, 비탈릭은 ‘기존 EVM 컨트랙트를 RISC-V로 컴파일하는 인터프리터’를 노드 안에 내장해 호환성을 보장하자고 이야기합니다. 이를 통해 RISC-V 전환 이전에 작성된 컨트랙트도 문제 없이 사용될 수 있을 것입니다. 그러나 이러한 호환성 보장 구조는 역으로 zkVM의 증명 효율을 떨어뜨립니다. 즉 RISC-V 이전에 작성된 컨트랙트와 상호작용하는 트랜잭션에 대해 ZK 증명을 생성하는 오버헤드는, RISC-V 전환 전후가 크게 다를 바 없다는 이야기죠. 이 때문에, 기존의 애플리케이션들이 바뀐 RISC-V 기반 구조로 전부 컨트랙트를 갈아없지 않는 이상 zkVM의 증명 효율이 몇백 배 증가하는 일은 일어나기 힘들 것입니다. 앞서 언급한 “Rust, Go, C++ 같은 범용 언어로 스마트 컨트랙트를 작성할 수 있다”는 전망은 가능성은 있지만 실제로는 생각보다 까다로울 수 있습니다. RISC-V는 단순한 명령어 집합일 뿐, 이더리움 체인의 계정, 스토리지, 가스 모델과 같은 상태 관리 추상화를 직접 제공하지 않습니다. 따라서 범용 언어를 사용하려면, 결국 EVM 런타임 레이어의 기능(상태 전이 규칙, 리소스 가격 결정 등)을 라이브러리 / crate / SDK 형태로 재구현해야 합니다. 이는 지난 10여 년간 이더리움이 축적해온 컨트랙트 전용 툴링(개발 도구 및 보안 추상화)을 상당 부분 다시 설계해야 함을 의미합니다. Solidity와 Vyper 같은 기존 언어 또한 RISC-V 기반 실행 환경과 호환되려면 컴파일러 백엔드 수정이나 추가 구현이 필요합니다. 다만 이러한 작업이 성공적으로 이뤄진다면, 오히려 개발자가 더 다양한 언어를 활용하면서도 개선된 성능과 새로운 툴링 경험을 누릴 수 있는 기회가 될 수 있습니다. 짧은 미래 안에 이뤄질 일은 절대 아니지만, 장기적으로 보았을 때 이더리움의 단순성을 올리고 보안 및 탈중앙화, 개발자 경험에 큰 도움이 될 수 있을 것으로 보이네요.