롤업 물결 속에서, VM은 아직 이야기할 것이 있다

1.1 VM이란?

가상 머신(VM)은 가상화된 컴퓨팅 자원의 구성 요소로, 컴퓨터와 거의 동일한 기능을 가지고 있으며, 애플리케이션과 운영 체제를 실행할 수 있습니다. 가상 머신의 개념은 새롭지 않으며, 이 기술은 여러 기술 생태계에서 널리 사용되고 있습니다.

블록체인 맥락에서 가상 머신(VM)은 프로그램을 실행하는 소프트웨어로, 일반적으로 블록체인 스마트 계약을 실행하는 런타임 환경으로 알려져 있습니다. 가상 머신은 일반적으로 다양한 하드웨어 장치를 시뮬레이션하여 가상 컴퓨터 환경을 제공합니다. 서로 다른 가상 머신이 시뮬레이션할 수 있는 하드웨어 장치는 다를 수 있지만, 일반적으로 CPU, 메모리, 하드 드라이브, 네트워크 인터페이스 등을 포함합니다. 체인 상의 거래가 제출되면, 가상 머신은 해당 거래를 처리하고 거래 실행에 영향을 받는 블록체인 상태를 업데이트하는 역할을 합니다(전체 네트워크의 현재 글로벌 상태). 네트워크 상태를 변경하는 구체적인 규칙은 VM에 의해 정의됩니다. 거래를 처리할 때, VM은 스마트 계약 코드를 노드/검증기 하드웨어가 실행할 수 있는 형식으로 변환합니다.

VM에서 가장 중요한 핵심은 LLVM(저수준 가상 머신)으로, 컴파일러의 가장 중요한 핵심으로 볼 수 있습니다. 그림은 원래 EVM의 작동 방식을 보여주며, 스마트 계약은 LLVM IR의 중간 코드를 통해 변환되어 바이트코드로 변환됩니다. 이러한 바이트코드는 블록체인에 저장되며, 스마트 계약이 호출될 때 바이트코드는 해당 Opcode로 변환되고, EVM과 노드 하드웨어에 의해 실행됩니다.

1.2 주요 VM

1.2.1 EVM------블록체인 VM의 공통점, EVM이 독점

대표 프로젝트: Optimism, Arbitrum

현재 업계에서 개발자 및 사용자 활동도가 가장 높은 블록체인 생태계인 이더리움 가상 머신 EVM은 스택 기반 가상 머신으로, CPU, 메모리, 저장소 및 스택 등의 하드웨어 장치를 시뮬레이션하여 가상 컴퓨터 환경을 제공하고, 이를 통해 스마트 계약의 명령을 실행하고 스마트 계약의 상태와 데이터를 저장합니다. EVM의 명령어 집합은 산술 연산, 논리 연산, 저장 연산, 점프 연산 등 다양한 작업 코드를 포함합니다.

EVM이 시뮬레이션하는 메모리와 저장소는 스마트 계약의 상태와 데이터를 저장하는 장치입니다. EVM은 메모리와 저장소를 두 개의 서로 다른 영역으로 간주하며, 메모리와 저장소를 읽고 쓰는 방식으로 스마트 계약의 상태와 데이터에 접근할 수 있습니다.

EVM이 시뮬레이션하는 스택은 명령어의 피연산자와 결과를 저장하는 데 사용됩니다. EVM의 명령어 집합에서 대부분의 명령어는 스택 기반으로, 스택에서 피연산자를 읽고 결과를 다시 스택에 푸시합니다.

EVM의 설계 과정은 명백히 하향식으로, 먼저 시뮬레이션할 하드웨어 환경(스택, 메모리)을 확정한 후, 해당 환경에 맞춰 자신만의 어셈블리 명령어 집합(OpCode)과 바이트코드(Bytecode)를 설계했습니다. 이더리움 커뮤니티는 EVM 실행 효율성을 위해 두 가지 컴파일형 고급 언어인 Solidity와 Vyper를 설계했습니다. Solidity는 두말할 필요가 없고, Vyper는 Vitalik이 Solidity의 일부 결함을 개선하여 설계한 EVM 고급 언어이지만, 커뮤니티에서 높은 채택률을 얻지 못해 점차 역사에서 사라지게 되었습니다.

