[CryptoTimes] 블록체인의 병렬 실행 기술 및 관련 프로덕트 분석 보고서

0. 본 보고서에 대하여

본 아티클은 2024년 6월 13일 일본 크립토 미디어 CryptoTimes의 리서치 플랫폼 CT Analysis에 발간된 'ブロックチェーンの並列実行を実現する技術とプロダクト解説レポート'의 번역본입니다. 크립토타임즈 시리즈는 액세스 프로토콜을 통해 스테이커 전용 콘텐츠로 제공되나, 본 아티클은 당사의 요청에 따라 전체 공개로 발간되었습니다.

본 보고서에서는 블록체인의 확장성 향상을 위한 트랜잭션 병렬 실행(Parallel Execution) 기술에 대해 설명합니다. 병렬 실행은 기존 블록체인의 주요 병목 현상이었던 트랜잭션 처리 속도가 개선하여, 노드가 더욱 효율적으로 트랜잭션을 처리할 수 있게 합니다.

1. 트랜잭션의 라이프사이클

병렬 처리를 이해하기 위해서는 우선 블록체인에서 트랜잭션이 어떻게 처리되는지 파악해야 합니다.

트랜잭션은 일반적으로 다음과 같은 단계를 거쳐 생성되고 실행됩니다:

1. 트랜잭션 생성: 사용자가 프라이빗 키로 트랜잭션에 서명합니다.
2. 브로드캐스트: 서명된 트랜잭션이 네트워크에 전파됩니다.
3. 트랜잭션 검증: 서명, 잔액, 형식 등 트랜잭션의 유효성을 검사합니다.
4. 메모리풀 저장: 검증을 통과한 유효한 트랜잭션을 임시로 보관합니다.
5. 블록 생성: 메모리풀에서 선택된 트랜잭션으로 블록을 생성하고, 블록 내에서 트랜잭션이 실행됩니다.
6. 블록 승인 및 추가: 새로 생성된 블록이 네트워크 전체에 전파되고, 다른 노드들이 블록을 검증하고 승인합니다.
7. 상태 업데이트: 트랜잭션 실행이 확정되고 체인의 상태가 업데이트됩니다.

이 일련의 과정은 블록체인의 노드에서 수행됩니다. 이때 노드에서 구동되는 소프트웨어가 VM (가상 머신)이며, 이는 트랜잭션의 실행과 검증을 위한 실행 환경을 제공합니다.

2. EVM에서의 트랜잭션과 병목 현상

이더리움에서 사용되는 EVM (Ethereum Virtual Machine)에는 트랜잭션 실행 과정에서 여러 병목 현상이 존재하며, 이는 확장성과 성능에 악영향을 미치고 있습니다.

다음은 이더리움의 구조적 특성으로 인해 성능을 제한하는 주요 요인입니다:

• 트랜잭션 실행이 단일 스레드로 이루어져, 한 번에 하나의 트랜잭션만 처리할 수 있습니다.
• 저장소와 그에 대한 접근 방식이 비효율적입니다.
• 실행과 합의 과정이 규칙상 분리되어 있지 않습니다.
• 상태(state)의 지속적인 증가와 향후 상태 접근에 따른 비용 증가

본 보고서에서 소개하는 L1 네트워크들은 각기 다른 설계의 VM 도입, 병렬 실행 구현, 그리고 저장소 접근 방식 개선 등을 통해 이러한 병목 현상을 해결하고, 더욱 확장 가능한 체인을 구축하는 것을 목표로 하고 있습니다.

3. 직렬 실행과 병렬 실행의 개념

3.1. 직렬 실행 (Serial Execution)

직렬 실행 방식을 채택한 블록체인에서는 예를 들어 트랜잭션 1, 2, 3이 있을 경우, 트랜잭션 1의 실행이 완료된 후에야 트랜잭션 2, 3이 순차적으로 실행됩니다. 해당 방식은 구조가 단순하고 데이터의 일관성을 유지하기 쉽다는 장점이 있지만, 트랜잭션 2, 3을 처리하기 위해 트랜잭션 1의 실행이 끝날 때까지 기다려야 하므로 처리 속도 면에서 단점이 있습니다.

3.2. 병렬 실행 (Parallel Execution)

