만자 해설: 병렬 EVM, 블록체인 성능 병목 현상을 어떻게 해결할 것인가?

2024.04.08

만자 해설: 병렬 EVM, 블록체인 성능 병목 현상을 어떻게 해결할 것인가?

병렬 EVM은 체인 상의 거래량이 어느 정도 수준에 도달한 후 등장한 새로운 서사이다.

2024.04.08 - 02:04:57

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

병렬 EVM은 체인 상의 거래량이 어느 정도 수준에 도달한 후 등장한 새로운 서사이다.

글: @leesper6

지도 교수: @CryptoScott_ETH

TL;DR

병렬 EVM은 체인상 거래량이 일정 수준에 도달한 후 등장한 새로운 서사다. 병렬 EVM은 주로 단일체 블록체인과 모듈화된 블록체인으로 나뉜다. 단일체 블록체인은 다시 L1과 L2로 구분된다. 병렬 L1 공용 블록체인은 EVM 진영과 비EVM 진영의 두 축으로 나뉜다. 현재 병렬 EVM 서사는 초기 발전 단계에 있다.
병렬 EVM 기술 구현 경로를 분석하면 가상머신과 병렬 실행 메커니즘의 두 가지 측면을 포함한다. 블록체인 맥락에서 가상머신은 분산 상태 머신을 가상화하는 프로세스 가상머신으로서 스마트 계약을 실행하는 용도다.
병렬 실행이란 다중 코어 프로세서의 장점을 활용해 가능한 한 동시에 여러 트랜잭션을 처리하되 최종 상태가 직렬 실행 시와 동일하게 유지되는 방식이다.
병렬 실행 메커니즘은 메시지 전달, 공유 메모리, 엄격한 상태 접근 리스트의 세 가지 유형으로 나뉜다. 공유 메모리는 다시 메모리 잠금 모델과 낙관적 병렬화로 나뉜다. 어떤 방식이든 기술적 복잡성이 증가한다.
병렬 EVM 서사는 산업 성장의 내재적 동력을 지닌 동시에 보안 문제에 대한 높은 주의가 필요하다.
각 병렬 EVM 프로젝트는 각기 다른 방식으로 병렬 실행 아이디어를 제시하며 기술적 공통점과 독자적인 혁신을 모두 지닌다.

1. 산업 개요

1.1 역사적 변천

성능은 이제 산업 추가 발전의 병목 현상이 되었다. 블록체인 네트워크는 개인과 기업의 거래에 있어 새로운 탈중앙화 신뢰 기반을 창출했다.

비트코인을 대표로 하는 1세대 블록체인 네트워크는 분산 원장 방식으로 탈중앙화 전자 화폐 거래의 새 모델을 개척하며 혁명적으로 새로운 시대를 열었다. 이더리움을 중심으로 하는 2세대 블록체인 네트워크는 상상력을 극대화하며 탈중앙화 애플리케이션(dApp)을 위한 분산 상태 머신 개념을 제시했다.

그 이후 블록체인 네트워크는 웹3 인프라에서부터 DeFi, NFT, 소셜 네트워크, GameFi 등을 대표로 하는 다양한 분야에 이르기까지 수십 년간 급속히 발전하며 무수한 기술 및 비즈니스 모델 혁신을 만들어냈다. 산업의 활발한 성장은 탈중앙화 애플리케이션 생태계 구축에 더 많은 신규 사용자를 끌어들이며 제품 경험에 대해 더욱 높은 요구를 하게 만들었다.

웹3는 '전례 없는' 형태의 신제품으로서 기능적 요구사항(기능성)뿐 아니라 보안성과 성능 사이의 균형(비기능적 요구사항)도 고려해야 한다. 탄생 이후 성능 문제 해결을 위해 다양한 솔루션이 제안되었다.

이러한 솔루션들은 대략 두 부류로 나눌 수 있다. 하나는 샤딩(sharding), DAG(Directed Acyclic Graph) 같은 체인 상 확장 솔루션이고, 또 다른 하나는 플라즈마, 번개망, 사이드체인, 롤업 등 체인 외부 확장 솔루션이다. 그러나 이러한 것들조차도 체인상 트랜잭션의 폭발적 증가 속도를 따라잡기에는 역부족이다.