1.2.2 zkEVM------모두 필요: EVM 환경 호환 + 글로벌 상태 루트 변환 생성 zk-proof 지원

대표 프로젝트: Taiko, Scroll, Polygon zkEVM

EVM이 구축될 때 zk-proof 계산을 고려하지 않았기 때문에, 특정 작업 코드, 스택 기반 아키텍처, 저장 비용 및 증명 비용 등에서 증명 회로에 대해 우호적이지 않은 특성을 가지고 있습니다. zkEVM은 zk-proof 계산과 호환되는 방식으로 스마트 계약을 실행하는 가상 머신으로, EVM의 실행 과정을 zk-proof/validity-proof를 통해 보다 효율적이고 저렴하게 검증할 수 있게 합니다. OP Rollup 실행 레이어가 EVM을 그대로 복사하는 것에 비해, EVM의 ZK 친화성을 구축하는 것은 ZK Rollup의 추가적인 도전 과제가 됩니다.

ZK-rollups는 이더리움 가상 머신(EVM)과 호환되기 어렵습니다. 회로에서 일반 EVM 계산을 증명하는 것은 간단한 계산(예: 앞서 설명한 토큰 전송)을 증명하는 것보다 더 어렵고 자원을 더 많이 소모합니다.

그러나 제로 지식 기술의 발전은 EVM 계산을 제로 지식 증명으로 포장하려는 관심을 다시 불러일으켰습니다. 이러한 노력은 프로그램 실행의 정확성을 효과적으로 검증할 수 있는 제로 지식 EVM(zkEVM) 구현을 목표로 합니다.

EVM과 마찬가지로 zkEVM은 특정 입력에 대한 계산을 수행한 후 상태 간 전환을 합니다. 다른 점은 zkEVM이 프로그램 실행의 각 단계의 정확성을 검증하기 위해 제로 지식 증명을 생성한다는 것입니다. 유효성 증명은 가상 머신 상태(메모리, 스택, 저장소)와 계산 자체의 작업의 정확성을 검증할 수 있습니다(즉, 해당 작업이 올바른 작업 코드를 호출하고 이를 올바르게 실행했는지?).

아이디어는 아름답지만 현실은 냉혹합니다. 현재 Rollup은 ZK 친화성과 EVM 호환성(심지어 동등성)을 동시에 달성하기 어렵습니다. 즉, 이더리움 L1 실행 레이어를 가능한 한 완벽하게 복사해야 하며, 해시, 상태 트리, 트랜잭션 트리, 사전 컴파일 등을 포함하여 이더리움 L1 실행 클라이언트가 Rollup 블록을 처리하는 데 그대로 사용할 수 있도록 해야 합니다. 또는 EVM 호환성을 포기하고 기존 Opcode를 재구성하여 회로에서 증명/검증을 수행하여 스마트 계약을 실행할 수 있도록 해야 합니다.

1.2.3 zkVM------물고기와 곰발바닥을 모두 가질 수는 없다: zk-proof 효율성 지향의 비 EVM 가상 머신

대표 프로젝트: Starknet, Zksync, RISC ZERO

zkVM은 EVM 호환성을 포기하고 데이터 증명과 상태 업데이트를 핵심 목표로 하여 암호학과 고급 언어 간의 공통점을 찾아 다양한 응용 프로그램에 대한 일반적인 프레임워크를 제공합니다.

Starkware는 ZK 분야에서 비교적 일찍 시작하여 기술 축적이 충분하여 일정한 기술적 우위를 가지고 있습니다. 그는 ZK 중심의 기술 아키텍처를 대표하며, ZK를 중심으로 Cairo VM과 Cairo 언어를 구축했습니다. 단점은 Cairo의 학습 비용이 높다는 것입니다.

ZKsync의 프레임워크는 EVM과 ZK 두 가지 측면의 특징을 통합하여 Solidity와 자체 개발한 회로 언어 Zinc를 결합하여 컴파일러 내부에서 두 언어를 IR 수준에서 통합했습니다. 장점은 컴파일러 핵심인 LLVM이 다양한 언어와 호환될 수 있다는 것입니다.

