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

작성자：0xjacobzhao 및 ChatGPT 4o

블록체인의 "불가능한 삼각형"(Blockchain Trilemma)인 "안전성", "탈중앙화", "확장성"은 블록체인 시스템 설계에서 본질적인 균형을 드러내며, 즉 블록체인 프로젝트가 "극한의 안전성, 모두의 참여, 고속 처리"를 동시에 달성하기 어렵다는 것을 의미합니다. "확장성"이라는 영원한 주제에 대해 현재 시장의 주류 블록체인 확장 솔루션은 패러다임에 따라 구분되며, 다음과 같은 방식이 있습니다:

• 실행 강화형 확장: 실행 능력을 원래 위치에서 향상시키는 방법으로, 예를 들어 병렬 처리, GPU, 다중 코어
• 상태 분리형 확장: 상태를 수평으로 분할하는 방법으로, 예를 들어 샤딩, UTXO, 다중 서브넷
• 체인 외부 아웃소싱형 확장: 실행을 체인 외부로 이동시키는 방법으로, 예를 들어 롤업, 코프로세서, DA
• 구조 분리형 확장: 아키텍처 모듈화 및 협력적 운영으로, 예를 들어 모듈 체인, 공유 정렬기, 롤업 메쉬
• 비동기 병렬형 확장: 액터 모델, 프로세스 분리, 메시지 기반으로, 예를 들어 에이전트, 다중 스레드 비동기 체인

블록체인 확장 솔루션에는 체인 내 병렬 계산, 롤업, 샤딩, DA 모듈, 모듈화 구조, 액터 시스템, zk 증명 압축, Stateless 아키텍처 등이 포함되며, 실행, 상태, 데이터, 구조의 여러 수준을 포괄하여 "다층 협력, 모듈 조합"의 완전한 확장 시스템을 형성합니다. 본 문서에서는 병렬 계산을 주류로 하는 확장 방식을 중점적으로 소개합니다.

체인 내 병렬 계산(intra-chain parallelism)은 블록 내부의 거래/명령의 병렬 실행에 초점을 맞추고 있습니다. 병렬 메커니즘에 따라, 그 확장 방식은 다섯 가지 주요 유형으로 나눌 수 있으며, 각 유형은 서로 다른 성능 추구, 개발 모델 및 아키텍처 철학을 나타내며, 병렬 세분화가 점점 더 세밀해지고 병렬 강도가 높아지며, 스케줄링 복잡성도 증가하고, 프로그래밍 복잡성과 구현 난이도도 높아집니다.

• 계좌 수준 병렬(Account-level): 프로젝트 솔라나(Solana)를 대표
• 객체 수준 병렬(Object-level): 프로젝트 수이(Sui)를 대표
• 거래 수준 병렬(Transaction-level): 프로젝트 모나드(Monad), 아프토스(Aptos)를 대표
• 호출 수준/마이크로 VM 병렬(Call-level/MicroVM): 프로젝트 메가이더(MegaETH)를 대표
• 명령 수준 병렬(Instruction-level): 프로젝트 갯링X(GatlingX)를 대표

체인 외부 비동기 병렬 모델은 액터 에이전트 시스템(Agent/Actor Model)을 대표하며, 이는 또 다른 병렬 계산 패러다임에 속합니다. 크로스 체인/비동기 메시지 시스템(비블록 동기화 모델)으로, 각 에이전트는 독립적으로 실행되는 "스마트 에이전트 프로세스"로, 비동기 메시지, 이벤트 기반으로 병렬 방식으로 운영되며, 대표 프로젝트로는 AO, ICP, Cartesi 등이 있습니다.

우리가 잘 알고 있는 롤업이나 샤딩 확장 솔루션은 시스템 수준의 병렬 메커니즘에 속하며, 체인 내 병렬 계산에 속하지 않습니다. 이들은 "여러 체인/실행 도메인을 병렬로 운영"하여 확장을 달성하며, 단일 블록/가상 머신 내부의 병렬성을 높이지 않습니다. 이러한 확장 솔루션은 본 문서에서 논의하는 주요 초점은 아니지만, 여전히 아키텍처 개념의 유사성 비교에 사용할 것입니다.

## EVM 계열 병렬 강화 체인: 호환성 속에서 성능 경계를 돌파하다

이더리움의 직렬 처리 아키텍처는 현재까지 샤딩, 롤업, 모듈화 아키텍처 등 여러 차례의 확장 시도를 거쳤지만, 실행 층의 처리량 병목 현상은 여전히 근본적인 돌파구를 찾지 못했습니다. 하지만 동시에 EVM과 Solidity는 여전히 현재 가장 개발자 기반과 생태계 잠재력을 가진 스마트 계약 플랫폼입니다. 따라서 EVM 계열 병렬 강화 체인은 생태계 호환성과 실행 성능 향상을 동시에 고려하는 핵심 경로로, 새로운 확장 진화의 중요한 방향이 되고 있습니다. 모나드와 메가이더는 이 방향에서 가장 대표적인 프로젝트로, 각각 지연 실행과 상태 분해를 통해 고병렬, 고처리량 시나리오를 위한 EVM 병렬 처리 아키텍처를 구축하고 있습니다.

