Cross-chain intent는 왜 브리지 UI가 아니라 solver 신뢰 계약일까: ERC-7683으로 보는 주문-정산 경계

10분 읽기·2026.07.31·출처 5개·00

오늘의 질문

사용자가 “A체인에서 내고 B체인에서 받기”만 원할 때, 개발자는 어떤 상태·권한·결제 가정을 명시해야 할까?

blockchain-dev.md

Intent Solver Boundary

Cross-chain intent는 왜 브리지 UI가 아니라 solver 신뢰 계약일까: ERC-7683으로 보는 주문-정산 경계

카테고리: blockchain_dev
예상 읽기 시간: 10분
오늘의 질문: 사용자가 “A체인에서 내고 B체인에서 받기”만 원할 때, 개발자는 어떤 상태·권한·결제 가정을 명시해야 할까?
핵심 출처:
- ERC-7683: Cross Chain Intents - 2024-04-11 생성, 2026-07-31 확인
- ethereum/ERCs commit 96d110f: Update ERC-7683: Redesign around resolvers - 2026-05-13, 2026-07-31 확인
- Ethereum Magicians: ERC-7683 Cross Chain Intents Standard - 2024-04-11 시작, 2026-07-03 최근 게시, 2026-07-31 확인
- ERC-7930: Interoperable Addresses - 2025-02-02 생성, 2026-07-31 확인
- ethereum/ERCs commit 65c3f42: Update ERC-7930: define Chain Identifier - 2026-05-24, 2026-07-31 확인

1. 왜 지금 봐야 하나

최근 블록체인 UX의 큰 흐름은 “사용자에게 체인을 숨기자”이다. 사용자는 ETH mainnet, Arbitrum, Base, Solana 같은 네트워크 이름보다 “내 USDC를 원하는 곳에서 쓰고 싶다”에 가깝게 생각한다. 그래서 브리지 버튼, 크로스체인 스왑, 계정 추상화, Paymaster, intent 기반 라우팅이 모두 같은 방향으로 움직인다.

문제는 개발자 관점에서 “체인을 숨기는 UX”가 보안 경계를 없애지는 않는다는 점이다. 오히려 사용자의 요청은 더 추상화되고, 그 요청을 실제 여러 체인의 트랜잭션으로 바꿔 실행하는 actor가 새로 생긴다. ERC-7683은 이 actor를 solver/filler로 보고, intent protocol이 solver에게 주문을 설명하는 공통 인터페이스를 정의하려는 Draft ERC다.

중요한 변화는 ERC-7683이 “하나의 표준 브리지 컨트랙트”를 만들려 하지 않는다는 점이다. 최신 ERC 문서는 intent protocol마다 자금 승인, 정산 검증, 가격 결정, escrow-first, resource-lock 기반 fill-first, auction 방식이 다를 수 있음을 인정한다. 대신 solver가 각 프로토콜의 payload를 직접 다 외우지 않도록, protocol-specific payload를 공통 주문 표현으로 풀어주는 resolver를 둔다.

개발자에게 이 주제는 가격 예측이나 특정 크로스체인 앱 홍보가 아니다. 질문은 이것이다.

“사용자의 결과 희망”을 “여러 체인의 상태 전이”로 바꿀 때, 누가 어떤 가정을 명시하고 누가 그 리스크를 부담하는가?

2. 핵심 개념

ERC-7683의 핵심 단어를 공부방식으로 풀면 다음과 같다.

Order: 사용자가 제안한 교환 조건

ERC-7683은 order를 “요구사항을 충족하는 대가로 지급을 제안하는 것”으로 본다. 예를 들어 사용자가 “A체인의 토큰을 내고 B체인에서 특정 토큰을 받겠다”고 표현하면, 이 요청은 체인 간 상태 전이를 포함하는 주문이 된다.

여기서 중요한 점은 order가 단순 calldata가 아니라는 것이다. order에는 실행해야 할 단계, 변수, 결제 조건, 만료, 체인별 주소, 토큰 동작, 정산 가정이 붙는다. UX는 버튼 하나여도, 시스템 입장에서는 “어느 체인에서 어떤 선행 조건이 만족되어야 다음 단계가 안전한가”를 표현해야 한다.

Solver: 먼저 실행하고 나중에 정산받는 actor

Solver는 사용자가 원하는 결과를 실제로 만들어주는 actor다. 크로스체인 intent에서는 solver가 한쪽 체인에서 유동성을 먼저 제공하거나, 여러 체인의 트랜잭션을 조율하거나, 경매에서 선택될 수 있다. 사용자는 편해지지만 solver는 자본, approval, 트랜잭션 수수료, 실패 리스크를 부담한다.

그래서 solver가 읽는 주문 표현은 “실행하면 돈을 벌 수 있는가”뿐 아니라 “실행한 뒤 결제가 무효화되지 않는가”를 판단할 수 있어야 한다.

Resolver: payload decoder이자 order validator/guarantor