RISC Zero는 RISC-V 아키텍처를 기반으로 한 시뮬레이터를 사용하여 프로그래머가 Rust, C/C++, Go와 같은 일반 언어로 zkVM을 위한 프로그램을 작성할 수 있게 하여, 응용 프로그램 논리가 Solidity로 표현할 수 있는 내용에 국한되지 않고 체인과 무관한 코드를 작성할 수 있도록 합니다.

1.2.4 Privacy zkVM------zk 친화적 + 네이티브 프라이버시 지원 시도는 생태계의 새로운 불꽃을 점화하다

대표 프로젝트: Aleo, Ola, Polygon Miden

블록체인은 공공 장부 시스템으로, 모든 거래가 체인에서 이루어지므로 주소나 계좌와 관련된 자산 정보의 상태 변화가 공개적이고 투명합니다. 따라서 확장성 솔루션 외에도 일부 블록체인 팀은 다음에 구현해야 할 핵심 기능이 프라이버시라고 믿고 있습니다.

Privacy zkVM은 zk 친화적 확장성 지원 기능 외에도, 본래의 프로그래밍 언어가 네이티브 프라이버시 기능을 지원하여 상위 응용 프로그램 개발자가 프라이버시 관련 dapp을 개발할 수 있게 하여, MEV 문제를 근본적으로 해결하고 사용자 데이터 소유권을 보장하는 등의 새로운 응용 시나리오와 거대한 서사를 가져올 것입니다. 물론 Privacy zkVM의 설계 복잡성은 더 큰 기술 팀이 구현해야 하며, 아마도 몇 년을 기다려야 실현될 수 있을 것입니다.

1.2.5 SVM------퇴조 후에도 여전히 잔재가 남아 있다: 성능 설계가 극대화된 실행 환경

대표 프로젝트: Eclipse Mainnet, Nitro, MakerDAO Chain(maybe)

SVM, 즉 Solana 가상 머신은 고성능 실행 환경을 주로 하며, 스마트 계약은 주로 Rust 언어로 작성됩니다. 단일 스레드 계산의 EVM 및 EOS WASM 실행 환경과 비교하여, Solana 트랜잭션이 실행 중 읽거나 쓸 모든 상태를 설명하도록 요구함으로써 SVM은 비중복 트랜잭션과 동일한 상태를 읽기만 하는 트랜잭션의 병렬 실행을 구현했습니다.

또한, 많은 거래 블록을 빠르게 검증/전파하기 위해 Solana 네트워크의 거래 검증 과정에서는 CPU 설계에서 일반적으로 사용되는 파이프라인 최적화를 광범위하게 사용했습니다. 이는 일련의 단계 처리에 대한 입력 데이터 흐름을 충족시키고 각 단계마다 다른 하드웨어가 담당하는 경우에 해당합니다. 전형적인 비유는 세탁기와 건조기로, 세탁/건조/접기를 순차적으로 여러 배치의 의류에 대해 수행합니다. 세탁은 건조 전에 이루어져야 하며, 건조 전에 접기가 이루어져야 하지만, 이 세 가지 작업은 각각 별도의 유닛에 의해 수행됩니다.

또한, SVM은 레지스터 기반이며 EVM보다 훨씬 작은 명령어 집합을 가지고 있어 SVM의 실행이 ZK에서 증명되기 더 쉽습니다. 낙관적 Rollup의 경우 레지스터 기반 설계는 체크포인트를 설정하는 데 더 쉽게 할 수 있습니다.

1.2.6 Fuel VM------buff가 가득 차다: UTXO 프레임워크 하의 병렬 가상 머신

대표 프로젝트: Fuel

Fuel VM은 EVM, Solana, WASM, BTC 및 Cosmos 기술 프레임워크를 기반으로 한 개선된 버전으로, EVM과 비교하여 다음과 같은 특징이 있습니다:

가장 독특한 점은 Fuel이 SVM과 유사하게 접근 목록(access lists)을 설정하고 비중복 트랜잭션의 병렬 실행 능력을 가지고 있을 뿐만 아니라 UTXO 모델을 채택하여 토큰 UTXO와 계약 UTXO를 분리하여 접근 효율성과 계산 처리량을 더욱 향상시켰다는 것입니다.

또한, Fuel VM은 자체 도메인 특화 언어 Sway와 지원 도구 체인 Forc를 통해 강력하고 원활한 개발자 경험을 제공합니다. 개발 환경은 Solidity와 같은 스마트 계약 언어의 장점을 유지하면서 Rust 도구 생태계에서 도입된 사례를 채택합니다.

