확장의 미래: Web3 병렬 컴퓨팅 트랙 전경도

2025.05.20

확장의 미래: Web3 병렬 컴퓨팅 트랙 전경도

Web3 병렬 컴퓨팅에 대한 심도 있는 해설.

2025.05.20 - 02:16:35

扩容并行计算

Web3 심층 보도에 집중하고 흐름을 통찰

Web3 병렬 컴퓨팅에 대한 심도 있는 해설.

글: 0xjacobzhao 및 ChatGPT 4o

블록체인의 「불가능한 삼각형」(Blockchain Trilemma)인 「보안성」, 「탈중앙화」, 「확장성」은 블록체인 시스템 설계에서 본질적인 트레이드오프를 드러내며, 즉 블록체인 프로젝트가 「극도의 보안성, 누구나 참여 가능, 고속 처리」를 동시에 달성하기는 어렵다는 것을 의미한다. 「확장성」이라는 영원한 주제에 대해 현재 시장의 주류 블록체인 확장 솔루션은 패러다임에 따라 다음과 같이 구분된다.

실행 강화형 확장: 기존 실행 능력을 향상시키는 방식으로, 예를 들어 병렬 처리, GPU, 멀티코어 활용 등
상태 분리형 확장: 상태/샤드를 수평적으로 분할하는 방식으로, 예를 들어 샤딩, UTXO, 다중 서브넷 등
체인 외부 아웃소싱형 확장: 실행을 체인 외부로 이전하는 방식으로, 예를 들어 롤업(Rollup), 코프로세서(Coprocessor), DA(Data Availability)
구조 분해형 확장: 아키텍처 모듈화 및 협업 실행 방식으로, 예를 들어 모듈러 체인, 공유 정렬기(sequencer), 롤업 메시(Rollup Mesh)
비동기 동시형 확장: 액터 모델, 프로세스 격리, 메시지 기반 처리 방식으로, 예를 들어 에이전트(Agent), 멀티스레드 비동기 체인

블록체인 확장 솔루션에는 체인 내 병렬 컴퓨팅, 롤업, 샤딩, DA 모듈, 모듈화 구조, 액터 시스템, zk 증명 압축, Stateless 아키텍처 등이 포함되며, 실행, 상태, 데이터, 구조 여러 계층을 포괄하며 「다중 계층 협업, 모듈 조합」이 가능한 종합적 확장 체계이다. 본 글에서는 병렬 컴퓨팅을 중심으로 한 확장 방식을 중점적으로 소개한다.

체인 내 병렬 컴퓨팅(intra-chain parallelism)은 블록 내 거래/명령의 병렬 실행에 집중한다. 병렬 메커니즘에 따라 이러한 확장 방식은 다섯 가지 범주로 나눌 수 있으며, 각각은 성능 추구, 개발 모델, 아키텍처 철학이 다르며, 점차 세분화된 병렬 단위, 더 강력한 병렬 강도, 더 높은 스케줄링 복잡도, 그리고 더 높은 프로그래밍 및 구현 난이도를 특징으로 한다.

계정 수준 병렬(Account-level): 대표 프로젝트 Solana
오브젝트 수준 병렬(Object-level): 대표 프로젝트 Sui
거래 수준 병렬(Transaction-level): 대표 프로젝트 Monad, Aptos
호출 수준 / 마이크로 VM 병렬(Call-level / MicroVM): 대표 프로젝트 MegaETH
명령어 수준 병렬(Instruction-level): 대표 프로젝트 GatlingX

체인 외부 비동기 동시 모델은 액터 기반 에이전트 시스템(Agent / Actor Model)을 중심으로 하며, 이는 다른 유형의 병렬 컴퓨팅 패러다임이며, 크로스체인/비동기 메시지 시스템(블록 동기 모델 아님)으로, 각 에이전트가 독립적으로 실행되는 「지능형 프로세스」로서, 비동기 메시지, 이벤트 기반, 동기화 스케줄링 없이 병렬 처리를 수행한다. 대표 프로젝트로 AO, ICP, Cartesi 등이 있다.

흔히 알고 있는 롤업 또는 샤딩 확장 솔루션은 시스템 수준 동시 메커니즘에 속하며, 체인 내 병렬 컴퓨팅에 포함되지 않는다. 이들은 「여러 체인/실행 도메인을 병렬로 실행」하여 확장을 달성하지, 개별 블록/가상머신 내부의 병렬도를 향상시키지는 않는다. 이러한 확장 방식은 본문의 논의 대상은 아니지만, 여전히 아키텍처 철학 비교에 사용될 것이다.

이, EVM 계열 병렬 강화 체인: 호환성 안에서 성능 한계 돌파

