개발자도 헷갈리는 ‘트랜잭션 검증 과정 정리’: UTXO부터 가스, 메르클 루트까지 한 번에 끝내기

블록체인 지갑에서 전송 버튼을 누르는 순간, 내 트랜잭션은 정확히 어떤 검증 절차를 거쳐 네트워크에 포함될까? 오늘은 제목 그대로 “트랜잭션 검증 과정 정리”를 표준처럼 딱딱하게 나열하기보다, 실무자가 현장에서 마주하는 체크포인트 중심으로 풀어보려 한다. 비트코인의 UTXO 모델과 이더리움의 계정(Account) 모델을 나란히 놓고, 노드가 어떤 규칙으로 트랜잭션을 거르고 받아들이는지, 왜 내 거래가 안 붙는지, 수수료 튜닝은 어떻게 해야 하는지까지 한번에 훑어보자.

OKX 오케이엑스

20% 수수료 캐시백
$60,000 선물 보너스

Bybit 바이비트

20% 거래 수수료 할인
$30,050 가입 보너스

Binance 바이낸스

20% 거래 수수료 할인
$100 가입 보너스
$10,000 선물 보너스

MEXC 멕스

20% 수수료 캐시백
$8,000 보너스

Gate 게이트아이오

20% 수수료 캐시백
$10,000 보너스

Bitget 비트겟

50% 거래 수수료 할인
20% 수수료 캐시백
$6,200 선물 보너스

CoinEx 코인엑스

$100~$1,500 USDT 상당의 보너스 팩
수수료 할인

핵심 키워드 미리보기: 트랜잭션 검증 과정 정리, 비트코인 트랜잭션 검증, 이더리움 트랜잭션 검증, UTXO, 서명 검증 ECDSA, 메모리풀, RBF, EIP-1559, 메르클 루트, nonce 검증

트랜잭션은 ‘요청’이 아니라 ‘증명’이다

트랜잭션(Transaction)은 블록체인 상태를 변경해 달라는 “요청”이 아니라, 변경을 정당화하는 “증명” 패키지다. 즉 “내가 이 자산을 쓸 권리가 있다”는 점을 서명과 규칙 준수로 입증해야 한다.
이 증명이 충분히 설득력 있으면 노드의 메모리풀(Mempool)에 들어가고, 채굴자/검증자에 의해 블록에 포함된다. 설득력이 부족하면? 노드는 가차없이 거절한다.

이 기본 인식을 갖고 나면, 아래의 검증 단계가 왜 필요한지 직관이 생긴다.

큰 그림: 노드가 트랜잭션을 거르는 표준 흐름

1) 형식 검증: 직렬화 포맷이 맞는가? 필수 필드가 유효한 범위인가? 크기 제한을 넘지 않는가?
2) 서명 검증: 입력 소유권 증명(비트코인) 또는 송신자 인증(이더리움)이 정확한가?
3) 잔액/자원 검증: UTXO 존재 여부(비트코인), 계정 잔액·nonce·가스(이더리움)가 충분한가?
4) 정책 검증: 표준성(IsStandard), dust 규칙, RBF 정책(비트코인) 등 노드 정책을 준수하는가?
5) 수수료 적정성: feerate(vBytes 대비 수수료), EIP-1559 base fee·priority fee 등 네트워크 상황에 맞는가?
6) 메모리풀 수용: 중복, 더 비싼 대체 트랜잭션 여부, 종속성(conflicts) 체크 후 수용 또는 거절
7) 블록 포함 및 최종성: 블록에 담긴 뒤엔 블록 수준 검증(머클 루트, 총 가스/용량 제한, 합의 규칙)까지 통과해야 한다.

UTXO vs Account: 모델 차이가 검증 포인트를 바꾼다

