Vitalik 장기 L1 실행 레이어 제안 전문: RISC-V로 EVM 대체

원제목: 《Long-term L1 execution layer proposal: replace the EVM with RISC-V》

저자: Vitalik Buterin

편집: KarenZ, Foresight News

4월 20일, Vitalik Buterin은 Ethereum Magicians 플랫폼에서 이더리움 장기 L1 실행 레이어에 관한 중요한 제안을 발표했다. 그는 기존의 EVM(이더리움 가상 머신)을 대체할 가상 계약 언어로 RISC-V 아키텍처를 채택할 것을 제안하며, 이는 이더리움 실행 레이어의 운영 효율성을 근본적으로 향상시키고 현재의 주요 확장 병목 중 하나를 극복하며 실행 레이어의 간결성을 대폭 단순화하는 것을 목표로 한다.

Foresight News는 이 제안의 전체 내용을 편집하여 독자들이 이 기술적 구상을 이해하는 데 도움을 주고자 한다. 다음은 제안 원문의 편집 내용이다:

이 문서는 이더리움 실행 레이어의 미래에 대한 급진적인 아이디어를 제안하며, 그 야망은 합의 레이어의 Beam Chain 계획에 못지않다. 이 제안은 이더리움 실행 레이어의 효율성을 대폭 향상시키고 주요 확장 병목 중 하나를 해결하며 실행 레이어를 상당히 단순화하는 것을 목표로 한다. 사실, 이는 이 목표를 달성하기 위한 유일한 방법일 수 있다.

핵심 구상: RISC-V로 EVM을 대체하여 스마트 계약 작성을 위한 가상 머신 언어로 사용한다.

중요한 설명:

• 계좌 시스템, 계약 간 호출, 저장소 등의 개념은 완전히 유지된다. 이러한 추상적 설계는 잘 작동하며 개발자들이 이미 익숙하게 사용하고 있다. 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의 주요 확장 병목을 해결할 수 있다. 중기적으로는 무상태성과 ZK-EVM을 통해 더 많은 문제를 해결할 것이다. 장기적으로 이더리움 L1 확장의 주요 제한 요소는 다음과 같이 변할 것이다:

1. 데이터 가용성 샘플링 및 역사 저장 프로토콜의 안정성
2. 블록 생산 시장 경쟁성을 유지해야 하는 요구
3. ZK-EVM의 증명 능력

나는 ZK-EVM을 RISC-V로 대체하는 것이 (2)와 (3)에서의 주요 병목을 해결할 수 있음을 주장할 것이다.

아래 표는 Succinct ZK-EVM이 EVM 실행 레이어의 각 단계에서 필요한 주기 수를 보여준다:

차트 설명: 네 가지 주요 소요 시간 단계는 deserializeinputs, initializewitnessdb, staterootcomputation 및 blockexecution이다.

여기서 initializewitnessdb와 staterootcomputation은 상태 트리와 관련이 있으며, deserialize_inputs는 블록과 증인 데이터를 내부 표현으로 변환하는 과정과 관련이 있다. 실제로 50% 이상이 증인 데이터 크기와 비례한다.

현재의 keccak 16-ary Merkle patricia tree를 증명하기 쉬운 해시 함수를 사용하는 binary tree로 대체함으로써 이러한 부분을 대폭 최적화할 수 있다. Poseidon을 사용하면 우리는 노트북에서 초당 200만 해시를 증명할 수 있다(반면 keccak은 약 15,000 hash/sec이다). Poseidon 외에도 많은 다른 선택지가 있다. 전반적으로 이러한 구성 요소는 큰 최적화 여지가 있다. 또한, bloom 제거를 통해 accruelogsbloom을 제거할 수 있다.

남은 block_execution은 현재 증명 주기(prover cycles)의 약 절반을 차지한다. 100배의 전체 증명 효율성을 달성하려면 EVM 증명 효율성이 최소 50배 향상되어야 한다. 해결책 중 하나는 EVM을 위한 더 효율적인 증명 구현을 만드는 것이고, 다른 하나는 현재 ZK-EVM 증명기가 실제로 EVM을 RISC-V로 컴파일하여 증명하고 있다는 점을 인식하여 스마트 계약 개발자가 해당 RISC-V 가상 머신에 직접 접근할 수 있도록 하는 것이다.

일부 데이터는 특정 상황에서 효율성이 100배를 초과할 수 있음을 보여준다:

실제 응용에서 남은 prover 시간은 현재의 사전 컴파일(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 코드를 실행하는 것이다. 즉, 만약 EVM 계약이 코드 C를 가지고 있고, EVM 해석기가 주소 X에 있다면, 해당 계약은 최상위 논리로 대체되어 외부에서 호출 매개변수 D로 호출될 때 X를 호출하고 (C, D)를 전달한 후 반환 값을 기다리고 전달한다. 만약 EVM 해석기가 해당 계약을 호출하여 CALL 또는 SLOAD/SSTORE을 실행하도록 요구하면, 계약은 이러한 작업을 수행한다.

절충안은 두 번째 방법을 채택하되, 프로토콜에서 "가상 머신 해석기" 개념을 명확히 지원하여 그 논리를 RISC-V로 작성하도록 요구하는 것이다. EVM은 첫 번째 사례가 될 것이며, 미래에는 다른 언어(예: Move)가 후보가 될 수 있다.

두 번째 및 세 번째 방법의 핵심 장점은 실행 레이어 규정을 크게 단순화할 수 있다는 것이다. SELFDESTRUCT와 같은 점진적 단순화를 제거하는 것조차 어려운 점을 고려할 때, 이러한 사고방식은 유일한 실행 가능한 단순화 경로일 수 있다. Tinygrad는 "코드가 1만 줄을 초과하지 않는다"는 엄격한 규정을 따르며, 최적의 블록체인 기반은 이 제한을 쉽게 충족하고 더욱 간소화할 수 있어야 한다. Beam Chain 계획은 이더리움 합의 레이어를 대폭 단순화할 것으로 기대되며, 실행 레이어가 유사한 향상을 이루려면 이러한 급진적 변화가 유일한 실행 가능한 길일 수 있다.