이더리움의 직렬 처리 아키텍처는 지금까지 샤딩, 롤업, 모듈화 아키텍처 등 다양한 확장 시도를 거쳤으나, 실행 계층의 처리량 병목 현상은 근본적으로 해결되지 않았다. 그러나 동시에 EVM과 Solidity는 여전히 가장 많은 개발자 기반과 생태계 잠재력을 가진 스마트 컨트랙트 플랫폼이다. 따라서 EVM 계열 병렬 강화 체인은 생태계 호환성과 실행 성능 향상을 동시에 고려하는 핵심 경로로서 새로운 확장 진화의 중요한 방향이 되고 있다. Monad와 MegaETH는 이 방향에서 가장 대표적인 프로젝트로, 각각 지연 실행과 상태 분해를 출발점으로 고병렬, 고처리량 환경을 위한 EVM 병렬 처리 아키텍처를 구축하고 있다.

Monad의 병렬 컴퓨팅 메커니즘 분석

Monad는 이더리움 가상머신(EVM)을 재설계한 고성능 레이어1 블록체인으로, 파이프라이닝(Pipelining)이라는 기본 병렬 개념을 기반으로, 합의 계층에서 비동기 실행(Asynchronous Execution), 실행 계층에서 낙관적 병렬 실행(Optimistic Parallel Execution)을 실현한다. 또한 합의 및 저장 계층에서 고성능 BFT 프로토콜(MonadBFT)과 전용 데이터베이스 시스템(MonadDB)을 도입하여 엔드투엔드 최적화를 달성한다.

Pipelining: 다단계 파이프라인 병렬 실행 메커니즘

Pipelining은 Monad의 병렬 실행 기본 개념으로, 핵심 아이디어는 블록체인 실행 프로세스를 여러 독립 단계로 분할하고 이를 병렬 처리하여 입체적인 파이프라인 구조를 형성하는 것이다. 각 단계는 독립된 스레드 또는 코어에서 실행되며, 블록 간 동시 처리를 통해 처리량 증가와 지연 감소를 달성한다. 이러한 단계에는 거래 제안(Propose), 합의 도달(Consensus), 거래 실행(Execution), 블록 제출(Commit)이 포함된다.

Asynchronous Execution: 합의-실행 비동기 분리

기존 체인에서는 거래 합의와 실행이 일반적으로 동기 프로세스로 이루어지며, 이러한 직렬 모델은 성능 확장을 심각하게 제한한다. Monad는 「비동기 실행」을 통해 합의 계층, 실행 계층, 저장 계층의 비동기를 실현함으로써 블록 생성 시간(block time)과 확인 지연을 크게 줄이고, 시스템의 탄력성을 높이며 처리 프로세스를 세분화하고 자원 활용률을 향상시킨다.

핵심 설계:

합의 과정(합의 계층)은 거래 순서만 결정하며, 스마트 컨트랙트 로직을 실행하지 않는다.
실행 과정(실행 계층)은 합의 완료 후 비동기적으로 트리거된다.
합의 완료 후 바로 다음 블록 합의 프로세스로 진입하며, 실행 완료를 기다리지 않는다.

Optimistic Parallel Execution: 낙관적 병렬 실행

기존 이더리움은 상태 충돌을 방지하기 위해 거래 실행에 엄격한 직렬 모델을 적용한다. 반면 Monad는 「낙관적 병렬 실행」 전략을 채택하여 거래 처리 속도를 크게 향상시킨다.

실행 메커니즘:

Monad는 대부분의 거래가 상태 충돌이 없다고 가정하고 모든 거래를 낙관적으로 병렬 실행한다.
동시에 「충돌 탐지기(Conflict Detector)」를 운영하여 거래 간에 동일한 상태(읽기/쓰기 충돌)에 접근했는지 모니터링한다.
충돌이 탐지되면 충돌 거래를 직렬화하여 다시 실행하여 상태의 정확성을 보장한다.

Monad는 호환성 경로를 선택했다. EVM 규칙을 최대한 적게 변경하며, 실행 중에 상태 쓰기를 연기하고 동적 충돌 탐지를 통해 병렬화를 실현하는 것으로, 마치 고성능 버전의 이더리움처럼 작동하며, 성숙도가 높고 EVM 생태계 이전이 용이하다. 이는 EVM 세계의 병렬 가속기라고 할 수 있다.

MegaETH의 병렬 컴퓨팅 메커니즘 분석

