Road to Web3 (3) 트랜잭션 생애주기 전파 → 멤풀 → 블록 포함

이 글은 Ethereum 및 EVM 계열을 기준으로 설명합니다. Solana 등 다른 체인은 용어는 비슷해도 멤풀, 블록 생산 방식, 확정성 모델이 다를 수 있습니다.

 

---

 

Road to Web3 (1) 블록체인 용어 최소 사전: 블록/노드/밸리데이터/멤풀

Road to Web3 (2) 블록체인 네트워크가 하는 일: 전 세계가 공유하는 DB 커밋 로그

Road to Web3 (3) 트랜잭션 생애주기 전파 → 멤풀 → 블록 포함

Road to Web3 (4) Confirm vs Finality: 블록 포함은 끝이 아니다

 

 

 

 

web2 개발자인 제가 처음 오해했던 것들입니다.

• 내가 트랜잭션을 올렸다
• 블록에 들어갔다
• 확정됐다

이 3개는 같은 말이 아닙니다. 이번 편에서는 그중 앞의 두 개를 분리합니다.

• 올렸다 = 네트워크에 제출했다, 전파가 시작됐다
• 블록에 들어갔다 = 어떤 블록에 포함됐다, 그래서 실행 결과가 체인 상태에 반영됐다

확정 finality는 다음 편에서 다룹니다.

---

 

 

1. 트랜잭션이란 무엇이던가

 

트랜잭션은 한 줄로 설명하면 아래와 같습니다.

• 상태를 바꾸는 서명된 커맨드

예를 들어 ERC-20 전송은 이런 의미를 담고 있습니다.

• 누구 주소에서
• 누구 주소로
• 어떤 토큰을
• 얼마를
• 수수료 조건과 함께
• 순서 nonce 를 포함해

그리고 이걸 개인키로 서명해서 네트워크에 보냅니다.

---

 

2. 전체 파이프라인 먼저 보기

 

전형적인 흐름은 이렇습니다.

1) 사용자가 지갑에서 트랜잭션을 서명한다
2) 클라이언트가 RPC 노드에 전송한다
3) 노드가 기본 검증 후 P2P로 전파한다 전파
4) 여러 노드의 멤풀에 들어간다 멤풀
5) 밸리데이터 또는 블록 빌더가 멤풀에서 골라 블록에 담는다
6) 블록이 네트워크에 채택되면 트랜잭션이 블록에 포함된다 포함

 

 

---

 

3. 1단계 전파 propagation 내가 올렸다의 의미

 

무엇이 일어나나

• 지갑 또는 앱이 서명된 트랜잭션을 만든다
• RPC 제공자 또는 내 노드에 제출한다
• 노드는 형식 검증을 하고 유효하면 다른 피어에게 퍼뜨린다

이 시점의 상태

• 네트워크 어딘가에는 트랜잭션이 도달했지만
• 아직 블록에 들어갔다고 보장할 수 없다

즉, 올렸다는 말은 보통 브로드캐스트 또는 제출을 의미합니다.

관찰 포인트

• 트랜잭션 해시 tx hash 가 생성된다
• 블록 익스플로러에서 pending 으로 보일 수 있다
• 어떤 경우에는 pending 도 안 뜰 수 있다 전파가 덜 됐거나 RPC 정책 문제

web2 비유

• HTTP 요청을 보냈다고 DB 커밋이 된 건 아닌 것과 같습니다
• 요청이 게이트웨이에 도착한 상태에 가깝습니다

참고로 트랜잭션 전파가 P2P로 이뤄진다고 해서 지갑이나 백엔드가 P2P로 직접 뿌리는 건 아닙니다. P2P 전파는 노드끼리 피어를 맺고 메시지를 확산시키는 프로토콜이라 피어 발견, 연결 유지, 스팸 방어, 체인 싱크 같은 운영 부담이 큽니다. 그래서 대부분의 앱은 서명한 트랜잭션을 RPC(JSON-RPC)로 한 노드(RPC 제공자나 자체 노드)에 제출하고, 그 노드가 자신의 P2P 피어들에게 전파를 시작하게 합니다. 웹2 관점으로는 클라이언트가 DB에 직접 쓰기하는 대신 API 서버에 요청을 보내고, 서버가 내부 시스템으로 확산시키는 구조와 비슷하다고 보면 됩니다.

 

---

 