특히 2020년 DeFi Summer와 2023년 말 비트코인 생태계 내 인스크립션의 연이은 폭발을 겪으며 업계는 '고성능, 저비용' 요구를 충족할 새로운 성능 향상 방안이 절실하게 요청되고 있다. 병렬 블록체인이 바로 이런 배경 아래에서 등장했다.

1.2 시장 규모

병렬 EVM 서사는 병렬 블록체인 분야에서 양강 구도가 형성되었음을 의미한다. 이더리움은 트랜잭션을 순차적으로 처리하는데, 트랜잭션들이 하나씩 순서대로 실행되기 때문에 자원 활용률이 낮다. 이를 병렬 처리로 전환하면 성능이 크게 향상된다.

솔라나(Solana), 아프토스(Aptos), 스위(Sui) 등 이더리움 경쟁자들은 자체적으로 병렬 처리 능력을 갖추고 있으며 생태계도 잘 발전하고 있다. 이들의 유통 시가총액은 각각 450억 달러, 33억 달러, 19억 달러에 달하며 병렬 비EVM 진영을 형성하고 있다. 이러한 도전 앞에서 이더리움 생태계도 결코 뒤처지지 않으며 EVM 강화를 위해 앞다퉈 나서며 병렬 EVM 진영을 구성하고 있다.

Sei는 v2 버전 업그레이드 제안에서 "최초의 병렬 EVM 블록체인"이 될 것이라고 공언했으며 현재 유통 시가총액은 21억 달러로 향후 더 큰 성장 가능성을 지닌다. 마케팅 열기가 가장 뜨거운 병렬 EVM 신규 공용 블록체인 Monad는 자본시장의 큰 관심을 받고 있으며 잠재력도 무시할 수 없다. 시가총액 1.7억 달러의 L1 공용 블록체인 Canto 또한 자체 무료 공공 인프라를 제공하면서 병렬 EVM 업그레이드 제안을 발표했다.

또한 초창기 단계에 있는 여러 L2 프로젝트들도 다양한 L1 체인의 기능을 통합하여 크로스 에코시스템 성능 향상을 제공하고 있다. Neon이 6900만 달러의 유통 시가총액을 기록한 것을 제외하면 다른 프로젝트들은 관련 데이터가 부족하다. 앞으로도 더 많은 L1과 L2 프로젝트들이 병렬 블록체인 시장에 합류할 것으로 예상된다.

병렬 EVM 서사는 여전히 큰 시장 성장 잠재력을 지닐 뿐 아니라, 병렬 EVM 서사가 속한 병렬 블록체인 시장 전체도 큰 성장 가능성에 있으며 따라서 전망이 밝다.

현재 L1과 L2 전체 유통 시가총액은 7521.23억 달러이며, 병렬 블록체인 유통 시가총액은 525.39억 달러로 약 7%에 불과하다. 그 중에서도 병렬 EVM 서사 관련 프로젝트의 유통 시가총액은 23.39억 달러로 병렬 블록체인 시가총액의 4%에 불과하다.

1.3 산업 지도

업계에서는 일반적으로 블록체인 네트워크를 4단계 구조로 나눈다:

Layer 0(네트워크): 블록체인 기본 네트워크로, 기본적인 네트워크 통신 프로토콜을 처리함
Layer 1(인프라): 다양한 합의 메커니즘을 기반으로 트랜잭션을 검증하는 탈중앙화 네트워크
Layer 2(확장): Layer 1에 의존하는 다양한 2단계 프로토콜로, 특히 확장성 문제를 해결하기 위한 목적
Layer 3(애플리케이션): Layer 2 또는 Layer 1에 의존하여 다양한 탈중앙화 애플리케이션(dApp)을 구축

병렬 EVM 서사 프로젝트는 주로 단일체 블록체인과 모듈화된 블록체인으로 나뉘며, 단일체 블록체인은 다시 L1과 L2로 나뉜다. 프로젝트 총수와 주요 분야의 발전 추이를 보면, 각 병렬 EVM L1 공용 블록체인 생태계는 여전히 이더리움 생태계에 비해 큰 성장 여지를 지닌다.