처리 속도의 병목 현상을 해결하기 위한 대안으로, 트랜잭션 1, 2, 3을 동시에 처리하는 병렬 실행(Parallel Execution) 방식이 주목받고 있습니다. 병렬 실행에서는 트랜잭션 2가 트랜잭션 1의 완료를 기다리지 않고 병렬적으로 실행되므로, 컴퓨팅 자원을 더욱 효율적으로 활용할 수 있습니다.

4. 병렬 실행의 주요 접근 방식과 비교 기준

병렬 실행을 구현하는 접근 방식에는 여러 가지가 있습니다.

4.1. 트랜잭션의 의존 관계

의존 관계란 한 트랜잭션의 실행 결과가 다른 트랜잭션에 영향을 미치는지 여부를 의미합니다. 다음은 앨리스가 시작점인 두 개의 트랜잭션 예시입니다:

이 경우, 트랜잭션 A와 B는 앨리스의 잔고에 의존하므로 동시에 실행하면 충돌이 발생합니다.

다음은 앨리스와 카를로스가 각각 시작점인 두 개의 트랜잭션 예시입니다:

이 경우에는 트랜잭션 A와 B가 서로 의존하지 않으므로 동시에 실행해도 문제가 없습니다.

이러한 관계를 의존 관계라고 하며, 위와 같은 동시 실행에서 충돌이 발생하면 병렬 처리에 어려움이 존재합니다.

일반적으로 의존 관계 관리는 다음 두 가지 방식으로 이루어집니다:

4.2. 정적 의존 관계 관리

정적 의존 관계 관리에서 트랜잭션은 사전에 의존성을 명시합니다. 트랜잭션 생성 시 어떤 데이터가 변경될지를 지정하여, 병렬 처리 과정에서 트랜잭션 간 충돌을 실행 전에 방지합니다. 해당방식을 채택한 블록체인으로는 Solana, Sui, Sei v2 등이 존재합니다.

4.3. 동적 의존 관계 관리

동적 의존 관계 관리에서는 트랜잭션의 의존 관계를 실행 시점에 동적으로 감지합니다. 이를 통해 의존 관계가 없는 트랜잭션은 병렬로 실행하고, 충돌이 발생하면 순차적으로 재실행합니다. 이 방식을 채택한 블록체인으로는 Monad, Aptos (Block-STM) 등이 있습니다.

5. 실행 모델 비교

5.1. 병렬 실행

병렬 실행 모델에서는 동일한 작업을 동시에 처리하여 처리 속도와 효율성을 높입니다. 해당 모델에서는 여러 트랜잭션을 동시에 실행하여 처리량을 증가시킬 수 있습니다. 의존 관계가 없는 여러 트랜잭션을 동시에 처리함으로써 블록 생성 시간을 단축하고, 트랜잭션 완료까지의 대기 시간을 줄일 수 있습니다. 의존 관계가 있는 두 개의 트랜잭션이 존재하는 경우, 이는 다음 처리 단계에서 재실행됩니다.

5.2. 파이프라인 실행

파이프라인 실행 모델에서는 작업을 단계적으로 처리하되, 각 단계가 독립적으로 병행 진행됩니다. 이를 통해 트랜잭션 처리가 일관되게 이루어지며, 전체적인 처리량을 향상합니다.

모나드 (Monad)는 파이프라인 실행을 지원하며, 위 그림에서 해당 메커니즘을 설명합니다. 하나의 작업(세탁)을 여러 단계(① 세탁, ② 건조, ③ 정리, ④ 보관)로 나누고, 작업 ①이 끝나고 ②가 시작되는 시점에 새로운 작업 ①을 동시에 실행합니다. 이를 통해 컴퓨팅 자원을 더욱 효율적으로 활용할 수 있습니다.

6. 프로젝트 비교

병렬 실행을 구현하는 네트워크들은 Move나 Rust와 같은 리소스 중심 언어를 사용한다는 공통점이 있습니다. 솔라나 (Solana), 앱토스 (Aptos), 수이 (Sui)는 EVM이 아닌 VM의 확장에 중점을 두는 반면, 모나드와 세이 (Sei)는 EVM의 병렬 실행에 초점을 맞추고 있습니다.