2026년 5월 13일 ethereum/ERCs에는 ERC-7683을 “resolver 중심”으로 재설계하는 커밋이 들어갔다. 현재 문서의 Abstract도 resolver를 protocol-specific payload를 common order representation으로 번역하는 계약으로 설명한다. Solver는 offchain eth_call로 resolver를 호출해 주문을 해석하고, 그 결과를 바탕으로 안전성·수익성·실행 가능성·지급 가능성을 평가한다.

이 구조가 중요한 이유는 중복 통합 비용을 줄이기 때문이다. 모든 solver가 모든 intent protocol의 payload 형식과 settlement semantics를 별도 구현하면 유동성이 파편화된다. 반대로 resolver가 공통 표현을 내면 solver는 “이 resolver를 신뢰/검증할 수 있는가”를 중심으로 통합할 수 있다.

Step과 dependency: 크로스체인 실행에도 순서 그래프가 있다

ERC-7683은 order requirements를 steps와 variables 목록으로 표현한다. 각 step은 hard dependency를 가질 수 있고, hard dependency는 acyclic이어야 하며, fulfillment는 dependency order로 진행되어야 한다. 즉 intent는 “알아서 잘 해줘”가 아니라 실행 순서를 가진 작은 workflow다.

개발자는 여기서 workflow 엔진을 떠올리면 된다. 다만 일반 백엔드 workflow와 다른 점은 각 step이 서로 다른 체인, 서로 다른 finality, 서로 다른 token behavior, 서로 다른 message path 위에서 실행될 수 있다는 것이다.

3. 최신 이슈와 연결

ERC-7683 자체는 2024년 4월 생성된 Draft ERC지만, 2026년에도 움직이고 있다. 확인한 GitHub commit 기록에 따르면 2026년 5월 13일 “Redesign around resolvers” 업데이트가 병합됐다. Ethereum Magicians 토론도 2026년 7월 3일까지 새 게시물이 있었다. 즉 이 주제는 이미 끝난 표준이 아니라, cross-chain intent가 실제 프로토콜 통합 문제로 바뀌면서 인터페이스가 다듬어지는 중인 영역이다.

또 하나 같이 봐야 할 문서는 ERC-7930이다. ERC-7683의 Key Terms는 interoperable address를 ERC-7930으로 인코딩된 주소라고 둔다. ERC-7930은 chain-specific address를 위한 versioned, length-prefixed binary envelope를 제안하며, motivation에서 Ethereum mainnet의 ERC-55 주소 형식이 여러 체인에서 공유되지만 체인 정보를 포함하지 않아 ambiguity와 operational risk를 만든다고 설명한다.

왜 intent 표준에서 주소 표준이 중요할까? 크로스체인 주문에서 0xabc...만 보고 target을 판단하면 위험하다. 같은 20바이트 주소가 여러 EVM 체인에 존재할 수 있고, non-EVM 체인은 주소 직렬화 규칙도 다르다. ERC-7930은 chain identification과 raw address를 묶어 compact하게 표현하려는 시도다. ERC-7683이 solver에게 “어디에 호출해야 하는가”를 알려주려면, target address가 어떤 체인의 주소인지부터 모호하지 않아야 한다.

4. 개발자 관점 해석

ERC-7683을 “브리지 UX 개선 표준”으로만 보면 핵심을 놓친다. 더 정확히는 다음 세 가지 경계를 표준화하려는 시도다.

1) 프로토콜별 payload와 solver-facing order의 경계

Intent protocol은 각자 사용자 서명, escrow, auction, resource lock, settlement contract를 다르게 설계할 수 있다. ERC-7683은 이것을 하나로 통일하지 않는다. 대신 solver가 읽을 수 있는 공통 표현을 resolver가 제공하도록 한다.

따라서 프로토콜 개발자는 “우리 payload는 내부적으로 맞다”에서 멈추면 안 된다. 외부 solver가 resolver 결과만 보고도 다음을 판단할 수 있어야 한다.

어떤 step을 어떤 체인에서 실행해야 하는가
어떤 변수는 누가 언제 결정하는가
어떤 step이 실패하면 주문은 abort되는가
solver가 먼저 쓴 자본은 어떤 조건에서 정산되는가
지급 경로가 중간 상태 변화로 무효화될 수 있는가

2) 사용자 안전과 solver 안전은 다르다

일반 브리지 글에서는 주로 사용자 자산 보호를 말한다. 하지만 intent 시스템에서는 solver 안전도 프로토콜 신뢰성의 일부다. Solver가 손실을 자주 보거나 hidden assumption을 감당해야 하면 solver network가 얇아지고, 사용자는 나쁜 가격·느린 실행·중앙화된 filler에 의존하게 된다.

ERC-7683의 Security Considerations도 resolver가 주문의 steps, payments, assumptions를 설명할 수 있지만 최종 정산 보안은 protocol, resolver implementation, settlement contracts, assets, offchain/cross-chain systems에 달려 있다고 말한다. 특히 solver가 capital, approvals, transactions를 commit한 시점부터 expected payment가 final and spendable해질 때까지 전체 execution and settlement window를 분석해야 한다고 강조한다.