미래에 Fuel VM은 Sway 언어 업그레이드 내용을 구현할 예정이며, 여기에는 바이트코드 크기와 관련된 컴파일러 최적화, Sway가 더 많은 백엔드를 지원(현재 EVM 백엔드가 개발 중), 추상화가 더욱 경제적이게 되고, 더 많은 응용 프로그램이 Solidity/Vyper에서 Sway로 이전하며, 컴파일러 수준의 재진입 분석 개선 등이 포함됩니다.

1.2.7 ESC VM------Ordinal/Smartweave의 후계자: 이더리움 위의 계산 레이어

대표 프로젝트: Ethscriptions Protocol

ESC VM, 즉 Ethscriptions Virtual Machine은 Ethscriptions Protocol이 제안한 스마트 계약 솔루션입니다. Ethscriptions Protocol 자체는 이더리움 체인에서 BTC Ordinal과 유사한 프로토콜로, 스마트 계약 및 L2와는 다른 저비용 대체 솔루션을 탐색하는 데 중점을 두고 있습니다.

Ethscriptions는 사용자가 매우 낮은 비용으로 스마트 계약 저장 및 실행을 우회할 수 있도록 하며, 미리 약정된 프로토콜 규칙을 통해 Tx의 calldata에서 계산을 수행합니다. 간단히 말해, 성공적인 이더리움 거래가 이루어지면, 해당 calldata가 규정된 유효한 데이터 규격을 충족하고 고유하며 "to" 주소가 0이 아니면 합법적으로 Ethscription이 생성된 것으로 간주됩니다. "from" 주소는 생성자, "to" 주소는 소유자가 됩니다.

설계 초기에는 각 Ethscription이 NFT 형태에 더 가까웠습니다. 예를 들어, 이미지 NFT는 이미지 내용을 Base64 형식으로 calldata에 직접 작성합니다:

최근에 인기를 끌고 있는 eths는 brc-20 프로토콜 규격을 참고하여 생성된 Ethscription입니다:

ESC VM이 도입한 스마트 계약은 "덤 계약"(Dumb Contract)이라고 불리며, 논리 계약으로 공개되지만 본래 EVM 형식으로 체인 상에서 상호작용하지 않습니다. 또한, ESC VM은 "컴퓨터 명령"이라는 특별한 형식을 추가하여, 이 형식으로 생성된 ethscriptions은 ESC VM이 인식하고 덤 계약과 상호작용합니다. 예를 들어, Deploy - 덤 계약 배포, Call - 덤 계약 호출 등이 있습니다.

이 솔루션은 몇 가지 한계가 있습니다. 첫째, "덤 계약"의 함수는 payable이 아니므로, 덤 계약을 통해 ETH를 보내려면 반드시 "브릿지 계약"을 통해야 하며, "브릿지 계약" 자체에는 권한 남용 및 자산 도용 위험이 존재합니다. 둘째, 생태계에는 진입 장벽이 있어 임의로 덤 계약을 생성할 수 없으며, 해당 코드가 Ethscriptions Protocol 거버넌스 제안을 통해 정의되어야 합니다.

결론적으로, ESC VM은 이더리움 L1을 데이터 저장 레이어로 사용하고, 그 위에 계약 논리, 계약 호출, 계약 호출 등의 데이터 내용을 이더리움 tx의 calldata 내에 구현하여 구축된 계산 레이어입니다. ESC VM의 글로벌 상태 합의는 ESC VM 클라이언트 합의로, Arweave의 SmartWeave 구현 논리에 근접하며, 단지 SmartWeave의 데이터 저장 레이어가 Arweave라는 점만 다릅니다.

1.2.8 Bit VM------흥미로운 연구 실험: BTC 위의 P2P 실행 채널

대표 프로젝트: ZeroSync

ZeroSync의 창립자 Robin Linus는 10월 9일 "BitVM: Compute Anything On Bitcoin"이라는 백서를 발표했습니다. 정확히 말하자면, 이는 VM이 아니라, 비트코인 체인에 계약이 저장되지만 계약의 논리 실행이 체인 외부에서 이루어지는 튜링 완전한 계산 공간을 만들고자 하는 시도입니다. 상대방이 계약을 위반했다고 판단되면, 본인은 체인 상에서 도전할 수 있으며, 상대방이 올바른 응답을 하지 못하면 본인은 계약 내의 모든 자금을 가져갈 수 있습니다.