비트코인(UTXO 모델): 각 입력이 과거의 미사용 트랜잭션 출력(UTXO)을 정확히 소비하는지, 스크립트 조건을 만족하는지, 총 입력 ≥ 총 출력 + 수수료인지 확인한다.
이더리움(계정 모델): 송신자 계정의 nonce 연속성, 잔액이 금액+가스 비용을 커버하는지, 서명과 체인 ID가 맞는지, 가스 한도 내에서 EVM 상태 전이가 유효한지 확인한다.

이 차이가 실무에서 “왜 안 붙지?”를 진단할 때 결정적 힌트를 준다.

비트코인: 트랜잭션 검증 과정 정리 (UTXO 상세)

1) 구조·정책

버전, locktime, input/output 개수 범위, 전체 크기 제한(블록 weight 규칙의 간접 영향) 확인
표준성(IsStandard) 정책: 너무 복잡하거나 비표준 스크립트는 릴레이 거부 가능
dust 출력 차단: 너무 작은 출력은 수수료 낭비 + 네트워크 부하로 간주되어 거절될 수 있음

2) UTXO 및 이중지불(double-spend) 체크

각 입력이 참조하는 outpoint(txid:vout)가 실제 UTXO 세트에 존재하는지
메모리풀 수준 이중지불 충돌 여부: 이미 동일 UTXO를 소비하려는 다른 트랜잭션이 있는지

3) 수수료와 feerate

fee = sum(inputs) – sum(outputs)
vBytes(= weight/4) 기준 feerate가 노드의 정책 임계값 이상인지. 혼잡 시 feerate가 낮으면 릴레이·채굴 우선순위에서 밀린다.
SegWit: witness 데이터가 weight에 반영. 서명 말레어빌리티 완화, feerate 계산 관점에서도 중요

4) 스크립트/서명 검증

ScriptSig + ScriptPubKey(또는 witness script) 실행 성공 여부
ECDSA(secp256k1), BIP-66/62 등 DER 형식, Low-S 규칙 준수
SIGHASH 유형에 따른 서명 범위 확인, Taproot(스나이더)·Schnorr 서명 적용 시 해당 규칙 준수

5) RBF(Replace-By-Fee) 및 정책 교체

입력의 sequence 설정이 RBF 허용이면, 더 높은 feerate의 대체 트랜잭션으로 교체 가능
지갑에서 수수료 부족으로 대기 중이면 RBF로 수수료 인상(replace) 시도

6) 블록 포함 후 검증

머클 루트에 트랜잭션 포함, 블록 헤더의 작업증명(PoW), 시간·난이도 규칙 통과
코인베이스 보상·수수료 집계 정확성 확인

Tip: 로컬에서 testmempoolaccept로 사전 점검하면 “이 트랜잭션을 노드가 왜 거절하는지” 바로 힌트를 얻는다.

이더리움: 트랜잭션 검증 과정 정리 (Account/EVM 상세)

1) 타입과 서명

Legacy(Type 0), Access List(Type 1, EIP-2930), Dynamic Fee(Type 2, EIP-1559)
ECDSA 서명 검증 + EIP-155 체인 ID 체크: 올바른 네트워크에 서명했는지

2) nonce 및 잔액

송신자 계정의 현재 nonce와 정확히 일치해야 함(갭이 있거나 중복이면 거절)
잔액 ≥ value + gasLimit × maxFeePerGas(or gasPrice) 충족

3) 가스 규칙

Intrinsic gas(데이터 바이트 0/비0 비용, 계약 생성 시 추가 비용) 이상인지
EIP-1559: maxFeePerGas ≥ baseFee + priorityFee 조건을 만족해야 포함 가능
블록 가스 한도 내에서 EVM 실행이 완료되어야 하며, 런타임 오류 시 revert(상태 롤백) + 사용한 가스는 차감

4) 트랜잭션 풀(txpool) 정책

동일 nonce의 대체 트랜잭션은 “가격 상승 폭” 조건 충족 시 교체(클라이언트별 정책 상이, 보통 10%+)
낮은 수수료의 트랜잭션은 혼잡 구간에서 장시간 대기 가능. baseFee 급등 시 maxFeePerGas 재설정 필요

