최종성 장애는 반드시 블록 생성 중단을 뜻하지 않는다. 새 블록이 head에 붙고 거래가 화면에 보여도 충분한 검증자 투표가 모이지 않으면 checkpoint가 justified·finalized 상태로 전진하지 않을 수 있다. 사고 공지에서는 마지막 finalized checkpoint, 현재 head, 영향받은 검증자 비중, 재구성 여부, 입출금·브리지의 확인 정책을 따로 확인해야 한다.
체인이 움직여도 최종성은 멈출 수 있다
블록체인 상태 화면에서 블록 높이가 증가하면 정상처럼 보인다. 그러나 proof-of-stake 체인에서는 현재 head를 고르는 포크 선택과 과거 checkpoint를 되돌리기 어렵게 확정하는 finality가 별도 절차일 수 있다. 일부 검증자가 블록을 제안하고 다른 노드가 이를 따라가도 충분한 지분의 투표가 모이지 않으면 최종화 지점은 뒤에 남는다.
ethereum.org는 checkpoint 쌍에 전체 예치 ETH의 66% 투표가 모이면 그 사이 블록이 명시적으로 finalized된다고 설명한다. finality는 단순히 확인 수가 많다는 표현과 다르다. 장애 기사에서 ‘블록 생산 재개’를 ‘거래 최종 확정’으로 바꾸어 쓰면 복구 상태를 과장하게 된다.
새 블록이 생겼다는 사실과 과거 블록을 되돌리기 어렵게 확정했다는 사실은 별도의 증거를 요구한다.
JOBCOIN 해설
그림은 이 주제의 공통 개념을 단순화한 설명입니다. 아래 항목에서 이 글의 구체적인 조건과 예외를 함께 읽어보세요.
- 체인이 움직여도 최종성은 멈출 수 있다
블록체인 상태 화면에서 블록 높이가 증가하면 정상처럼 보인다.
- head·justified·finalized를 한 줄에 섞지 않는다
head는 현재 포크 선택 규칙이 가리키는 체인 끝이다.
- 원인은 오프라인과 상충 투표를 나눠 본다
많은 검증자가 오프라인이면 필요한 투표가 부족해 finality가 늦어질 수 있다.
AI로 제작한 개념도 · 실제 가격·거래 내역·통계가 아닙니다.
head·justified·finalized를 한 줄에 섞지 않는다
head는 현재 포크 선택 규칙이 가리키는 체인 끝이다. justified checkpoint는 충분한 투표로 정당화된 기준점이고, 그 다음 checkpoint가 조건을 충족하면 앞의 checkpoint가 finalized된다. 구현과 체인마다 용어·시간은 다르므로 해당 프로토콜 사양을 우선한다. 이용자 화면의 latest block이 finalized block을 뜻한다고 가정하지 않는다.
사고 보고서에는 마지막 정상 finalized epoch와 장애 중 가장 앞선 head를 함께 기록한다. 둘의 간격이 벌어졌다면 그 구간의 거래는 원장에 보이더라도 최종성 정책상 대기 상태일 수 있다. 서비스가 몇 개 확인을 요구하는지, finalized 태그를 사용하는지에 따라 입출금 재개 시점도 달라진다.
| 상태 | 확인되는 사실 | 확인되지 않는 사실 |
|---|---|---|
| 블록 제안 | 새 블록 후보가 생성됨 | 네트워크 다수가 채택함 |
| head | 로컬 포크 선택이 현재 가리키는 끝 | 되돌릴 수 없는 확정 |
| justified | 정해진 투표 조건을 충족한 checkpoint | 바로 앞 모든 최신 거래의 최종화 |
| finalized | 사양상 강한 확정 조건 충족 | 외부 서비스의 즉시 입출금 재개 |
| 서비스 정상화 | 특정 운영 기능이 재개됨 | 모든 지역·제공자의 복구 |
원인은 오프라인과 상충 투표를 나눠 본다
많은 검증자가 오프라인이면 필요한 투표가 부족해 finality가 늦어질 수 있다. 서로 다른 체인을 본 검증자가 상충되는 투표를 하면 안전성 문제와 슬래싱 가능성까지 검토해야 한다. 클라이언트 구성 오류, 네트워크 분할, 소프트웨어 버그, 잘못된 업그레이드 설정은 겉으로 비슷한 non-finality를 만들지만 복구와 책임이 다르다.
2025년 Holešky Pectra 시험에서는 클라이언트 구성 문제로 체인 분기가 발생했고, 광범위한 inactivity leak과 긴 검증자 exit queue가 뒤따랐다. 네트워크는 다시 최종화했지만 검증자 수명주기 시험에 부적합해져 새 테스트넷 Hoodi가 도입됐다. ‘복구됨’이 사고의 모든 운영 영향을 없앴다는 뜻은 아니다.
이용자는 재전송보다 거래 상태를 먼저 확인한다
최종성이 지연될 때 지갑·탐색기·RPC가 서로 다른 head를 보여 줄 수 있다. 실패처럼 보인다고 동일 nonce나 같은 외부 결제를 즉시 다시 보내면 중복 위험이 생긴다. 거래 해시, 포함 블록, 현재 canonical 여부, finalized 태그를 여러 독립 소스로 확인한다.
브리지와 수탁 사업자는 자체 위험 한도에 따라 확인 수를 늘리거나 입출금을 멈출 수 있다. 이는 프로토콜이 완전히 정지했다는 증거가 아니라 위험 관리 조치일 수 있다. 공지에서 체인 상태와 서비스 정책을 분리하고, 급한 자금 이동을 유도하는 비공식 복구 링크는 사용하지 않는다.
- 마지막 finalized epoch·block과 현재 head를 기록한다
- 블록 생성률과 검증자 참여율을 별도로 확인한다
- 체인 분기·재구성 깊이와 상충 투표 여부를 찾는다
- 거래 재전송 전에 canonical·finalized 상태를 확인한다
- 브리지·거래 서비스의 별도 확인 정책과 재개 공지를 읽는다
복구 완료는 밀린 최종화가 따라잡았는지 본다
클라이언트 패치 배포, 검증자 재접속, 블록 생성률 정상화는 복구 과정이다. 마지막 finalized checkpoint가 전진하고, 서로 다른 클라이언트가 같은 head를 보고, 신규 블록이 정상 주기로 finality에 들어가야 합의 복구 근거가 강해진다. 이후 서비스들이 보수적으로 유지한 중단을 해제하는 데 추가 시간이 걸릴 수 있다.
사후 보고서에는 탐지 시각, 영향 시작, 완화, finality 회복, 서비스 정상화 시각을 따로 적는 편이 좋다. 한 개의 ‘resolved’ 시각은 어느 층의 복구인지 알기 어렵다. 시각은 UTC로 통일하고 해당 시점의 epoch·slot·block을 함께 남긴다.
사고의 안전 영향과 가용성 영향을 구분한다
finality 지연은 거래 확정 시간이 늘어난 가용성 문제일 수 있지만, 상충하는 finalized checkpoint가 생겼다면 훨씬 큰 안전성 사건이다. 단순 지연을 자산 탈취로 과장하지도, 블록이 계속 나온다는 이유로 안전성 조사를 생략하지도 않는다. 공식 보고서가 확인한 범위와 아직 조사 중인 가설을 구분한다.
기사의 결론은 가격 전망보다 이용자 행동을 안내해야 한다. 확정이 필요한 결제는 대기하고, 수탁 서비스 공지를 확인하며, 노드 운영자는 클라이언트 버전과 peer·attestation 로그를 보존한다. 원인이 확정되기 전 특정 클라이언트나 검증자를 단정적으로 지목하지 않는다.
자주 묻는 질문
블록이 계속 나오면 거래는 안전한가요?
최신 블록에 포함됐다는 사실과 finalized됐다는 사실은 다르다. 중요한 결제는 해당 체인의 최종성 상태와 서비스 정책을 확인한다.
최종성 지연 중 거래를 다시 보내도 되나요?
먼저 기존 거래의 canonical·finalized 상태와 nonce를 확인한다. 화면 지연만 보고 재전송하면 중복 동작이 생길 수 있다.
finality가 회복되면 모든 서비스도 즉시 열리나요?
아니다. 브리지·거래 서비스는 자체 확인과 위험 검토를 마친 뒤 별도로 재개할 수 있다.
더 깊이 읽기
본문에서 다룬 개념과 확인 절차를 다음 글에서 이어서 살펴보세요.