즉 “사용자가 받을 결과”와 “solver가 회수할 결제”는 서로 다른 finality를 가진다. 개발자는 둘을 같은 성공 이벤트로 묶으면 안 된다.

3) 주소·체인 식별은 UI 문자열이 아니라 상태 전이의 일부다

ERC-7930이 필요한 이유는 크로스체인 intent에서 주소가 독립 값이 아니기 때문이다. target address는 target chain과 함께 해석되어야 한다. 만약 resolver가 chain context를 모호하게 만들거나, front-end가 chain alias를 잘못 매핑하거나, indexer가 서로 다른 namespace의 주소를 같은 key로 저장하면 주문은 겉으로 정상이어도 다른 상태 전이로 실행될 수 있다.

이 문제는 단순 브리지보다 intent에서 더 커진다. Solver는 여러 프로토콜의 주문을 programmatically 평가한다. 사람이 화면에서 체인 아이콘을 확인하는 방식으로는 scale하지 않는다. 체인-주소 canonicalization이 API 계약이 되어야 한다.

5. 내 프로젝트에 적용할 체크포인트

크로스체인 intent, 브리지, solver, 자동 라우팅 기능을 붙인다면 다음 질문을 문서와 테스트에 넣자.

resolver trust boundary
- resolver가 protocol-specific payload를 어떻게 검증하는가?
- resolver upgrade 권한은 누구에게 있는가?
- solver가 특정 resolver 버전/hash를 allowlist할 수 있는가?
assumption surface
- 주문 실행에 필요한 oracle, bridge, message path, finality, token behavior가 explicit assumption으로 드러나는가?
- assumption이 바뀌면 order가 abort되는가, 아니면 solver가 손실을 떠안는가?
payment finality
- solver가 비용을 쓴 뒤 지급이 final and spendable해지는 시점은 언제인가?
- reorg, message delay, settlement pause, token blacklist, fee-on-transfer 같은 조건에서 지급 경로가 무효화되는가?
dependency graph
- step hard dependency가 acyclic인지 테스트하는가?
- step이 실패하거나 abort될 때 이미 실행된 cross-chain side effect를 어떻게 다루는가?
interoperable address
- 체인 ID와 address를 분리된 UI 필드로만 저장하지 않는가?
- 같은 20바이트 주소가 다른 체인에서 충돌해도 key가 분리되는가?
- non-EVM chain namespace의 serialization/canonicalization 규칙을 문서화했는가?
monitoring
- solver quote 실패율, settlement delay, resolver revert, fill 이후 payment failure를 별도 지표로 보는가?
- 사용자 성공률만 보고 solver 손실률을 숨기고 있지 않은가?

6. 오늘 10분 액션

오늘은 큰 구현보다 “내가 쓰는 크로스체인 기능을 order lifecycle로 다시 그리기”만 해보자.

최근 써본 브리지/크로스체인 스왑/체인 추상화 기능 하나를 고른다.
종이에 다음 6단계를 쓴다.
- user intent 생성
- order feed 또는 quote 요청
- solver/filler 선택
- source chain 자금 잠금 또는 지출
- destination chain 실행
- solver payment/settlement
각 단계 옆에 “누가 실패 비용을 부담하는가?”를 적는다.
target address가 chain context와 함께 저장되는지 확인한다.
마지막으로 resolver가 있다면, solver가 resolver 출력만 보고 안전성을 판단할 수 있는지 체크한다.

10분 뒤 남겨야 할 문장은 이것이다.

Cross-chain intent는 사용자가 체인을 몰라도 되게 만드는 UX가 아니라, 사용자의 추상 요청을 solver가 검증 가능한 주문·가정·정산 경계로 바꾸는 계약이다.

7. 더 볼 자료

중복 회피 메모

로컬 content/generated와 Supabase의 최근 blockchain_dev 글을 확인했다. 최근 글은 ERC-7201 namespaced storage, AFX hot-validator bridge key 운영, OP Stack interop fork choice, Chainlink SVR/OEV, Arbitrum Timeboost sequencing, KelpDAO/LayerZero DVN RPC quorum, EIP-4444 history expiry, EIP-7917 proposer lookahead, EIP-7939 CLZ opcode, EIP-7907 code size gas, Solana Alpenglow finality, Taiko bridge origin verification, OP Stack fault proof soundness, ERC-4626 NAV manipulation, P-256/passkey precompile, MODEXP repricing 등을 다뤘다. 이번 글은 특정 브리지 exploit, L2 시퀀서 정책, storage upgrade 문제가 아니라 ERC-7683과 ERC-7930을 통해 cross-chain intent에서 resolver, solver-facing order, payment finality, interoperable address가 어떤 신뢰 계약이 되는지에 집중해 중복을 피했다.

오늘 10분 액션+5%