Are you an LLM? Read llms.txt for a summary of the docs, or llms-full.txt for the full context.
Skip to content

실행

Stable EVM

Stable EVM

Stable EVM은 Stable의 이더리움 호환 실행 계층입니다. MetaMask와 같은 기존 이더리움 도구 및 지갑은 변경 없이 Stable과 상호 작용합니다. Stable EVM은 EVM의 개발자 경험과 Stable SDK의 모듈식 인프라를 결합합니다.

Stable EVM과 Stable SDK 간의 격차를 해소하기 위해 Stable EVM은 프리컴파일 세트를 도입합니다. 이 프리컴파일은 네이티브 Stable SDK 모듈 기능을 EVM 스마트 계약에 노출하여 핵심 체인 로직을 안전하고 원자적으로 호출할 수 있도록 합니다. 그러면 스마트 계약은 토큰 전송, 스테이킹 또는 거버넌스 참여와 같은 권한 있는 작업을 수행할 수 있습니다.

v1.4.0의 낙관적 병렬 실행

과거에는 블록체인 시스템이 순차적 실행에 의존했습니다. 즉, 각 트랜잭션이 하나씩 처리되어 모든 노드에서 결정론적 상태를 보장했습니다. 이러한 설계는 일관성을 보장하지만, 특히 최신 블록체인이 초당 수만 개의 트랜잭션을 지원하는 것을 목표로 함에 따라 처리량과 확장성을 심각하게 제한합니다.

Stable v1.4.0은 Block-STM을 통해 **낙관적 병렬 실행(OPE)**을 도입합니다. 트랜잭션은 CPU 코어에서 동시에 실행되며, 고정된 블록 내 순서는 최종 상태를 결정론적으로 유지합니다.

Block-STM 작동 방식

Block-STM은 낙관적 동시성 제어 메커니즘을 사용합니다. 트랜잭션은 먼저 충돌하지 않을 것이라는 가정하에 병렬로 실행됩니다. 그런 다음, 유효성 검사 단계에서 모든 충돌이 감지되고 재실행을 통해 처리됩니다. 이 프로세스는 다음 다섯 가지 주요 기술에 의존합니다.

1. 다중 버전 메모리 구조

Block-STM은 각 메모리 키의 여러 버전을 저장합니다.

  • 각 트랜잭션은 이전 트랜잭션이 커밋한 최신 버전을 읽습니다.
  • 실행 중에 읽기 및 쓰기 모두 버전이 지정됩니다.
  • 나중에 유효성 검사 중에 이러한 버전이 일관성을 위해 검사되어 충돌을 감지합니다.
2. 읽기-세트 / 쓰기-세트 기반 유효성 검사
  • 실행 중에 각 트랜잭션은 읽기-세트에 읽은 키와 버전을 기록합니다.
  • 실행이 끝나면 쓰기-세트를 다중 버전 메모리에 기록합니다.
  • 유효성 검사 중에 다른 트랜잭션이 읽기-세트의 키를 수정한 경우 해당 트랜잭션은 충돌하는 것으로 표시됩니다. 그런 다음 중단되고 증가된 인카네이션 번호로 재실행됩니다.
3. ESTIMATE 마커를 사용한 빠른 충돌 감지
  • 트랜잭션이 실패하면 해당 쓰기-세트가 ESTIMATE 플래그로 표시됩니다.
  • 다른 트랜잭션이 ESTIMATE로 표시된 값을 읽으면 즉시 중지하고 재실행을 기다립니다(READ_ERROR에 의해 트리거됨).
  • 이는 전체 트랜잭션 세트를 재실행하지 않고도 종속성을 신속하게 식별하여 오버헤드를 줄이는 데 도움이 됩니다.
4. 사전 설정 트랜잭션 순서
  • 블록 내의 모든 트랜잭션은 미리 설정된 결정론적 순서에 따라 실행됩니다.
  • 유효성 검사 및 커밋 단계도 동일한 순서를 따릅니다.
  • 이는 병렬 실행에서도 모든 노드가 동일한 최종 상태에 도달하도록 보장합니다.
5. 공동 작업 스케줄러
  • 공동 작업 스케줄러는 스레드 안전한 방식으로 실행 및 유효성 검사 작업자 간에 작업을 분배합니다.
  • 조기 커밋을 가속화하고 재실행을 최소화하기 위해 낮은 인덱스 트랜잭션의 우선순위를 지정합니다.
  • 스케줄러는 성공적으로 커밋될 때까지 반복되는 시도에 대한 트랜잭션 인카네이션을 관리합니다.

