브리지가 다시 메시지를 전달한다고 이용자 손실이 회복된 것은 아니다. 취약점 패치와 계약 재가동, 공격자 반환·동결·회수, backing 자산 보충, 손상된 wrapped asset의 상환, 이용자 claim 지급을 각각 확인해야 한다. ‘funds restored’도 누가 어떤 재원으로 부족분을 채웠는지와 피해자에게 실제 지급됐는지를 구분한다.
복구라는 말에는 서로 다른 과정이 섞인다
공격 직후 팀은 전송을 멈추고 취약 경로를 차단한다. 이후 계약을 고치고 validator·relayer를 재가동할 수 있다. 이 기술 복구와 공격자가 빼낸 자산 반환, wrapped asset backing 보충, 이용자 보상은 별도다. 공지의 ‘bridge is back up’은 새 전송 가능성을 뜻할 뿐 과거 손실의 지급 완료를 뜻하지 않는다.
과정마다 대상 체인·계약·기준 블록·거래 해시와 남은 금액을 기록한다. 패치됐지만 claim이 열리지 않았을 수 있고, 자산 일부가 돌아왔지만 브리지는 아직 중단일 수 있다. 하나의 완료율로 합치지 않는다.
브리지의 문이 다시 열렸다는 사실과 그 문을 통해 사라진 자산이 돌아왔다는 사실은 같지 않다.
JOBCOIN 해설
그림은 이 주제의 공통 개념을 단순화한 설명입니다. 아래 항목에서 이 글의 구체적인 조건과 예외를 함께 읽어보세요.
- 복구라는 말에는 서로 다른 과정이 섞인다
공격 직후 팀은 전송을 멈추고 취약 경로를 차단한다.
- 자산 모델부터 다시 그린다
lock-and-mint 구조는 source chain에 원자산을 잠그고 destination에서 wrapped asset을 발행한다.
- Nomad 사례는 단계적 복구를 보여 준다
Nomad는 2022년 공격 뒤 공식 원인 분석과 공격 거래 데이터셋을 공개하고 whitehat 반환용 recovery 주소를 마련했다.
AI로 제작한 개념도 · 실제 가격·거래 내역·통계가 아닙니다.
자산 모델부터 다시 그린다
lock-and-mint 구조는 source chain에 원자산을 잠그고 destination에서 wrapped asset을 발행한다. 메시지 검증 결함으로 가짜 mint가 생기면 wrapped 공급이 backing보다 커진다. burn-and-mint, liquidity pool, native issuance는 손실 위치와 복구 방식이 다르다.
공격 당시 각 체인의 잠금 잔액, wrapped 공급, 미처리 메시지, 유동성 공급자 채권을 재구성한다. 토큰 시장가격 회복을 backing 회복으로 대신하지 않는다. 시장가가 돌아와도 공식 상환 경로와 준비자산이 부족할 수 있다.
| 단계 | 완료 증거 | 남는 질문 |
|---|---|---|
| 취약점 차단 | pause·패치·감사 | 다른 공격 경로 |
| 재가동 | 정상 시험 메시지·운영 상태 | pending 처리 |
| 자산 회수 | 공식 recovery 주소·반환 거래 | 동결액의 처분 가능성 |
| backing 보충 | 준비자산 입금·공급 대조 | 재원 조건 |
| 보상 | 대상·산식·claim·지급 | 미청구·이의 처리 |
Nomad 사례는 단계적 복구를 보여 준다
Nomad는 2022년 공격 뒤 공식 원인 분석과 공격 거래 데이터셋을 공개하고 whitehat 반환용 recovery 주소를 마련했다. Road to Recovery 문서는 300개가 넘는 주소가 참여한 사건에서 조사·추적·반환과 pending 정상 거래를 별도로 다뤘다.
후속 relaunch guide는 취약점 수정과 madAsset 보유자의 회수 자산 비례 접근을 설명했다. 2022년 12월 업데이트는 브리지 재가동을 알리면서 staging wallet 잔액, 추가 처리액, bounty 재원을 따로 적었다. 재가동과 완전 보상이 같은 날 끝나지 않았다.
회수 주소와 반환액을 검증한다
공격 직후 가짜 recovery 주소가 퍼질 수 있다. 공식 도메인·저장소·여러 채널에서 주소를 대조하고 반환 거래의 token·chain·amount를 공개 데이터와 맞춘다. 공격자 주소에서 나간 모든 이동을 회수로 세지 않는다. 믹서·DEX·다른 주소 이동일 수 있다.
중앙화 발행 토큰이 동결됐다는 말도 이용 가능한 회수와 다르다. 법집행·발행자 재발행·법원 절차가 남을 수 있다. 약속액, 온체인 반환액, 실제 보상에 쓸 수 있는 금액을 나눈다.
- 브리지 자산 모델과 backing 차이를 계산한다
- 패치·감사·재가동 거래를 확인한다
- 공식 recovery 주소와 반환 데이터를 대조한다
- 회수·동결·보충·보상 재원을 각각 집계한다
- claim 조건과 지급 거래까지 추적한다
비례 보상은 기준시점과 분모가 핵심이다
회수액이 부족하면 snapshot 기준 피해 잔액에 비례해 claim을 줄 수 있다. 공격 직전 보유자, 공격 뒤 할인 매수자, LP 지분, in-flight 메시지 처리에 따라 분모가 달라진다. 스냅샷 블록과 제외 규칙을 공개해야 산식을 재현할 수 있다.
recovery token이 발행되면 법적 권리, 상환 우선순위, 양도 가능성, 추가 회수 반영 방식을 읽는다. 액면 1달러 표시는 즉시 1달러 상환을 보장하지 않는다. claim 대가로 추가 청구권을 포기하는지도 확인한다.
재가동 뒤 바뀐 신뢰 가정을 확인한다
패치뿐 아니라 관리자 키, validator threshold, upgrade delay, rate limit, 모니터링이 어떻게 바뀌었는지 본다. 긴급 중앙 권한은 대응 속도를 높이지만 새로운 통제 위험을 만든다. 감사 범위와 실제 배포 커밋을 연결한다.
제한된 cap으로 재가동했는지, 과거 token address와 새 복구 계약이 어떻게 연결되는지 확인한다. 공식 UI가 열렸다는 이유만으로 큰 금액을 즉시 옮기지 않고 소액 시험과 목적지 상환 가능성을 먼저 확인한다.
자주 묻는 질문
브리지가 재가동되면 손실도 복구됐나요?
아니다. 새 전송과 과거 backing·보상은 별도다.
공격자 자산이 동결되면 보상 재원이 되나요?
즉시 그렇지는 않다. 실제 처분 가능해져야 회수액으로 볼 수 있다.
비례 보상률은 어떻게 확인하나요?
snapshot 블록, 적격 피해액 분모, 사용 가능한 재원과 지급 거래를 확인한다.
더 깊이 읽기
본문에서 다룬 개념과 확인 절차를 다음 글에서 이어서 살펴보세요.
