작성자: 0xjacobzhao 및 ChatGPT 4o

블록체인의 "보안성", "탈중앙화", "확장성"이라는 "불가능한 삼각형"(블록체인 트릴레마)은 블록체인 시스템 설계의 본질적인 상충 관계를 보여줍니다. 즉, 블록체인 프로젝트가 "극도의 보안성, 모든 사람의 참여, 고속 처리"를 동시에 달성하기 어렵다는 것입니다. "확장성"이라는 영원한 주제와 관련하여, 시중에 나와 있는 주요 블록체인 확장 솔루션은 다음과 같은 패러다임으로 구분됩니다.

• 실행 강화 확장: 병렬화, GPU, 멀티 코어 등 현장 실행 기능 향상
• 상태 격리 확장: 수평 분할 상태/샤드, 예: 샤딩, UTXO, 다중 서브넷
• 오프체인 아웃소싱 확장: Rollup, Coprocessor, DA 등 체인 외부에서 실행을 수행
• 구조적 분리 확장: 모듈형 아키텍처 및 모듈 체인, 공유 시퀀서, 롤업 메시와 같은 협업 운영
• 비동기 동시 확장: 액터 모델, 프로세스 격리, 메시지 기반, 지능형 에이전트, 멀티스레드 비동기 체인 등

블록체인 확장 계획에는 체인 내 병렬 컴퓨팅, 롤업, 샤딩, DA 모듈, 모듈형 구조, 액터 시스템, ZK 증명 압축, 무상태 아키텍처 등이 포함되어 있으며, 실행, 상태, 데이터 및 구조의 여러 레벨을 포괄합니다. 이는 "다층 협업과 모듈형 결합"의 완전한 확장 시스템입니다. 본 논문에서는 병렬 컴퓨팅을 기반으로 한 용량 확장 방법에 초점을 맞추고 있다.

체인 내 병렬 처리는 블록 내에서 트랜잭션/명령의 병렬 실행에 초점을 맞춥니다. 병렬 메커니즘에 따르면 확장 방법은 다섯 가지 범주로 나눌 수 있습니다. 각 카테고리는 서로 다른 성과 추구, 개발 모델, 건축 철학을 나타냅니다. 병렬 세분성은 점점 더 세밀해지고, 병렬 강도는 점점 더 높아지고, 스케줄링 복잡도는 점점 더 높아지고, 프로그래밍 복잡도와 구현 난이도도 점점 더 높아지고 있습니다.

• 계정 수준 병렬 처리: 대표 프로젝트 Solana
• 객체 수준 병렬성: 대표 프로젝트 Sui
• 트랜잭션 수준 병렬성: 대표적인 프로젝트로는 Monad와 Aptos가 있습니다.
• 콜 레벨/MicroVM 병렬 처리: 대표 프로젝트 MegaETH
• 명령어 수준 병렬성: 대표 프로젝트 GatlingX

오프체인 비동기 동시 모델은 Actor / Actor Model로 표현됩니다. 이들은 또 다른 병렬 컴퓨팅 패러다임에 속합니다. 크로스체인/비동기 메시징 시스템(비블록 동기화 모델)으로서, 각 에이전트는 비동기 메시징과 이벤트 기반 병렬 방식을 갖춘 독립적으로 실행되는 "에이전트 프로세스"이며, 동기 스케줄링이 필요하지 않습니다. 대표적인 프로젝트로는 AO, ICP, Cartesi 등이 있습니다.

우리가 알고 있는 롤업이나 샤딩 확장 솔루션은 체인 내 병렬 컴퓨팅이 아닌 시스템 수준의 동시성 메커니즘에 속합니다. 그들은 단일 블록/가상 머신 내에서 병렬 처리 정도를 높이는 대신, 여러 체인/실행 도메인을 병렬로 실행하여 확장성을 달성합니다. 이 글에서는 이러한 유형의 확장 솔루션을 중점적으로 다루지 않지만, 이를 사용하여 아키텍처 개념의 유사점과 차이점을 비교해보겠습니다.

2. EVM 기반 병렬 향상 체인: 호환성에서 성능 경계를 돌파

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

모나드의 병렬 컴퓨팅 메커니즘 분석

Monad는 Ethereum Virtual Machine(EVM)을 위해 재설계된 고성능 Layer 1 블록체인입니다. 이는 파이프라인 처리의 기본 병렬 개념, 합의 계층에서의 비동기 실행, 실행 계층에서의 낙관적 병렬 실행을 기반으로 합니다. 또한, Monad는 합의 및 저장 계층에서 고성능 BFT 프로토콜(MonadBFT)과 전용 데이터베이스 시스템(MonadDB)을 도입하여 엔드 투 엔드 최적화를 달성했습니다.

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

파이프라인은 모나드 병렬 실행의 기본 개념입니다. 핵심 아이디어는 블록체인의 실행 프로세스를 여러 개의 독립적인 단계로 분할하고 이러한 단계를 병렬로 처리하여 3차원 파이프라인 아키텍처를 형성하는 것입니다. 각 단계는 독립적인 스레드나 코어에서 실행되어 블록 전반에 걸쳐 동시 처리를 달성하고, 궁극적으로 처리량을 향상시키고 지연 시간을 줄이는 효과를 얻습니다. 이러한 단계에는 거래 제안(Propose), 합의(Consensus), 거래 실행(Execution), 블록 제출(Commit)이 포함됩니다.

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