병렬화 방식은 크게 두 가지로 나눌 수 있습니다: 트랜잭션의 의존 관계를 사전에 데이터 구조에서 감지하는 수이 및 솔라나 방식과, 병렬 실행 후 충돌을 감지하는 낙관적 실행을 채택한 앱토스, 모나드, 세이 v2 방식입니다.

7. 앱토스

앱토스는 메타 (Meta) 사의 블록체인 프로젝트 “Diem (구 Libra)”에서 파생된 프로젝트로, Move라는 프로그래밍 언어와 Move VM을 채택한 L1 블록체인입니다.

관련 보고서: 앱토스 (Aptos) — 기술적 우수성을 넘어 생태계 확장의 새 시대로

앱토스는 Block-STM이라는 병렬 실행 엔진을 채택하여 트랜잭션을 멀티스레드로 병렬 실행함으로써 확장성을 크게 향상합니다. 앱토스는 이러한 병렬화를 통해 최대 170,000 TPS까지 달성할 수 있다고 주장합니다.

7.1. Block-STM

Block-STM은 고효율 멀티스레드 인메모리 병렬 실행 엔진으로 앱토스의 높은 TPS를 실현하는 핵심 기술 중 하나입니다.

멀티스레드는 하나의 프로세스 내에서 여러 스레드를 동시에 실행할 수 있게 해 줍니다. 트랜잭션 내의 여러 처리를 동시에 실행함으로써 전체 처리 시간을 크게 단축할 수 있습니다.

7.2. Block-STM에서의 트랜잭션 실행

1. 사전 순서 결정

블록 내에서 미리 정해진 순서에 따라 트랜잭션이 실행됩니다. 이 순서에 따라 동적으로 의존 관계를 감지하고 충돌을 회피합니다.

2. 낙관적 실행 및 검증

트랜잭션은 낙관적으로 실행되며, 실행 후 검증 과정을 거칩니다. 검증 시 충돌이 감지되면 해당 트랜잭션은 중단되고 재실행됩니다.

3. 협조적 스케줄링

실행 및 검증 작업을 효율적으로 스케줄링하여 트랜잭션 실행과 검증의 우선순위를 최적화합니다. 각 트랜잭션에는 인덱스가 부여되어 순서대로 실행(또는 재실행)됩니다.

7.3. STM의 장점

Software Transactional Memory (STM)에서는 트랜잭션이 의존 관계를 명시적으로 선언할 필요가 없습니다. 사용자가 트랜잭션을 작성할 때 의존 관계를 따로 명시하지 않아도 되며, 앱토스의 병렬 엔진이 이를 자동으로 처리하여 트랜잭션 표현을 더욱 단순화합니다.

8. 수이

수이는 앱토스와 마찬가지로 Move 언어와 Move VM을 채택한 L1 블록체인입니다. 다만 수이는 Sui Move라는 변형된 버전을 사용하며, 앱토스와는 다른 방식으로 병렬화를 구현합니다.

관련 보고서: 수이 (Sui) — 무브 프로그래밍 언어 기반 DPoS 레이어-1 블록체인

수이는 병렬화 구현을 위해 솔라나와 유사하게 실행 효율을 높이는 데이터 구조를 채택했습니다.

8.1. 수이의 데이터 구조와 합의

수이는 낙관적 실행 대신 리소스 중심의 데이터 모델을 채택하여 트랜잭션의 의존 관계를 사전에 파악함으로써 충돌을 방지하면서 병렬 실행을 가능케 합니다.

객체 유형은 단일 소유자 객체와 공유 객체 두 가지로 정의됩니다.

단일 소유자 객체는 기본적으로 소유자만이 변경할 수 있으며, 이 형식으로 정의된 트랜잭션은 실행 결과가 결정론적이고 기본적으로 충돌이 발생하지 않습니다.

이런 유형의 트랜잭션은 실행 결과가 무효화되어 재실행되는 경우가 없으므로 합의 과정을 생략할 수 있습니다. 이로 인해 합의를 거치지 않아 성능이 크게 향상됩니다.

공유 객체는 NFT 발행 컨트랙트나 디파이 관련 컨트랙트 등 여러 사용자가 이용할 것으로 예상되는 객체입니다.

