비탈릭의 새로운 제안: EVM 스마트 컨트랙트를 위한 가상 머신 언어로서의 RISC-V

출처: 비탈릭 부테린, 이더리움 마술사; 타오 주 편집, 골든 파이낸스

이 기사는 합의 레이어를 위한 빔 체인의 노력만큼이나 야심찬 이더리움 실행 계층의 미래에 대한 급진적인 아이디어를 제시하고 있습니다. 합의 레이어에 대한 빔 체인의 노력만큼이나 야심찬 아이디어입니다. 이는 이더 실행 레이어의 효율성을 획기적으로 개선하고, 주요 확장 병목 현상 중 하나를 해결하며, 실행 레이어의 단순성을 획기적으로 개선하는 것을 목표로 하며, 실제로 이 방법만이 유일한 방법일 수도 있습니다.

아이디어: EVM 스마트 컨트랙트 작성을 위한 가상 머신 언어로 RISC-V를 사용하세요.

중요한 설명:

• 계정, 교차 컨트랙트 호출, 스토리지 등의 개념은 그대로 유지됩니다. 이러한 추상화는 잘 작동하며 개발자는 이에 익숙합니다. SLOAD, SSTORE, BALANCE, CALL 등과 같은 옵코드는 RISC-V 시스템 호출이 될 것입니다.

• 이런 세상에서 스마트 컨트랙트를 Rust로 작성할 수도 있지만, 대부분의 개발자는 계속해서 솔리디티(또는 바이퍼)에서 스마트 컨트랙트를 작성할 것이며, 백엔드로서 RISC-V가 추가될 것으로 예상합니다. Rust로 작성된 스마트 컨트랙트는 실제로 상당히 추악한 반면, 솔리디티와 바이퍼는 훨씬 더 가독성이 높기 때문입니다. 아마도 개발자들이 변화를 거의 알아차리지 못할 정도로 데벡스의 변화가 작을 수도 있습니다.

• 구형 EVM 계약은 계속 작동하며 최신 RISC-V 계약과 완전히 양방향으로 상호 운용될 것입니다. 이를 위한 몇 가지 방법이 있으며, 이 글의 뒷부분에서 설명하겠습니다.

한 가지 선례는 기본적으로 RISC-V인 Nervos CKB VM입니다.

왜 이렇게 할까요?

단기적으로는 블록 레벨 액세스 목록, 지연 실행 및 분산 기록 저장, EIP-4444와 같은 향후 EIP를 통해 이더넷 L1 확장성의 주요 병목 현상이 해결될 것입니다. 중기적으로는 무국적과 ZK-EVM의 추가 문제가 해결될 것입니다. 장기적으로 이더리움 레이어1 확장에 대한 주요 제약 조건은 다음과 같습니다.

• 데이터 가용성 샘플링 및 기록 저장 프로토콜의 안정성

• 블록 생산 시장의 경쟁력을 유지하고자 하는 욕구

• ZK-EVM 검증 기능

ZK-EVM을 RISC-V로 대체하면 (2)와 (3)의 주요 병목 현상 중 하나를 해결할 수 있다고 생각합니다.

다음은 간결한 ZK-EVM이 EVM 실행 계층의 여러 부분을 정당화하기 위해 사용하는 루프 수 표입니다.

상당한 시간이 걸리는 네 가지 부분이 있습니다: serialise_inputs, initialize_witness_db, state_root_. 계산, 블록 실행입니다.

initialize_witness_db와 state_root_computation은 모두 상태 트리와 관련이 있으며, deserialize_input은 블록 및 감시 데이터를 내부 표현으로 변환하는 프로세스를 의미합니다. 실제로 50% 이상은 감시 크기에 비례합니다.

현재의 keccak $16 머클 패트리샤 트리를 증명자에게 친숙한 해시 함수를 사용하는 분기 트리로 대체하면 이러한 부분에서 많은 최적화를 수행할 수 있습니다. 포세이돈을 사용하면 노트북에서 초당 2백만 개의 해시를 증명할 수 있습니다(keccak의 초당 15,000개 해시 증명과 비교하면). 포세이돈을 대체할 수 있는 많은 대안이 있습니다. 대체로 이러한 구성 요소를 크게 줄일 수 있는 기회가 있습니다. 보너스로, 우리는 bloom을 제거함으로써 accrue_logs_bloom을 없앨 수 있습니다.

