브리지 중단 공지는 어느 체인의 어느 단계가 멈췄는지 읽어야 한다. 출발 체인에서 이미 잠금·소각된 전송은 신규 시작이 차단된 전송과 상태가 다르다. 출발 거래 해시, 메시지 식별자, 서명된 증명 생성 여부, 목적지 상환 거래를 순서대로 맞추면 UI 장애와 계약 pause, 검증자 지연을 구분할 수 있다.
브리지는 한 번의 송금이 아니라 상태 기계다
Wormhole의 wrapped token transfer 흐름에서 출발 체인 계약은 원본 토큰을 잠그거나 래핑 토큰을 소각하고 메시지를 낸다. Guardian들이 메시지를 관찰해 서명한 VAA를 만들면 목적지 계약이 이를 검증하고 래핑 토큰을 발행하거나 보관 자산을 해제한다. 사용자가 보는 한 번의 전송 버튼 뒤에 최소 두 체인과 메시지 증명 단계가 있다.
따라서 ‘브리지 중단’은 출발 계약의 신규 호출 금지, Guardian 관찰 지연, VAA 전달 실패, 목적지 계약의 redeem 금지, 웹 UI 접속 장애 중 하나일 수 있다. 공지가 체인 쌍과 토큰, 시작 시각, pause 대상 함수를 적지 않았다면 전체 브리지가 멈췄다고 넓혀 쓰지 않는다.
브리지 전송의 위치는 잔액 화면이 아니라 출발 거래·메시지 증명·목적지 거래의 연결로 찾는다.
JOBCOIN 해설
pause가 걸린 위치에 따라 대기열이 달라진다
Wormhole NTT 문서는 NTT Manager를 pause하면 새 전송 시작을 막지만 이미 비행 중인 전송은 rate limit 조건 아래 목적지에서 redeem될 수 있다고 설명한다. 또 Pauser가 중단할 수 있고 Owner만 재개할 수 있다. 이 설계에서는 ‘pause=true’가 모든 기존 메시지의 폐기를 뜻하지 않는다. 실제 프로토콜마다 구현이 다르므로 공지와 계약 권한을 함께 확인해야 한다.
교육용 예시로 A체인 거래 80건 중 60건이 VAA를 받았고 20건은 아직 관찰 단계라고 하자. pause가 신규 initiate 함수에만 적용되면 60건은 목적지 상환 후보이고, 20건은 메시지 생성 여부를 더 봐야 한다. 80건을 전부 손실로 계산하거나 전부 완료로 계산하면 두 상태를 모두 왜곡한다.
전송 한 건을 네 증거로 추적한다
브리지 탐색기나 UI의 pending 표시는 출발 체인의 성공만 반영할 수도 있다. 다음 표의 네 식별자를 같은 전송으로 연결해야 어디서 멈췄는지 말할 수 있다.
| 단계 | 필수 증거 | 판독 |
|---|---|---|
| 출발 실행 | source chain tx hash와 이벤트 | 잠금·소각 호출 성공 여부 |
| 메시지 관찰 | emitter chain·address·sequence | 어떤 메시지를 찾는지 특정 |
| 증명 생성 | Guardian 서명이 모인 VAA | 목적지 제출 가능한 증명 여부 |
| 목적지 실행 | redeem tx hash와 수신 주소 | 발행·해제 완료 여부 |
| 운영 화면 | 공식 status와 UI 상태 | 계약 상태와 별도로 기록 |
중단 중 새 전송을 만들지 않는 점검 순서
진단하려고 같은 전송을 반복 제출하면 nonce, 수수료, 중복 메시지까지 문제를 늘릴 수 있다. 먼저 공식 공지의 적용 체인과 계약 주소를 확인하고 출발 거래 영수증의 성공 여부를 읽는다. 그 다음 emitter와 sequence로 VAA를 찾고, 목적지 계약에서 이미 소비된 메시지인지 확인한다. 공식 재시도 안내가 있을 때만 해당 절차를 따른다.
공지가 ‘front end paused’라고만 했다면 다른 사이트에 지갑을 연결해 우회하기 전에 공식 계약 주소와 권장 경로를 확인한다. UI를 사칭한 피싱 페이지가 장애 시기에 등장할 수 있다. 시드 문구를 요구하는 복구 절차는 정상적인 브리지 메시지 재전달 과정이 아니다.
- 공식 공지의 체인 쌍·토큰·계약 주소를 저장한다
- 출발 거래의 status와 이벤트를 확인한다
- emitter chain·address·sequence를 기록한다
- VAA 존재와 Guardian 서명 검증 여부를 본다
- 목적지 redeem 거래와 수신 주소를 대조한다
- 재개 후 rate limit과 대기열 처리 순서를 확인한다
자산 안전과 서비스 가용성을 따로 보도한다
출발 체인에 자산이 잠겼고 목적지 발행이 지연됐다는 사실은 서비스 가용성 문제다. 잠금 계약 잔액 부족, 권한 탈취, 잘못된 발행처럼 안전 문제를 말하려면 별도의 온체인 증거가 필요하다. UI가 열리지 않는다는 캡처만으로 잠금 자산이 사라졌다고 쓸 수 없다.
반대로 계약 잔액이 남아 있다는 사실도 개별 전송의 상환 가능성을 보장하지 않는다. 메시지가 유효한지, 목적지에서 이미 소비됐는지, rate limit이 남았는지에 따라 처리 결과가 다르다. 기사에는 ‘신규 전송 차단’, ‘기존 전송 처리 지연’, ‘자산 손실 확인 안 됨’을 각각 독립 문장으로 둔다.
재개 뒤에는 양쪽 체인의 완료를 확인한다
재개 공지 이후 첫 성공 거래만 보고 전체 정상화로 결론내리지 않는다. 중단 전에 생성된 메시지, 중단 중 거절된 신규 호출, 재개 후 새 호출을 구분해 표본을 잡는다. 특히 기존 메시지가 자동 처리되는지 사용자가 VAA를 다시 제출해야 하는지 공식 지침을 읽는다.
최종 기록에는 공지 시각, pause와 unpause 거래가 있다면 그 해시, 영향받은 체인 쌍, 마지막 미처리 sequence를 남긴다. 교육용 예시는 실제 사고 규모가 아니며, 브리지 토큰의 가격 전망이나 투자 권유로 연결하지 않는다.
자주 묻는 질문
출발 체인 거래가 성공하면 전송도 끝난 건가요?
아니다. 출발의 잠금·소각이 끝났다는 뜻이다. 메시지 증명 생성과 목적지 계약의 발행·해제 거래가 남을 수 있다.
pause 전에 보낸 전송은 모두 취소되나요?
구현에 따라 다르다. Wormhole NTT는 신규 시작 pause 중에도 전송 중 메시지가 rate limit 아래 redeem될 수 있다고 설명한다. 해당 배포의 공지와 계약 상태를 확인해야 한다.
UI가 닫혔으면 계약도 멈춘 건가요?
UI와 온체인 계약은 별개다. 공식 상태 공지와 pause 상태, 계약 호출 결과를 함께 확인해야 한다.
