출처: 비탈릭 부테린, 이더리움 매지션; 번역: 도주, 진써차이징(Jinse)
이 글은 이더리움 실행 계층의 미래에 대해 빔 체인의 컨센서스 레이어 노력만큼 대담한 아이디어를 제시합니다. 이는 이더리움 실행 계층의 효율성을 크게 향상시키고, 주요 확장 병목 현상 중 하나를 해결하며, 실행 계층의 단순성을 크게 높이는 것을 목표로 합니다. 사실, 이것이 유일한 방법일 수 있습니다.
아이디어: RISC-V를 이더리움 가상 머신(EVM) 스마트 계약 작성을 위한 가상 머신 언어로 사용합니다.
중요한 명확화:
계정, 크로스 계약 호출, 저장소 등의 개념은 완전히 동일하게 유지됩니다. 이러한 추상화는 잘 작동하며 개발자들도 익숙합니다. SLOAD, SSTORE, BALANCE, CALL 등의 연산 코드는 RISC-V 시스템 호출이 됩니다.
이러한 세계에서 스마트 계약은 러스트로 작성될 수 있지만, 대부분의 개발자는 여전히 솔리디티(또는 바이퍼)로 스마트 계약을 작성할 것으로 예상됩니다. 이는 RISC-V를 백엔드로 추가하는 데 적합할 것입니다. 이는 러스트로 작성된 스마트 계약이 실제로 상당히 보기 흉하고, 솔리디티와 바이퍼의 가독성이 훨씬 더 높기 때문입니다. 개발자 경험의 변화는 아주 작을 것이며, 개발자들은 이러한 변화를 거의 알아차리지 못할 것입니다.
기존 이더리움 가상 머신(EVM) 계약은 계속 유효하며 새로운 RISC-V 계약과 완전히 양방향 상호 운용될 것입니다. 이를 달성하는 여러 방법이 있으며, 이에 대해 이후에 설명하겠습니다.
선례로는 기본적으로 RISC-V인 너보스(CKB) VM이 있습니다.
왜 이렇게 하는가?
단기적으로 이더리움 L1 확장성의 주요 병목 현상은 곧 출시될 이더리움 개선 제안(EIP)을 통해 해결될 것입니다. 중기적으로는 무상태 및 ZK-EVM의 추가 문제를 해결할 것입니다. 장기적으로 이더리움 레이어1 확장의 주요 제한 요인은 다음과 같습니다:
데이터 가용성 샘플링 및 역사 저장 프로토콜의 안정성
블록 생산 시장의 경쟁력 유지 희망
ZK-EVM 검증 능력
저는 ZK-EVM을 RISC-V로 대체하면 (2)와 (3)의 핵심 병목 현상을 해결할 수 있다고 생각합니다.
[이하 생략]