Monad의 L1 포지셔닝과 달리, MegaETH는 EVM 호환 모듈화 고성능 병렬 실행 계층으로 포지셔닝되며, 독립된 L1 공개체인이거나 이더리움 상의 실행 강화 계층(Execution Layer) 혹은 모듈화 구성 요소로도 작동할 수 있다. 그 핵심 설계 목표는 계정 로직, 실행 환경, 상태를 독립적으로 스케줄링 가능한 최소 단위로 격리 분해하여 체인 내 고병렬 실행과 저지연 응답 능력을 실현하는 것이다. MegaETH가 제시한 핵심 혁신은 Micro-VM 아키텍처 + State Dependency DAG(방향성 무순환 상태 의존 그래프) 및 모듈화 동기화 메커니즘이며, 이들이 함께 「체인 내 스레드화」를 위한 병렬 실행 체계를 구성한다.

Micro-VM(마이크로 가상머신) 아키텍처: 계정이 곧 스레드

MegaETH는 「각 계정마다 하나의 마이크로 가상머신(Micro-VM)」을 두는 실행 모델을 도입하여, 실행 환경을 「스레드화」하고 병렬 스케줄링을 위한 최소 격리 단위를 제공한다. 이러한 VM들은 비동기 메시지 통신(Asynchronous Messaging)을 통해 연결되며, 동기 호출이 아니다. 많은 수의 VM이 독립적으로 실행되고 저장되며, 자연스럽게 병렬화된다.

State Dependency DAG: 의존성 그래프 기반 스케줄링 메커니즘

MegaETH는 계정 상태 접근 관계 기반의 DAG 스케줄링 시스템을 구축하며, 시스템은 전역 의존성 그래프(Dependency Graph)를 실시간으로 유지한다. 매번 거래가 어떤 계정을 수정하고 어떤 계정을 읽었는지를 모두 의존성 관계로 모델링한다. 충돌이 없는 거래는 직접 병렬 실행되며, 의존성이 있는 거래는 위상 순서에 따라 직렬화하거나 지연되어 스케줄링된다. 의존성 그래프는 병렬 실행 중 상태 일관성과 중복 쓰기 방지를 보장한다.

비동기 실행 및 콜백 메커니즘

MegaETH는 비동기 프로그래밍 패러다임 위에 구축되며, 액터 모델과 유사한 비동기 메시지 전달을 통해 기존 EVM의 직렬 호출 문제를 해결한다. 스마트 컨트랙트 호출은 비동기적이며(재귀 실행 아님), 컨트랙트 A → B → C 호출 시 각 호출이 비동기화되어 차단 대기 없이 진행된다. 호출 스택은 비동기 호출 그래프(Call Graph)로 전개되며, 거래 처리는 비동기 그래프 순회 + 의존성 판별 + 병렬 스케줄링을 의미한다.

요약하자면, MegaETH는 기존 EVM의 단일 스레드 상태 머신 모델을 깨뜨리고, 계정 단위로 마이크로 가상머신을 캡슐화하며, 상태 의존 그래프를 통해 거래 스케줄링을 하고, 동기 호출 스택을 비동기 메시지 메커니즘으로 대체한다. 이는 「계정 구조 → 스케줄링 아키텍처 → 실행 프로세스」 전 범위에 걸쳐 재설계된 병렬 컴퓨팅 플랫폼으로, 차세대 고성능 온체인 시스템 구축에 패러다임 수준의 새로운 아이디어를 제공한다.

MegaETH는 재구성 경로를 선택했다. 계정과 컨트랙트를 완전히 독립된 VM으로 추상화하여 비동기 실행 스케줄링을 통해 극한의 병렬 잠재력을 해방한다. 이론상 MegaETH의 병렬 상한은 더 높지만, 복잡도 통제도 더 어려우며, 마치 이더리움 개념 하의 초분산형 운영체제 같다.

Monad와 MegaETH의 설계 철학은 샤딩(Sharding)과 상당히 다르다. 샤딩은 블록체인을 여러 독립 서브체인(샤드 Shards)으로 수평 분할하여 각 서브체인이 일부 거래와 상태를 담당함으로써 단일 체인 제약을 네트워크 계층에서 확장하는 것이고, 반면 Monad와 MegaETH는 단일 체인의 완전성을 유지하면서 실행 계층에서만 수평 확장을 이루며, 단일 체인 내부에서 극한의 병렬 실행 최적화로 성능을 돌파한다. 이 둘은 블록체인 확장 경로에서의 수직 강화와 수평 확장을 각각 대표한다.

Monad와 MegaETH 등의 병렬 컴퓨팅 프로젝트는 주로 처리량 최적화 경로에 집중하며, 체인 내 TPS 향상을 핵심 목표로 하며, 지연 실행(Deferred Execution)과 마이크로 가상머신(Micro-VM) 아키텍처를 통해 거래 수준 또는 계정 수준의 병렬 처리를 실현한다. 반면 Pharos Network는 모듈화되고 전 스택 병렬화된 L1 블록체인 네트워크로서, 핵심 병렬 컴퓨팅 메커니즘은 「Rollup Mesh」라고 불린다. 이 아키텍처는 메인넷과 특수 처리 네트워크(SPNs)의 협업을 통해 다중 가상머신 환경(EVM 및 Wasm)을 지원하며, 제로지식 증명(ZK), 신뢰 실행 환경(TEE) 등의 첨단 기술을 통합한다.

