Câu trả lời một dòng: một sự kiện rẻ được ghi vào log Nền B → gộp thành segment và neo lên chain Nền A → chain khác đọc và xác minh proof thay vì thực thi lại → giá trị chỉ settle ở Root, dưới bất biến tổng cung.

1. Dòng chảy một sự kiện, từ đầu đến cuối

Sơ đồ

Điểm mấu chốt: A1 tin sự kiện đó mà không cần ai gửi cho nó một message có trạng thái — nó chỉ cần một proof đối chiếu với commitment đã được neo. Đây chính là nội dung cổng MVC-1.

2. Bảy nguyên thủy — giao diện và bất biến

#1 UIR — Universal Identity Root


Bất biến	Một danh tính gốc phân giải được trên mọi chain; tài khoản theo chain suy ra tất định; uỷ quyền bằng một chữ ký
Giao diện	`deriveAccount(id, chain)` · `resolve(chain, address)` · `authorize(intent, sig)` · `identityRoot()`
Quy tắc cứng	`id` duy nhất toàn cục; `deriveAccount` phải tất định (cùng đầu vào → cùng địa chỉ); khôi phục tuân theo chính sách đã đăng ký

#2 UAC — Universal Asset Commitment


Bất biến	Bảo toàn tổng cung toàn cục và mỗi tài sản có một security-class tối thiểu
Công thức phải đúng tại mọi checkpoint Root	`totalSupply == Σ perChain + lockedInTransit`
Giao diện	`registerAsset` · `securityClassOf` · `checkPlacement(assetId, targetTier)` · `verifySupply`
Quy tắc cứng	`checkPlacement` phải trả false nếu tầng đích thấp hơn lớp tối thiểu; mọi tài sản mang giá trị bị từ chối ở Nền B; mint cập nhật tổng cung một cách nguyên tử

Đây là chỗ "tấn công hạ cấp" biến mất về mặt cấu trúc: không ai quên kiểm tra, vì phép kiểm nằm trong đường đi bắt buộc của mọi WRITE tài sản.

#3 XMP — XChain Messaging Protocol


Bất biến	Liên chuỗi trust-minimized, tách rõ READ (không đổi trạng thái) và WRITE (đổi trạng thái)
Vòng đời WRITE	`SendPacket` → ghi vào cây Merkle thư đi → relay kèm proof → `RecvPacket` (xác minh proof + chống replay bằng nonce) → thực thi → `Ack` / `Timeout`
Quy tắc cứng	`nonce` tăng đơn điệu theo cặp (nguồn, đích) để chống replay; READ không được đổi trạng thái và phải idempotent; WRITE tài sản phải gọi `UAC.checkPlacement`

#4 PAI — Proof Aggregation Interface


Bất biến	Tầng cha xác minh chuyển trạng thái của con mà không thực thi lại; gộp đệ quy độ sâu log
Giao diện	`proveTransition(prevRoot, txs, newRoot)` · `aggregate(children)` · `verify(agg, expectedChildren)`
Ngữ nghĩa bắt buộc	`verify(agg) == true` ⟹ với mọi chain con, `newRoot = Execute(prevRoot, txs)` theo luật VM của chain đó — và `verify` không được thực thi lại giao dịch

#5 DA Interface (phân tầng)


Bất biến	Dữ liệu đã cam kết là lấy được / lấy mẫu được theo chính sách của tầng
Giao diện	`publish(ns, data, tier)` · `sample(commitment, n)` · `retrieve` · `verifyAvailability`
Chính sách theo tầng	T0/T1 vĩnh viễn + sampling đầy đủ · T2 trung hạn · T3 prune sau thời hạn (chỉ commitment còn lại) · T4 ephemeral
Quy tắc cứng	Phải erasure-code và hỗ trợ truy xuất theo namespace; node nhẹ phải xác minh được availability bằng sampling mà không tải toàn bộ

#6 VLC — Verifiable Log Commitment (lõi Nền B)


Bất biến	Log append-only, có namespace, chống giả mạo + đóng dấu thời gian + chứng minh inclusion, không cần đồng thuận per-log, value-free
Giao diện	`append(ns, payload)` (rẻ, nhanh) · `commitSegment(ns, entries)` (định kỳ: publish DA + neo lên Nền A) · `proveInclusion` · `verifyInclusion`
Đảm bảo	Đổi bất kỳ entry nào cũng phá gốc Merkle; timestamp lấy từ anchor checkpoint; inclusion chứng minh được
KHÔNG đảm bảo (ghi rõ trong đặc tả)	Không chống double-spend · không có tổng thứ tự giữa các namespace · không giữ giá trị

#7 SC — Settlement Contract


