크로스체인 메시징, OFT, ERC-7683
도입
Cross-chain은 자산을 옮기는 버튼이 아니라 신뢰가정을 선택하는 일이다. lock/mint bridge는 origin에 자산을 잠그고 destination에 representation을 만든다. burn/mint는 source supply를 줄이고 destination supply를 늘릴 수 있다. message passing은 임의의 instruction을 전달하고, intent fill은 solver가 liquidity를 먼저 제공한 뒤 settlement를 받는다.
같은 "전송 완료"라도 실패 상태가 다르다. verifier가 잘못된 message를 승인할 수 있고, destination liquidity가 부족할 수 있고, timeout 이후 refund가 필요할 수 있고, replay protection이 빠질 수 있다. DeFi protocol은 route별 trust model을 사용자와 운영자에게 모두 보여줘야 한다.
학습 목표
- lock/mint, burn/mint, message passing, intent fill 방식의 trust model을 구분한다.
- DVN quorum, CCIP defense-in-depth, native interop 같은 용어를 risk control로 해석한다.
- cross-chain route를 volume이 아니라 security assumption과 failure state로 비교한다.
개념 설명
이 route를 결제나 담보 이동에 써도 되는가?
issuer 또는 protocol supply control이 명확하다
verifier quorum과 replay protection이 충분하다
solver가 liquidity risk를 맡고 refund path가 있다
failure state를 사용자에게 설명할 수 없다
| 방식 | 핵심 신뢰가정 | 실패 상태 |
|---|---|---|
| Lock/mint | locked asset custodian 또는 bridge verifier | wrapped asset depeg |
| Burn/mint | supply controller와 attestation | attestation delay |
| Message passing | verifier quorum | forged message, replay |
| Intent fill | solver liquidity와 settlement proof | fill without settlement |
코드로 확인하기
export function quorumAccepted(verifierCount: number, threshold: number, compromised: number) { const honest = verifierCount - compromised; return { acceptsHonestMessage: honest >= threshold, forgedMessageRisk: compromised >= threshold };}cross_chain_route_policy: require: - source_chain_id - destination_chain_id - finality_stage - verifier_model - timeout_refund_path reject_if: - no_replay_protection - unsupported_destination_token - unknown_verifier_setquorumAccepted는 단순하지만 verifier threshold의 의미를 직관적으로 보여준다. policy는 cross-chain route가 token address만으로 allowlist될 수 없다는 점을 강조한다.
강의 포인트
| 관점 | 확인할 질문 | 증거로 남길 것 |
|---|---|---|
| Trust | 누가 message를 승인하는가 | verifier model |
| Asset | native, wrapped, synthetic 중 무엇인가 | token mapping |
| Failure | 실패 시 환불 또는 dispute가 있는가 | timeout path |
| Monitoring | 어떤 event를 추적하는가 | source and destination logs |
실무 예시
백엔드[INDEXER] merchant checkout에서 cross-chain route를 허용한다고 하자. 가장 빠른 route만 고르면 안 된다. 같은 100 USDC라도 destination token이 native인지 wrapped인지, route가 burn/mint인지 lock/mint인지, verifier quorum이 어떻게 구성됐는지에 따라 settlement assurance가 달라진다.
운영 대시보드는 source tx와 destination receive만 보지 않는다. message nonce, verifier confirmation, finality stage, timeout/refund status를 함께 저장해야 support가 "돈이 어디에 있는지" 설명할 수 있다.
흔한 오해와 실패 시나리오
| 오해 | 실패 시나리오 | 교정 방식 |
|---|---|---|
| cross-chain은 bridge 선택이다 | message, liquidity, settlement가 섞인다 | route type을 분리한다 |
| wrapped token도 같은 자산이다 | issuer redemption path가 다르다 | native/wrapped 표시를 강제한다 |
| verifier 수가 많으면 안전하다 | threshold와 independence가 중요하다 | quorum model을 검토한다 |
| destination 수신이면 끝이다 | origin settlement나 refund가 남을 수 있다 | 양쪽 상태를 추적한다 |
실습 과제
- Verifier quorum 위험 계산하기: verifier count, threshold, compromised count를 받아 message acceptance 여부와 warning을 계산한다.
- Cross-chain route 비교표 만들기: lock/mint, burn/mint, message passing, intent fill을 trust assumption과 failure state로 비교한다.
완료 기준
- 1-of-1과 2-of-3 verifier model의 forged-message risk를 비교했다.
- cross-chain route별 timeout, replay, proof failure, liquidity failure 상태를 정의했다.
근거 자료
- 12 Infra and L2
- LayerZero Production DVN Configuration
- Chainlink CCIP