DeFi 분야는 '고속, 저비용'을 요구하고 게임 분야는 '실시간 상호작용'을 요구하며, 두 분야 모두 실행 속도에 일정한 요구가 있다. 병렬 EVM은 이러한 프로젝트들에게 더 나은 사용자 경험을 제공하며 산업 발전을 완전히 새로운 단계로 이끌 것이다.

L1은 자체 병렬 실행 능력을 갖춘 신규 공용 블록체인으로 고성능 인프라다. L1 진영에서는 Sei v2, Monad, Canto 등이 자체적으로 병렬 EVM을 설계하여 이더리움 생태계와 호환되면서도 고처리량 트랜잭션 처리 능력을 제공한다.

L2는 다른 L1 체인의 기능을 통합하여 크로스 에코시스템 협업을 위한 확장 능력을 제공하며 롤업의 정수다. L2 진영에서는 Neon이 솔라나 네트워크 상의 EVM 시뮬레이터이고, Eclipse는 솔라나에서 트랜잭션을 실행하지만 EVM에서 정산을 수행한다. Lumio는 Eclipse와 유사하나 실행 계층을 Aptos로 바꾸었다.

위의 단일체 블록체인 솔루션 외에도 Fuel은 자신만의 모듈화된 블록체인 구상을 제시했다. 두 번째 버전에서 스스로를 이더리움 롤업 운영체제로 포지셔닝하며 더 유연하고 철저한 모듈화 실행 능력을 제공하겠다고 한다.

Fuel은 트랜잭션 실행에 집중하며 나머지 부분은 하나 이상의 독립 계층 블록체인에 아웃소싱함으로써 더 유연한 조합을 실현한다. 즉 L2가 될 수도 있고 L1이 될 수도 있으며 사이드체인이나 상태 채널이 될 수도 있다. 현재 Fuel 생태계에는 17개 프로젝트가 있으며 주로 DeFi, NFT, 인프라 분야에 집중되어 있다.

그러나 Orally 크로스체인 오라클만 실제 적용되었으며, 탈중앙화 대출 플랫폼 Swaylend와 영구계약 거래 플랫폼 SPARK는 테스트넷에 올라왔고 나머지 프로젝트들은 아직 개발 중이다.

2. 기술 구현 경로

탈중앙화된 트랜잭션 실행을 실현하기 위해 블록체인 네트워크는 다음 네 가지 책임을 수행해야 한다:

실행: 트랜잭션 실행 및 검증
데이터 가용성: 새로운 블록을 블록체인 네트워크의 모든 노드에 분배
합의 메커니즘: 블록 검증 및 합의 도출
정산: 트랜잭션의 최종 상태를 정산 및 기록

병렬 EVM은 주로 실행 계층의 성능 최적화다. 이것은 일층 네트워크(L1) 솔루션과 이층 네트워크(L2) 솔루션으로 나뉜다. L1 솔루션은 트랜잭션 병렬 실행 메커니즘을 도입하여 가상머신 내에서 가능한 한 병렬로 트랜잭션을 실행한다. L2 솔루션은 본질적으로 이미 병렬화된 L1 가상머신을 이용해 어느 정도 '체인 외부 실행 + 체인 내부 정산'을 실현한다.

따라서 병렬 EVM의 기술 원리를 이해하려면 이를 분해해야 한다. 먼저 가상머신(virtual machine)이 무엇인지, 그리고 병렬 실행(parallel execution)이 무엇인지 이해해야 한다.

2.1 가상머신

컴퓨터 과학에서 가상머신은 컴퓨터 시스템을 가상화하거나 시뮬레이션하는 것을 말한다.

가상머신은 두 종류로 나뉜다. 하나는 시스템 가상머신(system virtual machine)으로 물리적 컴퓨터를 여러 대의 가상 머신으로 나누어 여러 운영체제를 실행하도록 하여 자원 활용률을 높이는 것이다. 다른 하나는 프로세스 가상머신(process virtual machine)으로 특정 고급 프로그래밍 언어에 추상화 계층을 제공하여 해당 언어로 작성된 프로그램이 다양한 플랫폼에서 플랫폼 독립적으로 실행될 수 있도록 한다.

