잠금-발행(lock-and-mint) 브리지는 원본 체인 예치 계약(escrow)의 정식 잔액이 도착 체인의 래핑 토큰(wrapped token) 공급량 이상인지 확인합니다. 반대 방향은 래핑 토큰 소각과 원본 해제를 같은 메시지에 묶어 봅니다. 소각-발행(burn-and-mint) 방식은 체인별 공급 증감이 서로 상쇄되는지 보고, 유동성 브리지는 래핑 토큰의 totalSupply가 아니라 각 풀의 부채·재고 규칙을 따라야 합니다. 처리 중인 메시지, 전송 수수료가 붙는 토큰, 재편성(reorg), 여러 브리지 계약을 나눠 보지 않으면 일시적인 차이나 중복을 결손으로 잘못 판단할 수 있습니다.
브리지 유형부터 식별합니다
잠금-발행 방식은 원본 토큰을 출발 체인 계약에 잠그고 도착 체인에서 대응 토큰을 발행합니다. 소각-해제 방식은 돌아올 때 래핑 토큰을 소각하고 예치 계약의 원본을 풉니다. CCTP처럼 출발 체인에서 네이티브 토큰을 소각하고 도착 체인에서 네이티브 토큰을 발행하는 방식에는 예치 잔액 공식이 없습니다.
Circle 문서는 브리지 USDC를, 다른 체인의 USDC가 브리지 계약에 잠긴 만큼 외부 업체가 만든 토큰으로 따로 구분합니다. 티커와 소수 자릿수가 같다는 이유만으로 상환 경로까지 같다고 가정하지 않습니다. 계약 주소와 브리지 경로를 자산 식별자에 포함합니다.
브리지 공급 대사는 두 체인의 totalSupply 비교가 아니라 한 메시지가 만든 잠금·발행·소각·해제를 연결하는 일입니다.
JOBCOIN 해설
그림은 이 주제의 공통 개념을 단순화한 설명입니다. 아래 항목에서 이 글의 구체적인 조건과 예외를 함께 읽어보세요.
- 브리지 유형부터 식별합니다
잠금-발행 방식은 원본 토큰을 출발 체인 계약에 잠그고 도착 체인에서 대응 토큰을 발행합니다.
- 정식 상태 기준으로 담보 공식을 계산합니다
이더리움 예치 계약에 원본 1,000만 개, L2 래핑 공급 980만 개, 나가는 쪽 처리 중 30만 개, 들어오는 쪽 소각 처리 중 10만 개가 있다고 가정해 보겠습니다.
- 메시지의 처리 단계를 원장으로 둡니다
입금이 시작됐다는 기록만 있고 도착 체인의 확정 처리가 없으면 처리 중으로 봅니다.
설명을 위한 개념도 · 실제 가격·거래 내역·통계가 아닙니다.
정식 상태 기준으로 담보 공식을 계산합니다
이더리움 예치 계약에 원본 1,000만 개, L2 래핑 공급 980만 개, 나가는 쪽 처리 중 30만 개, 들어오는 쪽 소각 처리 중 10만 개가 있다고 가정해 보겠습니다. 시점을 맞추고 나면 기대 차이는 0일 수 있습니다. 단순히 20만 개 초과 담보라고 결론 내리지 말고 메시지 상태를 반영합니다.
여러 도착 체인이 같은 예치 계약을 함께 쓰면 각 체인의 래핑 공급 합계를 비교 대상으로 씁니다. 예치 계약이 따로 있다면 계약별로 짝을 맞춥니다. 예치 잔액과 발행 공급량은 같은 최종성 기준 블록에서 읽습니다.
| 항목 | 수량 | 대사 처리 |
|---|---|---|
| 출발 체인 예치 잔액 | 10.0M | 담보 재고 |
| L2 유통 중인 래핑 토큰 | 9.8M | 부채 재고 |
| 나가는 쪽 처리 중 | 0.3M | 발행 예정 |
| 들어오는 쪽 소각 처리 중 | 0.1M | 해제 예정 |
| 조정 차이 | 0 | 정상 가정 |
메시지의 처리 단계를 원장으로 둡니다
입금이 시작됐다는 기록만 있고 도착 체인의 확정 처리가 없으면 처리 중으로 봅니다. 시간 초과 뒤 다시 시도할 수 있는지, 실패한 메시지가 환불되는지는 브리지 문서에 따라 상태를 나눕니다. 같은 논스를 두 번 처리하지 못하게 막는 장치와 도착 체인 이벤트도 확인합니다.
CCTP 증명(attestation) API는 출발 체인 소각 이벤트의 메시지 해시에 대한 서명 상태를 알려 줍니다. 증명 완료와 도착 체인 발행 거래의 성공은 별도 열로 기록합니다. 서명을 받았다고 발행이 끝난 것으로 기록하지 않습니다.
- 출발·도착 체인의 chainId와 계약을 고정합니다.
- 입금 메시지 ID와 잠금·소각 거래를 저장합니다.
- 도착 체인의 발행·해제 거래와 연결합니다.
- 양쪽 정식 최종성이 확보된 뒤 재고를 다시 읽습니다.
- 처리 중·실패·환불 건은 별도 묶음으로 남깁니다.
수수료형 토큰과 유동성 브리지는 따로 봅니다
전송 수수료가 붙는 토큰은 사용자가 100개를 보내도 예치 계약에는 98개만 도착할 수 있습니다. 브리지가 입력값 100개를 그대로 발행하면 부족분이 생깁니다. 실제 잔액 변화량을 쓰는지 지원 문서에서 확인하고, 지원하지 않는 토큰은 정상 공식에 억지로 넣지 않습니다.
유동성 브리지는 도착 체인 풀에 있던 토큰을 내주고, 재조정 담당자가 나중에 풀을 채울 수 있습니다. 이때 핵심은 풀 재고, 신용 한도, 아직 정산되지 않은 전송이며 래핑 공급량과 예치 잔액이 같아야 한다는 공식은 맞지 않습니다.
차이는 재현할 수 있는 증거로 남깁니다
대사 스냅숏에는 블록 해시, 예치 잔액, 래핑 토큰의 totalSupply, 처리 중 메시지 목록, 수수료와 소수 자릿수를 보관합니다. 업그레이드로 계약이 바뀌면 이전 전후의 잔액을 이어 붙이고, 옛 계약에 남은 수량을 숨기지 않습니다.
차이가 생기면 최종성 지연, 인덱서 누락, 지원되지 않는 토큰, 잘못된 계약, 중복 발행 순으로 조사합니다. 결손이나 해킹이라는 표현은 계약 상태와 메시지 이력을 확인한 뒤에만 씁니다.
자주 묻는 질문
래핑 공급이 예치 잔액보다 잠시 많으면 곧바로 담보 부족인가요?
최종성, 처리 중인 소각·발행, 수수료, 공유 예치 계약을 모두 조정한 뒤에도 차이가 남는지 확인해야 합니다.
모든 브리지는 원본을 잠그나요?
아닙니다. 소각-발행 방식과 유동성 풀 방식은 다른 대사 공식을 씁니다.
USDC라는 이름이 같으면 합산해도 되나요?
발행사, 계약, 상환 경로가 다를 수 있으므로 네이티브 발행분과 외부 업체 브리지 버전은 나눠서 집계해야 합니다.
더 깊이 읽기
본문에서 다룬 개념과 확인 절차를 다음 글에서 이어서 살펴보세요.