모나드의 병렬 계산 메커니즘 분석

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

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

파이프라인은 모나드 병렬 실행의 기본 개념으로, 블록체인의 실행 프로세스를 여러 개의 독립적인 단계로 분할하고 이 단계들을 병렬로 처리하여 입체적인 파이프라인 아키텍처를 형성합니다. 각 단계는 독립 스레드 또는 코어에서 실행되어 블록 간의 병렬 처리를 실현하며, 궁극적으로 처리량을 증가시키고 지연을 줄이는 효과를 가져옵니다. 이러한 단계에는 거래 제안(Propose), 합의 도달(Consensus), 거래 실행(Execution), 블록 제출(Commit)이 포함됩니다.

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

전통적인 체인에서는 거래 합의와 실행이 일반적으로 동기 프로세스입니다. 이러한 직렬 모델은 성능 확장을 심각하게 제한합니다. 모나드는 "비동기 실행"을 통해 합의 층 비동기, 실행 층 비동기 및 저장 비동기를 구현하여 블록 시간(block time)과 확인 지연을 현저히 줄이고 시스템의 탄력성을 높이며, 처리 프로세스를 더 세분화하고 자원 활용률을 높입니다.

핵심 설계:

• 합의 과정(합의 층)은 거래를 정렬하는 것만 담당하며, 계약 논리는 실행하지 않습니다.
• 실행 과정(실행 층)은 합의가 완료된 후 비동기적으로 촉발됩니다.
• 합의가 완료된 후 즉시 다음 블록 합의 프로세스로 들어가며, 실행 완료를 기다릴 필요가 없습니다.

낙관적 병렬 실행: Optimistic Parallel Execution

전통적인 이더리움은 상태 충돌을 피하기 위해 거래 실행에 엄격한 직렬 모델을 사용합니다. 반면 모나드는 "낙관적 병렬 실행" 전략을 채택하여 거래 처리 속도를 크게 향상시킵니다.

실행 메커니즘:

• 모나드는 모든 거래를 낙관적으로 병렬 실행하며, 대부분의 거래 간에 상태 충돌이 없다고 가정합니다.
• 동시에 "충돌 감지기(Conflict Detector)"를 실행하여 거래 간에 동일한 상태에 접근했는지(예: 읽기/쓰기 충돌)를 모니터링합니다.
• 충돌이 감지되면 충돌 거래를 직렬화하여 다시 실행하여 상태의 정확성을 보장합니다.

모나드는 EVM 규칙을 가능한 한 적게 변경하는 호환 경로를 선택하여, 실행 과정에서 상태 쓰기를 지연시키고 충돌을 동적으로 감지하여 병렬성을 실현합니다. 이는 성능 버전의 이더리움과 같으며, 성숙도가 높아 EVM 생태계의 이전을 쉽게 실현할 수 있는 EVM 세계의 병렬 가속기입니다.

메가이더의 병렬 계산 메커니즘 분석

모나드의 L1定位과는 달리, 메가이더는 EVM 호환 모듈화 고성능 병렬 실행 층으로, 독립 L1 공체인으로도 사용될 수 있으며, 이더리움의 실행 강화 층(Execution Layer) 또는 모듈화 구성 요소로도 사용될 수 있습니다. 그 핵심 설계 목표는 계좌 논리, 실행 환경 및 상태를 독립적으로 스케줄할 수 있는 최소 단위로 분해하여 체인 내 고병렬 실행 및 저지연 응답 능력을 실현하는 것입니다. 메가이더가 제안한 핵심 혁신은 마이크로-VM 아키텍처 + 상태 의존성 DAG(Directed Acyclic Graph) 및 모듈화 동기화 메커니즘으로, "체인 내 스레드화"를 위한 병렬 실행 시스템을 공동으로 구축합니다.

마이크로-VM 아키텍처: 계좌가 곧 스레드

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

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

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

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

메가이더는 비동기 프로그래밍 패러다임 위에 구축되어 있으며, 액터 모델과 유사한 비동기 메시지 전송을 통해 전통적인 EVM 직렬 호출 문제를 해결합니다. 계약 호출은 비동기적이며(재귀 실행이 아님), 계약 A -> B -> C를 호출할 때마다 호출이 비동기화되어 차단 대기할 필요가 없습니다. 호출 스택은 비동기 호출 그래프(Call Graph)로 펼쳐지며, 거래 처리는 비동기 그래프 탐색 + 의존성 분별 + 병렬 스케줄링으로 이루어집니다.