JVM은 자바 프로그래밍 언어를 위해 설계된 프로세스 가상머신의 일종이다. 자바 언어로 작성된 프로그램은 먼저 자바 바이트코드(중간 상태의 이진 코드)로 컴파일되며, JVM이 이를 해석해서 실행한다. 즉 JVM이 바이트코드를 인터프리터에 전달하면 인터프리터가 이를 다양한 머신의 기계어로 번역하여 실행한다.

블록체인 가상머신은 프로세스 가상머신의 일종이다. 블록체인 맥락에서 가상머신은 분산 상태 머신을 가상화하여 분산 방식으로 계약을 실행하고 dApp을 운영하는 용도다. JVM에 비유하자면 EVM은 솔리디티(Solidity) 언어를 위해 설계된 프로세스 가상머신이며, 스마트 계약은 먼저 opcode 바이트코드로 컴파일된 후 EVM에 의해 해석 실행된다.

이더리움 외의 신생 공용 블록체인은 가상머신을 구현할 때 WASM 또는 eBPF 바이트코드 기반의 가상머신을 더 많이 채택한다. WASM은 작고, 로딩이 빠르며, 이식성이 좋고 샌드박스 보안 메커니즘을 갖춘 바이트코드 형식으로, 개발자는 C, C++, Rust, Go, Python, Java, 심지어 TypeScript 등의 다양한 언어로 스마트 계약을 작성한 후 WASM 바이트코드로 컴파일하여 실행할 수 있다. Sei 공용 블록체인 상에서 실행되는 스마트 계약은 바로 이러한 바이트코드 형식을 채택하고 있다.

eBPF는 원래 BPF(Berkeley Packet Filter, 버클리 패킷 필터)였으며, 네트워크 패킷의 효율적 필터링을 위해 사용되다가 진화하여 eBPF가 되었고 더 풍부한 명령어 세트를 제공하게 되었다.

이 기술은 소스코드 변경 없이 운영체제 커널의 행동을 동적으로 간섭하고 수정할 수 있게 하는 혁신적인 기술이다. 이후 이 기술은 커널에서 벗어나 사용자 공간 eBPF 런타임으로 발전하였으며, 고성능, 보안성, 이식성을 갖췄다. 솔라나에서 실행되는 스마트 계약은 모두 eBPF 바이트코드로 컴파일되어 블록체인 네트워크에서 실행된다.

다른 L1 공용 블록체인 중 아프토스와 스위는 Move 스마트 계약 언어를 사용하여 특화된 바이트코드로 컴파일한 후 Move 가상머신에서 실행한다. Monad는 자체적으로 EVM opcode 바이트코드(Shanghai fork)와 호환되는 가상머신을 설계하였다.

2.2 병렬 실행

병렬 실행이란 다음과 같은 기술이다:

다중 코어 프로세서의 장점을 활용하여 여러 작업을 동시에 처리하고 시스템 처리량을 늘림
순차적으로 직렬 실행할 때와 완전히 동일한 트랜잭션 결과를 얻도록 보장함

블록체인 네트워크는 TPS(초당 처리 트랜잭션 수)를 처리 속도를 측정하는 기술 지표로 자주 사용한다. 병렬 실행 메커니즘은 복잡하며 개발자의 기술 수준을 시험하는 요소이므로 설명하기 쉽지 않다. 아래에서는 '은행' 사례를 들어 병렬 실행이 무엇인지 설명하겠다.

(1) 우선, 직렬 실행이란 무엇인가?

상황 1: 시스템을 은행으로, 작업 처리 CPU를 창구로 본다면 직렬 작업 처리는 은행이 오직 하나의 창구만 운영하는 것과 같다. 이 경우 은행 업무를 보기 위해 고객(작업)들은 일렬로 줄을 서서 차례로 업무를 본다. 각 고객에게 창구 직원은 동일한 동작(명령 실행)을 반복하여 업무를 처리한다. 자신의 차례가 오지 않은 고객은 기다릴 수밖에 없어 거래 시간이 늘어난다.