Rollup Mesh 병렬 컴퓨팅 메커니즘 분석:

전 생애주기 비동기 파이프라인 처리(Full Lifecycle Asynchronous Pipelining): Pharos는 거래의 각 단계(예: 합의, 실행, 저장)를 분리하고 비동기 처리 방식을 채택하여 각 단계가 독립적으로 병렬 처리되도록 함으로써 전체 처리 효율을 높인다.
이중 가상머신 병렬 실행(Dual VM Parallel Execution): Pharos는 EVM과 WASM 두 가지 가상머신 환경을 지원하여 개발자가 요구에 따라 적절한 실행 환경을 선택할 수 있게 한다. 이 이중 VM 아키텍처는 시스템 유연성을 높일 뿐 아니라 병렬 실행을 통해 거래 처리 능력을 향상시킨다.
특수 처리 네트워크(SPNs): SPNs는 Pharos 아키텍처의 핵심 구성 요소로, 모듈화된 서브네트워크와 유사하며 특정 유형의 작업이나 애플리케이션을 전담 처리한다. SPNs를 통해 Pharos는 자원의 동적 할당과 작업의 병렬 처리를 실현하며, 시스템의 확장성과 성능을 더욱 강화한다.
모듈화 합의 및 리스테이킹 메커니즘(Modular Consensus & Restaking): Pharos는 유연한 합의 메커니즘을 도입하여 다양한 합의 모델(PBFT, PoS, PoA 등)을 지원하며, 리스테이킹 프로토콜(Restaking)을 통해 메인넷과 SPNs 간의 보안 공유 및 자원 통합을 실현한다.

또한 Pharos는 다중 버전 Merkle 트리, 델타 인코딩(Delta Encoding), 버전 주소 지정(Versioned Addressing), ADS 푸시다운(ADS Pushdown) 기술을 통해 저장 엔진 하부에서 실행 모델을 재구성하며, 원생 블록체인 고성능 저장 엔진 Pharos Store를 출시하여 고처리량, 저지연, 강력한 검증이 가능한 온체인 처리 능력을 실현한다.

결론적으로, Pharos의 Rollup Mesh 아키텍처는 모듈화 설계와 비동기 처리 메커니즘을 통해 고성능 병렬 컴퓨팅 능력을 실현하며, Pharos는 크로스 롤업 병렬의 스케줄링 조정자로서 「체인 내 병렬」의 실행 최적화기가 아니라, SPNs를 통해 이종 맞춤형 실행 작업을 수용한다.

Monad, MegaETH, Pharos의 병렬 실행 아키텍처 외에도, 시장에서는 EVM 병렬 컴퓨팅에 GPU 가속을 적용하는 경로를 탐색하는 프로젝트들도 존재하며, 이는 EVM 병렬 생태계의 중요한 보완 및 선도적 실험이다. 여기서 Reddio와 GatlingX는 두 가지 대표적인 방향이다.

Reddio는 zk롤업과 GPU 병렬 실행 아키텍처를 결합한 고성능 플랫폼으로, 핵심은 EVM 실행 프로세스를 재구성하여 멀티스레드 스케줄링, 비동기 상태 저장, GPU 가속 거래 배치 처리를 통해 실행 계층의 원시 병렬화를 실현하는 것이다. 이는 거래 수준 + 연산 수준(멀티스레드 opcode 실행)의 병렬 입자도를 갖춘다. 이 설계는 멀티스레드 배치 처리 실행, 비동기 상태 로딩, GPU 병렬 처리 거래 로직(CUDA-Compatible Parallel EVM)을 도입한다. Monad/MegaETH와 마찬가지로 Reddio 역시 실행 계층의 병렬 처리에 집중하나, GPU 병렬 아키텍처를 통해 실행 엔진을 재구성하며, 고처리량 및 계산 집약형 시나리오(예: AI 추론)를 위해 설계되었다. 현재 SDK를 출시하여 통합 가능한 실행 모듈을 제공 중이다.
GatlingX는 자신을 「GPU-EVM」이라 칭하며, 더 급진적인 아키텍처를 제안하며, 기존 EVM 가상머신의 「명령어 수준 직렬 실행」 모델을 GPU 원시 병렬 환경으로 이전하려 한다. 핵심 메커니즘은 EVM 바이트코드를 동적으로 CUDA 병렬 작업으로 컴파일하여 GPU 멀티코어로 명령어 스트림을 실행함으로써 EVM의 순차적 병목을 가장 하부에서 깨뜨리는 것이다. 이는 명령어 수준(Instruction-Level Parallelism, ILP)의 병렬 입자도를 갖춘다. Monad/MegaETH의 「거래 수준/계정 수준」 병렬 입자도와 비교해, GatlingX의 병렬 메커니즘은 명령어 수준 최적화 경로에 속하며, 가상머신 엔진의 하부 재구성에 더 근접하다. 현재 개념 단계에 있으며 백서와 아키텍처 스케치를 발표했으나, SDK나 메인넷은 아직 없다.