장점은 비트코인 프로토콜을 수정할 필요 없이 비트코인에 튜링 완전성을 부여할 수 있다는 점입니다. 새로운 작업 코드가 필요 없고, 소프트 포크가 필요 없으며, 언제든지 적용할 수 있습니다.

단점도 분명합니다. 첫째, 두 당사자 간의 거래만 지원합니다(한쪽이 증명하고, 다른 쪽이 검증함). 둘째, 계약을 생성하려면 대량의 데이터를 생성하고 많은 거래를 미리 서명해야 하며, 체인 외부 정보 저장 비용이 막대합니다.

다음은 기술 논리에 대한 간단한 소개입니다:

(1) 점 입력 약속

점 입력 약속은 증명자가 논리 게이트에 대한 입력 값을 0 또는 1로 설정할 수 있게 하며, 이 약속에는 두 개의 해시 값 H(A0), H(A1)가 존재합니다. 증명자는 하나의 해시 원형을 공개해야 하며, 예를 들어 A0를 공개하면 입력 값을 0으로 설정하고, A1을 공개하면 입력 값을 1로 설정합니다.

(2) 논리 게이트 약속

입력 값이 설정되면, 비트코인의 AND, NOT 등의 작업 코드를 조합하여 비트코인 스크립트 내에서 임의의 논리 게이트를 조합할 수 있습니다.

(3) 이진 회로 약속

수억 개의 논리 게이트를 조합하여 이진 회로를 구성하면 튜링 완전성을 구현할 수 있습니다. 이 이진 회로를 비트코인 네트워크에 약속하기 위해서는 모든 논리 게이트를 Taproot 주소의 리프 노드에 넣어야 합니다.

(4) 도전 - 응답 단계

단순히 회로를 체인에 약속하는 것만으로는 충분하지 않으며, 거래 양측은 계약의 계산 결과가 올바른지 검증할 수 있는 효과적인 방법이 필요합니다. 이상적으로는 계약이 체인 외부에서 실행되고 양측이 협력적이며 결과에 대한 논쟁이 없으면 모두가 행복합니다. 그러나 거래 양측 간에 논쟁이 있을 경우, 도전 - 응답 단계로 들어가 계산 결과를 검증하고 비트코인 스크립트를 통해 채널 잔액을 강제로 분배해야 합니다.

따라서 BitVM은 어떤 Bitcoin Rollup이나 L2가 아니며, 완전한 가상 머신 실행 환경, 글로벌 상태, 복잡한 스마트 계약을 배포하기 위한 고급 언어를 갖추고 있지 않으며, 임의의 수의 사용자가 이러한 계약과 쉽게 상호작용할 수 있도록 허용하지 않습니다. 매우 일반적인 예로 설명하자면, BitVM은 모든 사람이 이동 단말기를 사용할 수 있는 시대에 방보다 큰 거대한 컴퓨터를 구축한 것과 같습니다.

1.2.9 MoveVM------Facebook Web2 유전자의 산물

대표 프로젝트: Aptos, Sui

Move는 안전한 스마트 계약을 작성하기 위한 프로그래밍 언어로, 처음에는 Facebook에서 개발하여 Diem 블록체인을 지원했습니다. Diem 블록체인 프로젝트가 중단된 후, Aptos와 Sui를 대표로 하는 프로젝트가 Move 언어의 사용을 이어갔습니다. Move 블록체인의 가장 큰 특징은 데이터 저장이 전역 저장소를 사용하며, 계좌 주소를 루트로 하는 트리로 구성되어 있어 각 주소가 자원 데이터와 모듈 코드를 저장할 수 있습니다.

Move에는 두 가지 다른 유형의 프로그램이 있습니다: 모듈과 스크립트. 모듈은 구조 유형을 정의하고 이러한 유형에 대한 작업을 수행하는 함수의 라이브러리입니다. 구조 유형은 Move의 전역 저장소 모델을 정의하며, 모듈 함수는 저장소를 업데이트하는 규칙을 정의합니다. 모듈 자체도 전역 저장소에 저장됩니다. 스크립트는 실행 파일의 진입점으로, 전통적인 언어의 main 함수와 유사하며, 전역 저장소에 게시되지 않은 임시 코드 조각입니다.