5) 블록 포함 후 검증

블록 헤더의 합의(현재 PoS: 검증자 서명·슬롯/에포크 규칙), 총 가스 사용량 한도, 로그/블룸 업데이트, 상태 루트(state root) 정합성

Tip: eth_estimateGas로 대략적 가스 한도를, eth_maxPriorityFeePerGas 또는 메타클라이언트 추정치를 참고하면 포함 가능성을 높일 수 있다.

왜 내 트랜잭션이 안 붙나요? 자주 터지는 이슈 8가지

1) 수수료 낮음: 비트코인 feerate, 이더리움 priority fee가 시장 수준보다 낮으면 릴레이/포함 지연
2) nonce 갭(이더리움): 이전 nonce가 미포함 상태면 이후 nonce는 대기열에 묶인다
3) 잔액 부족: value만 맞추고 가스 비용(또는 fee)을 간과하는 경우 다반사
4) UTXO 파편화: 너무 많은 잔돈이 쪼개져 있으면 트랜잭션 크기가 커져 수수료 부담 증가
5) 비표준 스크립트(비트코인): 릴레이 정책 위반으로 메모리풀 입장 거절
6) 말레어빌리티/형식 위반: 서명 DER 형식, Low-S 등 규칙 미준수
7) RBF 미허용: 대체 수수료 인상 시퀀스 설정이 안 되어 교체 불가
8) 체인 혼동: 테스트넷/메인넷 체인 ID 착오로 서명·브로드캐스트 실패

개발자·트레이더를 위한 실전 점검 체크리스트

비트코인
- [ ] inputs 참조 UTXO 존재, 이중지불 충돌 없음
- [ ] fee와 vBytes 계산으로 타겟 블록 당 포함 가능 feerate 설정
- [ ] 스크립트/서명 검증 통과, IsStandard 준수, dust 출력 회피
- [ ] RBF 필요 시 sequence 세팅, CPFP 전략 고려
이더리움
- [ ] nonce 정확히 일치, 동일 nonce의 하위가 선행 포함되도록 관리
- [ ] value + gasLimit × maxFeePerGas ≤ balance
- [ ] EIP-1559 기준 baseFee + priority 설정, 혼잡 시 priority 가산
- [ ] 계약 호출이면 estimateGas로 상한 파악, revert 여지 고려해 여유 가스 설정

머클 트리와 블록 수준 검증: “포함되었다”를 증명하는 방법

비트코인·이더리움 모두 트랜잭션들을 해시로 모아 머클 루트를 만든다(이더리움은 추가로 상태 루트를 헤더에 보관).
SPV(경량 지갑)는 블록 헤더 체인과 머클 증명만으로 “이 트랜잭션이 특정 블록에 포함”되었음을 검증한다.
실무 팁: 거래 상대방에 “머클 증명과 블록 헤더”를 요구하면 중앙화된 탐색기 의존을 줄일 수 있다.

보안 관점: 말레어빌리티, ECDSA, 그리고 프로토콜 개선

비트코인: BIP-66(서명 DER 형식), BIP-62(말레어빌리티 완화), SegWit/Taproot로 트랜잭션 ID 안정성 강화
이더리움: EIP-2로 서명 유효성 강화, EIP-155로 체인 재사용 공격 방지
공통: 프런트엔드/백엔드에서 서명 파라미터 정규화, 재생(replay)·피싱 방지 체인 ID 확인은 필수

노드·CLI로 미리 검증하는 법

비트코인 Core
- decoderawtransaction, testmempoolaccept, sendrawtransaction
- 특정 수수료에서 포함 예상 블록 높이는 mempool 정책·혼잡도에 좌우. 탐색기나 fee estimator 참고
이더리움 클라이언트(geth, nethermind 등)
- eth_call, eth_estimateGas, eth_feeHistory, txpool_content
- 대체 트랜잭션 교체율 정책은 클라이언트 별 차이 존재(보통 10% 가격 인상)