Artela는 또 다른 차별화된 병렬 설계 철학을 제안한다. EVM++ 아키텍처와 WebAssembly(WASM) 가상머신을 도입하여 개발자가 EVM 호환성을 유지하면서 Aspect 프로그래밍 모델을 이용해 체인 상에서 동적으로 확장 프로그램을 추가하고 실행할 수 있도록 한다. 함수/확장(Function/Extension) 호출 수준을 최소 병렬 단위로 삼으며, EVM 컨트랙트 실행 중 Extension 모듈(마치 「플러그인 가능한 미들웨어」)을 주입하여 로직 분리, 비동기 호출, 모듈 수준 병렬 실행을 실현한다. 실행 계층의 조합 가능성과 모듈화 아키텍처에 더 주목한다. 이는 미래 복잡 다중 모듈 애플리케이션에 새로운 아이디어를 제공한다.

삼, 원시 병렬 아키텍처 체인: VM의 실행 본체 재구성

이더리움의 EVM 실행 모델은 설계 초기부터 「거래 전순서 + 직렬 실행」의 단일 스레드 아키텍처를 채택하여 네트워크 내 모든 노드가 상태 변경에 대해 결정성과 일관성을 보장하도록 했다. 그러나 이 아키텍처는 성능상 천연 병목이 존재하여 시스템 처리량과 확장성을 제한한다. 이에 비해 Solana(SVM), MoveVM(Sui, Aptos), Cosmos SDK 기반 Sei v2 등 원시 병렬 컴퓨팅 아키텍처 체인은 하부 설계부터 병렬 실행을 위해 설계되었으며 다음과 같은 장점을 갖는다.

상태 모델이 자연스럽게 분리됨: Solana는 계정 잠금 선언 메커니즘을 채택하고, MoveVM은 오브젝트 소유권 모델을 도입하며, Sei v2는 거래 유형 분류를 기반으로 정적 충돌 판단을 실현하여 거래 수준 동시 스케줄링을 지원한다.
가상머신이 동시성에 최적화됨: Solana의 Sealevel 엔진은 원시적으로 다중 스레드 실행을 지원하며, MoveVM은 정적 동시성 그래프 분석이 가능하고, Sei v2는 다중 스레드 매칭 엔진과 병렬 VM 모듈을 통합한다.

물론 이러한 원시 병렬 체인은 생태계 호환성 측면에서 도전에 직면한다. 비EVM 아키텍처는 일반적으로 새로운 개발 언어(예: Move, Rust) 및 도구 체인을 필요로 하며, 개발자 입장에서 일정한 이전 비용이 발생한다. 또한 개발자는 상태 접근 모델, 동시성 제한, 오브젝트 생명주기 등 일련의 새로운 개념을 이해해야 하며, 이해 장벽과 개발 패러다임에 더 높은 요구를 제기한다.

3.1 Solana 및 SVM 계열의 Sealevel 병렬 엔진 원리

Solana의 Sealevel 실행 모델은 계정 병렬 스케줄링 메커니즘으로, 체인 내 병렬 거래 실행을 실현하는 핵심 엔진이다. 「계정 선언 + 정적 스케줄링 + 다중 스레드 실행」 메커니즘을 통해 스마트 컨트랙트 수준의 고성능 동시성을 실현한다. Sealevel은 블록체인 분야에서 실제 운영 환경에서 체인 내 동시 스케줄링을 성공적으로 구현한 최초의 실행 모델이며, 그 아키텍처 사상은 이후 많은 병렬 컴퓨팅 프로젝트에 영향을 미쳤으며, 고성능 레이어1 병렬 설계의 참고 패러다임이다.

핵심 메커니즘:

1. 명시적 계정 접근 선언(Account Access Lists): 각 거래 제출 시 관련 계정(읽기/쓰기)을 반드시 선언해야 하며, 시스템은 이를 기반으로 거래 간 상태 충돌 여부를 판단한다.

2. 충돌 탐지 및 다중 스레드 스케줄링

두 거래의 접근 계정 집합이 교집합 없음 → 병렬 실행 가능;
충돌 존재 → 의존 순서에 따라 직렬 실행;
스케줄러는 의존성 그래프를 기반으로 거래를 서로 다른 스레드에 할당한다.

