목적 및 범위
이 문서는 StableNet에서 트랜잭션이 시스템에 제출된 이후 블록체인에 최종 포함(finalized) 되기까지의 전체 라이프사이클을 설명합니다.RPC 또는 P2P를 통한 제출, 트랜잭션 풀 검증 및 수락, 마이닝 후보 선정, 상태 전이(EVM 실행), 블록 봉인, 합의 기반 최종화까지의 전 과정을 포괄합니다. 트랜잭션 타입 및 인코딩에 대한 세부사항은 트랜잭션 유형 및 인코딩을 참조하세요.
트랜잭션 풀 관리 정책은 트랜잭션 풀을 참조하세요.
EVM 실행 내부 동작은 EVM 실행을 참조하세요.
가스 수수료 및 팁 정책은 가스 수수료 정책을 참조하세요.
트랜잭션 라이프사이클 개요
StableNet의 트랜잭션은 다음 7단계 라이프사이클을 순차적으로 거칩니다. 트랜잭션 라이프사이클 단계- 트랜잭션 제출
- 풀 수준 검증 및 수락
- 마이닝 후보 선정
- 트랜잭션 실행(상태 전이)
- 블록 봉인 및 전파
- 블록 검증 및 체인 삽입
- 합의 기반 최종성 획득
단계 1: 트랜잭션 제출
트랜잭션은 두 가지 경로를 통해 StableNet 노드로 유입됩니다.진입점
| Path | Entry Point | Description |
|---|---|---|
| RPC API | internal/ethapi/api.go (TransactionAPI) | JSON-RPC eth_sendTransaction 또는 eth_sendRawTransaction 호출을 통해 트랜잭션을 제출하며, 내부적으로 SubmitTransaction → 백엔드 SendTx를 거쳐 txpool로 전달됩니다 |
| P2P Network | eth/handler.go (txFetcher) | 피어가 브로드캐스트한 트랜잭션을 수신한 후 txpool.Add(tx, remote) 경로로 풀에 추가합니다 |
TransactionArgs.setDefaults를 통해 nonce, gas limit, fee 필드가 보완되며,지갑 또는 키스토어 기반 서명(
SignTx) 이후 완전한 서명 트랜잭션이 txpool로 전달됩니다.
단계 2: 풀 수준 검증 및 수락
txpool은 제출된 트랜잭션을 즉시 실행하지 않고, 풀 레벨 검증 파이프라인을 통해 선별합니다. 주요 검증 항목은 다음과 같습니다.- 트랜잭션 타입 유효성(포크 활성화 여부 포함)
- 가스 한도 및 최소 가스 가격 조건
- EIP-1559 수수료 필드(
maxFeePerGas,maxPriorityFeePerGas) 일관성 - nonce 순서 및 계정별 nonce 갭 여부
- replacement 규칙(동일 nonce 재제출 시 가격 상승 조건)
- 계정별 queue / pending 슬롯 제한
- 수수료 위임 트랜잭션 타입 허용 여부
pending 또는 queued 서브풀에 저장되며, 조건을 만족하지 못한 트랜잭션은 즉시 거부되거나 queue 단계에서 대기 상태로 유지됩니다.
단계 3: 마이닝 후보 선정
마이닝 워커(miner/worker.go)는 다음 시점에 트랜잭션을 블록 후보로 선택합니다.
NewTxsEvent수신 시- 새로운 블록 빌드를 위한 작업 루프 시작 시
- 현재 블록의
baseFee, GovValidator에서 가져온 거버넌스 가스 팁, blob 수수료(EIP-4844) 등을 반영하여txpool.PendingFilter를 구성합니다. TxPool().Pending(filter)를 호출하여 조건을 만족하는 후보 트랜잭션을 조회합니다.- 로컬 트랜잭션을 우선 처리한 뒤 원격 트랜잭션을 고려합니다.
newTransactionsByPriceAndNonce를 통해 다음 기준으로 정렬합니다:- 유효 가스 팁 및 수수료 수준
- 계정별 nonce 연속성
- Anzeon 환경에서의 승인 계정 여부
commitTransactions가 블록 가스 한도에 도달할 때까지 탐욕적으로 트랜잭션을 선택합니다.
단계 4: 트랜잭션 실행 (상태 전이)
선택된 각 트랜잭션은core.StateTransition을 통해 순차적으로 실행됩니다.
실행 흐름은 다음과 같습니다.
NewStateTransition(evm, msg, gasPool)생성TransitionDb()호출로 상태 전이 시작preCheck()에서 실행 전 검증 수행:- nonce 정확성(TooLow / TooHigh / Max)
- 발신자가 EOA인지 여부(일반 컨트랙트 계정은 거부, EIP-7702 위임 코드 예외)
gasFeeCap,gasTipCap과 블록baseFee의 관계- blob 수수료(EIP-4844) 및 authorization(EIP-7702) 형식 검증
buyGas()에서 가스 한도 기준 선차감 수행:- 수수료 위임이 없는 경우 발신자 잔액 차감
- 수수료 위임이 있는 경우 FeePayer 잔액 차감
- EVM 실행을 통해 컨트랙트 호출 또는 생성 수행
- 사용 가스, 환불 가스, 실행 결과 및 로그 계산
단계 5: 블록 봉인 및 전파
모든 선택된 트랜잭션 실행이 완료되면 워커는 다음을 수행합니다.- 상태 루트, 영수증 루트, 로그 블룸을 계산하여 블록 헤더를 완성합니다.
- WBFT 합의 규칙에 따라 블록을 봉인합니다(BLS 서명 집계).
- 봉인된 블록을 로컬 체인에 기록하고,
eth/handler및 P2P 서브프로토콜을 통해 네트워크에 브로드캐스트합니다.
단계 6: 블록 검증 및 체인 삽입
다른 노드들은 수신한 블록에 대해 다음 검증을 수행합니다.- 헤더 검증(부모 해시, 타임스탬프, 가스 한도, extra 데이터)
- 트랜잭션 머클 루트 및 영수증 루트 검증
- 상태 재실행을 통한 상태 루트 검증
- WBFT 합의 서명 유효성 검증
단계 7: 최종성 및 확인
WBFT 합의에서 요구하는 조건(2/3 이상 검증자 서명)이 충족되면 블록은 finalized 상태로 표시됩니다.- finalized 블록은 되돌릴 수 없습니다.
- 클라이언트 및 애플리케이션은 이 시점을 기준으로 트랜잭션을 확정(confirm) 된 것으로 판단합니다.
- Safe / Final 헤더 개념을 통해 UI 및 API에서 신뢰 수준을 구분할 수 있습니다.