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

이 글은 Ethereum 및 EVM 계열을 기준으로 설명합니다. 특히 Ethereum 메인넷은 PoS 기반이며, 확정 finality 는 합의 레이어에서 체크포인트 단위로 제공됩니다. 이 글에서 말하는 확정은 결제 시스템 관점의 확정 정책까지 포함합니다.

 

 

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

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

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

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

 

 

 

 

트랜잭션이 블록에 포함된다는 것을 Web2 개발자인 저는 이렇게 생각했어요.

• 블록에 들어갔으니 끝
• 이제 돈은 무조건 이동 완료

하지만 실제로 그렇지 않았습니다.

• 포함되었다 included 는 되돌릴 수 없는 확정이 아닐 수 있다
• reorg 로 인해 잠깐 포함된 블록이 교체될 수 있다
• 따라서 서비스는 확인 confirm 과 최종성 finality 를 구분해 확정 정책을 세워야 한다

이번 편의 목표는 단 하나입니다.

• inclusion, confirm, finality 를 분리할 수 있도록 하기

 

---

 

요약

용어	뜻	참고
블록 포함 inclusion	트랜잭션이 어떤 블록에 들어감	영수증 receipt 가 생김
확인 confirmations	내 tx 가 들어간 블록 위에 추가 블록이 쌓인 개수	뒤집힐 확률이 줄어듦
최종성 finality	합의가 특정 시점 이후 되돌리기 매우 어렵다고 선언한 상태	정산 기준으로 쓰기 좋음
reorg	잠깐 정답처럼 보인 체인이 다른 체인으로 교체됨	포함된 tx 가 사라질 수 있음

 

 

---

 

1) Inclusion (블록 포함) 만으로는 왜 불안한가

 

블록체인은 중앙 DB가 아니고, 네트워크 지연이 있습니다.
그래서 같은 높이의 블록이 동시에 생기거나, 노드마다 잠깐 다른 체인을 보기도 합니다.

그 순간에는 이런 일이 가능합니다.

• 내 트랜잭션이 블록 A 에 포함됨
• 그런데 조금 뒤 더 긴 체인 혹은 더 강한 합의가 붙은 블록 B 체인이 정답으로 선택됨
• 결과적으로 블록 A 는 버려지고, 그 안의 트랜잭션도 사라진 것처럼 보임

이게 reorg 입니다.

 

 

이 단계에서 중요한 메시지는 이겁니다.

• 포함은 사실이지만, 그 사실이 오래 유지된다는 보장은 아직 약하다

참고.
reorg는 낙관적 락처럼 일단 처리된 것처럼 보이던 결과가 나중에 취소될 수 있다는 감각을 공유한다. 하지만 낙관적 락이 단일 DB에서 버전 충돌을 검출하는 메커니즘인 반면 reorg는 분산 네트워크에서 어떤 체인이 정답인지가 뒤늦게 재결정되면서 생기는 체인 수준의 롤백이다. 그래서 포함(inclusion)은 ‘낙관적 성공’에 가깝고, confirmations/finality는 그 결과가 뒤집힐 확률을 낮추는 안정화 단계라고 보는 게 합당하다.

 

---

 

2) confirmations 는 무엇을 의미하나

 

confirmations 는 보통 이렇게 계산합니다.

• 내가 포함된 블록의 높이가 N 이고
• 현재 체인의 tip 이 N + k 라면
• 내 트랜잭션 confirmations 는 k + 1 정도로 표현되곤 한다
  • 구현체마다 0 confirm, 1 confirm 표현이 달라 혼동이 있으니, 서비스에서는 블록 번호로 비교하는 편이 안전하다

감각적으로는 이렇습니다.

• 블록 위에 블록이 더 쌓일수록, 그 블록을 뒤집으려면 더 많은 것을 뒤집어야 한다
• 그래서 reorg 확률이 급격히 떨어진다

web2 비유로 말하면

