저는 장기간 RISC-V 애호가였습니다. 저는 4개의 RISC-V 장치를 가지고 있으며, 일부는 홈 서버로 사용하고, 일부는 컴파일 대상으로 확인하며, 제 zkvms 작업을 위한 테스트베드로 사용합니다. r55가 만들어질 때 그 자리에 있었고, 제작을 도왔으며, 이름을 고안했습니다(어디서 왔는지는 말하지 않겠습니다, 그건 바보 같은 말장난입니다).
면책 조항 현재 EOF와 RISC-V에 대한 논쟁과 인접해 있지만, 이는 주로 그것에 관한 것이 아닙니다. 지금 시점에서 RISC-V에 에너지를 투자하는 것의 적절성에 대한 진실된 평가입니다.
제 견해로는 EVM을 RISC-V로 대체하지 말아야 할 몇 가지 이유가 있습니다. 특히 단기적으로는 더욱 그렇습니다:
- 장난감 같은 것을 만지작거릴 때 명백한 것은 RISC-V 생태계가 제품화 준비가 되어 있지 않다는 것입니다: 링커는 치명적으로 느리고, 라이브러리 지원은 매우 초라해서 거의 아무것도 컴파일되지 않으며, 매우 적은 프로젝트만이 RISC-V 릴리스를 만들려고 노력하기 때문에 네트워크 효과가 없습니다.
- RISC-V는 하나가 아니라 여러 종류가 있습니다. 32바이트와 64바이트 사이의 선택이 있습니다. 메모리 관리, 부동 소수점 등을 지원하기 위한 명령어 집합 아키텍처(ISA) 확장이 있습니다. 모듈성은 훌륭하지만, 이러한 모든 확장은 혼란스러울 수 있습니다. 컴파일러는 일반적으로 하나 또는 두 개의 대상만 지원하며, 대부분의 경우 필요한 대상이 아닙니다. 예를 들어, Go는 RISC-V64gc만 컴파일하지만 대부분의 zkvms는 RISC-V32imc를 대상으로 합니다. 우리가 원하는 확장을 결정하는 데 쉽게 1년을 소비할 수 있습니다.
- RISC-V 하드웨어 자체가 여전히 매우 느립니다: 빠른 AMD64 프로세서에서 EVM을 에뮬레이션하는 것이 RISC-V 프로세서에서 네이티브 코드를 실행하는 것보다 훨씬 빠릅니다[*]
- 일부 zkvms가 RISC-V에서 벗어나 WASM(예: powdr)을 사용하거나 자체 ISA를 개발하고 있다는 이야기를 듣고 있습니다. 제가 알기로는 RISC-V도 그렇게 zk-친화적이지 않습니다. 워드 크기가 더 작기 때문에 EVM보다는 분명히 더 좋지만, 훨씬 더 잘할 수 있습니다. zkvms가 최종 목표라면, 지금 RISC-V를 고정하는 것은 아마도 좋지 않을 것입니다.
요약(TLDR) 이 시점에서 그렇게 큰 변화를 서두르는 것은 좋은 생각이 아니라고 생각합니다.
저는 RISC-V를 사랑하고 RISC-V 지원 이더리움을 원합니다. 더 나은 방법은 실행 엔진의 길일 것입니다. 제 의견으로는 RISC-V는 EVM 대체가 아니라 네이티브 롤업 로드맵의 일부로, 보조 실행 엔진으로 와야 합니다. 이렇게 하면 엔진을 독립적으로 유지할 수 있어 전환이 더 원활해질 것입니다.
[*] 성능이 훨씬 더 좋은 일부 중국 보드가 있다는 것을 알고 있지만, 현재 구매할 수 없으며 나열된 가격은 터무니없습니다.