기존 체인에서는 거래 합의와 실행이 일반적으로 동기적 프로세스로 진행됩니다. 이러한 직렬 모델은 성능 확장을 심각하게 제한합니다. 모나드는 "비동기 실행"을 통해 합의 계층 비동기, 실행 계층 비동기, 저장 비동기를 실현합니다. 블록 시간과 확인 지연을 크게 줄여 시스템을 더 유연하게 만들고, 처리 흐름을 더 세분화하고, 리소스 활용도를 더 효율적으로 만듭니다.

핵심 디자인:

• 합의 프로세스(합의 계층)는 거래를 정렬하는 데만 책임이 있으며 계약 논리를 실행하지 않습니다.
• 실행 프로세스(실행 계층)는 합의에 도달한 후 비동기적으로 시작됩니다.
• 합의가 완료되면 실행이 완료될 때까지 기다리지 않고 바로 다음 블록 합의 프로세스에 들어갑니다.

낙관적 병렬 실행: 낙관적 병렬 실행

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

실행 메커니즘:

• 모나드는 대부분의 거래가 서로 충돌하지 않는다는 가정 하에 모든 거래를 병렬로 낙관적으로 실행합니다.
• 또한 "충돌 감지기"는 트랜잭션이 동일한 상태(예: 읽기/쓰기 충돌)에 액세스하는지 모니터링하기 위해 실행됩니다.
• 충돌이 감지되면 충돌하는 거래가 직렬화되고 다시 실행되어 상태 정확성이 보장됩니다.

모나드는 호환 가능한 경로를 선택했습니다. 즉, EVM 규칙을 최소한으로 변경하고, 쓰기 상태를 연기하고 실행 중에 충돌을 동적으로 감지하여 병렬성을 달성합니다. 이는 이더리움의 고성능 버전과 더 비슷합니다. 그 성숙성 덕분에 EVM 생태계 마이그레이션을 쉽게 달성할 수 있으며, EVM 세계의 병렬 가속기 역할을 합니다.

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

Monad의 L1 포지셔닝과 달리 MegaETH는 EVM과 호환되는 모듈형 고성능 병렬 실행 계층으로 포지셔닝되어 독립적인 L1 퍼블릭 체인이나 실행 향상 계층(실행 계층) 또는 Ethereum의 모듈형 구성 요소로 사용될 수 있습니다. 핵심 설계 목표는 계정 논리, 실행 환경, 상태를 독립적으로 예약 가능한 최소 단위로 분리하고 분해하여 체인 내에서 높은 동시성 실행과 낮은 지연 시간 응답 기능을 달성하는 것입니다. MegaETH가 제안한 주요 혁신은 다음과 같습니다. 마이크로 VM 아키텍처 + 상태 종속성 DAG(지향성 비순환 상태 종속성 그래프) 및 모듈형 동기화 메커니즘은 "인체인 스레딩"을 위한 병렬 실행 시스템을 공동으로 구축합니다.

마이크로 VM 아키텍처: 스레드로서의 계정

MegaETH는 "계정당 하나의 마이크로 가상 머신(Micro-VM)" 실행 모델을 도입하여 실행 환경을 "스레드"하고 병렬 스케줄링을 위한 가장 작은 격리 단위를 제공합니다. 이러한 VM은 동기식 호출이 아닌 비동기식 메시징을 통해 서로 통신합니다. 많은 수의 VM을 독립적으로 실행하고 저장할 수 있어 자연스럽게 병렬 처리가 가능합니다.

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

MegaETH는 계정 상태 접근 관계를 기반으로 DAG 스케줄링 시스템을 구축했습니다. 시스템은 글로벌 종속성 그래프를 실시간으로 유지 관리합니다. 각 거래에서 어떤 계정이 수정되고 어떤 계정이 읽히는지는 모두 종속성으로 모델링됩니다. 충돌하지 않는 트랜잭션은 병렬로 직접 실행할 수 있으며, 종속성이 있는 트랜잭션은 토폴로지 순서대로 예약되거나 지연됩니다. 종속성 그래프는 병렬 실행 중에 상태 일관성과 중복되지 않은 쓰기를 보장합니다.

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

MegaETH는 Actor Model의 비동기 메시지 전달과 유사한 비동기 프로그래밍 패러다임을 기반으로 구축되어 기존 EVM 직렬 호출 문제를 해결합니다. 계약 호출은 비동기식(비재귀적 실행)입니다. 계약 A -> B -> C를 호출할 때 각 호출은 차단 및 대기 없이 비동기적으로 수행됩니다. 호출 스택은 비동기 호출 그래프(Call Graph)로 확장됩니다. 트랜잭션 처리 = 비동기 그래프 탐색 + 종속성 해결 + 병렬 스케줄링.

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

MegaETH는 계정과 계약을 완전히 독립적인 VM으로 추상화하고 비동기 실행 스케줄링을 통해 궁극적인 병렬 잠재력을 해제하는 재구성 경로를 선택했습니다. 이론적으로 MegaETH는 더 높은 병렬 상한을 가지고 있지만, 복잡성을 제어하기가 더 어렵습니다. 이는 이더리움 개념을 기반으로 한 초고속 분산 운영 체제와 더 유사합니다.

Monad와 MegaETH의 설계 개념은 샤딩과 상당히 다릅니다. 샤딩은 블록체인을 수평적으로 여러 개의 독립적인 하위 체인(샤드)으로 나눕니다. 각 하위 체인은 일부 거래와 상태를 담당하며 네트워크 계층에서 단일 체인 확장의 제한을 깨뜨립니다. Monad와 MegaETH는 둘 다 단일 체인의 무결성을 유지하고, 실행 계층에서만 수평적으로 확장하며, 단일 체인 내에서 극도의 병렬 실행을 통해 성능을 최적화합니다. 둘은 블록체인 확장 경로에서 수직적 강화와 수평적 확장 방향을 나타냅니다.

