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은 결정론적 최종 상태를 유지하면서 Block-STM으로 EVM 트랜잭션을 동시 실행합니다. 프리컴파일은 해당 실행 계층을 Stable SDK 모듈에 연결합니다.

Stable EVM

Stable EVM

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

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

v1.8.0의 낙관적 병렬 실행

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

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

Block-STM 작동 방식

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

1. 다중 버전 메모리 구조

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

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

Block-STM의 주요 이점

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

Stable의 OPE

Optimistic Parallel Execution on Stable

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

OBP 정보

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

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

커밋 후 재확인

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

Stable v1.8.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.8.0 릴리스 범위 및 활성화 세부 정보를 검토하세요.