이 기사는 Ethereum 공동 창립자 Vitalik의 글에서 나왔습니다.
Odaily Planet Daily( @OdailyChina )에서 편집
Azuma( @azuma_eth )님이 번역했습니다.
이 글에서는 합의 계층을 위한 빔 체인 계획만큼이나 야심찬, 이더리움 실행 계층의 미래에 대한 급진적인 아이디어를 제시하겠습니다. 이 이니셔티브의 목표는 이더리움 실행 계층의 효율성을 크게 개선하여 주요 확장 병목 현상 중 하나를 해결하는 동시에 실행 계층의 복잡성을 크게 단순화하는 것입니다. 실제로 이것이 단순화를 달성하는 유일한 방법일 수 있습니다.
이 글의 핵심 아이디어는 스마트 계약을 위한 가상 머신 언어로 EVM을 RISC-V로 대체하는 것입니다.
중요 참고 사항:
계정, 교차 계약 호출, 저장과 같은 개념은 완전히 유지됩니다. 이런 추상화는 잘 작동하며 개발자들은 이를 사용하는 데 익숙합니다. SLOAD, SSTORE, BALANCE, CALL 등의 명령어는 RISC-V 시스템 호출이 됩니다.
개발자는 여전히 Solidity나 Vyper를 선택할 수 있습니다. 스마트 계약은 이론적으로 Rust로 작성할 수 있지만, 대부분 개발자는 백엔드 컴파일 대상으로 RISC-V에 맞춰 조정될 Solidity(또는 Vyper)를 계속 사용할 것으로 예상됩니다 . Rust로 작성된 스마트 계약은 가독성이 떨어지는 반면, Solidity와 Vyper는 이해하기 쉽기 때문입니다. 개발 경험은 거의 변하지 않을 것이고, 개발자들은 전혀 차이를 느끼지 못할 수도 있습니다.
새로운 계약과 기존 계약은 양방향으로 상호 운용 가능합니다. 기존 EVM 계약은 계속 실행되며 새로운 RISC-V 계약과 완벽하게 상호 운용됩니다. 구체적인 구현 방법은 나중에 자세히 설명하겠습니다.
이미 선례가 있습니다. Nervos CKB VM은 본질적으로 RISC-V 기반 구현입니다.
왜 이런 변화가 필요한가요?
단기적으로 이더리움 레이어 1 확장의 주요 병목 현상은 다가올 EIP(블록 수준 접근 목록, 지연 실행, 분산 기록 저장, EIP-4444 등)를 통해 해결될 것입니다. 중기적으로 우리는 무국적화와 ZK-EVM을 통해 더 많은 문제를 해결할 것입니다. 하지만 장기적으로 Ethereum Layer 1 확장을 제한하는 주요 요인은 다음과 같습니다.
데이터 가용성 샘플링 및 과거 저장 프로토콜의 안정성
블록 생산을 위한 경쟁 시장을 유지해야 할 필요성
ZK-EVM의 검증된 기능.
이 글에서는 ZK-EVM을 RISC-V로 대체하면 2번과 3번의 주요 병목 현상을 극복할 수 있음을 보여드리겠습니다.
다음은 Succinct ZK-EVM이 EVM 실행 계층의 각 링크를 증명하는 데 필요한 사이클 수에 대한 통계 표입니다.
시간이 많이 걸리는 네 가지 주요 링크는 다음과 같습니다. deserialize_inputs(데이터 역직렬화), initialize_witness_db(위트니스 데이터베이스 초기화), state_root_computation(상태 루트 계산) 및 block_execution(블록 실행).
증인 데이터베이스 초기화와 상태 루트 계산은 모두 상태 트리와 관련이 있는 반면, 데이터 역직렬화는 블록 및 증인 데이터를 내부 표현으로 변환하는 프로세스를 말합니다. 따라서 실제로 50% 이상은 증인 데이터의 크기와 관련이 있습니다.
이러한 단계는 현재의 keccak 16-ary Merkle patricia tree를 증명 친화적인 해시 함수를 사용하는 이진 트리로 대체함으로써 상당히 최적화될 수 있습니다. 포세이돈을 사용하면 노트북에서 초당 200만 개의 해시를 증명할 수 있습니다(케칵의 경우 초당 약 15,000개의 해시). 포세이돈 외에도 많은 옵션이 있습니다. 전반적으로 이러한 단계에 소요되는 시간을 크게 줄일 수 있는 기회가 있습니다. 또한 accrue_logs_bloom을 제거하면 프로세스를 더욱 단순화할 수 있습니다.
이제는 블록 실행만 남았는데, 이는 현재 증명 주기의 약 절반을 차지합니다. 전반적인 증명 효율성을 100배 증가시키려면 EVM 증명 효율성을 최소한 50배 증가시켜야 합니다. 두 가지 경로가 있습니다. 하나는 증명 주기를 줄이기 위해 더 효율적인 EVM 구현을 만드는 것 입니다 . 다른 하나는 ZK-EVM의 하단에 채택된 RISC-V 가상 머신을 개발자가 직접 사용할 수 있도록 하는 것입니다.
일부 데이터에 따르면 특정 시나리오에서는 효율성이 100배 이상 향상될 수 있습니다.
실제로 남은 증명 시간은 주로 사전 컴파일에 소모됩니다. RISC-V를 기본 가상 머신으로 설정하면 가스 요금 메커니즘은 실제 증명 시간을 반영하게 되고, 경제적 압력으로 인해 개발자는 고비용 사전 컴파일 사용을 줄이게 됩니다 . 실제 수익률은 이론적인 가치만큼 좋지 않을 수 있지만, 여전히 매우 중요할 것으로 예상됩니다.
일반적인 EVM 실행에서도 EVM과 다른 링크가 50/50으로 유사하게 분할되는 현상이 존재하며, 직관적으로 EVM을 중간 계층으로 제거하면 비슷한 효율성 개선이 있을 것으로 생각합니다.
구현
위의 제안을 구현하는 방법은 여러 가지가 있습니다.
가장 방해가 적은 방법은 두 가상 머신을 모두 지원하고 두 가상 머신 중 하나에서 계약을 작성할 수 있도록 하는 것입니다. 두 유형의 계약 모두 동일한 기능(영구 저장소(SLOAD/SSTORE), ETH 잔액 관리, 전화 걸기 및 받기 등)에 액세스할 수 있습니다 . EVM 및 RISC-V 계약은 자유롭게 상호 운용 가능합니다. RISC-V 관점에서 EVM 계약을 호출하는 것은 특수 매개변수가 있는 시스템 호출(syscall)로 간주되지만, 호출을 수신하는 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줄을 넘지 않도록 엄격하게 규정하고 있습니다. 이상적인 블록체인 기반 계층은 더욱 극단적인 단순성을 추구해야 합니다. 빔 체인 프로젝트는 이더리움의 합의 계층을 단순화하는 방법을 제시하며, 실행 계층에서도 이와 유사한 획기적인 발전은 근본적인 변화를 통해서만 달성될 수 있습니다.