Monad 및 MegaETH와 같은 병렬 컴퓨팅 프로젝트는 주로 처리량 최적화 경로에 초점을 맞추고 있으며, 핵심 목표는 체인 내 TPS를 개선하고 지연 실행 및 마이크로 가상 머신(Micro-VM) 아키텍처를 통해 트랜잭션 수준 또는 계정 수준의 병렬 처리를 달성하는 것입니다. Pharos Network는 모듈식 풀스택 병렬 L1 블록체인 네트워크이며, 핵심 병렬 컴퓨팅 메커니즘은 "Rollup Mesh"라고 합니다. 이 아키텍처는 메인 네트워크와 특수 처리 네트워크(SPN) 간의 협업을 통해 여러 가상 머신 환경(EVM 및 Wasm)을 지원하고, 제로 지식 증명(ZK) 및 신뢰할 수 있는 실행 환경(TEE)과 같은 고급 기술을 통합합니다.

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

1. 전체 수명 주기 비동기 파이프라인: Pharos는 트랜잭션의 다양한 단계(합의, 실행, 저장 등)를 분리하고 비동기 처리를 사용하여 각 단계를 독립적으로 병렬로 수행할 수 있도록 하여 전반적인 처리 효율성을 개선합니다.
2. 듀얼 VM 병렬 실행: Pharos는 EVM과 WASM 가상 머신 환경을 모두 지원하므로 개발자는 필요에 따라 적절한 실행 환경을 선택할 수 있습니다. 이러한 이중 VM 아키텍처는 시스템의 유연성을 향상시킬 뿐만 아니라, 병렬 실행을 통해 트랜잭션 처리 기능도 향상시킵니다.
3. 특수 처리 네트워크(SPN): SPN은 Pharos 아키텍처의 핵심 구성 요소이며 특정 유형의 작업이나 애플리케이션을 처리하는 데 전념하는 모듈식 하위 네트워크와 같습니다. SPN을 통해 Pharos는 동적 리소스 할당과 작업의 병렬 처리를 달성하여 시스템의 확장성과 성능을 더욱 향상시킵니다.
4. 모듈식 합의 및 재스테이킹: Pharos는 다양한 합의 모델(PBFT, PoS, PoA 등)을 지원하는 유연한 합의 메커니즘을 도입하고 재스테이킹 프로토콜(Restaking)을 통해 메인넷과 SPN 간의 안전한 공유 및 리소스 통합을 달성합니다.

또한 Pharos는 멀티버전 Merkle 트리, 델타 인코딩, 버전 기반 주소 지정, ADS 푸시다운 기술을 통해 저장 엔진의 하단부터 실행 모델을 재구성하고, 네이티브 블록체인 고성능 저장 엔진인 Pharos Store를 출시하여 높은 처리량, 낮은 지연 시간, 높은 검증 가능성을 갖춘 온체인 처리 기능을 구현합니다.

일반적으로 Pharos의 Rollup Mesh 아키텍처는 모듈식 설계와 비동기 처리 메커니즘을 통해 고성능 병렬 컴퓨팅 기능을 구현합니다. 크로스 롤업 병렬 처리를 위한 스케줄링 코디네이터인 Pharos는 "체인 내 병렬" 실행 최적화 프로그램이 아니라 SPN을 통해 이기종 사용자 정의 실행 작업을 수행합니다.

Monad, MegaETH, Pharos의 병렬 실행 아키텍처 외에도 EVM 병렬 컴퓨팅에서 GPU 가속의 적용 경로를 탐색하는 몇몇 프로젝트가 시장에 존재하며, 이는 EVM 병렬 생태계에 대한 중요한 보완이자 최첨단 실험입니다. 그 중 대표적인 두 방향으로는 Reddio와 GatlingX가 있다.

• Reddio는 zkRollup과 GPU 병렬 실행 아키텍처를 결합한 고성능 플랫폼입니다. 핵심은 EVM 실행 프로세스를 재구성하고 멀티스레드 스케줄링, 비동기 상태 저장, GPU 가속 트랜잭션 배치 실행을 통해 실행 계층의 기본 병렬화를 실현하는 것입니다. 병렬 세분성은 트랜잭션 수준 + 작업 수준(멀티스레드 명령어 실행)에 속합니다. 이 설계에는 멀티스레드 배치 실행, 비동기 상태 로딩 및 GPU 병렬 처리 트랜잭션 로직(CUDA 호환 병렬 EVM)이 도입되었습니다. Monad/MegaETH와 마찬가지로 Reddio도 실행 계층에서 병렬 처리에 중점을 둡니다. 차이점은 실행 엔진이 GPU 병렬 아키텍처를 통해 재구성되었으며 높은 처리량과 컴퓨팅 집약적 시나리오(예: AI 추론)에 맞게 설계되었다는 것입니다. 통합 실행 모듈을 제공하는 SDK가 출시되었습니다.
• GatlingX는 자신을 "GPU-EVM"이라고 부르며, 기존 EVM 가상 머신의 "명령어 수준 직렬 실행" 모델을 GPU의 기본 병렬 운영 환경으로 마이그레이션하려는 보다 혁신적인 아키텍처를 제안합니다. 핵심 메커니즘은 EVM 바이트코드를 CUDA 병렬 작업으로 동적으로 컴파일하고, GPU 멀티 코어를 통해 명령어 스트림을 실행하여 가장 낮은 수준에서 EVM의 순차적 병목 현상을 해소하는 것입니다. 명령어 수준 병렬 처리(ILP)의 병렬 세분성에 속합니다. Monad/MegaETH의 "거래 수준/계정 수준" 병렬 세분성과 비교했을 때, GatlingX의 병렬 메커니즘은 가상 머신 엔진의 기본 재구성에 더 가까운 명령어 수준 최적화 경로에 속합니다. 현재는 개념 단계에 있으며, 백서와 아키텍처 스케치가 공개되었지만 SDK나 메인넷은 아직 없습니다.