결론적으로, 메가이더는 전통적인 EVM 단일 스레드 상태 머신 모델을 깨고 계좌 단위로 마이크로 가상 머신을 포장하여 상태 의존성 그래프를 통해 거래 스케줄링을 수행하고 비동기 메시지 메커니즘으로 동기 호출 스택을 대체합니다. 이는 "계좌 구조 → 스케줄링 아키텍처 → 실행 프로세스" 전방위적으로 재설계된 병렬 계산 플랫폼으로, 차세대 고성능 체인 시스템 구축을 위한 패러다임 수준의 새로운 사고를 제공합니다.

메가이더는 재구성 경로를 선택하여 계좌와 계약을 독립 VM으로 완전히 추상화하고 비동기 실행 스케줄링을 통해 극한의 병렬 잠재력을 해방합니다. 이론적으로 메가이더의 병렬 한계는 더 높지만, 복잡성을 제어하기가 더 어려워 이더리움의 개념 아래에서의 슈퍼 분산 운영 체제와 유사합니다.

모나드와 메가이더 두 프로젝트의 설계 철학은 샤딩(Sharding)과 상당히 다릅니다. 샤딩은 블록체인을 수평으로 여러 독립적인 서브 체인(샤드)으로 나누어 각 서브 체인이 일부 거래와 상태를 담당하여 단일 체인의 제한을 깨고 네트워크 층에서 확장합니다. 반면 모나드와 메가이더는 단일 체인의 완전성을 유지하며, 실행 층에서 수평으로 확장하여 단일 체인 내부에서 극한의 병렬 실행 최적화를 통해 성능을 돌파합니다. 두 프로젝트는 블록체인 확장 경로에서 수직 강화와 수평 확장의 두 가지 방향을 대표합니다.

모나드와 메가이더와 같은 병렬 계산 프로젝트는 주로 처리량 최적화 경로에 집중하여 체인 내 TPS를 향상시키는 것을 핵심 목표로 하며, 지연 실행(Deferred Execution)과 마이크로 가상 머신(Micro-VM) 아키텍처를 통해 거래 수준 또는 계좌 수준의 병렬 처리를 실현합니다. 한편, 파로스 네트워크(Pharos Network)는 모듈화된 전방위 병렬 L1 블록체인 네트워크로, 그 핵심 병렬 계산 메커니즘은 "롤업 메쉬(Rollup Mesh)"라고 불립니다. 이 아키텍처는 메인넷과 특수 처리 네트워크(SPN)의 협력 작업을 통해 다중 가상 머신 환경(EVM 및 Wasm)을 지원하며, 제로 지식 증명(ZK), 신뢰 실행 환경(TEE) 등 첨단 기술을 통합합니다.

롤업 메쉬 병렬 계산 메커니즘 분석:

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

또한 파로스는 다중 버전 머클 트리, 차등 인코딩(Delta Encoding), 버전 주소 지정(Versioned Addressing) 및 ADS 하향(ADS Pushdown) 기술을 통해 저장 엔진의 하부에서 실행 모델을 재구성하여 원주율 블록체인 고성능 저장 엔진인 파로스 스토어(Pharos Store)를 출시하여 높은 처리량, 낮은 지연, 강력한 검증 가능한 체인 상 처리 능력을 실현합니다.

종합적으로 볼 때, 파로스의 롤업 메쉬 아키텍처는 모듈화 설계와 비동기 처리 메커니즘을 통해 고성능 병렬 계산 능력을 실현하며, 파로스는 크로스 롤업 병렬 스케줄 조정자로서 "체인 내 병렬" 실행 최적화기가 아니라 SPNs를 통해 이종 맞춤형 실행 작업을 수용합니다.

모나드, 메가이더 및 파로스의 병렬 실행 아키텍처 외에도, 우리는 시장에서 EVM 병렬 계산에서 GPU 가속의 응용 경로를 탐색하는 몇 가지 프로젝트를 관찰하고 있으며, 이는 EVM 병렬 생태계에 중요한 보충 및 최전선 실험으로 작용하고 있습니다. 그 중 Reddio와 GatlingX는 두 가지 대표적인 방향입니다:

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

Artela는 차별화된 병렬 설계 개념을 제안합니다. EVM++ 아키텍처 웹어셈블리(WASM) 가상 머신을 도입하여 개발자가 EVM 호환성을 유지하면서 Aspect 프로그래밍 모델을 활용하여 체인 상에서 동적으로 확장 프로그램을 추가하고 실행할 수 있도록 합니다. 이는 계약 호출 세분화(Function/Extension)를 최소 병렬 단위로 하여 EVM 계약 실행 시 Extension 모듈(유사 "플러그인 미들웨어")을 주입하여 논리 분리, 비동기 호출 및 모듈 수준 병렬 실행을 실현합니다. 이는 실행 층의 조합 가능성과 모듈화 아키텍처에 더 많은 초점을 맞추고 있으며, 미래 복잡한 다중 모듈 응용 프로그램에 대한 새로운 사고를 제공합니다.