(2) 그렇다면 병렬 실행이란 무엇인가?

상황 2: 은행이 혼잡을 보고 여러 개의 창구를 추가하여 업무를 처리한다. 4명의 직원이 동시에 창구 업무를 처리하므로 원래보다 약 4배 빠르며 고객 대기 시간도 약 1/4로 줄어들고 은행의 업무 처리 속도가 향상된다.

(3) 보호 조치 없이 두 사람이 동시에 다른 사람에게 송금하면 어떤 오류가 발생할까?

상황 3: A, B, C 세 사람의 계좌 잔액이 각각 2 ETH, 1 ETH, 0 ETH라고 하자. 지금 A와 B가 각각 C에게 0.5 ETH를 송금하려 한다. 직렬 실행 시스템에서는 아무런 문제가 없다(왼쪽 화살표 "<="는 장부 읽기를, 오른쪽 화살표 "=>"는 장부 쓰기를 나타냄, 아래 동일)

하지만 병렬 실행은 겉보기만큼 간단하지 않다. 매우 미묘한 디테일들이 존재하며 조금만 주의를 기울이지 않아도 매우 심각한 오류를 초래할 수 있다. 만약 A와 B의 C에 대한 송금 거래가 병렬로 실행된다면 각 단계의 수행 순서에 따라 일관되지 않은 결과를 초래할 수 있다:

병렬 작업 1이 A에서 C로의 송금을 실행하고, 병렬 작업 2가 B에서 C로의 송금을 실행한다. 표에서 * 표시가 된 단계는 문제가 있다: 작업이 병렬로 실행되기 때문에 단계 2에서 병렬 작업 1의 수지 균형 계산이 장부에 기록되기 전에 단계 3에서 작업 2가 C의 계좌 잔액(아직 0)을 읽어오고, 단계 5에서 잔액 0을 기반으로 잘못된 수지 균형 계산을 하며, 단계 6에서 장부 업데이트 작업에서 단계 4에서 이미 업데이트된 계좌 잔액 0.5를 잘못 다시 0.5로 업데이트한다. 결국 A와 B가 각각 C에게 0.5 ETH를 송금했음에도 불구하고 거래 완료 후 C의 계좌 잔액은 0.5 ETH에 불과하며 나머지 0.5 ETH는 사라진다.

(4) 보호 조치 없이 의존 관계가 없는 두 작업의 병렬 실행은 오류가 발생하지 않는다.

상황 4: 병렬 작업 1이 A(잔액 2 ETH)가 C(잔액 0 ETH)에게 0.5 ETH를 송금하고, 병렬 작업 2가 B(잔액 1 ETH)가 D(잔액 0 ETH)에게 0.5 ETH를 송금한다. 두 송금 작업 사이에는 의존 관계가 없다. 따라서 두 작업의 단계가 어떻게 교차 실행되든 위와 같은 문제는 발생하지 않는다:

두 시나리오를 비교 분석하면 작업 사이에 의존 관계가 있을 때 병렬 실행 시 상태 업데이트 오류가 발생할 수 있고, 그렇지 않으면 오류가 발생하지 않는다는 것을 알 수 있다. 다음 두 조건 중 하나라도 만족하면 작업(거래) 사이에 의존 관계가 있다고 말한다:

한 작업이 쓰는 출력 주소가 다른 작업이 읽는 입력 주소인 경우
두 작업이 동일한 주소에 출력하는 경우

이것은 탈중앙화만의 특징은 아니다. 병렬 실행이 필요한 모든 시나리오에서 의존 관계가 있는 여러 작업이 공유 리소스(은행 예에서의 '장부', 컴퓨터 시스템의 공유 메모리 등)에 보호 없이 접근할 경우 데이터 불일치가 발생하며 이를 경쟁 조건 문제(data races)라고 한다.

업계는 병렬 실행의 경쟁 조건 문제를 해결하기 위해 메시지 전달 메커니즘, 공유 메모리 메커니즘, 엄격한 상태 접근 리스트 메커니즘의 세 가지 실행 메커니즘을 제안했다.

2.3 메시지 전달 메커니즘