아르텔라는 차별화된 병렬 디자인 컨셉을 제안했습니다. EVM++ 아키텍처 WebAssembly(WASM) 가상 머신을 도입함으로써 개발자는 Aspect 프로그래밍 모델을 사용하여 EVM 호환성을 유지하면서 체인에 확장 기능을 동적으로 추가하고 실행할 수 있습니다. 이는 계약 호출 세분성(함수/확장)을 최소 병렬 단위로 사용하고, EVM 계약 런타임 동안 확장 모듈(플러그형 미들웨어와 유사) 주입을 지원하며, 논리적 분리, 비동기 호출 및 모듈 수준 병렬 실행을 실현합니다. 실행 계층의 구성 가능성과 모듈형 아키텍처에 더 많은 주의를 기울이세요. 이 개념은 미래의 복잡한 다중 모듈 애플리케이션에 대한 새로운 아이디어를 제공합니다.

3. 네이티브 병렬 아키텍처 체인: VM의 실행 엔터티 재구성

이더리움의 EVM 실행 모델은 네트워크의 모든 노드에 대한 상태 변경의 확실성과 일관성을 보장하는 것을 목표로 하며, 처음부터 "전체 거래 순서 + 직렬 실행"의 단일 스레드 아키텍처를 채택해 왔습니다. 그러나 이 아키텍처는 자연스럽게 성능 병목 현상이 발생하여 시스템 처리량과 확장성이 제한됩니다. 이와 대조적으로 Cosmos SDK를 기반으로 하는 Solana(SVM), MoveVM(Sui, Aptos), Sei v2와 같은 기본 병렬 컴퓨팅 아키텍처 체인은 최하위 설계부터 병렬 실행에 맞춰져 있으며 다음과 같은 장점이 있습니다.

• 상태 모델의 자연스러운 분리: Solana는 계정 잠금 선언 메커니즘을 채택하고, MoveVM은 객체 소유권 모델을 도입하며, Sei v2는 트랜잭션 유형 분류를 기반으로 정적 충돌 판별을 달성하고 트랜잭션 수준 동시 스케줄링을 지원합니다.
• 가상 머신은 동시성을 위해 최적화되었습니다. Solana의 Sealevel 엔진은 기본적으로 멀티스레드 실행을 지원합니다. MoveVM은 정적 동시성 그래프 분석을 수행할 수 있습니다. Sei v2는 멀티스레드 매칭 엔진과 병렬 VM 모듈을 통합했습니다.

물론, 이러한 유형의 토착 병행 사슬도 생태적 호환성 측면에서 어려움에 직면합니다. EVM이 아닌 아키텍처는 일반적으로 새로운 개발 언어(Move, Rust 등)와 툴 체인을 필요로 하며, 이로 인해 개발자는 특정 마이그레이션 비용을 부담하게 됩니다. 또한 개발자는 상태 액세스 모델, 동시성 제한, 객체 수명 주기와 같은 일련의 새로운 개념을 숙지해야 하며, 이로 인해 임계값과 개발 패러다임을 이해하는 데 더 많은 요구가 발생합니다.

3.1 Solana 및 SVM 기반 해수면 병렬 엔진 원리

솔라나의 Sealevel 실행 모델은 계정 병렬 스케줄링 메커니즘이며, 체인 내에서 병렬 거래 실행을 구현하기 위한 솔라나의 핵심 엔진입니다. "계정 선언 + 정적 스케줄링 + 멀티스레드 실행" 메커니즘을 통해 스마트 계약 수준에서 고성능 동시성을 달성합니다. Sealevel은 블록체인 분야에서 프로덕션 환경에서 체인 내 동시 스케줄링을 성공적으로 구현한 최초의 실행 모델입니다. 이러한 아키텍처 아이디어는 이후의 많은 병렬 컴퓨팅 프로젝트에 영향을 미쳤으며 고성능 레이어 1 병렬 설계를 위한 기준 패러다임이 되었습니다.

핵심 역학:

1. 명시적 계정 접근 목록: 각 거래는 제출될 때 관련 계정(읽기/쓰기)을 선언해야 하며, 시스템은 이를 사용하여 거래 간에 상태 충돌이 있는지 여부를 확인합니다.

2. 충돌 감지 및 멀티스레드 스케줄링

• 두 거래에서 접근하는 계정 집합에 교차점이 없는 경우 → 병렬로 실행될 수 있습니다.
• 충돌이 있는 경우 종속성 순서대로 순차적으로 실행합니다.
• 스케줄러는 종속성 그래프를 기반으로 트랜잭션을 여러 스레드에 할당합니다.

3. 독립 실행 컨텍스트(프로그램 호출 컨텍스트): 각 계약 호출은 교차 호출 간섭을 방지하기 위해 공유 스택 없이 격리된 컨텍스트에서 실행됩니다.

SealevelSealevel은 Solana의 병렬 실행 스케줄링 엔진이고, SVM은 Sealevel(BPF 가상 머신 사용)을 기반으로 구축된 스마트 계약 실행 환경입니다. 이들은 함께 Solana의 고성능 병렬 실행 시스템의 기술적 기반을 형성합니다.