4. 2단계 멤풀 mempool 줄 서기

 

web2에서도 큐에 작업이 쌓이면 우선순위 큐, 가중치 스케줄링 같은 기준으로 먼저 처리할 작업을 고르죠. EVM 네트워크에서 그 우선순위 역할을 보통 가스비(특히 tip)가 합니다. 이번 편에서는 멤풀에서 선택 기준이 존재한다는 사실만 잡고, 가스비 구조는 별도 편에서 자세히 다룹니다.

멤풀은 무엇인가

멤풀은 각 노드가 들고 있는 임시 대기열입니다.

• 영구 저장소가 아니다
• 노드마다 내용이 완전히 같지 않을 수 있다
• 수수료 정책 스팸 필터링에 따라 들어오거나 빠질 수 있다

멤풀에서 실제로 벌어지는 일

• 동시에 들어온 트랜잭션이 줄을 선다
• 블록 빌더가 그중 일부를 뽑는다
• 일반적으로 수수료가 유리한 트랜잭션이 먼저 선택될 가능성이 높다

 

자주 겪는 현상 3가지

1) pending

• 수수료가 낮거나 네트워크가 혼잡하면 블록에 못 들어간다

2) dropped

• 노드가 멤풀에서 제거했거나 전파가 불충분해서 사라진 것처럼 보일 수 있다

3) replaced

• 같은 계정, 같은 nonce 로 더 높은 수수료 트랜잭션을 보내면 대체될 수 있다

replaced 는 web2로 치면 같은 idempotency key 로 더 높은 우선순위의 작업을 다시 넣어서 기존을 취소하는 느낌입니다.

---

 

5. inclusion 블록에 들어갔다의 의미

 

포함되면 무엇이 달라지나

트랜잭션이 블록에 포함되면 보통 다음을 의미합니다.

• 특정 블록 번호 block number 가 생긴다
• 실행 결과가 체인 상태에 반영된다
• 성공 여부 status 와 가스 사용량 gas used 같은 영수증 receipt 를 얻을 수 있다

즉 블록 포함은 단순히 보관이 아니라 실행과 반영까지 포함합니다.

포함됐는데 실패인 경우도 있다

포함은 되지만 실행이 revert 로 실패할 수 있습니다.

• 포함됐지만 status 가 실패
• 상태 변화는 롤백되지만 가스는 소모될 수 있다

이건 다음 편 비용 모델에서 더 자세히 다룹니다.

포인트

• receipt 에 blockHash blockNumber transactionIndex status logs 등이 포함된다
• 이벤트 로그는 여기서 처음 의미를 갖는다 블록 포함 이후에만 확정된 로그가 된다

---

 

6. 내가 올렸다와 블록에 들어갔다를 구분하는 체크리스트

 

클라이언트 또는 백엔드에서 확인할 수 있는 것들

• tx hash 를 받았다면 제출은 성공했을 가능성이 높다
• pending 을 확인한다면 전파는 어느 정도 됐다
• receipt 를 받았다면 블록 포함까지 완료됐다
  • 서비스 로직에서 올렸다를 성공 처리로 쓰면 사고가 난다
  • 최소한 receipt 를 기준으로 포함 여부를 판단하는 쪽이 안전하다
  • 단 포함도 확정 finality 는 아니므로 정산 같은 민감한 행위는 정책을 정해야 한다

---

 

7. 트러블슈팅

 

상황 A. tx hash 는 받았는데 익스플로러에 안 뜸

• 전파가 부족했거나 RPC가 브로드캐스트를 거절했을 수 있다
• 다른 RPC로 조회해보면 보이는 경우가 있다
• 같은 nonce 로 재전송하는 전략이 필요할 수 있다

상황 B. pending 이 너무 길다

• 수수료가 낮다
• replace by fee 로 수수료를 올린다

상황 C. 포함됐는데 실패 status 0

• 잔액 부족
• allowance 부족
• 컨트랙트 조건 불만족 require 실패
• 이 경우는 가스비는 나갔을 가능성이 크다

---

 

8. 결론

 

• 올렸다는 말은 제출 전파 단계일 뿐이다
• 멤풀은 각 노드의 임시 큐다
• 블록 포함은 실행과 반영까지 포함한다
• 올렸다와 포함됐다를 분리하면 이후 confirm vs finality reorg 멱등성이 훨씬 쉽게 이해된다.