대부분의 크로스체인 설계는 모든 상호작용을 한 종류의 트래픽으로 다루다가 실패합니다. XChain은 READ(상태를 바꾸지 않음)와 WRITE(상태를 바꿈) 사이에 굵은 선을 긋습니다 — 모델 전체가 이 하나의 근본 구분에 매달려 있습니다. 크로스체인 수요의 대부분은 “X가 체인 A에서 일어났다”를 검증하는 것뿐입니다 — 이는 READ이고 Interchain Queries(ICQ)를 통하며, 싸고 사실상 무제한입니다. 원자적 상태 변경만이 WRITE이며, IBC v2/Eureka + Interchain Accounts(ICA)를 통하고 의도적으로 희소하게 유지됩니다.

READ가 거의 공짜인 이유

이 비대칭은 요금표에서 오는 것이 아니라, 각 연산이 실제로 무엇을 해야 하는지에서 옵니다. READ는 질의하는 체인이 이미 추적하고 있는 root에 대해 포함 증명을 검증합니다 — Settlement Layer가 PAI로 유지하는 바로 그 root입니다. 새로 합의할 것도 없고, 합의 라운드도 열리지 않으며, 상태도 건드리지 않습니다. 할 일은 증명 검증 한 번이고, 그 비용은 읽히는 상태의 크기에 따라 커지지 않습니다. 10억 건짜리 로그에서 한 사건을 증명하는 값이나 1천 건짜리에서 증명하는 값이나 같습니다.

이것을 그저 싼 것이 아니라 안전하게 만드는 두 가지 엄격한 규칙이 있습니다. READ는 상태를 바꿔서는 안 되고, READ는 멱등이어야 합니다 — 그래서 재시도는 무해하고, 중복 질의는 아무것도 바꾸지 않으며, 릴레이어가 옛 질의를 재전송해도 손해를 끼칠 수 없습니다. READ 예산을 사실상 무제한으로 둘 수 있는 이유가 바로 이것입니다. 아무것도 바꿀 수 없는 연산은 무언가를 바꾸도록 악용될 수도 없습니다.

유형	방식	비용	예산
READ	ICQ — 기존 root에 대해 증명을 검증	저렴(검증 1회)	사실상 무제한
Cell 안의 WRITE	공유 시퀀서(원자적 포함)	낮음	상태를 가진 트래픽의 대부분
Zone/Region을 넘는 WRITE	XMP + ZK 라이트 클라이언트 + pessimistic proof	높음, 비동기	< 0.1%
전역 원자적 WRITE	Settlement Layer(Tier T0)에서만. intent/solver가 인수	매우 높음	< 0.01%

WRITE는 실제로 무엇을 치르는가

WRITE가 희소한 것은 그것이 정말로 비싸기 때문이고, 그 값은 명확한 검사 묶음을 사 옵니다. 생애주기는 고정되어 있습니다: SendPacket → 메시지가 아웃바운드 메시지 Merkle 트리에 기록됨 → 릴레이어가 증명과 함께 실어 나름 → RecvPacket 이 증명과 재전송 방지 nonce를 검증 → 메시지 실행 → Ack 또는 Timeout. 여기 어디에도 릴레이어를 믿는 대목은 없습니다. 릴레이어는 바이트를 나를 뿐이고, 거짓말하거나 훼손하거나 흘리면 증명 검사가 실패하거나 타임아웃 경로가 작동합니다. 릴레이어는 WRITE를 늦출 수는 있어도 위조할 수는 없습니다.

세 가지 의무가 MUST로 규정되어 있고, 이것이 체인을 늘려도 모델이 흐트러지지 않는 이유입니다:

nonce는 (출발지, 목적지) 쌍마다 단조 증가해야 합니다 — 이것이 재전송을 ‘가능성이 낮은’ 것이 아니라 구조적으로 불가능하게 만듭니다.
자산을 옮기는 WRITE는 반드시 **UAC.checkPlacement** 를 호출해야 합니다 — 그래서 2 도메인 경계가 발행 시점뿐 아니라 이전할 때마다 다시 검사됩니다.
지역을 넘는 WRITE는 반드시 pessimistic-proof 회계를 실어야 합니다 — 원격지의 장애를 상한이 있는 손실로 바꾸는 장치입니다.

기준 데이터 경로 — ‘좋아요’를 기록하고, 다시 실행하지 않고 체인을 넘어 증명하기:

다이어그램

그림 4 — 기준 데이터 경로: 추가하고, 닻 내리고, 체인을 넘어 포함을 증명한다.

무엇이 깨지고, 무엇은 그대로인가

크로스체인 시스템은 순조로운 경로가 아니라 실패 양상으로 평가받아야 합니다. 그래서 중요한 것들을 적습니다 — XChain이 일부러 하지 않는 보장까지 포함해서:

무슨 일이 생기나	어떻게 되나	그래도 남는 것
릴레이어가 끊기거나 검열한다	WRITE가 지연되고 결국 `Timeout` 이 발동한다	부분 적용은 없습니다. 메시지는 유효한 증명과 함께 실행되거나 시간이 만료되거나 둘 중 하나입니다. 누구나 릴레이어를 돌릴 수 있으니 검열은 안전성이 아니라 라이브니스 문제입니다
메시지가 재전송된다	`RecvPacket` 이 nonce 단계에서 거부한다	쌍마다 단조 증가하는 nonce가 재전송을 ‘있음직하지 않은’ 것이 아니라 불가능하게 만듭니다
체인이 장악되어 맡긴 것보다 더 인출하려 한다	pessimistic proof가 초과분을 거부한다	피해가 그 체인 자신의 몫 안에 갇힙니다 — 이것이 바로 인수 기준 MVC-3이 고장을 흉내 낸 체인으로 확인하는 지점입니다(노드 운영하기)
누군가 고가치 자산을 데이터 도메인으로 옮기려 한다	`UAC.checkPlacement` 가 그 WRITE를 거부한다	도메인 경계는 발행 때만이 아니라 이전할 때마다 강제됩니다
지역 간 WRITE가 절반만 완료된다	막지 못합니다. 독립된 합의 구역을 넘는 원자성에는 신뢰 불필요한 구성법이 없습니다	봉쇄와 경제적 인수가 손실에 상한을 겁니다. 이것은 덮지 않고 미해결 문제로 명시되어 있습니다 — 미해결 과제 참조

마지막 줄이 이 설계의 정직한 가장자리입니다. XChain은 전역 원자성을 주장하지 않습니다. 아무도 그것을 신뢰 없이 구성해 내지 못했기 때문입니다. 주장하는 것은, 장애가 그것이 일어난 지역 안에 머문다는 것, 그리고 손실의 크기가 나중에 발견되는 것이 아니라 미리 알려져 있다는 것입니다.

요점: 다른 체인이 증명 확인 한 번으로 그 ‘좋아요’가 일어났음을 증명합니다 — 상태를 가진 메시지도, 재실행도 없이. 지역을 넘는 원자적 WRITE는 프로토콜 계층에서 전부 아니면 전무를 약속하지 않습니다. pessimistic proof와 경제적 인수를 통해 봉쇄를 달성합니다. 다만 거의 공짜인 읽기 경로가 안전하려면, 읽는 대상 경계를 넘어 가치가 새어 나갈 수 없어야 합니다 — 이는 보안의 문제이고, 다음 절이 답합니다.