해당 경우에도 트랜잭션의 의존 관계가 데이터 구조 내에 정의되어 있어, 실행 시 의존 관계가 없는 트랜잭션들을 병렬로 실행할 수 있습니다.

9. 모나드

모나드는 이더리움 트랜잭션의 파이프라인 실행과 병렬 실행을 가능하게 하는 L1 블록체인입니다.

EVM 바이트코드 및 이더리움 RPC와 완벽한 호환성을 갖추고 있으며, 성능을 크게 개선하면서도 EVM 개발자들을 위한 애플리케이션 호환성을 제공합니다.

모나드는 다음 네 가지 특징을 가지고 있습니다:

1. Monad BFT — 트랜잭션 순서에 대한 합의를 이루는 합의 메커니즘입니다.
2. Deferred Execution (지연 실행) — 합의 형성과 트랜잭션 실행을 파이프라인화합니다. 노드는 트랜잭션의 순서에 대해 먼저 합의를 이루고, 이후 트랜잭션을 실행합니다. 트랜잭션 실행 결과는 합의 형성에 필요하지 않습니다.
3. Parallel Execution (병렬 실행) — 트랜잭션을 병렬로 실행하고 업데이트된 상태를 순차적으로 통합합니다.
4. Monad DB — 상태를 유지하는 데이터베이스입니다.

9.1. Optimistic Execution (낙관적 실행)

모나드는 낙관적 실행을 통해 트랜잭션 병렬 실행을 구현합니다. 이름 그대로 트랜잭션 A가 완료되기 전에 다음 트랜잭션 B를 낙관적으로 실행하여, A의 실행 완료를 기다리지 않고 B가 실행됩니다.

다만, A의 상태 업데이트로 인해 B가 무효화되는 상황도 발생할 수 있습니다. Monad의 낙관적 실행에서는 이를 방지하기 위해 실행된 트랜잭션 결과를 상태에 즉시 병합하고, 위와 같은 충돌 상황에서는 미리 실행된 A의 입력과 출력을 참조할 수 있는 메커니즘을 갖추고 있습니다. 만약 충돌이 감지되면 B는 정확한 데이터를 사용해 재실행됩니다.

10. 솔라나

솔라나는 2017년 아나톨리 야코벤코가 설립한 L1 블록체인으로, 강력한 GPU와 병렬 처리를 통해 최대 50,000 TPS까지 처리할 수 있습니다.

관련 보고서:
솔라나 (Solana) — 빠르게 성장하는 솔라나 생태계 톺아보기 (2021년 4월 24일 작성)
솔라나 (Solana) — 솔라나 서머 2.0, FTX 파산부터 지금까지 (2023년 12월 14일 작성)

솔라나는 병렬 처리 기술과 더불어 솔라나만의 독자적인 기술을 적용하여 확장성을 더욱 증가시켰습니다.

10.1. Sealevel

솔라나의 VM (SVM)의 핵심 요소 중 하나인 Sealevel 엔진을 통해 솔라나는 스마트 컨트랙트의 병렬 실행을 지원합니다.

솔라나에서는 스마트 컨트랙트를 실행할 때, 해당 트랜잭션이 어떤 데이터(상태)에 대해 읽기와 쓰기를 수행할지 실행 시점에 명시적으로 지정해야 합니다. 해당 설계를 통해 트랜잭션 간 충돌 여부를 사전에 파악하고, 충돌하지 않는 트랜잭션들을 동시에 멀티스레드로 실행할 수 있습니다.

동시 실행이 가능해짐으로써 초당 처리할 수 있는 트랜잭션의 절대 수가 증가하고, 이는 솔라나의 높은 성능으로 이어집니다.

10.2. Cloudbreak

솔라나의 효율적인 병렬 실행에 기여하는 또 다른 요소는 Cloudbreak라는 솔라나 고유의 데이터베이스 구조입니다. 해당 데이터베이스에는 계정 및 잔고 관련 정보가 저장됩니다.

병렬 실행과 관련된 주요 특징으로 뛰어난 개정 정보 인덱싱을 꼽을 수 있습니다. 계정 정보는 샤딩 (sharding)되어 분산 관리되므로 여러 샤드에 대해 병렬 처리가 가능합니다.