3. 독립 실행 컨텍스트(Program Invocation Context): 각 컨트랙트 호출은 격리된 컨텍스트에서 실행되며 공유 스택 없이 크로스 호출 간섭을 방지한다.

Sealevel은 Solana의 병렬 실행 스케줄링 엔진이며, SVM은 Sealevel 위에 구축된 스마트 컨트랙트 실행 환경(BPF 가상머신 사용)이다. 이 둘은 함께 Solana 고성능 병렬 실행 체계의 기술적 기반을 구성한다.

Eclipse는 Solana VM을 모듈화된 체인(예: Ethereum L2 또는 Celestia)에 배포하는 프로젝트로, Solana의 병렬 실행 엔진을 롤업 실행 계층으로 활용한다. Eclipse는 Solana의 실행 계층(Sealevel + SVM)을 Solana 메인넷에서 분리하여 모듈화된 아키텍처로 이전하는 최초의 프로젝트 중 하나이며, Solana의 「강력한 동시 실행 모델」을 Execution Layer-as-a-Service 형태로 모듈화하여 출력하므로 Eclipse 역시 병렬 컴퓨팅 대분류에 속한다.

Neon의 경로는 다르다. Neon은 EVM을 SVM/Sealevel 환경에서 실행시키는 것이다. Solidity로 컨트랙트를 개발하고 SVM 환경에서 실행할 수 있는 EVM 호환 런타임 계층을 구축하지만, 스케줄링 실행은 SVM+Sealeve를 사용한다. Neon은 모듈화된 블록체인(Modular Blockchain) 범주에 더 가까우며 병렬 컴퓨팅 혁신을 강조하지 않는다.

요약하면, Solana 및 SVM은 Sealevel 실행 엔진에 의존하며, Solana의 운영체제 스타일 스케줄링 철학은 커널 스케줄러와 유사하며 실행이 빠르지만 유연성은 상대적으로 낮다. 이는 원시 고성능, 병렬 컴퓨팅형 공개체인이다.

3.2 MoveVM 아키텍처: 리소스 및 오브젝트 기반

MoveVM은 체인 상 리소스 보안과 병렬 실행을 위해 설계된 스마트 컨트랙트 가상머신으로, 핵심 언어 Move는 원래 Meta(구 Facebook)가 Libra 프로젝트를 위해 개발하였으며 「리소스는 오브젝트다」라는 개념을 강조한다. 모든 체인 상 상태는 오브젝트로 존재하며 명확한 소유권과 생명주기를 갖는다. 이를 통해 MoveVM은 컴파일 시점에 거래 간 상태 충돌 여부를 분석하여 오브젝트 수준 정적 병렬 스케줄링을 실현하며, Sui와 Aptos 등의 원시 병렬 공개체인에서 널리 사용된다.

Sui의 오브젝트 소유권 모델

Sui의 병렬 컴퓨팅 능력은 독특한 상태 모델링 방식과 언어 수준 정적 분석 메커니즘에 기인한다. 기존 블록체인의 전역 상태 트리와 달리, Sui는 「오브젝트」 기반의 상태 모델(Object-centric model)을 구축하며 MoveVM의 선형 타입 시스템과 결합하여 병렬 스케줄링을 컴파일 시점에 결정 가능한 프로세스로 만든다.

오브젝트 모델(Object Model)은 Sui 병렬 아키텍처의 기반이다. Sui는 체인 상 모든 상태를 독립적인 오브젝트(Object)로 추상화하며, 각 오브젝트는 고유 ID, 명확한 소유자(계정 또는 컨트랙트), 타입 정의를 갖는다. 이 오브젝트들은 상태를 공유하지 않으며 천연 격리성을 갖는다. 컨트랙트 호출 시 관련 오브젝트 집합을 명시적으로 선언해야 하며, 기존 체인의 「전역 상태 트리」 상태 결합 문제를 회피한다. 이 설계는 체인 상 상태를 여러 독립 단위로 분할하여 동시 실행이 구조적으로 가능한 스케줄링 전제를 마련한다.
정적 소유권 분석(Static Ownership Analysis)은 Move 언어의 선형 타입 시스템 지원 하에 구현된 컴파일 시점 분석 메커니즘이다. 시스템이 거래 실행 전에 오브젝트 소유권을 통해 어떤 거래가 상태 충돌을 일으키지 않을지를 추론하여 병렬 실행으로 배치할 수 있게 한다. 기존 런타임 충돌 탐지 및 롤백과 비교해 Sui의 정적 분석 메커니즘은 실행 효율을 높이는 동시에 스케줄링 복잡도를 크게 낮추며, 고처리량, 결정적 병렬 처리 능력을 실현하는 핵심이다.