## 원주율 병렬 아키텍처 체인: VM의 실행 본체 재구성

이더리움의 EVM 실행 모델은 설계 초기부터 "거래 전순서 + 직렬 실행"의 단일 스레드 아키텍처를 채택하여, 네트워크 내 모든 노드가 상태 변경에 대한 결정성과 일관성을 보장하는 것을 목표로 하였습니다. 그러나 이러한 아키텍처는 성능상 자연적인 병목 현상을 가지고 있어 시스템의 처리량과 확장성을 제한합니다. 반면 솔라나(Solana)(SVM), 무브VM(MoveVM)(수이(Sui), 아프토스(Aptos)) 및 코스모스 SDK를 기반으로 구축된 세이 v2(Sei v2)와 같은 원주율 병렬 계산 아키텍처 체인은 근본적인 설계에서 병렬 실행을 위해 맞춤화되어 있으며, 다음과 같은 장점을 가지고 있습니다:

• 상태 모델이 자연스럽게 분리됨: 솔라나는 계좌 잠금 선언 메커니즘을 사용하고, 무브VM은 객체 소유권 모델을 도입하며, 세이 v2는 거래 유형 분류를 기반으로 정적 충돌 판별을 구현하여 거래 수준의 병렬 스케줄링을 지원합니다.
• 가상 머신이 병렬 최적화를 위해 설계됨: 솔라나의 시일레벨(Sealevel) 엔진은 원주율 다중 스레드 실행을 본질적으로 지원하며, 무브VM은 정적 병렬 그래프 분석을 수행할 수 있습니다. 세이 v2는 다중 스레드 매칭 엔진과 병렬 VM 모듈을 통합합니다.

물론 이러한 원주율 병렬 체인도 생태계 호환성의 도전에 직면해 있습니다. 비EVM 아키텍처는 일반적으로 새로운 개발 언어(예: Move, Rust)와 도구 체인을 필요로 하며, 개발자에게는 일정한 이전 비용이 발생합니다. 또한 개발자는 상태 접근 모델, 병렬 제한, 객체 생애 주기 등 일련의 새로운 개념을 이해해야 하며, 이해의 장벽과 개발 패러다임에 대한 요구가 더 높아집니다.

3.1 솔라나 및 SVM 계열의 시일레벨 병렬 엔진 원리

솔라나의 시일레벨 실행 모델은 계좌 병렬 스케줄링 메커니즘으로, 솔라나가 체인 내 병렬 거래 실행을 구현하기 위한 핵심 엔진입니다. "계좌 선언 + 정적 스케줄링 + 다중 스레드 실행" 메커니즘을 통해 스마트 계약 수준의 고성능 병렬성을 실현합니다. 시일레벨은 블록체인 분야에서 생산 환경에서 체인 내 병렬 스케줄링을 성공적으로 구현한 첫 번째 실행 모델로, 그 아키텍처 사상은 이후 많은 병렬 계산 프로젝트에 영향을 미쳤으며, 고성능 Layer1 병렬 설계의 참고 패러다임이 되었습니다.

핵심 메커니즘:

1. 명시적 계좌 접근 선언(Account Access Lists): 각 거래는 제출 시 관련된 계좌(읽기/쓰기)를 선언해야 하며, 시스템은 이를 기반으로 거래 간 상태 충돌이 있는지를 판단합니다.

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

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

1. 독립 실행 컨텍스트(Program Invocation Context): 각 계약 호출은 격리된 컨텍스트에서 실행되며, 공유 스택이 없어 교차 호출 간섭을 방지합니다.

시일레벨은 솔라나의 병렬 실행 스케줄링 엔진이며, SVM은 시일레벨 위에 구축된 스마트 계약 실행 환경(BPF 가상 머신 사용)입니다. 두 가지는 솔라나 고성능 병렬 실행 시스템의 기술적 기초를 형성합니다.

이클립스(Eclipse)는 솔라나 VM을 모듈화 체인(예: 이더리움 L2 또는 셀레스티아)에 배포하는 프로젝트로, 솔라나의 병렬 실행 엔진을 롤업 실행 층으로 활용합니다. 이클립스는 솔라나의 실행 층(시일레벨 + SVM)을 솔라나 메인넷에서 분리하여 모듈화 아키텍처로 이전하는 것을 처음으로 제안한 프로젝트 중 하나로, 솔라나의 "초강력 병렬 실행 모델"을 Execution Layer-as-a-Service로 모듈화하여, 따라서 이클립스도 병렬 계산의 큰 범주에 속합니다.

