Phần lớn thiết kế liên chuỗi thất bại vì coi mọi tương tác là một loại lưu lượng. XChain kẻ một lằn ranh cứng giữa READ (không đổi trạng thái) và WRITE (đổi trạng thái) — một phân biệt nguyên thủy duy nhất mà cả mô hình treo lên đó. Phần lớn nhu cầu liên chuỗi chỉ là xác minh "X đã xảy ra trên chain A" — một READ, qua Interchain Queries (ICQ) — rẻ và gần như vô hạn. Chỉ chuyển trạng thái atomic mới là WRITE, qua IBC v2/Eureka + Interchain Accounts (ICA), và bị giữ cho khan hiếm có chủ đích.

Vì sao một READ gần như miễn phí

Sự bất đối xứng này không đến từ biểu phí, nó đến từ việc mỗi thao tác thật sự phải làm gì. Một READ kiểm một proof inclusion đối chiếu với root mà chain đi hỏi vốn đã theo dõi sẵn — đúng cái root Layer Settlement duy trì qua PAI. Không có gì mới phải thống nhất, không mở vòng đồng thuận nào, không chạm vào trạng thái nào. Việc phải làm là một phép kiểm proof, và chi phí đó không tăng theo kích thước trạng thái được đọc: chứng minh một sự kiện nằm trong một log một tỷ mục tốn đúng bằng chứng minh nó nằm trong log một nghìn mục.

Hai luật cứng khiến điều này an toàn chứ không chỉ rẻ. Một READ KHÔNG ĐƯỢC đổi trạng thái, và một READ PHẢI idempotent — nên thử lại là vô hại, hỏi trùng không đổi gì, và một relayer phát lại truy vấn cũ không gây được thiệt hại nào. Đó chính là lý do ngân sách READ để gần như vô hạn được: một thao tác không thể thay đổi gì thì không thể bị lợi dụng để thay đổi thứ gì.

Loại	Cơ chế	Chi phí	Ngân sách
READ	ICQ — kiểm một proof với root có sẵn	Rẻ (một phép verify)	Gần như vô hạn
WRITE trong một Cell	Shared sequencer (atomic inclusion)	Thấp	Phần lớn lưu lượng có trạng thái
WRITE liên Zone/Region	XMP + ZK light client + pessimistic proof	Cao, async	< 0,1%
Global atomic WRITE	Chỉ Layer Settlement (Tier T0); intent/solver bảo lãnh	Rất cao	< 0,01%

Một WRITE thật sự tốn những gì

WRITE khan hiếm vì nó đắt thật, và cái giá đó mua về một bộ kiểm tra cụ thể. Vòng đời của nó cố định: SendPacket → message được ghi vào Cây Merkle Message Đi Ra → một relayer mang nó đi kèm proof → RecvPacket kiểm proof và nonce chống phát lại → message thực thi → Ack hoặc Timeout. Không chỗ nào tin relayer cả: nó chỉ chở byte, và nếu nó nói dối, làm hỏng hay đánh rơi message thì phép kiểm proof trượt hoặc nhánh timeout kích hoạt. Relayer có thể làm chậm một WRITE; nó không giả mạo được một WRITE.

Ba nghĩa vụ được quy định ở mức MUST — đây là thứ giữ mô hình không trôi khi thêm chain mới:

Nonce PHẢI tăng đơn điệu theo từng cặp (nguồn, đích) — đây là thứ khiến phát lại thành bất khả về mặt cấu trúc, chứ không chỉ là khó xảy ra.
Mọi WRITE có dịch chuyển tài sản PHẢI gọi **UAC.checkPlacement** — nên ranh giới 2 Miền được kiểm lại ở mỗi lần chuyển, không chỉ lúc phát hành.
WRITE liên vùng PHẢI mang hạch toán pessimistic-proof — cơ chế biến một sự cố ở xa thành một khoản thiệt hại có chặn trên.

Đường đi dữ liệu tham chiếu — ghi một "like" và chứng minh nó xuyên chain mà không chạy lại:

Sơ đồ

Hình 4 — Đường đi dữ liệu tham chiếu: append, neo, và chứng minh inclusion xuyên chain.

Cái gì hỏng, và cái gì vẫn đứng

Hệ liên chuỗi được đánh giá bằng các kiểu hỏng của nó, không phải bằng đường đi thuận lợi — nên đây là những kiểu hỏng đáng kể, kể cả điều XChain cố ý KHÔNG hứa:

Chuyện gì xảy ra	Hệ quả	Cái gì vẫn đứng
Relayer offline hoặc kiểm duyệt	WRITE bị trễ; cuối cùng `Timeout` kích hoạt	Không có áp dụng nửa vời: message hoặc thực thi với proof hợp lệ, hoặc hết hạn. Ai cũng chạy relayer được, nên kiểm duyệt là vấn đề liveness chứ không phải an toàn
Một message bị phát lại	`RecvPacket` từ chối ở bước nonce	Nonce tăng đơn điệu theo cặp khiến phát lại là bất khả, không phải "khó xảy ra"
Một chain bị chiếm và tìm cách rút nhiều hơn số đã nạp	Pessimistic proof từ chối phần vượt	Thiệt hại bị chặn trong đúng phần của chain đó — đây chính là thứ tiêu chí nghiệm thu MVC-3 đánh vào, với một chain hỏng mô phỏng (Chạy node)
Ai đó tìm cách đưa tài sản giá trị cao vào Miền dữ liệu	`UAC.checkPlacement` từ chối WRITE	Ranh giới Miền được cưỡng chế ở mỗi lần chuyển, không chỉ lúc phát hành
Một WRITE liên vùng hoàn tất nửa chừng	Không ngăn được. Tính atomic xuyên các vùng đồng thuận độc lập chưa có cách dựng không-cần-tin-cậy nào	Containment và bảo lãnh kinh tế chặn trên thiệt hại. Điều này được nói ra như một bài toán chưa giải, không tô vẽ — xem Bài toán mở

Dòng cuối là mép trung thực của thiết kế này. XChain không tuyên bố atomic toàn cục, vì chưa ai có cách dựng không-cần-tin-cậy cho nó; thứ nó tuyên bố là sự cố ở lại bên trong vùng nơi nó xảy ra, và độ lớn thiệt hại được biết trước chứ không phải phát hiện ra sau.

Câu chốt: một chain tách biệt chứng minh cái "like" đã xảy ra bằng một phép kiểm proof — không message có trạng thái, không chạy lại. WRITE atomic liên vùng không được hứa all-or-nothing ở tầng giao thức; chúng chỉ đạt containment qua pessimistic proof và bảo lãnh kinh tế. Nhưng một đường đọc gần-miễn-phí chỉ an toàn khi giá trị không bao giờ rò qua được ranh giới mà nó đọc xuyên — đó là câu hỏi bảo mật, trả lời ngay sau đây.