간단 의사코드: 노드가 트랜잭션을 검증·수용하는 흐름

“`pseudo
function validateTransaction(tx, chainState, mempool):
if !parseable(tx) or !withinSizeLimits(tx):
return Reject(“format/size”)

if isBitcoin(tx):
if !isStandard(tx): return Reject(“policy”)
if !allInputsExistAsUTXO(tx, chainState): return Reject(“missing-UTXO”)
if isDoubleSpend(tx, mempool): return Reject(“double-spend”)
if !verifyScriptsAndSignatures(tx): return Reject(“script-fail”)
fee = sumInputs(tx) – sumOutputs(tx)
if fee < minRelayFeeByVBytes(tx): return Reject(“low-fee”)
else if isEthereum(tx):
if !verifyECDSASignature(tx): return Reject(“bad-signature”)
if tx.nonce != account.nonce: return Reject(“bad-nonce”)
if account.balance < tx.value + tx.gasLimit * tx.maxFeePerGas:
return Reject(“insufficient-funds”)
if !gasAndEIP1559Valid(tx, chainState): return Reject(“fee-policy”)

if conflictsWithMempoolPolicies(tx, mempool):
return Reject(“policy-conflict”)

mempool.add(tx)
propagate(tx)
return Accept
“`

수수료와 체감 속도를 높이는 현실적 팁

비트코인: 혼잡도 급등 시에는 RBF를 켠 상태에서 전송하고, feerate를 타깃 블록 포함 시간에 맞춰 조절한다. 필요하다면 자식이 부모를 끌어올리는 CPFP(Child-Pays-For-Parent) 전략도 고려.
이더리움: baseFee가 변동하므로 maxFeePerGas를 여유 있게, priority fee는 혼잡 구간에서 소폭 상향. contract call은 eth_estimateGas 기반으로 최소 10~20% 여유 버퍼.

실전 환경에서의 검증·거래 경험을 개선하고 싶다면

네트워크 상황에 따라 수수료와 포함 속도는 많이 출렁인다. 파생상품·스팟 거래를 병행하면서 온체인 전송 타이밍을 맞추려면, 거래소의 수수료 체계와 보너스 혜택도 체감 차이를 만든다. 내가 써 본 옵션 중 하나를 아래에 공유해 둔다.

OKX 혜택으로 비용 줄이기와 실행력 높이기

신규/기존 유저 모두 대상 프로모션이 자주 열리고, 파생상품 유동성 측면에서 체감이 확실했다.
현재 제공 혜택(예시):
- 20% 수수료 캐시백
- 최대 $60,000 선물 보너스
가입 경로: OKX 가입 링크
추천코드: CRYPTONEWER

메이커/테이커 수수료가 줄면 실질 체결가가 개선되고, 온체인에서 대기하는 동안의 시장 대응력도 조금은 여유가 생긴다. 거래량이 많다면 캐시백 누적 체감이 의외로 크다.

(참고: 거래에는 언제나 리스크가 따른다. 본 문서는 교육 목적으로 작성되었으며, 투자 권유가 아니다.)

추가 자료와 레퍼런스 링크 모음

비트코인
- Bitcoin Core 문서: https://bitcoincore.org/en/doc/
- 정책·표준성: https://github.com/bitcoin/bitcoin
이더리움
- EIPs: https://eips.ethereum.org/
- JSON-RPC: https://ethereum.org/en/developers/docs/apis/json-rpc/

한눈에 보는 “트랜잭션 검증 과정 정리” 요약 노트

비트코인: UTXO 존재 → 스크립트/서명 → 수수료/표준성 → RBF/메모리풀 → 블록 포함(PoW·머클 루트)
이더리움: 서명/체인ID → nonce·잔액 → 가스·EIP-1559 → txpool 정책 → 블록 포함(PoS·가스 한도·상태 루트)
공통: 낮은 수수료·정책 위반·형식 오류·리소스 부족은 즉시 거절 사유. 사전 추정 툴로 선점 대응이 가장 경제적이다.