네온(Neon)의 경로는 다릅니다. 네온은 EVM을 SVM/시일레벨 환경에서 실행하도록 도입합니다. EVM 호환 실행 층을 구축하여 개발자가 Solidity로 계약을 개발하고 SVM 환경에서 실행할 수 있도록 하지만, 스케줄 실행은 SVM + 시일레벨을 사용합니다. 네온은 모듈화 블록체인(Modular Blockchain) 범주에 더 가깝고 병렬 계산 혁신을 강조하지 않습니다.

결론적으로, 솔라나 및 SVM은 시일레벨 실행 엔진에 의존하며, 솔라나 운영 체제식 스케줄링 철학은 커널 스케줄러와 유사하여 실행이 빠르지만 유연성은 상대적으로 낮습니다. 이는 원주율 고성능, 병렬 계산형 공체인입니다.

3.2 무브VM 아키텍처: 자원 및 객체 기반

무브VM은 체인 상 자원 안전 및 병렬 실행을 위해 설계된 스마트 계약 가상 머신으로, 그 핵심 언어인 무브(Move)는 메타(Meta)(구 페이스북)가 리브라 프로젝트를 위해 개발하였으며, "자원은 객체"라는 개념을 강조합니다. 모든 체인 상 상태는 객체로 존재하며, 명확한 소유권과 생애 주기를 가집니다. 이는 무브VM이 컴파일 시 거래 간 상태 충돌이 있는지를 분석하여 객체 수준의 정적 병렬 스케줄링을 구현할 수 있게 합니다. 이는 수이(Sui) 및 아프토스(Aptos)와 같은 원주율 병렬 공체인에서 널리 사용됩니다.

수이의 객체 소유권 모델

수이의 병렬 계산 능력은 그 독특한 상태 모델링 방식과 언어 수준의 정적 분석 메커니즘에서 비롯됩니다. 전통적인 블록체인이 전역 상태 트리를 사용하는 것과 달리, 수이는 "객체" 기반 상태 모델(Object-centric model)을 구축하여 무브VM의 선형 타입 시스템과 결합하여 병렬 스케줄링이 컴파일 시에 완료될 수 있는 결정적 과정을 가능하게 합니다.

• 객체 모델(Object Model)은 수이 병렬 아키텍처의 기초입니다. 수이는 체인 상 모든 상태를 독립적인 객체(Object)로 추상화하며, 각 객체는 고유 ID, 명확한 소유자(계좌 또는 계약) 및 유형 정의를 가집니다. 이러한 객체 간에는 상태를 공유하지 않으며, 자연스럽게 격리됩니다. 계약 호출 시 반드시 관련된 객체 집합을 명시적으로 선언해야 하며, 이는 전통적인 체인 상 "전역 상태 트리"의 상태 결합 문제를 피합니다. 이러한 설계는 체인 상 상태를 여러 독립 단위로 나누어 병렬 실행이 구조적으로 가능하도록 합니다.
• 정적 소유권 분석(Static Ownership Analysis)은 무브 언어의 선형 타입 시스템 지원 하에 구현된 컴파일 시 분석 메커니즘입니다. 이는 시스템이 거래가 실행되기 전에 객체 소유권을 통해 어떤 거래가 상태 충돌을 발생시키지 않을지를 유도하여 병렬 실행을 위해 배치할 수 있도록 합니다. 전통적인 런타임의 충돌 감지 및 롤백과 비교할 때, 수이의 정적 분석 메커니즘은 실행 효율성을 높이는 동시에 스케줄링 복잡성을 크게 줄이며, 이는 고처리량, 결정적 병렬 처리 능력을 실현하는 핵심 요소입니다.

수이는 객체를 단위로 상태 공간을 나누고 컴파일 시 소유권 분석을 결합하여 저비용, 롤백이 필요 없는 객체 수준 병렬 실행을 실현합니다. 전통적인 체인의 직렬 실행이나 런타임 감지와 비교할 때, 수이는 실행 효율성, 시스템 결정성 및 자원 활용률 측면에서 현저한 향상을 이룹니다.

아프토스의 블록-STM 실행 메커니즘

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

블록-STM은 하나의 블록의 거래 실행을 세 가지 단계로 나누어 진행합니다:

• 낙관적 병렬 실행(Speculative Execution): 모든 거래는 실행 전에 기본적으로 충돌이 없다고 가정하며, 시스템은 거래를 병렬로 여러 스레드에 스케줄링하여 실행을 시도하고, 접근한 계좌 상태(읽기 집합/쓰기 집합)를 기록합니다.
• 충돌 감지 및 검증(Validation Phase): 시스템은 실행 결과를 검증합니다. 두 거래 간 읽기/쓰기 충돌이 존재하면(예: Tx1이 Tx2가 쓴 상태를 읽음) 하나를 롤백합니다.
• 충돌 거래 롤백 재시도(Retry Phase): 충돌 거래는 의존 관계가 해결될 때까지 재실행을 위해 다시 배치됩니다. 최종적으로 모든 거래는 유효하고 결정적인 상태 제출 순서를 형성합니다.

블록-STM은 "낙관적 병렬 + 롤백 재시도"의 동적 실행 모델로, 상태 집약적이고 논리가 복잡한 체인 상 거래 배치 처리 시나리오에 적합하며, 아프토스가 고범용성, 고처리량 공체인을 구축하는 병렬 계산의 핵심입니다.

솔라나는 엔지니어링 스케줄링 파로, "운영 체제 커널"과 유사하여 명확한 상태 경계와 제어 가능한 고빈도 거래에 적합하며, 하드웨어 엔지니어 스타일로 체인을 하드웨어처럼 운영해야 합니다(하드웨어 등급 병렬 실행); 아프토스는 시스템 내결함성 파로, "데이터베이스 병렬 엔진"과 유사하여 상태 결합이 강하고 호출 체인이 복잡한 계약 시스템에 적합합니다; 수이는 컴파일 안전 파로, "자원 기반 스마트 언어 플랫폼"과 유사하여 자산 분리 및 조합이 명확한 체인 상 응용 프로그램에 적합하며, 아프토스와 수이는 프로그램 언어 엔지니어처럼 소프트웨어처럼 안전하게 체인을 운영해야 합니다(소프트웨어 등급 자원 보안). 이 세 가지는 Web3 병렬 계산이 서로 다른 철학 아래 기술적 실현 경로를 대표합니다.

3.3 코스모스 SDK 병렬 확장형

세이 V2는 코스모스 SDK를 기반으로 구축된 고성능 거래형 공체인으로, 그 병렬 능력은 주로 두 가지 측면에서 나타납니다: 다중 스레드 매칭 엔진(Parallel Matching Engine) 및 가상 머신 층의 병렬 실행 최적화로, 고빈도, 저지연의 체인 상 거래 시나리오(예: 주문서 DEX, 체인 상 거래소 인프라 등)를 서비스하는 것을 목표로 합니다.

핵심 병렬 메커니즘:

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

3.4 UTXO 모델 재구성자 연료(Fuel)

연료는 이더리움 모듈화 아키텍처 설계를 기반으로 한 고성능 실행 층으로, 그 핵심 병렬 메커니즘은 개선된 UTXO 모델(Unspent Transaction Output)에서 비롯됩니다. 이더리움의 계좌 모델과는 달리, 연료는 UTXO 구조를 사용하여 자산과 상태를 나타내며, 이 모델은 자연스럽게 상태 분리를 제공하여 어떤 거래가 안전하게 병렬 실행될 수 있는지를 판단하기 용이합니다. 또한 연료는 자사 개발의 스마트 계약 언어인 스웨이(Sway)(Rust와 유사)를 도입하고, 정적 분석 도구와 결합하여 거래 실행 전에 입력 충돌을 확인하여 효율적이고 안전한 거래 수준 병렬 스케줄링을 실현합니다. 이는 성능과 모듈화를 모두 고려한 EVM 대체 실행 층입니다.

## 액터 모델: 스마트 에이전트 병렬 실행의 새로운 패러다임

액터 모델은 스마트 에이전트 프로세스(Agent 또는 Process)를 단위로 하는 병렬 실행 패러다임으로, 전통적인 체인 상 전역 상태의 동기 계산(Solana/Sui/Monad 등 "체인 내 병렬 계산" 시나리오)과는 다르게, 각 스마트 에이전트가 독립적인 상태와 행동을 가지며 비동기 메시지를 통해 통신 및 스케줄링을 강조합니다. 이러한 아키텍처 하에서 체인 상 시스템은 서로 분리된 많은 프로세스가 병렬로 실행될 수 있으며, 매우 강력한 확장성과 비동기 내결함성을 가집니다. 대표 프로젝트로는 AO(Arweave AO), ICP(Internet Computer) 및 Cartesi가 있으며, 이들은 블록체인이 실행 엔진에서 "체인 상 운영 체제"로 진화하도록 추진하고 있으며, AI 에이전트, 다중 작업 상호작용 및 복잡한 논리 편성을 위한 원주율 기반 인프라를 제공합니다.

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

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

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

핵심 아키텍처 특성:

• 프로세스 아키텍처: 각 스마트 에이전트는 하나의 프로세스라고 하며, 독립적인 상태, 독립 스케줄러 및 실행 논리를 가집니다.
• 블록체인 구조 없음: AO는 하나의 체인이 아니라 Arweave의 분산 저장 층 + 다중 스마트 에이전트 메시지 기반 실행 엔진입니다.
• 비동기 메시지 스케줄링 시스템: 프로세스 간에는 메시지(Message)를 통해 통신하며, 무잠금 비동기 실행 모델을 채택하여 자연스럽게 병렬 확장을 지원합니다.
• 상태 영구 저장: 모든 스마트 에이전트 상태, 메시지 기록 및 지시는 Arweave에 영구적으로 기록되어 완전한 감사성과 분산 투명성을 보장합니다.
• 에이전트 네이티브: 복잡한 다단계 작업(예: AI 에이전트, DePIN 프로토콜 제어기, 자동 작업 편성기 등)을 배포하는 데 적합하며, "체인 상 AI 코프로세서"를 구축할 수 있습니다.

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

4.2 ICP(Internet Computer), 전방위 Web3 호스팅 플랫폼

ICP는 DFINITY가 출시한 Web3 네이티브 전방위 체인 상 응용 플랫폼으로, 체인 상 계산 능력을 Web2와 유사한 경험으로 확장하고, 완전한 서비스 호스팅, 도메인 바인딩 및 서버리스 아키텍처를 지원하는 것을 목표로 합니다.

핵심 아키텍처 특성:

• 캔스터 아키텍처(Canister Architecture): 각 캔스터는 Wasm VM에서 실행되는 스마트 에이전트로, 독립적인 상태, 코드 및 비동기 스케줄링 능력을 가집니다.
• 서브넷 분산 합의 시스템(Subnet): 전체 네트워크는 여러 서브넷으로 구성되며, 각 서브넷은 일련의 캔스터를 유지하고 BLS 서명 메커니즘을 통해 합의에 도달합니다.
• 비동기 호출 모델: 캔스터 간에는 비동기 메시지 통신을 통해 비차단식 실행을 지원하며, 자연스럽게 병렬성을 가집니다.
• 체인 상 웹 호스팅: 스마트 계약이 프론트엔드 페이지를 직접 호스팅할 수 있도록 지원하며, 원주율 DNS 매핑을 통해 브라우저에서 직접 dApp에 접근할 수 있는 최초의 블록체인 플랫폼입니다.
• 시스템 기능 완전: 체인 상 핫 업그레이드, 인증 신원, 분산 랜덤성, 타이머 등 시스템 API를 갖추고 있어 복잡한 체인 상 서비스 배포에 적합합니다.

ICP는 플랫폼 재구성, 통합 포장 및 강력한 플랫폼 제어의 운영 체제 패러다임을 선택하여, 합의, 실행, 저장 및 접속을 통합한 "블록체인 운영 체제"를 갖추고 있으며, 완전한 서비스 호스팅 능력을 강조하고 시스템 경계를 전방위 Web3 호스팅 플랫폼으로 확장합니다.

또한, 다른 액터 모델 패러다임의 병렬 계산 프로젝트는 아래 표를 참조할 수 있습니다:

## 다섯, 요약 및 전망

가상 머신 아키텍처 및 언어 시스템의 차이에 따라 블록체인 병렬 계산 솔루션은 대체로 두 가지로 나눌 수 있습니다: EVM 계열 병렬 강화 체인과 원주율 병렬 아키텍처 체인(비EVM).

전자는 EVM/Solidity 생태계 호환성을 유지하면서 실행 층을 깊이 최적화하여 더 높은 처리량과 병렬 처리 능력을 실현하며, 이더리움 자산과 개발 도구를 상속받으면서 성능 돌파를 원하는 시나리오에 적합합니다. 대표 프로젝트에는 다음이 포함됩니다:

• 모나드: 지연 쓰기 및 런타임 충돌 감지를 통해 EVM 호환 낙관적 병렬 실행 모델을 구현하며, 합의 완료 후 의존 그래프를 구축하고 다중 스레드로 스케줄링 실행합니다.
• 메가이더: 각 계좌/계약을 독립적인 마이크로 가상 머신(Micro-VM)으로 추상화하여 비동기 메시지 전송 및 상태 의존성 그래프를 기반으로 높은 해체된 계좌 수준 병렬 스케줄링을 실현합니다.
• 파로스: 롤업 메쉬 아키텍처를 구축하여 비동기 파이프라인 및 SPN 모듈 협력을 통해 프로세스 간 시스템 수준 병렬 처리를 실현합니다.
• 레디오(Reddio): zkRollup + GPU 아키텍처를 채택하여 배치 SNARK 생성을 가속화하여 zkEVM의 체인 외 검증 과정을 개선하고 검증 처리량을 높입니다.