• 커밋 로그가 여러 복제본에 전파되고
• 그 위로 더 많은 커밋이 쌓여서
• 롤백을 하려면 더 많은 후속 작업을 되돌려야 하는 상태

 

중요한 주의점 하나

• confirmations 는 확률을 낮추는 장치이고, 0이 되는 장치는 아니다
• confirmations는 finality를 예측하는 확률이 아니라 reorg 위험을 낮추는 지표

---

 

3) finality 는 무엇이고, Ethereum 에서는 어떻게 오나

 

EVM 은 실행 규칙이고, finality 는 합의 레이어의 기능입니다.

Ethereum PoS 에서는 체크포인트 단위로 finality 를 말합니다.
보통 직관적으로는 다음처럼 이해하면 됩니다.

• 블록 포함 included 는 금방 일어난다
• confirm 은 시간이 지나며 숫자가 쌓인다
• finality 는 일정 주기마다 체크포인트가 굳어지며 선언된다

실무적으로는

• finality 가 뜬 블록은 뒤집히기 매우 어렵다
• 뒤집으려면 경제적 손실, 슬래싱 위험을 감수해야 한다
• 다만 네트워크 이상 상황에서는 finality 가 지연될 수도 있다

여기서의 결론은 단순합니다.

• 포함 included 는 사용자 UX 에는 빠르다
• finality 는 정산과 리스크 관리에 유리하다

---

 

4) 그래서 서비스는 무엇을 기준으로 확정이라고 할까

 

여기서부터는 기술이 아니라 정책입니다.
결제 시스템에서도 승인과 매입이 다르듯, 블록체인에서도 포함과 확정은 다를 수 있습니다.

추천하는 방식은 리스크 단계별로 나누는 것입니다.

액션	예시	권장 기준
즉시 UX 제공	화면에 전송중 표시	tx hash 생성 또는 pending 관측
약한 확정	소액 지급, 비가역 혜택 아님	receipt 로 포함 확인 + N confirmations
강한 확정	크레딧 지급, 출금, 정산	finality 또는 매우 큰 confirmations + 추가 검증
최고 강도	브리지, 대금 결제, 고액	finality + 다중 소스 검증 + 리스크 룰

 

핵심은

• 서비스가 제공하는 가치가 되돌릴 수 없을수록, 더 강한 기준을 써야 한다

---

 

5) reorg 를 서비스가 어떻게 핸들링할까

 

reorg 는 드물지만, 0은 아닙니다.
그래서 백엔드는 상태 머신으로 다루는 게 안전합니다.

상태

• created: tx 를 만들었고 hash 를 얻음
• broadcasted: 네트워크에 제출됨
• pending: 멤풀 또는 pending 관측
• included: receipt 확보, 블록 번호 확보
• confirmed: confirmations 가 정책 기준 이상
• finalized: finality 달성
• replaced: 같은 nonce 다른 tx 로 대체됨
• dropped: 네트워크에서 사라짐 또는 오래 미포함
• failed: 포함은 됐지만 실행 실패 revert

 

 

참고

1) 포함 included 를 최종 성공으로 취급하지 말 것
2) 정산급 이벤트는 finalized 를 기준으로 하거나, 적어도 강한 confirmations 를 요구할 것
3) receipt 를 단일 RPC 에서만 믿지 말고, 필요하면 복수 RPC 로 교차 확인할 것
4) replaced 를 반드시 다룰 것 같은 nonce 는 하나만 성공한다
5) reorg 대응을 위해 블록 번호 기반으로 재검증하는 주기를 둘 것

---

 

6) 결론

 

• 블록 포함은 끝이 아니다
• confirmations 는 확률을 줄이는 장치다
• finality 는 합의가 제공하는 더 강한 확정 신호다
• 서비스는 리스크에 맞게 확정 정책을 계층화해야 한다
• reorg 는 상태 머신으로 대응해야 운영이 편해진다