결론적으로, Move 모듈은 시스템 실행 파일이 실행 시 로드되는 동적 라이브러리 모듈과 유사하며, 스크립트는 주 프로그램과 유사합니다. 사용자는 자신의 스크립트를 작성하여 전역 저장소에 접근하고 모듈을 호출할 수 있으며, 모듈을 게시하거나 스크립트를 실행하는 것은 Move VM을 통해 이루어집니다.

1.3 생태계 발전 추세

EVM 네트워크 효과가 이렇게 강력한 지금, EVM 사용자가 비 EVM 체인 생태계로 이동하는 것은 신흥 블록체인 프로젝트의 최대 성장점이 되었으며, 이는 더 많은 Dapp의 조합 가능성을 가져오고, 더 큰 연결성이 향후 몇 년간 더 빠른 사용자 성장을 촉발할 수 있습니다.

1.3.1 지갑 프론트엔드 호환

EVM 사용자를 비 EVM 체인으로 유입하는 것은 항상 주요 장애물이었지만, 최근 출시된 Metamask Snap이 이 장애물을 허물 것입니다. EVM 사용자는 지갑을 전환할 필요 없이 MetaMask를 계속 사용할 수 있습니다. Drift의 오픈 소스 기여 덕분에 뛰어난 MetaMask Snap 구현이 구축되었으며, UX는 모든 EVM 체인과 상호작용하는 것과 동일합니다. Eclipse 메인넷 사용자는 MetaMask 내의 네이티브 애플리케이션과 상호작용하거나 Solana 네이티브 지갑(예: Salmon)을 사용할 수 있습니다.

1.3.2 VM 백엔드 호환

1.3.2.1 변환기 / 컴파일러

대표 프로젝트: Wrap

Warp는 Solidity-Cairo 변환기로, 현재 이더리움의 유명한 인프라 팀인 Nethermind에 의해 개발이 완료되었습니다. Warp는 Solidity 코드를 Cairo로 변환할 수 있지만, 변환된 Cairo 프로그램은 종종 수정 및 Cairo 특성(예: 내장 함수 호출, 메모리 최적화 등)을 추가해야 실행 효율성을 극대화할 수 있습니다.

1.3.2.2 바이트코드 해석기 / VM 호환 레이어

대표 프로젝트: Kakarot, Neon EVM

Kakarot은 Starknet에 배포된 Cairo로 작성된 EVM 바이트코드 해석기로, Cairo 스마트 계약의 형태로 EVM의 스택, 메모리, 실행 등을 시뮬레이션합니다. 코드 변환에 비해 Kakarot은 EVM 뒤의 Opcode와 Pre-compile을 개별적으로 구현하고, Account Registry, Blockhash Registry 등의 구성 요소를 구축하여 계좌 주소 매핑, 블록 정보 수집 등의 추가 처리를 수행하여 kakarot의 원주율 호환성을 높였습니다.

Neon EVM은 스마트 계약으로 실행되는 EVM으로, 모든 SVM 체인에 배포할 수 있습니다. Eclipse 메인넷은 SVM을 실행 환경으로 사용하지만, Neon EVM을 통해 완전한 EVM 호환성(여기에는 EVM 바이트코드 지원 및 이더리움 JSON-RPC 포함)을 가져오며, 단일 스레드 EVM보다 처리량이 더 높습니다. 또한 각 Neon EVM 인스턴스는 자체 로컬 수수료 시장을 가지고 있으며, 이는 특정 블록 높이에서 단일 계약 계좌 상호작용과 관련된 계산 단위에 상한이 존재함을 의미합니다(블록 계산 단위의 1/4). 따라서 사용자는 특정 핫 계약 상호작용이나 블록이 가득 찼을 때만 우선 수수료를 지불하면 됩니다. 이러한 의미에서, 응용 프로그램이 자신의 계약을 배포하면 거의 응용 프로그램 체인의 이점을 얻을 수 있으며, 특정 계약 상호작용 tx가 혼잡할 때 전체 네트워크 사용자 경험, 안전성 또는 유동성에 미치는 피해를 줄일 수 있습니다.