출처: 비탈릭 부테린

4월 20일, 비탈릭 부테린은 Ethereum Magicians 플랫폼에서 Ethereum의 장기 L1 실행 계층에 대한 중요한 제안을 내놓았습니다. 그는 스마트 계약을 작성하기 위한 가상 머신 언어로 기존 EVM(이더리움 가상 머신)을 대체하기 위해 RISC-V 아키텍처를 사용할 것을 제안했습니다. 이를 통해 이더리움 실행 계층의 운영 효율성을 근본적으로 개선하고, 현재 주요 확장 병목 현상 중 하나를 돌파하며, 실행 계층의 단순성을 크게 단순화하는 것이 목표입니다.

Foresight News는 독자들이 이 기술적 비전을 이해하는 데 도움이 되도록 제안서의 전문을 편집했습니다. 다음은 원래 제안의 편집본입니다.

이 글은 합의 계층을 위한 빔 체인 계획 못지않게, 이더리움 실행 계층의 미래에 대한 급진적인 아이디어를 제안합니다. 이 제안은 이더리움 실행 계층의 효율성을 크게 개선하여 주요 확장 병목 현상 중 하나를 해결하고 실행 계층을 크게 단순화하는 것을 목표로 합니다. 사실, 이 목표를 달성할 수 있는 유일한 방법일 수도 있습니다.

핵심 개념: 스마트 계약을 작성하기 위한 가상 머신 언어로 EVM을 대체하기 위해 RISC-V를 사용합니다.

중요 참고 사항:

Nervos CKB VM은 선례를 만들었고 본질적으로 RISC-V 구현 입니다.

왜 이렇게 하나요?

단기적으로, 다가올 EIP( 블록 수준 액세스 목록 , 지연 실행 , 분산 기록 저장, EIP-4444 등)는 이더리움 L1의 주요 확장 병목 현상을 해결할 수 있습니다. 중기적으로는 무국적화와 ZK-EVM을 통해 더 많은 문제가 해결될 것입니다. 장기적으로 이더리움 L1 확장의 주요 제한 요소는 다음과 같습니다.

저는 ZK-EVM을 RISC-V로 교체하면 (2) 및 (3)의 주요 병목 현상을 해결할 수 있다고 주장합니다.

다음 표는 Succinct ZK-EVM을 사용하여 EVM 실행 계층의 각 단계를 증명하는 데 필요한 사이클 수를 보여줍니다.

차트 설명: 시간이 많이 소요되는 4가지 주요 단계는 deserialize_inputs, initialise_witness_db, state_root_computation 및 block_execution입니다.

initialize_witness_db와 state_root_computation이 상태 트리와 관련된 반면, deserialize_inputs는 블록과 위트니스 데이터를 내부 표현으로 변환하는 프로세스를 포함합니다. 실제로 50% 이상이 위트니스 데이터의 크기에 비례합니다.

이러한 부분은 현재의 케작 16차원 머클 패트리샤 트리를 쉽게 증명할 수 있는 해시 함수를 사용하는 이진 트리로 대체함으로써 상당히 최적화될 수 있습니다. 포세이돈을 사용하면 노트북에서 초당 200만 개의 해시를 증명할 수 있습니다(케칵의 경우 초당 약 15,000개의 해시). 포세이돈 외에도 다른 많은 옵션이 있습니다. 일반적으로 이러한 구성요소를 최적화할 수 있는 여지가 많습니다. 또한, bloom을 제거 하면 accrue_logs_bloom을 제거할 수 있습니다.

나머지 block_executions은 현재 증명자 주기의 약 절반을 차지합니다. 전반적인 증명 효율성을 100배 향상시키려면 EVM 증명 효율성을 최소 50배 증가시켜야 합니다. 한 가지 해결책은 EVM에 대한 보다 효율적인 증명 구현을 만드는 것이고, 또 다른 해결책은 현재의 ZK-EVM 증명자가 실제로 EVM을 RISC-V로 컴파일하여 증명한다는 점을 지적하는 것입니다. 이를 통해 스마트 계약 개발자는 RISC-V 가상 머신에 직접 액세스할 수 있습니다.

일부 데이터에 따르면 특정 경우 효율성 개선이 100배를 초과할 수 있다고 합니다.

실제 응용 프로그램에서 남은 증명자 시간은 주로 현재 사전 컴파일 작업에 의해 차지될 수 있습니다. RISC-V를 주 가상 머신으로 사용하면 가스 일정은 실제 증명 시간을 반영하게 되고, 경제적 압박으로 인해 개발자는 비용이 많이 드는 사전 컴파일 사용을 줄이게 됩니다. 그렇더라도 그 이득은 그렇게 극적이지는 않겠지만 상당할 것이라고 믿을 만한 이유가 충분히 있습니다.

( 일반 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는 " 코드는 10,000줄을 넘지 않는다 "는 엄격한 규칙을 따르며, 최적의 블록체인 기반 계층은 이 제한을 쉽게 충족하고 이를 더욱 간소화할 수 있어야 합니다. 빔 체인 프로젝트는 이더리움의 합의 계층을 크게 단순화할 것을 약속하며, 이러한 근본적인 변화는 실행 계층에서도 비슷한 개선을 이룰 수 있는 유일한 실행 가능한 경로일 수 있습니다.