Block-STM의 주요 이점

  • 잠금 없는 병렬 처리: MVCC(다중 버전 동시성 제어)를 활용하여 Block-STM은 뮤텍스 잠금 없이 여러 트랜잭션이 동시에 읽고 쓸 수 있도록 합니다. 충돌은 실행 후에만 확인되므로 초기 처리 단계에서 최대 처리량을 허용합니다.
  • ESTIMATE 마커를 통한 최소 오버헤드: 실패한 트랜잭션은 쓰기-세트에 ESTIMATE 마커를 표시하여 종속 트랜잭션이 조기에 일시 중지하도록 신호를 보내 불필요한 실행을 방지합니다. 이는 유효한 실행 경로를 더 빠르게 수렴하게 합니다.
  • 효율적인 스케줄링 및 우선순위가 지정된 커밋: 공동 작업 스케줄러를 사용하여 시스템은 낮은 인덱스 트랜잭션을 먼저 커밋하여 재시도를 최소화합니다. 이는 전반적인 처리량을 개선하고 실행 주기를 단축합니다.
  • 결정론 및 합의 호환성: 모든 트랜잭션이 고정된 순서를 따르기 때문에 재실행된 트랜잭션도 궁극적으로 동일한 순서로 커밋됩니다. 이는 병렬화된 환경에서도 합의 무결성을 유지하면서 모든 노드에서 안전하고 결정론적인 상태 동의를 보장합니다.

Stable의 OPE

Stable의 낙관적 병렬 실행

Stable은 OPE를 **낙관적 블록 처리(OBP)**와 결합합니다. 두 최적화는 서로 다른 작업을 처리합니다.

OBP 정보

  • OBP는 병렬 처리가 아니라 실행 타이밍에 관한 것입니다.
  • ProcessProposal 단계에서 Stable은 블록이 다른 노드에 전파되는 동안 블록을 미리 실행합니다.
  • 결과 상태는 메모리에 캐시되고 FinalizeBlock 중에 재사용되어 시간을 절약하고 중복 계산을 줄입니다.

OPE는 여러 CPU 코어를 사용하여 실행 시간을 줄입니다. OBP는 제안 처리와 최종화에서 동일한 블록을 두 번 실행하는 것을 방지합니다.

커밋 후 재확인

블록이 커밋된 후 CometBFT는 일반적으로 멤풀에서 대기 중인 모든 트랜잭션을 재확인합니다. 이 반복적인 작업은 노드 CPU의 31~34%를 소비할 수 있습니다.

Stable v1.4.0은 선택적 RecheckTx를 추가합니다. 애플리케이션은 블록의 상태 변경 델타를 반환하고, 노드는 영향을 받는 계정의 트랜잭션만 재확인합니다. CometBFT는 애플리케이션 지원을 감지하고 선택적 재확인이 불가능할 경우 전체 재확인으로 폴백합니다.

고유한 송신자로부터 10,000개의 보류 중인 트랜잭션에 대한 최상의 벤치마크에서 처리량은 700에서 1,400 TPS로 증가했습니다. 더 일반적인 워크로드에서는 1.5–1.7배 개선이 예상됩니다.

여기에 절약된 CPU는 OPE 작업자에게 제공됩니다. MemIAVL은 이러한 실행 이득을 제한할 수 있는 스토리지 병목 현상을 제거합니다.

향후 로드맵: StableVM++

낙관적 병렬 실행(OPE) 및 낙관적 블록 처리(OBP)와 같은 노력은 여러 트랜잭션이 동시에 실행되는 방식을 최적화하는 데 중점을 두지만, 또 다른 중요한 성능 요소는 개별 트랜잭션이 얼마나 효율적으로 처리되는지입니다.

Stable은 현재 실행 속도를 높이기 위해 대체 EVM 구현을 모색 중입니다. 후보 중 C++로 작성된 고성능 EVM인 EVMONE은 기존 Go 기반 EVM을 대체할 강력한 경쟁자로 두드러집니다. 이 전환은 이론적 벤치마크를 기반으로 EVM 실행 성능에서 최대 6배 증가를 가져올 것으로 예상됩니다.

다음으로 이동할 곳

  • 스토리지 (StableDB): 디스크 I/O에 블로킹되지 않고 분리된 상태 커밋이 실행에 어떻게 공급되는지 확인하세요.
  • 고성능 RPC: 실행 결과를 클라이언트에 표시하는 분할 경로 RPC를 이해하세요.
  • 이더리움 호환성: 표준 EVM 도구를 사용하여 기존 계약을 Stable에 포팅하세요.
  • 네트워크 업그레이드: 전체 v1.4.0 릴리스 범위 및 롤아웃 노트를 검토하세요.