Eclipse는 Solana의 병렬 실행 엔진을 Rollup 실행 계층으로 활용하여 Ethereum L2나 Celestia와 같은 모듈형 체인에 Solana VM을 배포하는 프로젝트입니다. Eclipse는 Solana 실행 계층(Sealevel + SVM)을 Solana 메인넷에서 분리하고 이를 모듈식 아키텍처로 마이그레이션하고, Solana의 "슈퍼 동시 실행 모델"을 Execution Layer-as-a-Service로 모듈화하는 것을 제안한 최초의 프로젝트 중 하나입니다. 따라서 Eclipse도 병렬 컴퓨팅 범주에 속합니다.

네온은 다른 경로를 택해 EVM을 SVM/해수면 환경으로 가져옵니다. EVM과 호환되는 런타임 계층을 구축합니다. 개발자는 Solidity를 사용하여 계약을 개발하고 SVM 환경에서 실행할 수 있지만 스케줄링 실행에는 SVM + Sealeve가 사용됩니다. 네온은 모듈형 블록체인 범주에 더 가깝고 병렬 컴퓨팅 혁신을 강조하지 않습니다.

요약하자면, Solana와 SVM은 Sealevel 실행 엔진에 의존합니다. 솔라나의 운영체제 스케줄링 철학은 커널 스케줄러와 비슷한데, 커널 스케줄러는 빠르게 실행되지만 유연성이 상대적으로 낮습니다. 이는 기본적으로 고성능, 병렬 컴퓨팅을 지원하는 공개 체인입니다.

3.2 MoveVM 아키텍처: 리소스 및 개체 드라이버

MoveVM은 체인상 리소스 보안과 병렬 실행을 위해 설계된 스마트 계약 가상 머신입니다. 핵심 언어인 Move는 원래 Libra 프로젝트를 위해 Meta(구 Facebook)가 개발했습니다. 이는 "대상으로서의 자원"이라는 개념을 강조합니다. 모든 온체인 상태는 명확한 소유권과 수명 주기를 가진 객체로 존재합니다. 이를 통해 MoveVM은 컴파일 시점에 트랜잭션 간에 상태 충돌이 있는지 분석하고, 객체 수준의 정적 병렬 스케줄링을 구현할 수 있으며, Sui 및 Aptos와 같은 네이티브 병렬 공개 체인에서 널리 사용됩니다.

수이의 객체 소유권 모델

수이의 병렬 컴퓨팅 기능은 고유한 상태 모델링 방법과 언어 수준의 정적 분석 메커니즘에서 비롯됩니다. 글로벌 상태 트리를 사용하는 기존 블록체인과 달리, Sui는 MoveVM의 선형 유형 시스템을 결합하여 병렬 스케줄링을 컴파일 타임에 완료할 수 있는 결정론적 프로세스로 만드는 객체 중심 모델을 구축했습니다.

• 객체 모델은 Sui 병렬 아키텍처의 기반입니다. Sui는 체인의 모든 상태를 독립적인 객체(Object)로 추상화합니다. 각 객체에는 고유한 ID, 명확한 소유자(계정 또는 계약), 유형 정의가 있습니다. 이러한 객체는 서로 상태를 공유하지 않으며 본질적으로 고립되어 있습니다. 계약을 호출할 때 관련 객체 집합을 명시적으로 선언해야 하므로 기존 체인의 "전역 상태 트리"에서 발생하는 상태 결합 문제를 피할 수 있습니다. 이 디자인은 온체인 상태를 여러 개의 독립적인 단위로 나누어 동시 실행을 구조적으로 실행 가능한 스케줄링 전제 조건으로 만듭니다.
• 정적 소유권 분석은 Move 언어의 선형 유형 시스템을 지원하여 구현된 컴파일 타임 분석 메커니즘입니다. 이 기능을 사용하면 시스템은 트랜잭션이 실행되기 전에 객체 소유권을 통해 어떤 트랜잭션이 상태 충돌을 일으키지 않을지 추론하여 병렬 실행을 구성할 수 있습니다. 기존 런타임의 충돌 감지 및 롤백과 비교했을 때, Sui의 정적 분석 메커니즘은 스케줄링 복잡성을 크게 줄이는 동시에 실행 효율성을 향상시킵니다. 이는 높은 처리량과 결정론적 병렬 처리 기능을 달성하는 데 중요한 요소입니다.

Sui는 상태 공간을 객체로 나누고 컴파일 타임 소유권 분석과 결합하여 저비용, 롤백 없는 객체 수준 병렬 실행을 달성합니다. 기존 체인의 직렬 실행이나 런타임 감지와 비교했을 때, Sui는 실행 효율성, 시스템 결정성 및 리소스 활용도 측면에서 상당한 개선을 이룹니다.

Aptos의 Block-STM 구현 메커니즘

Aptos는 Move 언어를 기반으로 하는 고성능 레이어 1 블록체인입니다. 병렬 실행 기능은 주로 독립적으로 개발된 Block-STM(블록 수준 소프트웨어 트랜잭션 메모리) 프레임워크에서 비롯됩니다. 수이의 "컴파일 시점의 정적 병렬 처리" 전략과 달리 Block-STM은 "런타임의 낙관적 동시성 + 충돌 롤백"이라는 동적 스케줄링 메커니즘으로, 복잡한 종속성이 있는 트랜잭션 세트를 처리하는 데 적합합니다.

Block-STM은 블록의 거래 실행을 세 단계로 구분합니다.