상황 5: 은행이 4개의 창구에서 동시에 고객을 상대한다고 가정하자. 이제 4명의 창구 직원에게 각각 전용 장부를 주되, 이 장부는 자신만 수정할 수 있다. 장부에는 자신이 담당하는 고객의 계좌 잔액이 기록되어 있다.

각 직원이 고객 업무를 처리할 때 해당 고객 정보가 자신의 장부에 있으면 바로 처리하고, 그렇지 않으면 다른 직원에게 해당 고객의 업무 내용을 알려주면 다른 직원이 처리한다.

이것이 메시지 전달 모델의 원리다. 액터 모델(actor model)은 메시지 전달 모델의 일종으로, 각 트랜잭션을 처리하는 실행자가 액터(actor)이며, 각 액터는 자신의 프라이빗 데이터에만 접근할 수 있고, 다른 액터의 프라이빗 데이터에 접근하려면 메시지를 보내야 한다.

액터 모델의 장점은 각 액터가 자신의 프라이빗 데이터에만 접근할 수 있으므로 경쟁 조건 문제가 발생하지 않는다는 점이다.

단점은 두 가지다. 하나는 각 액터가 직렬로만 실행되기 때문에 일부 시나리오에서 병렬 이점을 살리지 못한다는 점이다(예: 2번, 3번, 4번 직원이 동시에 1번 직원에게 고객 A의 계좌 잔액을 묻는 메시지를 보내면, 1번 직원은 이런 모델에서 하나씩 메시지를 처리해야 하고, 본래는 병렬 처리가 가능했을 것이다).

두 번째는 시스템 전체 상태에 대한 글로벌 정보가 없어 시스템이 복잡할 경우 전반적인 파악, 버그 위치 파악 및 수정이 어렵다는 점이다.

2.4 공유 메모리 메커니즘

2.4.1 메모리 잠금 모델

상황 6: 은행에 하나의 큰 장부만 있고, 여기에는 모든 고객의 계좌 잔액이 기록되어 있다고 가정하자. 장부 옆에는 장부를 수정할 수 있는 한 자루의 서명용 펜만 있다.

이 경우 4명의 직원은 업무를 볼 때 누가 더 빠르게 달려가느냐에 달려있다: 한 직원이 먼저 펜을 가져가(잠금) 장부를 수정하며 업무를 시작하고, 다른 3명의 직원은 기다려야 한다. 직원이 펜을 놓을 때까지(잠금 해제) 다른 직원들은 펜의 사용권을 두고 경쟁하며, 이렇게 반복된다. 이것이 바로 메모리 잠금 모델(memory locks)이다.

메모리 잠금은 병렬 작업이 공유 리소스에 접근할 때 잠금(lock) 작업을 수행하여 공유 리소스에 접근하는 동안 다른 작업은 잠금 해제(unlock) 후 다시 잠금을 걸어야 접근할 수 있게 한다.

읽기-쓰기 잠금(read-write lock)은 더 정교한 처리를 하며 공유 리소스에 읽기 잠금(read lock) 또는 쓰기 잠금(write lock)을 걸 수 있다. 차이점은 여러 병렬 작업이 동시에 여러 번의 읽기 잠금을 걸고 공유 리소스 데이터를 읽을 수 있지만 수정은 허용되지 않는다는 점이며, 쓰기 잠금은 하나만 걸 수 있고, 잠근 자만이 독점적으로 접근할 수 있다.

솔라나, 스위, Sei v1은 메모리 잠금 기반 공유 메모리 모델을 채택하고 있다. 이 메커니즘은 겉보기엔 간단해 보이지만 구현은 매우 복잡하며 개발자의 멀티스레드 프로그래밍 능력을 시험한다. 조금만 실수해도 각종 버그를 남길 수 있다:

상황 1: 작업이 공유 리소스에 잠금을 건 후 실행 중 오류로 충돌 종료되면 공유 리소스가 잠긴 채로 접근 불가능해짐
상황 2: 작업이 이미 잠금을 걸었으나 실행 중 비즈니스 로직 중첩으로 인해 재잠금을 시도하여 자기 자신을 기다리게 됨

메모리 잠금 모델은 가장 쉽게 데드락(dead lock), 라이브락(live lock), 기아(starvation) 등의 문제가 발생한다:

(1) 여러 병렬 작업이 여러 공유 리소스를 두고 경쟁하며 각 작업이 일부를 점유하고 상대방이 자원을 해제하기를 기다리며 데드락 발생

(2) 병렬 작업이 다른 병렬 작업이 활성 상태임을 감지하고 자신의 공유 리소스를 양보하여 서로 양보를 반복하며 라이브락 발생

(3) 우선순위가 높은 병렬 작업이 항상 공유 리소스 접근 권한을 얻어 다른 낮은 우선순위 작업이 장시간 기다리는 '기아' 현상 발생

2.4.2 낙관적 병렬화

상황 7: 은행 4명의 직원 각자가 업무를 처리할 때 별도로 장부를 조회하고 수정할 수 있으며 다른 직원이 장부를 사용하는지 여부는 신경 쓰지 않는다. 직원은 장부를 사용할 때 자신의 이름이 적힌 개인 라벨을 붙인다. 업무를 마친 후 매번 다시 검토하여 라벨이 자신의 것이 아닌 것을 발견하면 기록이 다른 직원에 의해 수정된 것이므로 이번 업무는 무효화하고 다시 처리한다.

이것이 낙관적 병렬화의 기본 원리다. 낙관적 병렬화의 핵심 사상은 모든 작업이 상호 독립적이라고 가정하는 것이다. 먼저 병렬로 작업을 실행한 후 각 작업을 검증하고, 검증에 실패하면 해당 작업을 다시 실행하여 모든 작업이 완료될 때까지 반복한다. 8개의 병렬 작업이 낙관적 병렬화 방식으로 실행되며, 이 과정에서 2개의 공유 리소스 A와 B에 접근한다고 가정하자.

1단계 실행 시 작업 1, 2, 3이 병렬로 실행된다. 하지만 작업 2와 3이 동시에 공유 리소스 B에 접근하여 충돌이 발생하므로 작업 3은 다음 단계에서 재스케줄링되어 실행된다. 2단계 실행 시 작업 3과 4가 동시에 공유 리소스 B에 접근하여 작업 4가 재스케줄링되어 실행되고, 이처럼 계속 진행되어 모든 작업이 완료될 때까지 충돌이 발생한 작업이 지속적으로 반복 실행된다.

낙관적 병렬화 모델은 각 쓰기 값과 그 버전 정보를 기록하는 다중 버전 메모리 데이터 구조(multi-version in-memory data structure)를 사용한다(은행 직원 라벨 부착과 유사).

각 병렬 작업의 실행은 두 단계로 나뉜다: 실행(execution)과 검증(validation). 실행 단계에서는 모든 읽기 및 쓰기 동작을 기록하여 읽기 집합(read set)과 쓰기 집합(write set)을 형성한다. 검증 단계에서는 읽기 집합과 쓰기 집합을 다중 버전 데이터 구조와 비교하여 최신이 아니면 검증에 실패한다.

낙관적 병렬화 모델은 소프트웨어 트랜잭션 메모리(Software Transaction Memory, STM)에서 유래했는데, 이는 데이터베이스 분야의 무잠금 프로그래밍 메커니즘이다. 블록체인 네트워크가 트랜잭션을 처리하는 것이 자연스럽게 결정적인 순서를 가지므로 이 개념이 도입되어 Block-STM 메커니즘으로 발전했다. 아프토스와 Monad는 Block-STM을 자신의 병렬 실행 메커니즘으로 채택했다.

참고로 Sei 공용 블록체인은 곧 출시될 v2 버전에서 기존 메모리 잠금 모델을 폐기하고 낙관적 병렬화 모델로 전환한다. Block-STM은 매우 빠른 실행 속도를 가지며, 실험 환경에서 아프토스의 트랜잭션 실행 속도가 놀라운 160k tps에 달해 순차 실행보다 18배 빠르다.

Block-STM은 복잡한 트랜잭션 실행 및 검증을 핵심 메커니즘 구현 팀에 맡기므로 개발자는 순차 실행 프로그램을 작성하듯 쉽게 스마트 계약을 작성할 수 있다.