CCTP 브릿지 안정성 — 서버 크래시에도 USDC를 잃지 않는 설계

1. Circle — 인터넷의 달러를 만들려는 회사

Circle은 2013년 설립된 금융 인프라 회사다. 비트코인 결제 앱으로 시작했지만 지금은 완전히 다른 정체성을 갖는다. Circle의 핵심 제품은 USDC — 달러와 1:1로 페깅된 스테이블코인이다. 발행량 550억 달러 이상, 매일 수백억 달러가 결제·DeFi·기업 재무에 쓰이는 실질적인 달러 인프라다.

Circle의 전략은 명확하다. B2B 금융 인프라 회사로서 "USDC가 달러처럼 어디서나 쓰이도록" 만드는 것이다. Visa·BlackRock·Coinbase와 파트너십을 맺고, 미국 IPO를 추진하며, 규제 당국과 적극적으로 협력한다. CCTP는 그 전략의 핵심 레고 블록이다 — USDC가 체인에 갇히지 않도록.

2. 왜 CCTP를 만들었나 — 브릿지 해킹과 래핑 USDC 문제

2021~2022년, 멀티체인 수요가 폭발하면서 크로스체인 브릿지 시장이 급성장했다. 그리고 연달아 대형 해킹이 터졌다.

기존 브릿지들은 대부분 Lock-and-Mint 방식이었다. Ethereum에 USDC를 잠가두고 다른 체인에 "wrapped USDC"를 발행하는 구조다. 잠겨 있는 유동성 풀 자체가 해커의 타깃이 됐다. 그리고 두 번째 문제가 생겼다 — "어떤 USDC가 진짜인가?"

3. Circle CCTP 동작 원리

CCTP(Cross-Chain Transfer Protocol)는 Circle이 운영하는 공식 USDC 크로스체인 전송 프로토콜이다. Ethereum ↔ Base, Ethereum ↔ Arbitrum 등 지원 체인 간에 USDC를 네이티브로 이동시킨다. 핵심 메커니즘은 "소각 후 발행(Burn & Mint)"이다 — 소스 체인에서 USDC를 영구 소각하고, Circle의 증명을 받아 목적지 체인에서 같은 양을 새로 발행한다.

4. 자금 손실 시나리오 — 어느 구간이 위험한가?

4단계 중 대부분의 구간에서 서버 크래시가 발생해도 USDC는 안전하다. 문제는 단 하나의 구간에서 발생한다.

서버: 트랜잭션 서명
서버: broadcast → 체인에 전송
체인: burn 컨펌 (USDC 영구 소각)
서버: ← 여기서 크래시!!
서버: DB에 burnTxHash 저장  ← 실행 안 됨

재시작 후:
DB: burnTxHash = null
서버: "이 job이 어디까지 됐지? 알 수 없음."
결과: USDC는 소각됐지만 mint 불가 → 자금 손실

5. 해결책 — broadcast 전에 txHash를 먼저 저장하라

단 세 줄의 순서 변경

// broadcast 이후 저장
const burnTxHash =
  await this.evm.broadcastTx(
    signedTx, fromChain
  );

await updateJob({ burnTxHash });
// ↑ broadcast 후 저장
// 크래시 시 저장 안 됨

// broadcast 전에 계산 & 저장
const burnTxHash =
  ethers.keccak256(signedTx);
  // ↑ 서명만 되면 확정됨

await this.prisma.bridgeJob.update({
  where: { id: jobId },
  data: { burnTxHash },
});
// ↑ broadcast 전에 먼저 저장

await this.evm.broadcastTx(
  signedTx, fromChain
);

이 패턴은 데이터베이스 설계에서 WAL(Write-Ahead Logging)과 동일한 사상이다. 실제 작업을 수행하기 전에 무엇을 할 것인지를 먼저 기록하고, 크래시 후 재시작 시 그 기록을 보고 복구한다.

sign 완료
    │
    ▼
burnTxHash = keccak256(signedTx)  ← DB 저장 (여기까지는 동일)
    │
    ├─ [케이스 A] broadcast 전 크래시
    │       체인에 tx 자체가 없음
    │       receipt 조회 → null
    │       USDC 안전 ✓
    │
    ├─ [케이스 B] broadcast 했지만 revert
    │       잔액 부족 / allowance 부족 / 컨트랙트 에러
    │       receipt.status = 0
    │       USDC 소각 안 됨, 안전 ✓
    │
    └─ [케이스 C] broadcast + 성공
            receipt.status = 1
            USDC 실제로 소각됨 → attestation 재개 필수

const receipt = await provider.getTransactionReceipt(burnTxHash);

if (!receipt) {
  // 케이스 A: broadcast 안 됨 → USDC 안전 → FAILED
  return markFailed(jobId);
}

if (receipt.status === 0) {
  // 케이스 B: tx revert → USDC 안전 → FAILED
  return markFailed(jobId);
}

// 케이스 C: receipt.status === 1 → 진짜 소각됨
await resumeFromAttestation(jobId, burnTxHash);

6. 서버 재시작 시 자동 복구 패턴

txHash를 미리 저장해두면 재시작 시 자동으로 복구할 수 있다. NestJS의 onModuleInit 훅에서 미완료 job을 찾아 재개한다.

// MessageTransmitter 컨트랙트 내부
// 각 burn에 대해 nonce는 단 한 번만 사용 가능
mapping(bytes32 => bool) public usedNonces;

// 두 번째 receiveMessage 호출 시:
require(!usedNonces[nonceHash], "Nonce already used");
// → revert 발생

7. DB가 날아갔을 때 — 수동 복구 방법

DB가 완전히 유실된 최악의 상황에서도 burn 트랜잭션 해시만 알고 있다면 복구할 수 있다. CCTP의 mint는 언제든 재시도 가능하기 때문이다.

GET https://iris-api.circle.com/v2/{sourceDomain}
  ?transactionHash={burnTxHash}

// Response
{
  "status": "complete",
  "message": "0x...",
  "attestation": "0x..."
}

// ethers.js
const transmitter = new ethers.Contract(
  MESSAGE_TRANSMITTER_ADDRESS,
  ['function receiveMessage(bytes message, bytes attestation)'],
  signer
);

await transmitter.receiveMessage(
  irisResponse.message,
  irisResponse.attestation
);

8. 전체 안전성 매트릭스

9. 남은 한계와 권장 대응

10. 설계 원칙 — 블록체인 서비스의 내결함성

CCTP 브릿지 안정성 설계에서 얻을 수 있는 일반적인 원칙들이다. 온체인 자금을 다루는 모든 서비스에 적용된다.