오늘날 사용되는 증명 주기의 약 절반을 차지하는 block_execution만 남았습니다. 전체 증명기의 효율성을 100배 높이려면 EVM 증명기의 효율성을 최소 50배 이상 높여야 한다는 사실을 피할 수 없습니다. 우리가 할 수 있는 한 가지 방법은 증명 주기 측면에서 더 효율적인 EVM 구현을 만드는 것입니다. 우리가 할 수 있는 또 다른 방법은 오늘날 이미 ZK-EVM 증명자가 RISC-V로 컴파일하고 스마트 컨트랙트 개발자가 해당 RISC-V VM에 직접 액세스할 수 있는 EVM 구현을 증명함으로써 작동한다는 점에 주목하는 것입니다.

일부 데이터에 따르면 제한된 경우에 효율성을 100배 이상 높일 수 있다고 합니다.

사실, 남은 증명 시간은 다음과 같을 것으로 예상됩니다. 오늘의 사전 컴파일이 대부분을 차지할 것으로 예상합니다. RISC-V를 기본 VM으로 사용하면 가스 프로그램에 증명 시간이 반영되기 때문에 더 비싼 사전 컴파일을 사용하지 않으려는 경제적 압박이 있겠지만, 그렇다고 해도 이득이 그렇게 크지는 않겠지만, 이득이 상당할 것이라고 믿을 만한 충분한 이유가 있습니다.

(참고로, 'EVM'과 '다른 것' 사이의 대략 50 대 50 분할은 일반적인 EVM 구현에서도 발생하며, '중간자'로서 EVM을 제거함으로써 얻을 수 있는 이득이 상당할 것으로 직관적으로 예상합니다. "중간자"로서의 EVM을 제거함으로써 얻을 수 있는 이득도 똑같이 클 것으로 직관적으로 예상합니다)

구현 세부 사항

이런 유형의 제안을 구현할 수 있는 방법에는 여러 가지가 있습니다. 가장 방해가 적은 접근 방식은 두 개의 가상 머신을 지원하고 어느 한 쪽에서 계약서를 작성할 수 있도록 하는 것입니다. 두 유형의 콘트랙트 모두 동일한 유형의 시설에 접근할 수 있습니다: 영구 저장소(SLOAD 및 SSTORE), 이더리움 잔액 보유 기능, 전화 걸기 및 받기 기능 등. EVM과 RISC-V 콘트랙트는 서로 자유롭게 호출할 수 있으며, RISC-V 관점에서 볼 때 EVM 콘트랙트를 호출하면 몇 가지 특수 매개 변수가 있는 시스템 호출로 보이며, 메시지를 수신하는 EVM 콘트랙트는 이를 특수 매개 변수가 있는 시스템 호출로 해석할 것입니다. 프로토콜 관점에서 보다 근본적인 접근 방식은 기존 EVM 컨트랙트를 기존 EVM 코드를 실행하는 RISC-V로 작성된 EVM 인터프리터 컨트랙트를 호출하는 컨트랙트로 변환하는 것입니다. 즉, EVM 컨트랙트에 코드 C가 있고 EVM 인터프리터가 주소 X에 있는 경우, 외부에서 호출 매개변수 D로 호출할 때 (C, D)로 X를 호출한 다음 반환 값을 기다렸다가 전달하는 최상위 수준 로직으로 컨트랙트가 대체됩니다. EVM 인터프리터 자체에서 컨트랙트를 호출하고 CALL 또는 SLOAD/SSTORE를 실행하도록 요청하면 컨트랙트가 이를 실행합니다.

두 번째 옵션을 취하되 이를 위한 명시적 프로토콜 함수를 만드는 것, 즉 기본적으로 "가상 머신 인터프리터"라는 개념을 도입하고 그 로직이 RISC-V로 작성되도록 하는 것이 중간 지점입니다. EVM이 첫 번째가 되겠지만 다른 것도 있을 수 있습니다(예: Move가 후보가 될 수 있음).

두 번째와 세 번째 제안의 주요 이점 중 하나는 실행 계층 사양을 크게 단순화한다는 점입니다. 사실 이 아이디어가 유일하게 실행 가능한 접근 방식일 수 있는데, SELFDESTRUCT 제거와 같은 점진적 단순화조차 매우 어렵기 때문입니다. 타이니그래드는 코드의 양이 10,000줄을 넘지 않아야 한다는 엄격한 규칙을 가지고 있으며, 최고의 블록체인 기본 레이어는 이보다 작지는 않더라도 이 경계 내에 잘 맞아야 합니다. 빔체인의 노력은 이더의 합의 레이어를 크게 간소화할 수 있다는 점에서 큰 가능성을 지니고 있습니다. 그러나 실행 레이어의 경우, 이러한 급진적인 변화가 비슷한 이득을 얻을 수 있는 유일한 방법일 수 있습니다.