• 낙관적 동시 실행(추측 실행): 모든 거래는 실행 전에는 기본적으로 충돌이 없습니다. 시스템은 동시 실행을 위해 여러 스레드에 병렬로 트랜잭션을 예약하고 액세스된 계정 상태(읽기 세트/쓰기 세트)를 기록합니다.
• 충돌 감지 및 검증(검증 단계): 시스템은 실행 결과를 검증합니다. 두 트랜잭션 간에 읽기-쓰기 충돌이 있는 경우(예: Tx1이 Tx2가 쓴 상태를 읽는 경우) 그 중 하나가 롤백됩니다.
• 충돌하는 트랜잭션은 롤백되고 재시도됩니다(재시도 단계): 충돌하는 트랜잭션은 종속성이 해결될 때까지 실행을 위해 다시 예약되고, 결국 모든 트랜잭션이 유효하고 결정론적인 상태 제출 시퀀스를 형성합니다.

Block-STM은 상태 집약적이고 논리적으로 복잡한 온체인 거래 일괄 처리 시나리오에 적합한 "낙관적 병렬 처리 + 롤백 및 재시도"의 동적 실행 모델입니다. Aptos의 병렬 컴퓨팅 핵심은 다재다능하고 처리량이 높은 공개 체인을 구축하는 것입니다.

솔라나는 엔지니어링 스케줄링 학교로, 명확한 상태 경계와 제어 가능한 고빈도 트랜잭션에 적합하며, 하드웨어 엔지니어의 스타일을 갖추고 있어 하드웨어처럼 체인을 실행합니다(하드웨어 등급 병렬 실행). Aptos는 시스템 장애 허용 학교로, 강력한 상태 결합과 복잡한 호출 체인을 갖춘 계약 시스템에 적합한 "데이터베이스 동시성 엔진"과 더 유사합니다. 수이는 컴파일 보안 학교로, "리소스 기반 지능형 언어 플랫폼"에 가깝고, 명확한 자산 분리 및 조합을 통해 온체인 애플리케이션에 적합합니다. Aptos와 Sui는 프로그래밍 언어 엔지니어와 같아야 하며 소프트웨어만큼 안전하게 체인을 운영해야 합니다(소프트웨어 등급 리소스 보안). 이 세 가지는 서로 다른 철학 하에 Web3 병렬 컴퓨팅의 기술적 구현 경로를 나타냅니다.

3.3 Cosmos SDK 병렬 확장

Sei V2는 Cosmos SDK를 기반으로 구축된 고성능 거래 기반 공개 체인입니다. 병렬 기능은 주로 두 가지 측면에 반영됩니다. 멀티스레드 매칭 엔진(Parallel Matching Engine)의 병렬 실행 최적화와 주문장 DEX, 온체인 거래 인프라 등과 같은 고주파, 저지연 온체인 거래 시나리오를 제공하는 것을 목표로 하는 가상 머신 계층입니다.

핵심 병렬 메커니즘:

1. 병렬 매칭 엔진: Sei V2는 주문 매칭 로직에 멀티스레드 실행 경로를 도입하여 주문장과 매칭 로직을 스레드 수준에서 분리합니다. 이를 통해 여러 시장(거래 쌍) 간의 매칭 작업을 병렬로 처리하여 단일 스레드 병목 현상을 피할 수 있습니다.
2. 가상 머신 수준의 동시성 최적화: Sei V2는 동시 실행 기능을 갖춘 CosmWasm 런타임 환경을 구축하여 일부 계약 호출이 상태 충돌 없이 병렬로 실행될 수 있도록 하고, 트랜잭션 유형 분류 메커니즘과 협력하여 더 높은 처리량 제어를 달성합니다.
3. 실행 계층 스케줄링을 통한 병렬 합의: 합의 계층과 실행 계층 간의 처리량 분리를 강화하고 전체 블록 처리 효율성을 개선하기 위해 소위 "트윈 터보" 합의 메커니즘을 도입합니다.

3.4 UTXO 모델 재구성 연료

Fuel은 이더리움의 모듈형 아키텍처를 기반으로 설계된 고성능 실행 계층입니다. 핵심 병렬 메커니즘은 개선된 UTXO 모델(사용되지 않은 거래 출력)에서 파생되었습니다. 이더리움의 계정 모델과 달리 Fuel은 UTXO 구조를 사용하여 자산과 상태를 나타냅니다. 이 모델은 본질적으로 상태 격리를 갖추고 있어 어떤 거래를 병렬로 안전하게 실행할 수 있는지 쉽게 판단할 수 있습니다. 또한 Fuel은 자체 개발한 스마트 계약 언어인 Sway(Rust와 유사)를 도입하고 정적 분석 도구와 결합하여 트랜잭션 실행 전에 입력 충돌을 파악함으로써 효율적이고 안전한 트랜잭션 수준의 병렬 스케줄링을 구현했습니다. 이는 성능과 모듈성을 모두 고려한 EVM 대체 실행 계층입니다.

4. Actor Model: 지능형 에이전트의 동시 실행을 위한 새로운 패러다임

액터 모델은 에이전트 프로세스(에이전트 또는 프로세스)를 기반으로 하는 병렬 실행 패러다임입니다. 체인 상의 글로벌 상태에 대한 기존 동기식 계산(Solana/Sui/Monad 및 기타 "온체인 병렬 컴퓨팅" 시나리오)과 달리, 각 에이전트가 독립적인 상태와 동작을 가지고 비동기 메시지를 통해 통신하고 일정을 조정한다는 점을 강조합니다. 이 아키텍처에서는 온체인 시스템이 매우 강력한 확장성과 비동기 장애 허용성을 갖추고 다수의 분리된 프로세스에 의해 동시에 실행될 수 있습니다. 대표적인 프로젝트로는 AO(Arweave AO), ICP(Internet Computer), Cartesi 등이 있으며, 이러한 프로젝트는 블록체인을 실행 엔진에서 "온체인 운영 체제"로 발전시켜 AI 에이전트, 멀티태스크 상호작용, 복잡한 로직 오케스트레이션을 위한 기본 인프라를 제공합니다.