Sui는 오브젝트 단위로 상태 공간을 분할하고 컴파일 시점 소유권 분석을 결합하여 비용이 낮고 롤백이 필요 없는 오브젝트 수준 병렬 실행을 실현한다. 기존 체인의 직렬 실행 또는 런타임 탐지와 비교해 Sui는 실행 효율, 시스템 결정성, 자원 활용률 측면에서 현저한 향상을 달성한다.

Aptos의 Block-STM 실행 메커니즘

Aptos는 Move 언어 기반의 고성능 레이어1 블록체인으로, 그 병렬 실행 능력은 자체 개발한 Block-STM(Block-level Software Transactional Memory) 프레임워크에 기반한다. Sui가 「컴파일 시점 정적 병렬」 전략을 선호하는 것과 달리, Block-STM은 「런타임 낙관적 동시성 + 충돌 롤백」의 동적 스케줄링 메커니즘으로, 복잡한 의존관계를 가진 거래 집합 처리에 적합하다.

Block-STM은 블록 내 거래 실행을 세 단계로 나눈다.

낙관적 동시 실행(Speculative Execution): 모든 거래는 기본적으로 충돌이 없다고 가정하며, 시스템은 거래를 여러 스레드에 병렬 스케줄링하여 동시 실행을 시도하고, 접근한 계정 상태(읽기 집합/쓰기 집합)를 기록한다.
충돌 탐지 및 검증(Validation Phase): 시스템은 실행 결과를 검증한다. 두 거래가 읽기-쓰기 충돌이 있으면(예: Tx1이 Tx2가 쓴 상태를 읽음), 그 중 하나를 롤백한다.
충돌 거래 롤백 재시도(Retry Phase): 충돌 거래는 다시 스케줄링되어 실행되며, 의존 관계가 해결될 때까지 반복하여 결국 모든 거래가 유효하고 결정적인 상태 제출 시퀀스를 형성한다.

Block-STM은 「낙관적 병렬 + 롤백 재시도」의 동적 실행 모델로, 상태 집약형, 논리가 복잡한 체인 상 거래 배치 처리 시나리오에 적합하며, Aptos가 고범용성, 고처리량 공개체인을 구축하는 병렬 컴퓨팅 핵심이다.

Solana는 공학 스케줄링 파로, 마치 「운영체제 커널」 같아서 명확한 상태 경계, 제어 가능한 고빈도 거래에 적합하며 하드웨어 엔지니어 스타일로 하드웨어처럼 체인을 운용한다(Hardware-grade parallel execution). Aptos는 시스템 오류 허용 파로, 마치 「데이터베이스 동시성 엔진」 같아서 상태 결합이 강하고 호출 체인이 복잡한 컨트랙트 체계에 적합하다. Sui는 컴파일 보안 파로, 마치 「리소스형 스마트 언어 플랫폼」 같아서 자산 분리, 조합이 명확한 체인 상 애플리케이션에 적합하다. Aptos와 Sui는 프로그래밍 언어 엔지니어처럼 소프트웨어처럼 안전하게 체인을 운용한다(Software-grade resource security). 이 셋은 Web3 병렬 컴퓨팅이 서로 다른 철학 아래 기술적으로 실현된 경로를 대표한다.

3.3 Cosmos SDK 병렬 확장형

Sei V2는 Cosmos SDK 기반의 고성능 거래형 공개체인으로, 그 병렬 능력은 두 가지 측면에서 나타난다: 다중 스레드 매칭 엔진(Parallel Matching Engine) 및 가상머신 계층의 병렬 실행 최적화. 이는 고빈도, 저지연 체인 상 거래 시나리오(예: 오더북 DEX, 체인 상 거래소 인프라 등)를 위해 설계되었다.

핵심 병렬 메커니즘:

병렬 매칭 엔진: Sei V2는 주문 매칭 로직에 다중 스레드 실행 경로를 도입하여 호가창과 매칭 로직을 스레드 수준으로 분할하여 여러 시장(trading pairs) 간 매칭 작업을 병렬 처리할 수 있도록 하여 단일 스레드 병목을 피한다.
가상머신 수준 동시성 최적화: Sei V2는 동시 실행 능력을 갖춘 CosmWasm 실행 환경을 구축하여 상태 충돌이 없는 경우 일부 컨트랙트 호출을 병렬 실행할 수 있으며, 거래 유형 분류 메커니즘과 결합하여 더 높은 처리량 제어를 실현한다.
병렬 합의와 실행 계층 스케줄링 연계:所谓「Twin-Turbo」 합의 메커니즘을 도입하여 합의 계층과 실행 계층 간 처리량 분리를 강화하고 전체 블록 처리 효율을 향상시킨다.

