이 기사는 Ethereum 개발자 levochka.eth에서 나왔습니다.
Odaily Planet Daily( @OdailyChina )에서 편집함; Azuma( @azuma_eth ) 님이 번역했습니다.
편집자 주:
어제, 이더리움의 공동 창립자인 비탈릭은 이더리움의 실행 계층 업그레이드에 대한 급진적인 기사를 게시했습니다(참고: 비탈릭의 급진적인 새 기사: 실행 계층 확장에는 혁신이 필요하고, EVM은 향후 반복되어야 함 ). 해당 기사에서는 스마트 계약을 위한 가상 머신 언어로 EVM을 대체하기 위해 RISC-V를 사용하고자 한다는 내용을 언급했습니다.
이 기사가 공개되자마자 이더리움 개발자 커뮤니티에서는 즉각적으로 큰 반향을 일으켰고, 많은 기술 리더들이 이 계획에 대해 다양한 의견을 표명했습니다. 기사가 발표된 직후, 이더리움의 일선 개발자인 levochka.eth가 원문 아래에 긴 기사를 써서 비탈릭의 관점을 반박했습니다. 그는 비탈릭이 증명 시스템과 그 성능에 대해 잘못된 가정을 했으며, RISC-V는 확장성과 유지 관리성을 모두 고려할 수 없어 최선의 선택이 아닐 수도 있다고 생각했습니다.
다음은 Odaily Planet Daily에서 번역한 levochka.eth의 원본 내용입니다.
이러지 마세요.
이 계획은 증명 시스템과 그 성능에 대해 잘못된 가정을 하고 있기 때문에 타당하지 않습니다.
가설을 검증하다
제가 아는 한, 이 접근 방식의 주요 장점은 확장성과 유지보수성입니다.
먼저, 유지보수성에 대해 논의하고 싶습니다.
실제로 모든 RISC-V zk-VM은 컴퓨팅 집약적 작업을 처리하기 위해 사전 컴파일을 사용해야 합니다 . SP 1의 사전 컴파일된 목록은 Succinct 설명서에서 찾을 수 있으며, 여기에는 EVM의 거의 모든 중요한 계산 명령어가 포함되어 있습니다.
따라서 기본 계층 암호화 기본 요소에 대한 모든 수정 사항은 이러한 사전 컴파일에 대한 새로운 회로를 작성하고 감사해야 하며, 이는 심각한 제한 사항입니다.
실제로 성능이 충분히 좋다면 실행 클라이언트의 비 EVM 부분의 유지 관리가 비교적 쉬울 수 있습니다. 성능이 충분히 좋을지는 잘 모르겠지만, 다음과 같은 이유로 이 부분에 대해서는 자신감이 덜합니다.
상태 트리 계산은 실제로 친화적인 사전 컴파일(예: 포세이돈)을 통해 크게 가속화될 수 있습니다.
하지만 역직렬화를 우아하고 유지 관리 가능한 방식으로 처리할 수 있는지는 확실하지 않습니다.
또한 블록 평가 시간에 속하지만 실제로는 비 EVM 부분으로 분류되어야 하는 까다로운 세부 사항(예: 가스 계량 및 다양한 점검)이 있으며, 이러한 부분은 종종 유지 관리 압력에 더 취약합니다.
다음은 확장성에 대한 부분입니다.
사전 컴파일을 사용하지 않고는 RISC-V가 EVM 워크로드를 처리할 수 있는 방법은 전혀 없다는 점을 다시 한번 강조하고 싶습니다.
따라서 최종 증명 시간은 현재의 사전 컴파일 작업에 의해 좌우될 것이라는 원래 기사의 진술은 기술적으로는 맞지만 지나치게 낙관적인 것입니다 . 이는 미래에 사전 컴파일이 없을 것이라고 가정한 것이지만, 사실(이 미래 시나리오에서) 사전 컴파일은 여전히 존재하며 EVM의 계산 집약적 명령어(서명, 해싱, 그리고 아마도 대규모 수치 아날로그 연산)와 완벽하게 일치합니다.
피보나치 예시와 관련하여 매우 낮은 수준의 세부 사항을 살펴보지 않고는 판단하기 어렵지만 , 그 강점은 적어도 부분적으로 다음에서 나옵니다.
해석과 실행 오버헤드의 차이점
루프 풀기(RISC-V의 제어 흐름을 줄입니다. Solidity에서 이를 구현할 수 있는지는 확실하지 않지만, 단일 명령어라도 해석 오버헤드로 인해 많은 제어 흐름/메모리 접근을 생성합니다.)
더 작은 데이터 유형을 사용하세요.
여기서 지적하고 싶은 것은 1번과 2번의 이점을 얻으려면 해석 오버헤드를 제거해야 한다는 것입니다. 이는 RISC-V 개념과 일치 하지만, 현재 논의하고 있는 RISC-V는 아니며, 유사한 (?)RISC-V입니다. 계약 개념을 지원하는 등 특정 추가 기능이 필요합니다.
문제는 여기에 있습니다
그런데 여기에는 몇 가지 문제가 있습니다.
유지 관리를 개선하려면 EVM을 컴파일할 수 있는 RISC-V(사전 컴파일 포함)가 필요합니다. 이것이 기본적으로 현재 상황입니다.
확장성을 개선하려면 완전히 다른 것이 필요합니다. RISC-V와 같은 새로운 아키텍처가 필요합니다. 이 아키텍처는 계약 개념을 이해하고, 이더리움 런타임의 한계와 호환되며, 해석 오버헤드 없이 계약 코드를 직접 실행할 수 있습니다.
지금은 두 번째 사례를 말하는 것으로 추정합니다(이 글의 나머지 부분이 그런 의미인 듯합니다). 이 환경 외부의 모든 코드는 여전히 현재의 RISC-V zkVM 언어로 작성될 것이며, 이는 유지 관리에 상당한 영향을 미칠 수 있다는 점을 알려드립니다.
다른 가능성
고수준 EVM 명령어로부터 바이트코드를 컴파일할 수 있습니다. 컴파일러는 생성된 프로그램이 스택 오버플로를 방지하는 등 불변성을 유지하는지 확인할 책임이 있습니다. 이것이 바닐라 EVM에서 시연되는 것을 보고 싶습니다. 적절하게 편집된 SNARK는 계약 배포 지침과 함께 제공될 수 있습니다.
우리는 또한 특정 불변식이 성립한다는 형식적 증명을 구성할 수 있습니다. 제가 아는 한, 이 접근 방식은(가상화보다는) 이미 일부 브라우저 컨텍스트에서 사용되고 있습니다. 이러한 공식적 증명의 SNARK를 생성하면 비슷한 결과를 얻을 수 있습니다.
물론, 가장 쉬운 방법은 그냥 실행하는 것입니다...
최소한의 체인 MMU 구축
게시물에서 암시했을 수도 있지만, 다시 한번 상기시켜 드리겠습니다. 가상화 오버헤드를 제거하려면 컴파일된 코드를 직접 실행해야 합니다. 즉, 계약(이제는 실행 가능한 프로그램)이 커널(EVM 구현이 아닌) 메모리에 쓰는 것을 어떻게든 방지해야 합니다.
그러므로 우리에게는 일종의 메모리 관리 장치(MMU)가 필요합니다. 기존 컴퓨터의 페이징 메커니즘은 필요하지 않을 수 있습니다. 왜냐하면 물리적 메모리 공간이 거의 무한하기 때문입니다. 이 MMU는 가능한 한 간소해야 합니다( 아키텍처 자체와 동일한 추상화 수준에 있기 때문 ). 하지만 일부 기능(예: 트랜잭션의 원자성 )은 이 계층으로 옮겨질 수 있습니다.
이 시점에서 증명 가능한 EVM은 이 아키텍처에서 실행되는 커널 프로그램이 됩니다.
RISC-V가 최선의 선택이 아닐 수도 있습니다.
흥미로운 점은 이러한 모든 조건 하에서 이 작업에 가장 적합한 명령어 세트 아키텍처(ISA)는 RISC-V가 아니라 EOF-EVM과 같은 것일 수 있다는 것입니다 . 그 이유는 다음과 같습니다.
작은 명령어는 실제로 많은 수의 메모리 접근을 초래하는데, 이는 기존의 증명 방법으로는 효율적으로 처리하기 어렵습니다.
분기 오버헤드를 줄이기 위해 최근 논문인 Morgana에서는 EOF와 유사한 정적 점프를 사용하여 사전 컴파일러 수준의 성능으로 코드를 증명하는 방법을 보여줍니다.
제가 제안하는 것은 최소한의 MMU를 사용하여 계약을 별도의 실행 파일로 실행할 수 있는 증명 친화적인 새로운 아키텍처를 구축하는 것입니다. 저는 RISC-V가 되어야 한다고 생각하지 않습니다. 오히려 SNARK 프로토콜의 제약에 최적화된 새로운 ISA 이거나, 심지어 EVM 명령어의 하위 집합을 부분적으로 상속하는 ISA가 더 나을 수도 있습니다. 알다시피 사전 컴파일은 원하든 원치 않든 존재하기 때문에 RISC-V는 이 부분에서 어떠한 단순화도 가져오지 않습니다.
