블록체인 성능에서 주요 병목 중 하나는 디스크 I/O에 있습니다. 보다 구체적으로는, 블록 실행 후 상태 데이터를 커밋하고 저장하는 작업이 핵심 병목 지점입니다. Stable은 이 문제를 해결하기 위해 MemDB, VersionDB, 메모리 매핑 파일 I/O 메커니즘 (mmap)와 같은 아키텍처 혁신을 도입하여 처리량을 획기적으로 향상시킵니다.

​
디스크 I/O가 병목이 되는 이유

​
상태 전환과 저장

트랜잭션 블록이 실행될 때마다 블록체인은 하나의 상태에서 다음 상태로 전환됩니다. 이 과정은 다음과 같은 두 가지 기본 단계로 나뉩니다:
  1. 상태 커밋: 트랜잭션 실행 후, 새로운 애플리케이션 상태가 커밋됩니다
  2. 상태 저장: 커밋된 상태가 디스크에 영구적으로 저장되어, 향후 접근성과 과거 기록에 검증을 가능하게 합니다.
Coupled State Commitment and Storage 기존 아키텍처에서는, 상태 저장이 상태 커밋과 강하게 결합되어 있습니다. 이는 다음을 의미합니다.
  • 노드는 다음 블록을 실행하기 전에 새로운 상태가 디스크에 완전히 저장될 때까지 대기해야 합니다.
  • 상태 데이터는 고정된 주소를 가지지 않은 임의의 디스크 위치에 기록됩니다. 이로 인해 이후 트랜잭션 실행 시 상태 데이터를 검색하는 데 높은 레이턴시가 발생합니다.
합의 및 실행 계층이 아무리 최적화되어 있어도, 이처럼 느린 디스크 작업에 대한 의존성 때문에 시스템 전체 성능에는 상한선이 생깁니다.

​
더 높은 처리량을 위한 DB 연산 최적화

이러한 제약을 극복하기 위해 Stable은 상태 연산의 분리 및 메모리 매핑 DB 최적화 라는 두 가지 아키텍처 개선을 제안합니다.

​
1. 상태 커밋과 저장의 분리

Decoupled State Commitment and Storage 첫 번째 단계는 상태 커밋과 저장을 분리하는 것입니다:
  • 새로운 상태가 커밋되면, 노드는 즉시 다음 블록을 실행합니다.
  • 상태를 디스크에 저장하는 작업은 비동기적으로 백그라운드에서 처리됩니다.
이러한 분리를 통해 실행은 디스크 쓰기의 레이턴시에 영향받지 않고 즉시 진행될 수 있으며, 의존성에 의해 작업이 멈추는 현상을 제거하여 결국 전체적인 성능이 향상될 수 있습니다.

​
2. mmap 을 통한MemDB 및 VersionDB 도입

Stable은 메모리 매핑 파일 I/O 메커니즘 (mmap)을 기반으로 한 이중 데이터베이스 모델을 도입하여 이를 보강합니다:
  • MemDB (메모리 DB):
    • 자주 접근되는 최근/활성 데이터를 저장
    • mmap을 통한 고정 주소 매핑을 사용하여 빠르고 결정론적인 조회가 가능
    • 최근 수정된 상태에 접근하는 대부분의 트랜잭션에 대해 이상적인 구조
  • VersionDB (히스토리컬 DB):
    • 오래된 과거 상태를 디스크에 저장
    • 자주 접근되지 않는, 오래되거나 넓은 범위의 데이터에 대한 쿼리에 최적화됨
이 설계를 통해 핫 데이터는 빠른 메모리 기반 구조에서 제공되고, 콜드 데이터는 느리지만 영구적인 스토리지로 오프로드됩니다. 효율을 고려하여 상태를 분류하고 mmap 접근을 활용함으로써, Stable은 블록 실행 중 DB의 읽기/쓰기 지연을 크게 줄일 수 있습니다.

​
예상되는 성능 개선 및 선례

이 아키텍처 최적화는 이론적인 아이디어에 그치지 않습니다. Sei 및 Cronos와 같은 고성능 블록체인들이 유사한 구조를 이미 구현하고 있으며, 메모리 매핑 DB 및 상태 커밋/저장의 분리를 통해 전체 TPS가 최대 2배 향상되었음을 보고했습니다. Stable 또한 이와 유사한 성능 향상을 기대하고 있으며, 새로운 아키텍처에서는 스토리지 레이어가 더 이상 병목이 되지 않기 때문에, 합의 및 실행 성능이 디스크 연산에 의해 제한되지 않고 자유롭게 확장될 수 있게 됩니다.

​
추가 자료

더 자세한 기술 분석과 구현 내용을 보려면 다음 문서를 참고하세요: