Vitalik 장기 L1 실행 계층 제안 전문: EVM 대신 RISC-V 채택
출처: Vitalik Buterin
번역: KarenZ, Foresight News
4월 20일, Vitalik Buterin은 Ethereum Magicians 플랫폼에서 이더리움 장기 L1 실행 계층에 관한 중요한 제안을 발표했다. 그는 기존의 EVM(이더리움 가상 머신)을 대체하여 스마트 계약 작성을 위한 가상 머신 언어로 RISC-V 아키텍처를 채택할 것을 제안하며, 이를 통해 이더리움 실행 계층의 운영 효율성을 근본적으로 향상시키고 현재 주요한 확장성 병목 문제 중 하나를 해결하는 동시에 실행 계층의 간결성을 크게 개선하고자 한다.
Foresight News는 독자들이 이러한 기술적 구상을 이해할 수 있도록 해당 제안서 전문을 번역하였다. 아래는 원문 내용의 번역본이다.
본 문서는 이더리움 실행 계층의 미래에 대한 극단적인 아이디어를 제시한다. 그 야심 찬 정도는 컨센서스 계층의 Beam Chain 프로젝트에 버금간다. 이 제안은 이더리움 실행 계층의 효율성을 획기적으로 높이고 주요 확장성 병목 현상 중 하나를 해결하며 실행 계층을 상당히 단순화하는 것을 목표로 한다. 실제로 이러한 목표를 달성할 수 있는 유일한 방법일 수도 있다.
핵심 개념: 스마트 계약 작성용 가상 머신 언어로서 EVM을 RISC-V로 대체한다.
중요 안내:
-
계정 시스템, 계약 간 호출, 스토리지 등의 개념은 완전히 유지된다. 이러한 추상화 설계는 잘 작동하며 개발자들도 이미 익숙하다. SLOAD, SSTORE, BALANCE, CALL 등의 오퍼코드는 RISC-V 시스템 콜로 전환될 것이다.
-
이 모델 하에서는 스마트 계약을 Rust로 작성할 수 있지만, 대부분의 개발자는 여전히 Solidity 또는 Vyper를 사용해 계약을 작성할 것으로 예상되며, 이러한 언어들은 새로운 백엔드로 RISC-V를 지원하도록 조정될 것이다. 왜냐하면 Rust로 작성된 스마트 계약은 사실상 가독성이 떨어지고, Solidity와 Vyper가 더 명확하고 이해하기 쉬우므로 개발 경험은 거의 영향을 받지 않을 것이며, 개발자가 변화를 인지하지 못할 수도 있기 때문이다.
-
기존 EVM 계약은 계속해서 실행되며 새롭게 도입된 RISC-V 계약과 완전히 양방향 호환된다. 구현 방식에는 여러 가지가 있으며, 이후 본문에서 자세히 다룰 것이다.
Nervos CKB VM은 선구적인 사례로, 본질적으로 RISC-V 구현체이다.
왜 이렇게 해야 하는가?
단기적으로 보면, 곧 시행될 EIP들(예: 블록 수준 접근 리스트, 지연 실행, 분산형 역사 저장 및 EIP-4444)을 통해 이더리움 L1의 주요 확장성 병목 문제를 해결할 수 있다. 중기적으로는 상태 없는(stateless) 아키텍처와 ZK-EVM으로 더 많은 문제를 해결하게 될 것이다. 장기적으로 보면, 이더리움 L1 확장성의 주요 제한 요소는 다음과 같이 세 가지가 된다:
-
데이터 가용성 샘플링 및 역사 저장 프로토콜의 안정성
-
블록 생산 경쟁 시장 유지 필요성
-
ZK-EVM의 증명 능력
나는 ZK-EVM을 RISC-V로 대체함으로써 (2)와 (3)의 핵심 병목 현상을 해결할 수 있다고 주장할 것이다.
아래 표는 Succinct ZK-EVM이 EVM 실행 계층 각 단계를 증명하는 데 필요한 사이클 수를 보여준다:
차트 설명: 네 가지 주요 시간 소모 단계는 deserialize_inputs, initialize_witness_db, state_root_computation, block_execution이다.
여기서 initialize_witness_db와 state_root_computation은 상태 트리와 관련되며, deserialize_inputs는 블록과 위트니스 데이터를 내부 표현으로 변환하는 과정을 의미한다. 실제로 위트니스 데이터 크기에 비례하는 작업이 50% 이상을 차지한다.
현재의 keccak 기반 16진 Merkle Patricia 트리를 증명이 용이한 해시 함수를 사용하는 이진 트리(binary tree)로 교체하면 이러한 부분들을 크게 최적화할 수 있다. Poseidon을 사용한다면 노트북에서도 초당 200만 회 해시 증명이 가능하다(keccak은 약 15,000 hash/sec). Poseidon 외에도 다양한 선택지가 있다. 전반적으로 이러한 구성 요소들은 큰 최적화 여지를 지닌다. 또한 블룸 필터 제거를 통해 accrue_logs_bloom도 제거할 수 있다.
남은 block_execution은 현재 증명 사이클(prover cycles)의 약 절반을 차지한다. 전체 증명 효율을 100배 향상시키려면 EVM 증명 효율은 최소한 50배 이상 향상되어야 한다. 해결책 중 하나는 EVM을 위한 더 효율적인 증명 구현을 만드는 것이고, 다른 하나는 현재 ZK-EVM 증명기가 실제로 EVM을 RISC-V로 컴파일하여 증명한다는 점에 주목해, 스마트 계약 개발자에게 바로 그 RISC-V 가상 머신을 직접 제공하는 것이다.
특정 조건에서 효율성 향상이 100배를 초과할 수 있다는 일부 데이터도 존재한다:
실제 적용에서는 남은 증명 시간(prover time) 대부분이 현재의 사전 정의 연산(precompiles)에 의해 차지될 가능성이 높다. RISC-V를 주요 가상 머신으로 삼으면, 가스 스케줄(gas schedule)은 실제 증명 시간을 반영하게 되고, 경제적 압박이 개발자들로 하여금 고비용의 사전 정의 연산 사용을 줄이도록 유도할 것이다. 그래도 이득이 지금처럼 눈에 띄지는 않겠지만, 충분히 상당한 이득을 기대할 수 있다는 이유가 있다.
(참고로, 일반적인 EVM 실행에서도 「EVM 오퍼레이션」과 「기타 오퍼레이션」의 처리 시간 비율도 약 50:50에 가깝기 때문에, EVM을 「중간 계층」으로서 제거하면 동등하게 큰 성능 향상을 얻을 수 있을 것이라고 직관적으로 생각할 수 있다.)
구현 세부사항
이 제안은 여러 가지 방식으로 구현할 수 있다. 가장 파괴력이 적은 방법은 두 가지 가상 머신을 모두 지원하여 계약이 임의로 선택해 작성할 수 있도록 하는 것이다. 두 유형의 계약 모두 동일한 기능에 접근할 수 있다: 영속 저장소(SLOAD/SSTORE), ETH 잔액 보유 능력, 호출 발신/수신 등. EVM과 RISC-V 계약은 서로 호출할 수 있다—RISC-V 입장에서는 EVM 계약을 호출하는 것이 특수 매개변수를 포함한 시스템 콜을 실행하는 것과 같다. 반대로 메시지를 수신하는 EVM 계약은 이를 CALL로 해석한다.
프로토콜 관점에서 더 급진적인 방법은 기존 EVM 계약을 RISC-V로 작성된 EVM 인터프리터 계약을 호출하는 방식으로 변환하는 것이다. 즉, 어떤 EVM 계약이 코드 C를 가지고 있고, EVM 인터프리터가 주소 X에 위치한다면, 이 계약은 외부에서 호출 매개변수 D와 함께 호출될 때, (C, D)를 매개변수로 하여 X를 호출하고 반환값을 기다린 후 이를 전달하는 최상위 로직으로 교체된다. 만약 EVM 인터프리터 자체가 이 계약을 호출하여 CALL 또는 SLOAD/SSTORE를 수행하라고 요구하면, 해당 계약은 실제로 그 작업을 수행한다.
折中方案은 두 번째 방안을 취하면서도 프로토콜 차원에서 「가상 머신 인터프리터」 개념을 명시적으로 지원하고, 그 로직은 RISC-V로 작성해야 한다고 규정하는 것이다. EVM이 첫 번째 인스턴스가 되며, 향후 다른 언어(Move가 후보가 될 수 있음)도 지원할 수 있다.
두 번째 및 세 번째 방안의 핵심 장점은 실행 계층 사양(specification)을 매우 크게 단순화할 수 있다는 점이다. SELFDESTRUCT 제거와 같은 점진적 단순화조차도 극도로 어렵다는 점을 감안하면, 이러한 접근법이 유일하게 실현 가능한 단순화 경로일 수 있다. Tinygrad는 코드 1만 줄 이하라는 엄격한 규칙을 따르는데, 최적의 블록체인 기반 시스템 역시 이러한 제한을 쉽게 충족하고 더 나아가 더욱 간소화되어야 한다. Beam Chain 프로젝트는 이더리움 컨센서스 계층을 크게 단순화할 전망이며, 실행 계층도 유사한 수준의 개선을 이루고자 한다면 이러한 급진적 변화가 유일한 현실적인 길일 수 있다.
TechFlow 공식 커뮤니티에 오신 것을 환영합니다
Telegram 구독 그룹:https://t.me/TechFlowDaily
트위터 공식 계정:https://x.com/TechFlowPost
트위터 영어 계정:https://x.com/BlockFlow_News
@VitalikButerin