액터 모델의 디자인은 표면적 특징(병렬성, 상태 격리, 비동기 처리 등) 측면에서 샤딩과 몇 가지 유사점이 있지만, 본질적으로 두 모델은 완전히 다른 기술적 경로와 시스템 철학을 나타냅니다. Actor 모델은 "다중 프로세스 비동기 컴퓨팅"을 강조합니다. 각 에이전트(Actor)는 독립적으로 실행되고, 독립적으로 상태를 유지하며, 메시지 기반 방식으로 상호 작용합니다. 샤딩은 전체 블록체인을 여러 개의 하위 시스템(샤드)으로 나누어 독립적으로 거래를 처리하는 "상태와 합의의 수평적 분할" 메커니즘입니다. Actor Model은 Web3 세계의 "분산형 지능형 에이전트 운영 체제"와 더 유사한 반면, 샤딩은 체인 내의 거래 처리 기능을 위한 구조적 확장 솔루션입니다. 두 방법 모두 병렬성을 달성하지만 시작점, 목표, 실행 아키텍처가 다릅니다.

4.1 저장 계층 위에 있는 초병렬 컴퓨터인 AO(Arweave)

AO는 Arweave 영구 저장 계층에서 실행되는 분산 컴퓨팅 플랫폼입니다. 핵심 목표는 대규모 비동기 지능형 에이전트의 작동을 지원하는 온체인 운영 체제를 구축하는 것입니다.

핵심적인 건축적 특징:

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

AO는 궁극적인 "지능형 네이티브 + 스토리지 기반 + 체인리스 아키텍처" 경로를 택하여 유연성과 모듈 분리를 강조합니다. 이는 "저장 계층에 구축된 온체인 마이크로커널 프레임워크"입니다. 시스템 경계는 의도적으로 축소되어 가벼운 컴퓨팅과 구성 가능한 제어 구조가 강조됩니다.

4.2 ICP(인터넷 컴퓨터), 풀스택 Web3 호스팅 플랫폼

ICP는 DFINITY가 출시한 Web3 기반 풀스택 온체인 애플리케이션 플랫폼입니다. 이 서비스의 목표는 온체인 컴퓨팅 기능을 Web2와 유사한 경험으로 확장하고 완전한 서비스 호스팅, 도메인 이름 바인딩, 서버리스 아키텍처를 지원하는 것입니다.

핵심적인 건축적 특징:

• 캐니스터 아키텍처(컨테이너를 에이전트로 사용): 각 캐니스터는 Wasm VM에서 실행되는 에이전트로, 독립적인 상태, 코드 및 비동기 스케줄링 기능을 갖추고 있습니다.
• 서브넷 분산 합의 시스템(서브넷): 전체 네트워크는 여러 서브넷으로 구성되며, 각 서브넷은 캐니스터 세트를 유지하고 BLS 서명 메커니즘을 통해 합의에 도달합니다.
• 비동기 호출 모델: 캐니스터는 비동기 메시지를 통해 서로 통신하여 비차단 실행과 자연스러운 병렬 처리를 지원합니다.
• 온체인 웹 호스팅: 프런트엔드 페이지를 직접 호스팅하는 스마트 계약과 기본 DNS 매핑을 지원하며, 브라우저가 dApp에 직접 액세스할 수 있도록 지원하는 최초의 블록체인 플랫폼입니다.
• 이 시스템은 완벽한 기능을 갖추고 있습니다. 온체인 핫 업그레이드, 인증 ID, 분산 난수성, 타이머 등의 시스템 API를 갖추고 있으며 복잡한 온체인 서비스 배포에 적합합니다.

ICP는 플랫폼, 통합 패키징, 강력한 플랫폼 제어를 강조하는 운영 체제 패러다임을 선택합니다. 합의, 실행, 저장, 액세스를 통합하는 "블록체인 운영 체제"를 갖추고 있습니다. 이는 완전한 서비스 호스팅 기능을 강조하며, 시스템 경계가 풀스택 Web3 호스팅 플랫폼으로 확장되었습니다.

또한, 다른 Actor Model 패러다임 병렬 컴퓨팅 프로젝트는 다음 표를 참조할 수 있습니다.

V. 요약 및 전망

가상 머신 아키텍처와 언어 시스템의 차이점에 따라 블록체인 병렬 컴퓨팅 솔루션은 대략 EVM 기반 병렬 강화 체인과 기본 병렬 아키텍처 체인(비 EVM)의 두 가지 범주로 나눌 수 있습니다.

전자는 EVM/Solidity 생태계와의 호환성을 유지하면서 실행 계층을 심층적으로 최적화하여 더 높은 처리량과 병렬 처리 기능을 구현합니다. 이 기술은 이더리움 자산과 개발 도구를 계승하면서 성능 혁신을 이루고자 하는 시나리오에 적합합니다. 대표적인 프로젝트는 다음과 같습니다.