Bất biến	Logic tối thiểu ở Root: finalize giá trị liên vùng, cập nhật registry, tiêu thụ aggregated proof
Giao diện	`submitRegionCommitment` · `settle(request)` (chỉ T0) · `updateRegistry`
Quy tắc cứng	Chỉ nhận commitment có aggregated proof hợp lệ; không được thực thi giao dịch ứng dụng; phải enforce bất biến tổng cung khi chuyển tài sản liên vùng

3. Mô hình bảo mật — ba lớp cho giá trị cao

Sơ đồ

Ba lớp bảo mật chain, chọn theo giá trị chứ không theo sở thích:

Lớp	Dùng cho	Bảo đảm
SOVEREIGN	T3–T4, giá trị thấp	Validator riêng của chain
SHARED	T1–T2	Bảo mật chia sẻ (Partial Set Security)
ZK_SECURED	T0–T1	Bắt buộc có validity proof

Pessimistic proof bảo đảm failure isolation: một chain lỗi chỉ mất phần của chính nó — đã được chứng minh ở cổng MVC-3, nơi thao tác rút vượt bị chặn và tổng số dư vẫn khớp tổng đã nạp.

4. Vì sao READ rẻ mà WRITE đắt

Loại	Cơ chế	Chi phí	Ngân sách
READ	Xác minh proof đối chiếu root đã có	Một lần verify	Không giới hạn thực tế
WRITE nội Cell	Shared sequencer, atomic inclusion	Thấp	Phần lớn traffic có trạng thái
WRITE liên Zone/Region	XMP + ZK light client + pessimistic proof	Cao, bất đồng bộ	< 0,1%
WRITE atomic toàn cục	Chỉ T0, có bảo chứng kinh tế	Rất cao	< 0,01%

Trung thực về giới hạn: WRITE atomic liên vùng không được đảm bảo all-or-nothing ở tầng giao thức. Cái đạt được là containment qua pessimistic proof cộng bảo chứng kinh tế. Đặc tả nói thẳng điều này thay vì để người đọc tự phát hiện.

5. Tham số quy chiếu giai đoạn hiện tại

Tham số	Giá trị
Số chain Nền A (testnet)	3
Số namespace Nền B (testnet)	9 trên một DA node
Đồng thuận	CometBFT, block time ~1s
Hàm băm của eo thắt	SHA-256 (tương thích CometBFT/IAVL/IBC)
Hệ chứng minh	MOCK (giai đoạn testnet) → SP1/Boojum sau
DA mỗi giao dịch sau nén (mục tiêu)	5–16 byte
Lưu giữ T3	Vài tuần rồi prune
Tỷ lệ WRITE liên vùng	< 0,1%

6. Kỷ luật kỹ thuật của dự án

Đây là phần ít được nói tới nhưng quyết định chất lượng của mọi thứ ở trên:

Luật cứng	Nội dung
Đặc tả là nguồn chân lý	Khi code lệch đặc tả thì sửa code, không sửa đặc tả cho vừa code
RFC 2119 được tôn trọng	MUST / MUST NOT trong đặc tả là ràng buộc, không phải gợi ý
Verify trước khi tuyên bố xong	Build được thì mới nói build được; test chạy thì dán output; không chấp nhận "có vẻ đúng"
Không build ngược đồ thị phụ thuộc	`UIR → (UAC, XMP)` · `DA → (VLC, PAI)` · tất cả → SC
Không lift code mù	Mỗi phần lift từ dự án khác phải rà bỏ những giả định không thuộc XChain
Bất biến tổng cung có test riêng	Đây là ràng buộc đúng-đắn tới hạn, không phải một khẳng định trong tài liệu
Chạm production cần người duyệt	Devnet và scaffold thì tự do

7. Bốn kịch bản nghiệm thu — cách kiểm chứng lại

Cổng	Kiểm chứng điều gì
MVC-1	Sự kiện rẻ ở Nền B được một chain khác đọc và xác minh xuyên chain, không cần message có trạng thái
MVC-2	Tài sản giá trị cao không thể tồn tại ở Nền B — placement bị chặn bằng mã
MVC-3	Một chain lỗi không kéo theo chain lành; rút vượt bị chặn; tổng số dư khớp tổng đã nạp
MVC-4	Proof của ba chain gộp lên Root và settle kèm bất biến tổng cung; chứng chỉ giả mạo bị từ chối

Cả bốn chạy lại được từ trạng thái sạch bằng một kịch bản duy nhất — đó là điều biến "đã kiểm chứng" từ một lời tuyên bố thành một thao tác lặp lại được.

Tiếp theo: Hỏi–Đáp — 50 câu hỏi thường gặp