Bỏ qua điều hướng
XChain Docs

Cơ chế — kiến trúc

Cập nhật lần cuối: 06/08/20262 phút đọc

Toàn bộ kiến trúc xoay quanh một câu hỏi bạn có thể hỏi về bất kỳ mẩu dữ liệu nào:

"Cái này có cần chống double-spend hay composability không?" → Nền A. Không → Nền B.

Ranh giới đó không phải lời khuyên; nó được Asset Registry (nguyên thủy UAC) cưỡng chế, nên Nền B không bao giờ chứa giá trị — do cấu trúc, không do tự giác.

Trên tầng chia đó là năm tầng đảm bảo. Khối lượng ở dưới, cam kết ở trên — để ba bức tường thật sự khó (proof ZK, DA vĩnh viễn, đồng thuận) chỉ đè lên phần nhỏ có giá trị:

TầngĐảm bảo cốt lõiData availability% khối lượng
T0 RootSettlement cuối cùng, ZKVĩnh viễn<0,01%
T1 ValueChống double-spend, ZK validityLưu lâu~1%
T2 InteractiveTrạng thái nhất quán, ZK/fraud proofTrung hạn~9%
T3 EventsTamper-evidence + timestamp + inclusionPrune ~tuần~85%
T4 EdgeAttestation khi checkpointEphemeral~5%

Hai cơ chế khiến nó bay:

  • READ vs WRITE. 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): rẻ, an toàn, gần như vô hạn. Chỉ chuyển trạng thái atomic — một WRITE (qua IBC v2/Eureka + ICA) — mới đắt, và bị cố ý giữ dưới 0,1% lưu lượng.
  • Bảo mật đi theo tài sản. Mỗi tài sản mang một security-class tối thiểu; tài sản giá trị cao đơn giản không thể tồn tại trên Nền B. Nhờ vậy tấn công "hạ cấp" biến mất về mặt cấu trúc, và an toàn của giá trị dựa trên soundness ZK cộng vốn kinh tế toàn cục — không dựa vào lòng tin ở số ít validator.

Phép màu, cụ thể hoá: một chain hoàn toàn tách biệt có thể chứng minh rằng một 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. Đó là verify, don't re-execute, và là toàn bộ luận điểm gói trong một sơ đồ.

Cơ chế — kiến trúc — XChain Docs