• 모나드: 지연된 쓰기와 런타임 충돌 감지를 통해 EVM과 호환되는 낙관적 병렬 실행 모델을 구현합니다. 합의가 완료되면 종속성 그래프가 구축되고 다중 스레드 스케줄링이 수행됩니다.
• MegaETH: 각 계정/계약을 독립적인 마이크로 가상 머신(Micro-VM)으로 추상화하고, 비동기 메시지 전달 및 상태 종속성 그래프를 기반으로 고도로 분리된 계정 수준 병렬 스케줄링을 구현합니다.
• Pharos: Rollup Mesh 아키텍처를 구축하고 비동기 파이프라인과 SPN 모듈과의 협업을 통해 프로세스 전반에서 시스템 수준의 병렬 처리를 달성합니다.
• Reddio: zkRollup + GPU 아키텍처를 채택하여 일괄 SNARK 생성을 통해 zkEVM의 오프체인 검증 프로세스를 가속화하고 검증 처리량을 개선하는 데 중점을 둡니다.

후자는 이더리움 호환성의 한계를 완전히 벗어나 가상 머신, 상태 모델 및 스케줄링 메커니즘의 실행 패러다임을 재설계하여 기본적으로 고성능 동시성 기능을 구현합니다. 일반적인 하위 범주는 다음과 같습니다.

• Solana(SVM 시리즈): 계정 접근 선언과 정적 충돌 그래프 스케줄링을 기반으로 계정 수준 병렬 실행 모델을 나타냅니다.
• Sui / Aptos(MoveVM 시리즈): 리소스 객체 모델과 유형 시스템을 기반으로 컴파일 타임 정적 분석을 지원하고 객체 수준 병렬 처리를 구현합니다.
• Sei V2(Cosmos SDK 경로): 고빈도 거래 애플리케이션에 적합한 Cosmos 아키텍처에 멀티스레드 매칭 엔진과 가상 머신 동시성 최적화를 도입합니다.
• Fuel(UTXO + Sway 아키텍처): UTXO 입력 세트의 정적 분석을 통한 트랜잭션 수준 병렬 처리, 모듈형 실행 계층 및 사용자 정의 스마트 계약 언어 Sway와 결합됨

또한, 보다 광범위한 병렬 시스템인 Actor Model은 Wasm이나 사용자 정의 VM을 기반으로 하는 비동기 프로세스 스케줄링 메커니즘을 통해 "멀티 에이전트 독립 작업 + 메시지 기반 협업"의 온체인 실행 패러다임을 구축합니다. 대표적인 프로젝트는 다음과 같습니다.

• AO(Arweave AO): 지속적인 스토리지 기반 지능형 런타임을 기반으로 하는 온체인 비동기 마이크로커널 시스템 구축
• ICP(인터넷 컴퓨터): 컨테이너화된 지능형 엔티티(캐니스터)를 최소 단위로 사용하고 서브넷 조정을 통해 비동기적이고 확장성이 높은 실행을 달성합니다.
• Cartesi: 신뢰할 수 있는 컴퓨팅 결과에 대한 온체인 검증 경로를 제공하는 오프체인 컴퓨팅 환경으로 Linux 운영 체제를 도입하여 복잡하거나 리소스 집약적인 애플리케이션 시나리오에 적합합니다.

위의 논리에 따라 현재 주류를 이루는 병렬 컴퓨팅 퍼블릭 체인 솔루션을 다음 차트에 나타난 분류 구조로 요약할 수 있습니다.

용량 확장의 더 넓은 관점에서 볼 때, 샤딩과 롤업(L2)은 상태 분할이나 오프체인 실행을 통해 시스템의 수평적 확장을 달성하는 데 중점을 두는 반면, 병렬 컴퓨팅 체인(예: Monad, Sui, Solana)과 액터 지향 시스템(예: AO, ICP)은 실행 모델을 직접 재구성하고 체인 내부 또는 시스템 수준에서 기본적인 병렬성을 달성합니다. 전자는 멀티스레드 가상 머신, 객체 모델, 트랜잭션 충돌 분석 등을 통해 체인 내 처리량을 향상시킵니다. 후자는 프로세스/에이전트를 기본 단위로 사용하고, 메시지 기반 및 비동기 실행 방법을 채택하며, 여러 에이전트의 동시 작동을 실현합니다. 이에 비해 샤딩과 롤업은 "여러 체인에 걸쳐 부하를 분할"하거나 "오프체인에 아웃소싱"하는 것에 가깝고, 병렬 체인과 액터 모델은 "실행 엔진 자체에서 성능 잠재력을 방출"하여 아키텍처 진화의 보다 철저한 방향을 반영합니다.

병렬 컴퓨팅과 샤딩 아키텍처, 롤업 스케일링, 액터 지향 스케일링 경로 비교

대부분의 네이티브 병렬 아키텍처 체인이 메인넷 출시 단계에 들어섰다는 점을 지적하고 싶습니다. 전반적인 개발자 생태계는 아직 EVM 기반 Solidity 시스템과 비교하기 어렵지만, Solana와 Sui로 대표되는 프로젝트는 고성능 실행 아키텍처와 점진적인 생태적 애플리케이션의 번영으로 인해 시장에서 많은 주목을 받는 핵심 퍼블릭 체인이 되었습니다.

반면, 이더리움 롤업(L2) 생태계는 '수천 개의 체인이 동시에 출시'되거나 심지어 '과잉 용량' 단계에 접어들었지만, 현재 주류를 이루는 EVM 기반 병렬 강화 체인은 여전히 ​​대체로 테스트 네트워크 단계에 있으며, 아직 메인 네트워크 환경에서 실제로 검증되지 않았습니다. 확장성과 시스템 안정성은 아직 추가 테스트가 필요합니다. 이러한 프로젝트가 호환성을 희생하지 않고도 EVM 성능을 크게 개선하고 생태적 전환을 촉진할 수 있는지, 아니면 대신 이더리움 유동성과 개발 리소스의 차별화를 더욱 심화시킬 수 있는지는 시간이 지나서야 테스트해야 합니다.