비탈릭 대 최고 개발자: Web3 가상 머신 논쟁의 <가상 원탁 회의>
각 블록체인은 고유한 강점과 스토리텔링을 가지고 있으며, 기술적으로 보면 블록체인의 코드 모듈은 거의 유사합니다. 노드 통신, 합의, 실행 등의 기능을 모두 갖추고 있지만, 각 프로젝트는 자신에게 가장 적합한 기술과 알고리즘, 특히 합의 알고리즘과 실행 계층의 가상 머신(Virtual Machine) 기술을 선택하고 있습니다. 최근 이더리움이 EVM 노드코드에서 RISC-V 명령어 세트로 전환하려는 시도 덕분에 비교적 은밀했던 가상 머신이라는 기술 분야가 일반 대중 앞에 드러나게 되었습니다.
며칠 전, 저는 RISC-V에 대한 과학기술 소개 글을 정리해 독자들이 그 과거와 미래를 이해할 수 있도록 했습니다.
EVM에서 RISC-V로? RISC-V의 역사와 Web3 분야 적용
오늘은 제가 좀 더 포괄적이고 종합적인 관점에서 가상 머신에 대해 여러분과 공유하고자 합니다. 저 자신은 가상 머신에 깊이 연구한 전문가는 아니지만, 인터넷 상에서 다양한 프로젝트의 가상 머신 전문가들이 제시한 설계 아이디어나 평론들을 혼합하여 정리함으로써, 각기 다른 가상 머신들의 차이점을 이해할 수 있도록 하겠습니다.
자료를 정리하면서 저는 이러한 견해들이 중국 춘추전국 시대의 백가쟁명(百家爭鳴)처럼 치열하게 부딪치는 모습을 보았고, 순간적으로 영감이 떠올라 현재 유행하는 원탁 회의/스페이스 형식으로 그들의 표현을 통합하여 "가상의 원탁 회의"를 구성해 "쟁명(爭鳴)"이라는 역동성을 강조해 보았습니다. 군자는 화합하되 일치하지 않는다는 말처럼 말입니다.
핵심 논점을 빠르게 파악하기 위해 여기서는 주요 Web3 가상 머신의 핵심 특징을 구조화된 표로 나란히 비교하며, 본문에 등장하는 10명 이상의 기술 리더들의 심층 토론 내용을 요약했습니다.
RISC-V, WASM, EVM 등 9개 유형의 방안에 대한 아키텍처 설계, 성능, 실현 과제 등을 포함: (표를 좌우로 스크롤하여 전체 표 확인)
2024년 이더리움 커뮤니티 내에서 RISC-V가 EVM을 대체해야 한다는 제안이 제기되면서 격렬한 논의가 벌어졌으며, 우리는 가상으로 각 파생 VM 설계자들을 초청해 기술 본질, 생태계 적합성, ZK 친화성 등의 측면에서 격돌을 펼쳐봅니다…
진행자: 먼저 @VitalikButerin[1], 이더리움 공동 창립자이자 EVM의 개척자로서, 많은 사람들이 EVM을 개선하려는 당신의 새로운 아이디어에 관심을 갖고 있습니다. 말씀해주실 수 있겠습니까?
@VitalikButerin: 네티즌 여러분 안녕하세요! 저는 비탈릭입니다. 중국 팬들은 저를 “작은 V”라고 부르기도 하죠(웃음~). 최근 제가 발표한 EVM → RISC-V 전환 제안에 대해 다들 알고 계실 겁니다. 자세한 내용은 포럼 원문[2](중문판[3])을 참고해 주세요. 여기서는 주요 내용만 간략히 설명하겠습니다:
• RISC-V를 스마트 계약 작성용 가상 머신 언어로 사용하는 것은 다소 급진적인 생각이지만— 사실 이것이 목표 달성의 유일한 방법일 수도 있습니다.
• 이더리움 L1 확장에는 여러 제약 요인이 있으며, 그 중 실행 효율성이 주요 병목 현상 중 하나입니다. 우리는 효율성을 높이고 실행 계층을 크게 단순화해야 합니다.
• 기존 EVM 계약은 계속 작동하며, 새롭게 도입될 RISC-V 계약과 완전한 양방향 호환성을 유지합니다. 이를 위한 구현 방법은 다양합니다:
• 가장 적은 혼란을 주는 방안은 두 가지 가상 머신을 동시에 지원하는 것입니다.
• 더 급진적인 방법은 기존 EVM 계약을 RISC-V로 작성된 EVM 인터프리터 계약을 호출하도록 변환하는 것입니다.
• 프로토콜 차원에서 '가상 머신 인터프리터' 개념을 명시적으로 지원하고, 그 로직을 RISC-V로 작성하도록 요구합니다. EVM이 첫 번째 사례가 될 것입니다.
• 향후 Move 언어 등 다른 언어도 지원 가능합니다.
• 개발자 경험은 거의 영향을 받지 않으며, 개발자조차 변화를 느끼지 못할 수도 있습니다.
• Nervos CKB VM이 이미 선례를 만들었으며, 본질적으로 RISC-V 기반 구현입니다[4].
진행자: @VitalikButerin 님이 이더리움의 최신 계획을 공유해주셔서 감사합니다. 원본 게시물에서 많은 사람이 지지를 표했지만 일부는 추가 연구가 필요하다고 주장했습니다. 본 토론의 주제는 가상 머신의 장단점을 종합적으로 비교하는 것이므로, RISC-V의 타당성에 관한 세부 사항은 생략하겠습니다. 물론 이번 주제에 부합하는 몇몇 게스트들도 아래 토론에 참여하셨습니다.
진행자: 오늘 두 번째 게스트를 소개합니다. @IAmNickDodson[5], Fuel Network[6] 창립자이자 CEO이며, 전 ConsenSys 소속으로 이더리움 인프라 및 도구 개발에 깊이 관여했고, 이더리움 클라이언트(Geth 또는 Parity 등) 최적화 작업에도 직접 참여한, VM 설계 및 구현에 풍부한 경험과 권위를 가진 분입니다.
@IAmNickDodson: 우선, Vitalik의 글은 매우 고무적입니다. 저는 이더리움 메인넷 출시 이전부터 EVM을 접해왔으며, 당시에도 결함이 있다는 것을 알았고, 지금까지도 여전히 문제가 남아있다고 말할 수 있습니다. 하지만 부정할 수 없는 사실은 EVM이 진정한 탈중앙 애플리케이션 구축의 기반이 되었다는 점이며, 이에 대해 감사함을 표합니다. [src[7]]
진행자: 다른 기존 솔루션이 아닌 FuelVM 개발을 선택하신 이유가 무엇입니까?
@IAmNickDodson: FuelVM 설계 시 MIPS, RISC-V, x86, ARM 같은 명령어 집합 아키텍처(ISA), WASM 같은 가상 머신 방식, 그리고 EVM, BitcoinScript, MoveVM, SVM 등 블록체인 전용 VM을 연구했습니다. 각각 장점이 있지만 우리의 요구를 완전히 충족시키지는 못했습니다. 잠시 후 제가 이 선택들에 대한 분석과 사고를 말씀드리겠습니다. 그 전에, 화면 앞의 여러분께도 다음 세 가지 핵심 질문을 함께 생각해보시길 바랍니다: 이 아키텍처는 블록체인 시나리오에 맞게 설계되었는가? 대립적 가스 계측 환경에서도 성능을 유지할 수 있는가? EVM 대비 실제로 개선되었는가?[src[8]]
진행자: 위 게스트분들의 자기소개에 감사드립니다. 이제 @IAmNickDodson의 연구 순서에 따라 대표적인 VM 프로젝트/기술을 선별하여 각자의 견해와 분석을 들어보겠습니다. 반대 의견도 자유롭게 제시해 주세요.
MIPS/RISC-V
@IAmNickDodson: 이러한 CPU 명령어 집합은 초기 마이크로칩과 임베디드 장치를 위해 설계되었습니다.
장점:아키텍처가 간단하고 문서가 잘 정비되어 있으며, 오픈소스 생태계, 네이티브 머신 코드로 컴파일 가능(추가 처리 필요 시도 있음), 다양한 언어 지원(Rust/Go 등).
단점:CPU 명령어 집합임과 동시에 가상 컴퓨팅 아키텍처는 아님, MIPS 명령어 집합이 너무 기초적이어서 x86이나 전용 VM의 단일 명령어 기능을 수행하기 위해 더 많은 오퍼코드가 필요함(CISC 부분 참조), 대립적 가스 계측을 고려하지 않음, 블록체인 시나리오에 최적화되지 않음, 제로지식 증명 처리 효율이 낮음(Starkware/Valida 연구 참조).
ZK 기술이 노드 계측 요구를 낮출 수 있다 하더라도, 고처리량 시나리오에서는 여전히 사전 계산/공유 증명이 필요하며, 이때 DoS 방지를 위한 계측 메커니즘이 여전히 중요합니다. [src[9]]
Georgios Konstantopoulos[10](Paradigm[11] 파트너 겸 CTO): @VitalikButerin의 제안을 좋아하신다면, 지난 몇 달간 우리가 조용히 개발해온 이 R55[12]도 마음에 드실 겁니다... [src[13]]
0xpedro.eth/acc[14]: R55를 통해 순수 Rust로 스마트 계약을 작성하고 이더리움 클라이언트 내 RISC-V에서 실행할 수 있습니다. 일반적으로 Solidity는 EVM 바이트코드로 컴파일되지만, R55는 Rust를 RISC-V 명령어로 컴파일하며, 하드웨어 최적화 잠재력을 해방하는 오픈소스 프레임워크입니다. 이더리움에서 Rust를 사용한다는 것? 흥미롭지만 까다롭습니다. RISC-V 자체는 이더리움 상태(저장, 호출 등)를 알지 못하므로 R55는 시스템 호출을 추가합니다. RISC-V의 ecall을 통해 Rust 계약은 저장(SLOAD 예시)을 읽거나, 계약을 호출하거나, 로그를 전송할 수 있어 이더리움과 Rust를 매끄럽게 연결합니다.
R55는 아직 개발 중이며 가스 및 보안 조정이 필요하지만 미래가 기대됩니다: 롤업이나 애플리케이션 체인이 네이티브 Rust 계약을 실행하거나, zkEVM이 RISC-V를 이용해 암호화 연산을 수행할 수 있습니다. 개인적으로 Rust의 보안성과 속도는 이더리움의 강력한 무기가 될 수 있다고 생각합니다. R55가 이더리움에 Rust 개발자 물결을 불러올 수 있을까요? 아마 아직 시기상조이겠지만 주목할 가치가 있습니다. [src[15]]
Dave Rauchwerk[16]: @VitalikButerin 정말 훌륭한 아이디어입니다. RISC-V의 중요한 장점 중 하나는 명확한 확장성입니다. 핵심적이고 성능이 중요한 EVM 오퍼코드를 가속화하기 위한 맞춤형 RISC-V 명령어 세트를 정의하는 연구가 필요합니다. RISC-V의 개방성은 일반 CPU 실행 외에 ASIC, FPGA 같은 전용 하드웨어 구현도 가능하게 하며, 이를 통해 실리콘 내부에서 핵심 EVM 로직을 직접 가속화하여 현재의 소프트웨어 인터프리터 또는 JIT 방식보다 수 개의 수량급 빠른 속도로 L1 TPS를 크게 향상시킬 수 있는 길이 열립니다.
검증 가능성과 보안성: 복잡한 기존 ISA에 비해 RISC-V의 모듈화 및 간결한 설계는 형식적 검증을 더 쉽게 만듭니다. 형식적으로 검증된 RISC-V 코어가 EVM 로직을 실행하면 고가치 스마트 계약의 보안을 위해 더 강력한 런타임 행동 보장을 제공할 수 있습니다. RISC-V는 EVM 중심의 맞춤형 명령어로 향상될 수 있으며, 더 높은 성능, 보안성, 확장성을 갖춘 Layer 1을 실현하는 매력적인 경로를 제공합니다.
또한 기존 EVM 구현과 잠재적인 RISC-V 소프트웨어 모델을 벤치마킹하는 것도 필요합니다. revive/PolkaVM이 훌륭해 보입니다 - 현재 RV32EM만 지원하지만 논의할 가치가 있습니다. [src[17]]
Koute[18](Parity Technologies[19] PolkaVM 책임자): 방금 PolkaVM 언급하셨으니, 제가 자세히 설명드리겠습니다.
PolkaVM은 현재 riscv64emac의 Zbb 확장을 지원하지만, 대부분(모든?) 다른 RISC-V VM과 달리 RISC-V 바이너리를 그대로 실행할 수 없습니다(사실상 RISC-V VM이 아닙니다!). 오프라인에서 일반 컴파일러로 생성한 RISC-V ELF 바이너리를 추출한 후, VM(네이티브 하드웨어가 아닌) 사용에 최적화된 더 제한적이고 효율적인 사용자 정의 바이트코드로 변환합니다. 저희의 목적은 체인 상에서 실행되는 VM 자체의 복잡성을 가능한 한 줄이고, 복잡한 부분은 오프라인 도구(체인 외부에서 실행 가능)로 이전하며, 불필요한 기능을 삭제함으로써 보안성을 높이는 것입니다(예: 원래 RISC-V에서는 임의 주소로 점프 가능하지만, PolkaVM 바이트코드에서는 코드 주소 공간이 완전히 가상화되어 어디든 점프할 수 없으며, 바이트코드 자체도 프로그램이 접근 가능한 메모리에 로드되지 않습니다).
성능 면에서 거의 베어메탈 수준에 근접합니다[1]; 최첨단 WASM VM(wasmtime)만큼 빠르며, O(n) 재컴파일 시간을 보장하고 프로그램을 네이티브 코드로 재컴파일하는 속도를 수백 배 향상시킵니다. 구체적으로, 원시 PolkaVM 바이트코드에서 시작하여 프로그램을 네이티브 코드로 재컴파일하는 것이, 캐시된 재컴파일 아티팩트를 해시값으로 조회하는 것보다 훨씬 빠릅니다(즉, 프로그램 재컴파일이 해시 계산보다 빠름). 또한 이 과정은 *런타임 실행 성능을 희생하지 않습니다.
저희가 RISC-V를 주로 사용하는 이유는 VM 용 바이트코드로 특별히 우수해서라기보다(사실 그렇게 좋지는 않습니다)단순하고 잘 지원되며, 상대적으로다른 것으로 전환하기 쉬워서, 뛰어난 소프트웨어 호환성(기존 컴파일러와 프로그래밍 언어 사용 가능, 예: 며칠 전 Quake를 PolkaVM에 이식함)과 사용자 정의 최적화된 바이트코드의 이점(매우 빠른 컴파일 속도, 네이티브 수준 성능, 단순성 및 사용자 정의 가능성)을 동시에 얻을 수 있기 때문입니다. [src[20]]
dilrong[21]: @VitalikButerin은 RISC-V로 이더리움 가상 머신(EVM)을 교체하면 제로지식(ZK) 증명의 효율이 50~100배 향상될 수 있다고 주장합니다. 그러나 RISC-V가 정말 더 낫습니까? EVM은 약 9년간 안정적으로 운영되어 검증된 플랫폼이지만, RISC-V는 블록체인 실행 환경에서 풍부한 실전 경험을 갖추지 못했습니다. PolkaVM이 RISC-V를 채택했지만, 아직 메인넷에서 철저히 검증되지 않았기 때문에 충분히 검증되었다고 보기 어렵습니다.
EVM은 스마트 계약 실행에 특화된 반면, RISC-V는 범용 아키텍처로 설계되어 블록체인 사례에 맞춘 맞춤형 최적화가 부족할 수 있습니다. RISC-V의 다용도성은 다른 블록체인의 프로그래밍 언어 사용을 가능하게 하지만, 비탈릭 본인도 기존 Solidity를 개선하는 것이 더 바람직하다고 지적했습니다. 전체 생태계를 새로운 아키텍처로 전환하는 것은 거대한 도전입니다.
소프트웨어에서 RISC-V를 구현하면 불가피하게 성능 저하가 발생합니다. 소프트웨어 기반 에뮬레이터는 과제를 효과적으로 처리할 능력에 의문을 제기합니다. 반면 RISC-V 하드웨어 채택은 큰 전환 비용을 초래합니다. 저는 ZK-EVM이 현재 요구를 이미 충족할 수 있다고 생각합니다. 개발 비용, 전환에 필요한 작업량, 예측 불가능한 오류 가능성을 고려하면, EVM을 RISC-V로 교체하는 것은 실현 가능한 방안이 아닐 수 있습니다.
RISC-V로의 전환이 잠재적 이점을 가져올 수는 있지만, 저는 ZK-EVM 개선과 기존 EVM 최적화가 더 실용적이고 안정적인 대안이라고 생각합니다. [src[22]]
Eduardo Bart[23](Cartesi[24] VM 코어 개발자): 블록체인 애플리케이션용 RISC-V 가상 머신인 Cartesi Machine[25] 개발에 적극 참여한 개발자로서, 이더리움 실행 계층에서 RISC-V 탐색을 지지하는 일부 견해를 공유하고자 합니다.
제 생각에 RISC-V 채택의 가장 큰 장점 중 하나는 성숙한 도구와 생태계에 즉시 접근할 수 있다는 점입니다. 완전히 맞춤형 환경을 구축할 필요 없이, RISC-V를 사용하면 개발자(및 코어 프로토콜)가 GCC 및 LLVM 같은 컴파일러, 디버거, 라이브러리, 심지어 수십 년간 축적된 Linux 같은 완전한 운영체제 경험을 활용할 수 있습니다. 새로 출현하고 실증되지 않은 도구 체인과 비교하면, 이는 개발자 진입 장벽을 크게 낮추며 컴파일러 버그로 인한 위험도 줄일 수 있습니다. 이는 Rust나 C++ 등 언어로 작성된 계약이 표준 백엔드를 통해 컴파일되어 이더리움을 타겟으로 삼는 목표와 매우 잘 맞습니다. LLVM 또는 GCC의 버그를 걱정하는 사람들에게는 CompCert[26] 같은 형식적으로 검증되고 현재 RISC-V를 타겟으로 할 수 있는 컴파일러를 사용해 보안을 강화하는 것이 가능합니다. 더 큰 맥락에서 보면, RISC-V 특권 ISA 사양을 포함하는 가상 머신(제가 개발 중인 것처럼)에서 공식 검증된 RISC-V OS 커널(seL4[27]) 위에서 애플리케이션을 실행하는 것도 가능하며, 운영체제 환경에서 실행돼야 하는 더 복잡한 애플리케이션에 대한 가능성을 열어줍니다.
일부가 제기한 성능 우려는 터무니없는 것이 아니지만 해결 가능합니다. 제 경험상 올바르게 구현된 RISC-V는 실행 성능을 희생하지 않습니다. u256 연산은 자연스럽게 여러 명령어로 분해되지만, 실제로 잘 최적화된 RISC-V 가상 머신에서는 대부분 경우 성능에 큰 영향을 미치지 않을 것입니다. 또한 가상 머신 수준의 최적화 기술은 이러한 비용을 크게 줄일 수 있으며, RISC-V ISA는 블록체인용 맞춤형 확장을 추가할 수 있을 정도로 충분히 확장 가능하여 Keccak256과 같은 일반적인 암호화 연산을 최적화할 수 있습니다.
제 생각에 미래의 실행 계층을 RISC-V처럼 표준화되고 개방적이며 잘 지원되는 ISA 위에 구축하면 견고한 기반을 제공할 것입니다. 이는 기존 소프트웨어 생태계를 활용할 수 있는 길을 제공하며, 개발자 경험을 단순화하고 RISC-V 분야의 미래 하드웨어 발전의 혜택을 누릴 수 있을 것입니다.
과정이 복잡하긴 하지만, 저는 RISC-V가 확장성, 도구 성숙도, 장기 유지관리성 측면에서 잠재적 이점을 가지고 있어 미래 블록체인 실행 환경을 향한 매우 추구할 만한 방향이라고 믿습니다. 현재 블록체인 분야에서 많은 기존 RISC-V 가상 머신은 견고하고 바로 사용 가능한 RISC-V 구현이 가능함을 입증하고 있습니다. 특히 저는 Cartesi Machine이 표준 개방형 ISA의 강력함을 보여준다고 생각합니다. 이는 안정적이며 고성능인 RISC-V 시뮬레이터로, 표준 RV64GC ISA를 구현하며 수정되지 않은 RV64GC ELF 바이너리와 전체 Linux 소프트웨어 스택을 실행할 수 있습니다. 결정적으로 완전히 결정론적이며 부동소수점 연산까지 포함됩니다. 관심이 있고 실행 능력을 확인하고 싶은 분들에게는 제 WebCM[28] 실험을 추천합니다. 이는 서버리스 터미널로, 웹브라우저 내에서 WebAssembly로 컴파일된 Cartesi Machine 시뮬레이터가 구동하는 RISC-V 머신을 시뮬레이션하여 가상 Linux를 직접 실행합니다.
현재 L1 제안은 제로지식 증명에 집중하고 있지만, Cartesi는 현재 상호작용형 사기 증명을 통해 결정론적 실행과 상태 Merkle 증명을 활용해 체인 상에서 검증을 수행하고 있습니다. 검증 메커니즘은 다르지만, Cartesi는 RISC-V 위에 검증 가능하고 결정론적인 실행 환경을 구축하는 것이 가능하고 가치 있다는 것을 확인했습니다.
물론 RISC-V를 L1에 직접 통합하고 제로지식 증명을 수행하는 것은 가스 계측, 상태 상호작용을 위한 정확한 시스템 호출 정의, RISC-V 명령어에 대한 제로지식 회로 최적화 등에서 고유하고 중대한 도전을 동반합니다. 제로지식 증명 특정 환경下的 성능도 심층 연구가 필요합니다. 다행히 많은 RISC-V 제로지식 가상 머신 프로젝트가 이러한 분야를 연구하고 개발 중입니다.
구현 전략에 대해 저는 '급진적 방법', 즉 RISC-V로 컴파일된 가상 머신 인터프리터 개념을 프로토콜에 통합하는 것을 진지하게 고려해야 한다고 생각합니다. 이 방법은 이더리움 코어 RISC-V 가상 머신을 최소화하고 단순화하면서도, EVM 외부의 다양한 가상 머신 인터프리터를 수용할 수 있어 개발자에게 VM 개발에서 더 많은 자유를 제공할 수 있는 길을 열어줍니다.
요약하자면, 저는 RISC-V 같은 표준을 활용하는 것이 도구, 개발자 친숙도, 유연성, 심지어 장기적인 하드웨어 가속화 가능성 측면에서 큰 이점을 가진다고 믿습니다. Cartesi Machine의 업무 경험은 RISC-V가 차세대 검증 가능 블록체인 컴퓨팅의 강력하고 실현 가능한 기반이라는 관점을 강화시켰습니다. 이더리움 코어 실행 계층에 진지하게 고려되는 것을 보며 매우 흥분됩니다. [src[29]]
Xuejie Xiao[30]: 안녕하세요, 저는 Nervos CKB-VM의 원초 설계자이자 현재 유지자입니다. Nervos 입장에서 CKB-VM을 선택한 것은 완전히 제1원칙(First Principles)적 사고에서 비롯되었습니다: 우리는 간단하고, 안전하며, 빠른 샌드박스를 원했고, 상용 CPU에서尽可能軽量하게 실행되기를 원했습니다. 결과적으로 CPU 명령어 집합이 최선의 선택임이 입증되었으며, 그중에서도 RISC-V가 다른 선택지들 사이에서 두드러졌습니다. 물론 다른 오픈소스 RISC CPU 코어도 존재하지만, 우리看来 RISC-V가 가장 주목받고 있으므로 도구 체인 개발에 더 많은 사람들이 참여할 것입니다. 이는 우리에게 큰 이점이 됩니다.
EVM과 RISC-V를 논의할 때, 저는 둘 다 사전 컴파일 포함 여부를 동일하게 설정하거나, 둘 다 사전 컴파일을 포함하지 않는 상태에서 장단점을 비교하는 것이 좋다고 제안합니다. 사전 컴파일을 포함한 EVM과 사전 컴파일을 포함하지 않은 RISC-V를 비교하거나 그 반대로 비교하는 것은 적절하지 않다고 생각합니다. JIT 또는 AOT RISC-V 구현을 사용하거나 AVX 명령어를 도입한다고 가정하면, 사전 컴파일 없는 RISC-V 가상 머신을 사용하는 EVM과 유사한 성능을 얻을 수 있을 것입니다.
저희가 아는 한, RISC-V는 7년 전 최선의 해결책이었으며, 예견 가능한 미래에도 여전히 최선의 해결책이라고 생각합니다. 누군가 RISC-V를 하드웨어 해결책이라고 말한다면, 그렇다고 하겠습니다. 우리는 순수 소프트웨어로 이미 이를 구현했으며, 여전히 우리의 요구를 완벽하게 충족시키고 있습니다. 이 의미에서 현재 상황에 만족하며, 이 길을 계속 걸어갈 것입니다. [src[31]]
진행자: CKB-가상머신(CKB-VM)은 Nervos CKB에서 스마트 계약을 실행하기 위해 RISC-V 명령어 집합 기반의 가상 머신으로, Rust로 작성되었습니다. 관심 있으신 분은 2018년 @Xuejie Xiao가 발표한 An Introduction to Nervos CKB-VM[32]을 참고하시면 당시의 사고를 이해할 수 있으며, 아주 훌륭한 공유입니다!
ZKM[33]: @VitalikButerin이 이더리움을 위한 RISC-V 계획은 매우 대담하지만, MIPS의 성숙도와 전통은 눈에 띄는 다크호스입니다— 제로지식(ZK) 증명에 적합한 고정된 명령어 집합입니다. MIPS는 40년간 핵심 시스템을 운영해 왔으며— Ethereum은 이러한 안정성을 활용해 유사하거나 더 나은 효율 향상을 달성할 수 있으며, RISC-V처럼 과도하게 홍보되고 아직 성숙하지 않은 ISA를 채택하는 위험을 줄일 수 있습니다. MIPS가 이미 검증되었다면, 왜 RISC-V의 성장통에 베팅해야 합니까? [src[34]]
WebAssembly(WASM)
@IAmNickDodson: 브라우저/격리 환경에서 임의 코드 실행을 위해 설계됨: 장점: 다양한 언어/환경 지원, 네이티브 코드로 컴파일 가능, 명확한 오픈소스 사양, 이후 가스 계측 기능 추가(추가 오버헤드 있음); 단점: 스택 기반 아키텍처(학계 연구에선 성능 낮다고 판단되지만 변증법적으로 봐야 함), 블록체인 전용 설계 아님, 계측 기능이 후속 패치로 성능에 영향, 디버깅 경험 매우 나쁨.
이론적으로 WASM은 좋은 선택이지만, 실제 개발에서는 디버깅이 극도로 고통스럽습니다. WASM에 올인한 여러 팀과 대화한 결과 모두 후회한다고 말했습니다. 비교하면 RISC-V/MIPS가 이해하기 더 쉽고, 이것이 Succinct/RISC0 등 팀들이 이를 선택하는 이유일 수 있습니다. [src[35]]
Peter Kieltyka[36](Sequence[37] 공동 창립자): @VitalikButerin 이것은 다소 억지스럽게 들릴 수 있지만, 미래의 L1 실행 계층으로 Offchain Labs 팀이 개발한 EVM+/Stylus를 고려해보세요. 이는 EVM 바이트코드와 완전 호환되며 WASM VM에서 실행되며 WASM을 지원하는 모든 언어(Rust 등)를 사용할 수 있고, 성능이 크게 향상되며, 런타임에서도 EVM 바이트코드 계약과 완전한 상호 운용성을 유지합니다. 호환성을 유지하면서 가장 간단한 업그레이드 경로처럼 느껴집니다. [src[38]]
Xuejie Xiao[39]: 많은 사람들이 WASM이 블록체인 가상 머신의 이상적인 선택이라고 생각하는데, 주로 WASM이 소프트웨어 구현을 위해 설계되었기 때문입니다(이 말이 성립한다면 일단 무시하겠습니다). WASM이 등장하기 전, JavaScript의 하위 집합인 asm.js가 한때 인기를 끌었음을 아십니까? asm.js는 이후 WASM으로 진화했고, 어쩌다 보니 asm.js의 초기 비전보다 훨씬 방대해졌습니다(솔직히 말해, 지금 WASM은 asm.js보다는 깔끔하고 완전히 새롭게 설계된 JVM처럼 보입니다). 하지만 우리는 asm.js의 초기 목표를 잊지 말아야 합니다: 사람들은 JIT가 90%의 시간만 가능한 것이 아니라, 네이티브 CPU 명령어에 결정론적으로 매핑되는 소프트웨어 IR을 원했습니다. 만약 RISC-V가 그런 목표를 달성할 수 있다면, 저는 소프트웨어 가상 머신으로서 매우 적합하다고 생각합니다. [src[40]]
Hazel Hu[41](Delphinus Lab[42]): 비록 @VitalikButerin이 RISC-V를 강력히 지지하지만, 제로지식 가상 머신에는 이 외의 기술 경로도 있습니다. ZK 가상 머신은 ETH 전용도 아니며, ETH 생태보다 더 크고 독립적인 것이 될 수 있습니다. ETH는 ZKVM이 필요하지만, ZKVM은 이더리움 생태에 국한되지 않습니다. [src[43]]
ZK 시스템은 RISC 즉 축소 명령어 세트를 사용하며, 여기에는 두 가지 선택이 있습니다. 하나는 Cairo처럼 ZK 특화 언어가 자체적으로 사용자 정의 명령어 세트를 구축하는 것이고(학습 곡선이 지나치게 가파름), 다른 하나는 기존 명령어 세트를 사용하는 것입니다. RISC-V가 그 중 하나입니다. @RiscZero[44], @SuccinctLabs[45], @NexusLabs[46], @a16z[47]가 지원하는 Jolt 등은 모두 RISC-V 기반 ZK 가상 머신 프로젝트입니다.
이미 2018년, 이더리움 생태계는 eWASM 프로젝트를 시작했으며, EVM의 창시자 @gavofyork[48]도 WASM이 EVM을 대체할 수 있음을 언급했고, Polygon 창립자 @sandeepnailwal[49]도 WASM의 강력한 지지자였습니다. 그러나 eWASM은 공학적 복잡성, 우선순위 조정, L2 솔루션의 부상으로 인해 결국 광범위하게 채택되지 못했으며, 이후 발표된 로드맵에서 eWASM은 보류되었습니다.
@VitalikButerin이 제안을 발표한 후, Zebra 창립자 @shumochu[50], 1kx 리서치 파트너 @_weidai[51] 등은 WASM이 이더리움 실행 계층에 RISC-V보다 더 적합할 수 있다고 지적하며 다음과 같은 이유를 들었습니다:
절차가 더 간편함: RISC-V는 하드웨어 구현을 위해 설계되었으며 중간 표현용으로 설계되지 않았습니다. 이더리움 계약의 실행 계층으로 사용하려면 여전히 가스 소비와 실행 흐름을 처리하는 가상 머신 계층을 구축해야 하며, 이는 복잡성을 증가시킵니다.
정적 분석에 친화적: WASM은 점프 명령어가 없어 코드 구조가 단순하며, 계약 속성을 검증하기 쉬움.
언어 지원이 광범위함: 개발자는 현재 거의 모든 주류 프로그래밍 언어로 프로그램을 작성해 WASM으로 컴파일할 수 있어 학습 비용이 크게 낮아짐. Miden 창립자 @bobbinth[52]는 추가로 ZK 친화성을 추구한다면 RISC-V보다 더 나은 명령어 세트를 설계하거나 WASM 구성 요소 모델을 사용할 것을 제안했습니다. [src[53]]
제가 속한 @Delphinuslab[54]는 업계 최초의 ZKWASM 가상 머신을 오픈소스로 공개했습니다. 현재는 solidity SDK만 제공하지만, 실제로 ZKVM 계약 결제는 어떤 체인에서도 가능하며, 앞으로 Solana, Sui 등 EVM 이종 체인으로도 완전히 확장할 수 있습니다.
ZKWASM 가상 머신은 도대체 무엇에 쓸 수 있나요?
1. 더 많은 개발자가 가장 익숙한 프로그래밍 언어를 사용해 블록체인 세계에 진입할 수 있게 하며, 모두에게 Solidity(그리고 더 복잡하고 소수 언어) 또는 Rust를 배우도록 강요하지 않음
2. 더 많은 Web2.5 웹 앱이 일클릭으로 블록체인에 올릴 수 있게 하며, 완전히 구현된다면 수천 개의 브라우저 앱을 빠르게 블록체인에 배포할 수 있음
3. 불가능 삼각형을 깨고 탈중앙화, 효율, 보안의 균형을 실현함. [src[55]]
x86/ARM
@IAmNickDodson: 이 두 CPU 명령어 집합은 모두 오픈소스가 아닙니다: ARM은 RISC 축소 명령어 집합, x86은 CISC 복잡 명령어 집합에 속합니다. CPU 하드웨어 발전과 함께 둘 다 극도로 복잡해졌습니다. 주목할 점은 CISC가 CPU 분야에서 점차 RISC에 의해 대체되고 있지만, 블록체인 시나리오에서는 오히려 CISC가 더 큰 이점을 가진다는 점입니다. [src[56]]
Xuejie Xiao[57]: x64는 너무 무겁습니다(처음 RISC-V를 시도할 때, 누군가 x64로 블록체인 가상 머신을 구축하고 있었습니다!), Arm은 라이선스 문제가 있을 수도 있고, 없을 수도 있습니다. [src[58]]
Bitcoin Script
@IAmNickDodson: 첫 번째 블록체인 VM로, 비트코인 프로그래밍을 위해 설계됨:
장점: 블록체인 및 비트코인 거래 모델에 특화, 대립적 환경에 적응, 다중 서명 등 기본 작업 지원
단점: 기능이 극도로 제한적, 비트코인 네트워크 처리 능력에 심각하게 제약됨.
우리는 Bitcoin Script로부터 P2SH(스크립트 해시로 지불)라는 강력한 패러다임—조건부 프로그래밍을 계승했습니다. 이는 실행 후 전체 노드에서 삭제 가능한 트리밍 가능한 프로그램 패턴으로, 오프체인 거래/다중 서명 지갑/상품 경매 등 풍부한 시나리오를 지원할 수 있습니다. 비트코인 아키텍처는 VM 설계가 반드시 거래 모델과 깊이 협력해야 함을 시사합니다. [src[59]]
MoveVM
@IAmNickDodson: 메타 팀이 개발한 블록체인 전용 VM으로, 보안성 강조:
장점: 블록체인 네이티브 설계, 대립적 계측 지원, 전용 언어 Move 제공
단점: 보안을 위해 많은 상태 유연성 희생, 과도한 RISC화(앞서 분석 참조), 생태계 분열(SUI/Aptos 불호환 변형 존재).
2020-21년 Move 생태계는 거의 정체되었습니다. 우리는 타인의 아키텍처에 얽매여 혁신할 수 없는 상황을 피하고자 포기했으며, 그 "보안" 특성이 더 많은 것은 RISC 시스템의 포장에 불과하고 나쁜 코드 작성을 막지 못한다고 생각했습니다. 당시 형식적 검증은 간단한 메서드에만 적용 가능하며 전체 애플리케이션에는 적용되지 않아 비용 대비 효율이 극히 낮았습니다. [src[60]]
EVM
@IAmNickDodson: 블록체인계의 PHP라 불릴 만큼 수천억 달러 가치의 스마트 계약을 지탱:
장점: 블록체인 네이티브 설계, 완벽한 계측 메커니즘, 전체 생태계 호환, Solidity 언어 검증됨
단점: 256비트 워드 길이 설계, 호출/계약만 지원하고 스크립트 기능 부족, 조건부 프로그래밍 부재(P2SH 등가물 없음), 과도하게 단순화된 거래 모델 기반, 비효율(워드 길이 및 오퍼코드 설계로 인한 계산 낭비 많음), 고도로 상태화된 설계로 인해 저장소 접근이 성능 병목.
일부 팀은 새로운 데이터베이스나 상태 접근 방안으로 문제를 해결했다고 주장하지만, 본질적으로 이러한 계산은 피할 수 있었습니다. EVM은 생태계를 빠르게 구축하는 데 적합하지만, 거래 모델과 설계 공간 관점에서 혁신이 부족합니다. 비탈릭의 발언은 아마도 이 점을 인식했기 때문일 것입니다. [src[61]]
Alex Vlasov[62]: RISC-V가 EVM보다 정말 더 나은지는 불확실합니다. EVM은 스택 기반으로 레지스터 파일이 작습니다. EVM은 256비트 숫자를 다룹니다. 값이 훨씬 작다면 문제가 될 수 있습니다. 그러나 증명기는 실제 실행 궤적에 접근할 수 있으므로 작은 값에 더 가벼운 구현 옵션을 선택할 수 있습니다(예: 32비트 값의 바이트 분해는 256비트 값의 바이트 분해보다 행 수가 적음). [src[63]]
다른 측면은 스마트 계약의 형식적 검증 비용입니다. EVM의 명령어 집합(ISA)은 RISC-V보다 제한적이므로 F/V 전반적으로 더 복잡합니다. RISC-V 스마트 계약은 일반적으로 더 많은 루프와 더 많은 메모리 작업을 포함하며, 이 둘 다 F/V에 문제를 일으킵니다.
예를 들어 한 연구(/www.cs.utexas.edu/~isil/solis.pdf[64])에 따르면, 약 5분의 1의 EVM 스마트 계약이 하나 이상의 루프를 포함합니다. EVM은 256비트 값을 다루므로 RISC-V 코드에서는 더 많은 루프가 필요합니다. 루프展開하더라도 더 큰 SMT 쿼리가 발생합니다.
RISC-V는 더 풍부한 메모리 모델을 가지며, 따라서 더 많은 메모리 작업이 있을 것입니다(예: EVM은 1024개의 256비트 스택을 가지지만, RISC-V는 16-32개의 32/64비트 레지스터를 가짐). 따라서 별칭(aliasing, 두 개의 구문적으로 다른 표현이 동일한 메모리 위치를 가리키는 것)이 더 심각한 문제가 될 것입니다. 이는 다시 정적 분석, 예를 들어 호출 그래프 재구성, 포인터 분석 등에 영향을 미칩니다.
제 예상으로는, 루프/별칭이 있는 RISC-V 스마트 계약에 대해 EVM 스마트 계약보다 형식적 추론이 더 도전적일 것입니다. [src[65]]
SVM
@IAmNickDodson: Solana 가상 머신(SVM)은 최근 급부상:
장점: 블록체인 네이티브 설계, 대립적 계측 지원, 네이티브 코드로 컴파일 가능, 고성능 설계
단점: 아키텍처가 복잡하고 이해하기 어려움, Rust 등 언어 개발 경험 나쁨, 전용 언어 부족.
저희가 SVM을 선택하지 않은 주요 이유는 거래 모델 가정 때문입니다— 이더리움과 유사한 단순 설계는 복잡한 다자간 결제보다 속도를 추구하며, 이는 우리가 계획한 거래 모델과 맞지 않습니다. [src[66]]
CairoVM
Akash Balasubramani(StarkWare 생태 매니저): @IAmNickDodson 훌륭한 분석입니다! CairoVM도 포함됐으면 더 좋았을 텐데요. [src[67]]
@IAmNickDodson: 포함하지 않은 것은 2020/21년 조사 당시 아직 저희 시야에 들어오지 않았기 때문입니다. 저는 Cairo와 STARK 기술의 열렬한 팬입니다. [src[68]]
Eli Ben-Sasson(StarkWare 공동 창립자): @IAmNickDodson 훌륭한 토론입니다! 하나만 제안하면 Cairo 분석을 추가하는 것입니다. 제가 보충해보겠습니다: 장점: 블록체인 + zkSTARK 효율을 위해 특별히 설계, 선형 타입 안전, 효율적인 가스 계측(Sierra), 단점: 인지도/도구 체인 완성도 낮음 :) [src[69]]
진행자: 모두의 훌륭한 평론에 감사드립니다. 마지막으로 여러분의 결론은 무엇이며, 우리 모두와 나눌 수 있는 통찰이 있습니까?
@IAmNickDodson: 모든 VM을 조사한 후 우리는 VM 자체의 중요성이 과대평가되었다는 것을 깨달았습니다. 이론적으로 이 VM들은(BTC Script 제외) 서로 다른 효율로 필요한 계산을 수행할 수 있습니다. 진정으로 중요한 것은 VM과 거래 모델의 공동 설계입니다. 많은 체인이 VM에 지나치게 집중하지만 거래 모델을 간과합니다— 이것이 바로 블록체인 행동의 핵심입니다. [src[70]]
FuelVM의 독특함은 바로 여기에 있으며, 이는 FuelVM의 복합 최적화입니다 [src[71]]:
• 메모리 효율성(공유 메모리 컨텍스트로 복사 감소)
• 레지스터와 메모리의 지능적 활용(예: 전체 거래를 가시 메모리에 두어 런타임 자가 검사 가능)
• IO 접근을 극도로 감소
• 거래 계층 능력 강화(거래가 더 많은 일을 하고, VM은 덜 하게 함)
• 거래 모델이 상태 접근과 다중 자산/다중 조건/다중 실행 모드 전환 능력을 모두 갖춤
• CISC와 RISC의 황금 비율
• 전역 상태 트리 없음(UTXO 모델이 시간 역행을 통해 자연스럽게 이중 지출 방지)
• 모든 오퍼코드가 계측 효율을 위해 최적화됨
• 조건부 프로그래밍 등 다양한 프로그램 유형 지원
• Sway 언어가 Rust 성능과 Solidity 개발 경험을 동시에 제공
전통적 인식은 블록체인 VM이 보안과 네이티브 코드 컴파일 고려로 극도로 간단한 명령어를 추구해야 한다고 생각합니다. 하지만 문제는 낙관적 검증 시나리오에서 모든 작업이 계측돼야 한다는 점입니다. VM이 단순할수록 동일 기
TechFlow 공식 커뮤니티에 오신 것을 환영합니다
Telegram 구독 그룹:https://t.me/TechFlowDaily
트위터 공식 계정:https://x.com/TechFlowPost
트위터 영어 계정:https://x.com/BlockFlow_News