후자는 이더리움 호환성의 제한을 완전히 벗어나 가상 머신, 상태 모델 및 스케줄링 메커니즘을 재설계하여 원주율의 고성능 병렬 능력을 실현합니다. 전형적인 하위 클래스에는 다음이 포함됩니다:

• 솔라나(SVM 계열): 계좌 접근 선언 및 정적 충돌 그래프 스케줄링을 기반으로 하여 계좌 수준 병렬 실행 모델을 대표합니다.
• 수이(Sui)/아프토스(Aptos)(무브VM 계열): 자원 객체 모델 및 타입 시스템을 기반으로 하여 컴파일 시 정적 분석을 지원하고 객체 수준 병렬을 실현합니다.
• 세이 V2(코스모스 SDK 경로): 코스모스 아키텍처에 다중 스레드 매칭 엔진 및 가상 머신 병렬 최적화를 도입하여 거래형 고빈도 응용에 적합합니다.
• 연료(Fuel)(UTXO + 스웨이 아키텍처): UTXO 입력 집합 정적 분석을 통해 거래 수준 병렬을 실현하며, 모듈화 실행 층 및 맞춤형 스마트 계약 언어 스웨이를 결합합니다.

또한 액터 모델은 보다 광범위한 병렬 시스템으로, Wasm 또는 사용자 정의 VM 기반의 비동기 프로세스 스케줄링 메커니즘을 통해 "다중 스마트 에이전트 독립 실행 + 메시지 기반 협력"의 체인 상 실행 패러다임을 구축합니다. 대표 프로젝트에는 다음이 포함됩니다:

• AO(Arweave AO): 영구 저장 기반의 스마트 에이전트 런타임을 기반으로 체인 상 비동기 마이크로 커널 시스템을 구축합니다.
• ICP(Internet Computer): 컨테이너화된 스마트 에이전트(Canister)를 최소 단위로 하여 서브넷 조정을 통해 비동기 고확장 실행을 실현합니다.
• Cartesi: 리눅스 운영 체제를 체인 외 계산 환경으로 도입하여 신뢰할 수 있는 계산 결과의 체인 상 검증 경로를 제공합니다. 이는 복잡하거나 자원 집약적인 응용 시나리오에 적합합니다.

위의 논리를 바탕으로 현재 주류 병렬 계산 공체인 솔루션을 다음과 같은 도표로 요약할 수 있습니다:

보다 광범위한 확장 관점에서 보면, 샤딩(Sharding)과 롤업(L2)은 상태 분할 또는 체인 외 실행을 통해 시스템 수평 확장을 실현하는 데 중점을 두는 반면, 병렬 계산 체인(예: 모나드, 수이, 솔라나)과 액터 지향 시스템(예: AO, ICP)은 실행 모델을 직접 재구성하여 체인 내 또는 시스템 층에서 원주율 병렬을 실현합니다. 전자는 다중 스레드 가상 머신, 객체 모델, 거래 충돌 분석 등을 통해 체인 내 처리량을 높이며, 후자는 프로세스/스마트 에이전트를 기본 단위로 하여 메시지 기반 및 비동기 실행 방식을 채택하여 다중 스마트 에이전트 병렬 실행을 실현합니다. 비교적 샤딩과 롤업은 "부하를 여러 체인으로 분산"하거나 "체인 외부로 아웃소싱"하는 것과 유사한 반면, 병렬 체인과 액터 모델은 "실행 엔진 자체에서 성능 잠재력을 해방"하여 보다 근본적인 아키텍처 진화를 나타냅니다.

병렬 계산 vs 샤딩 아키텍처 vs 롤업 확장 vs 액터 지향 확장 경로 비교

특히 주목할 점은 현재 대부분의 원주율 병렬 아키텍처 체인이 메인넷 출시 단계에 접어들었으며, 전체 개발자 생태계는 EVM 계열의 Solidity 시스템과 비교하기 어려운 상황이지만, 솔라나와 수이를 대표로 하는 프로젝트는 그 고성능 실행 아키텍처와 생태계 응용의 점진적인 번영 덕분에 시장에서 높은 관심을 받고 있는 핵심 공체인이 되었습니다.

반면 이더리움 롤업(L2) 생태계는 "만 체인이 동시에 발사"되거나 "생산 능력 과잉" 단계에 접어들었지만, 현재 주류 EVM 계열 병렬 강화 체인은 여전히 테스트넷 단계에 머물러 있으며, 메인넷 환경에서의 실제 검증을 거치지 않았고, 그 확장 능력과 시스템 안정성은 여전히 추가 검증이 필요합니다. 이러한 프로젝트가 호환성을 희생하지 않고 EVM 성능을 크게 향상시켜 생태계의 도약을 촉진할 수 있을지, 아니면 오히려 이더리움의 유동성과 개발 자원의 분화를 더욱 심화시킬지 여부는 시간에 따라 검증되어야 할 것입니다.