3.4 UTXO 모델 재구성자 Fuel

Fuel은 이더리움 모듈화 아키텍처 기반의 고성능 실행 계층으로, 핵심 병렬 메커니즘은 개선된 UTXO 모델(Unspent Transaction Output)에 기반한다. 이더리움의 계정 모델과 달리, Fuel은 자산과 상태를 표현하기 위해 UTXO 구조를 사용하며, 이 모델은 천연적으로 상태 격리성을 가지며 어느 거래들이 안전하게 병렬 실행될 수 있는지 판단하기 쉬운 장점이 있다. 또한 Fuel은 자체 개발한 스마트 컨트랙트 언어 Sway(Rust와 유사)를 도입하고 정적 분석 도구와 결합하여 거래 실행 전에 입력 충돌을 결정할 수 있어 효율적이고 안전한 거래 수준 병렬 스케줄링을 실현한다. 이는 성능과 모듈화를 모두 고려한 EVM 대체 실행 계층이다.

사, 액터 모델: 스마트 에이전트 동시 실행의 새로운 패러다임

액터 모델은 스마트 에이전트 프로세스(Agent 또는 Process)를 단위로 하는 병렬 실행 패러다임으로, 기존 체인의 전역 상태 동기 계산(Solana/Sui/Monad 등의 「체인 내 병렬 컴퓨팅」 시나리오)과 다르게 각 에이전트가 독립 상태와 행동을 가지며 비동기 메시지를 통해 통신 및 스케줄링을 강조한다. 이 아키텍처 하에서 체인 상 시스템은 서로 분리된 다수의 프로세스가 동시 실행되며 매우 높은 확장성과 비동기 오류 허용 능력을 갖는다. 대표 프로젝트로 AO(Arweave AO), ICP(Internet Computer), Cartesi가 있으며, 이들은 블록체인을 실행 엔진에서 「체인 상 운영체제」로 진화시키며 AI Agent, 다중 작업 상호작용, 복잡한 로직 오케스트레이션에 원시 인프라를 제공한다.

액터 모델의 설계는 표면적 특징상(예: 병렬성, 상태 격리, 비동기 처리) 샤딩(Sharding)과 다소 유사하지만, 본질적으로는 완전히 다른 기술 경로와 시스템 철학을 대표한다. 액터 모델은 「다중 프로세스 비동기 계산」을 강조하며, 각 스마트 에이전트(Actor)는 독립적으로 실행되고 상태를 유지하며 메시지 기반으로 상호작용한다. 반면 샤딩은 「상태와 합의의 수평 분할」 메커니즘으로 전체 블록체인을 여러 독립 거래 처리 서브시스템(Shard)으로 분할한다. 액터 모델은 마치 Web3 세계의 「분산형 스마트 에이전트 운영체제」인 반면, 샤딩은 체인 내 거래 처리 능력의 구조적 확장 솔루션이다. 둘 다 병렬성을 실현하지만 출발점, 목표, 실행 아키텍처가 다르다.

4.1 AO (Arweave), 저장 계층 위의 초병렬 컴퓨터

AO는 Arweave의 영구 저장 계층 위에서 작동하는 분산 컴퓨팅 플랫폼으로, 대규모 비동기 스마트 에이전트 실행을 지원하는 체인 상 운영체제를 구축하는 것이 핵심 목표이다.

핵심 아키텍처 특성:

Process 아키텍처: 각 스마트 에이전트는 Process라 불리며 독립 상태, 독립 스케줄러, 실행 로직을 갖는다.
블록체인 구조 없음: AO는 체인이 아니라 Arweave의 분산 저장 계층 + 다중 스마트 에이전트 메시지 기반 실행 엔진에 기반한다.
비동기 메시지 스케줄링 시스템: Process 간 통신은 메시지(Message)를 통해 이루어지며, 무락(lock-free) 비동기 실행 모델을 채택하여 자연스럽게 동시 확장을 지원한다.
상태 영구 저장: 모든 스마트 에이전트 상태, 메시지 기록, 명령어는 Arweave에 영구 저장되어 완전한 감사성과 분산 투명성을 보장한다.
Agent-native: 복잡한 다단계 작업(예: AI 에이전트, DePIN 프로토콜 컨트롤러, 자동 작업 오케스트레이터 등) 배포에 적합하며 「체인 상 AI 코프로세서」를 구축할 수 있다.

AO는 극단적인 「스마트 에이전트 원시 + 저장 기반 + 무체인 아키텍처」 경로를 걷는다. 유연성과 모듈 분리를 강조하며, 「저장 계층 위에 구축된 체인 상 마이크로커널 프레임워크」로, 시스템 경계를 의도적으로 축소하여 경량 계산 + 조합 가능한 제어 구조를 강조한다.