또한 트랜잭션 실행(계정 변경)은 인덱스를 통해 사전에 의존성을 파악할 수 있어 효율적으로 처리가 가능합니다.

11. 세이 v2

세이 v2는 의존 관계 해결에 DAG를 사용하고, 앱토스의 Block-STM과 유사한 낙관적 병렬 제어를 통해 병렬 실행을 지원하는 L1 네트워크입니다. 최근, 병렬 실행 기능을 갖춘 v2가 출시되었습니다.

세이 v2에서는 EVM을 지원하며, 이더리움과 코즘와즘 (CosmWasm)의 스마트 컨트랙트를 원활하게 상호 운용할 수 있습니다. 병렬화를 통한 성능 향상을 위해 다음과 같은 기술이 사용됩니다.

11.1. 낙관적 실행

세이 v2는 앱토스 Block-STM에서 사용하는 병렬 제어와 유사한 낙관적 실행 기술을 채택하고 있습니다. v2의 주요 변경 사항 중 하나로, 트랜잭션 작성 전에 의존 관계를 명시할 필요가 없어졌습니다. 트랜잭션은 충돌이 없다고 가정하여 낙관적 병렬 실행을 수행합니다.

또한 세이 v2에서는 네트워크가 트랜잭션 충돌을 체인 레벨에서 확인하고, 충돌이 해결될 때까지 재실행합니다. 해당 실행 방식은 세이의 네이티브 트랜잭션, 코즘와즘 트랜잭션, 그리고 EVM 트랜잭션 모두에 적용됩니다.

12. 요약 및 고찰

지금까지 블록체인의 병렬 실행을 구현하는 기술과 레이어 1 네트워크가 이를 어떻게 제품에 적용하고 있는지 설명했습니다. 이제 이러한 제품과 병렬 실행 패러다임에 대한 필자의 견해를 말씀드리겠습니다.

12.1. Solidity vs Move/Rust

본 보고서에서 소개한 블록체인은 L1, VM, 합의 등 새로운 기술을 도입하여 성능을 개선하거나 혹은 EVM을 확장하는 두 가지 접근 방식을 취하고 있습니다. Solidity (EVM)는 설계상 저장소 접근 등에 제한이 있지만, 낙관적 병렬화를 통해 확장성을 개선하고 있습니다. EVM 확장 측면에서는 L2 설루션보다 다소 떨어질지라도, 독자적인 합의를 채택함으로써 L2에서는 구현할 수 없는 1초 미만의 완결성을 실현할 수 있다는 장점이 존재합니다. 반면, 보안성 측면에서는 이더리움의 경제적 보안성에 비해 부족한 모습을 보입니다.

앱토스, 수이, 그리고 솔라나는 Move 혹은 Rust 등 리소스 중심 언어와 VM을 처음부터 구축하여 EVM보다 설계 면에서 더 효율적인 트랜잭션 처리가 가능합니다. 기본적인 처리 효율과 확장성 측면에서 EVM의 설계보다 우수하므로, 앞으로 더 높은 TPS가 요구될 경우 EVM 대신 Move VM이나 SVM이 선택될 가능성도 충분히 존재합니다. 하지만 경제적 보안성의 약점, 개발자 수 부족 등 향후 사용자 수 증가에 어려움이 될 수 있는 여러 요소도 존재하기 때문에 어떠한 접근 방식이 옳은지 단정 짓기는 어렵습니다.

12.2. 기대 활용 방안

병렬 실행을 활용할 수 있는 사례로 DEX (Perp DEX)에서의 오더북 온체인화를 기대할 수 있습니다. EVM을 활용하여 온체인 오더북을 설계하려는 시도도 여러 차례 있었지만, 완결성까지의 오랜 시간이 걸리고 트랜잭션 비용이 높아 큰 성공을 거두지 못했습니다. 따라서 현재는 오프체인의 별도 네트워크를 통해 오더북을 생성하고, 경제적 보안성만 보장받는 접근이 주를 이루고 있습니다. 병렬 실행 환경에서는 짧은 시간 내에 여러 트랜잭션을 처리할 수 있어 오프체인 네트워크에 의존하지 않고도 서비스를 제공할 수 있습니다.