Cosmos Interchain Security: chuỗi provider, consumer, phần thưởng và slashing

Interchain Security (ICS) kết nối các chuỗi Cosmos riêng biệt qua giao thức Inter-Blockchain Communication (IBC). Chuỗi provider quản lý bộ validator, còn chuỗi consumer sử dụng các validator đủ điều kiện của provider để đề xuất và xác nhận block của chính mình. Mỗi chuỗi vẫn có máy trạng thái, sổ cái, phí, token, quản trị và quy tắc ứng dụng riêng.

“Chia sẻ bảo mật” không có nghĩa là coin của người ủy quyền chuyển sang consumer. ATOM đã ủy quyền vẫn được khóa theo quy tắc staking của provider. Consumer nhận được sự tham gia của validator được bảo chứng bằng stake của provider và có thể gửi bằng chứng về một số hành vi sai phạm tới provider. Vì vậy, số dư ví, token của consumer và stake đang khóa trên provider là các khái niệm khác nhau.

ICS cũng không chỉ là cầu nối token IBC. IBC cung cấp liên lạc được xác thực giữa các chuỗi; ICS dùng một ứng dụng xác thực liên chuỗi riêng để chuyển cập nhật bộ validator và bằng chứng vi phạm. Một giao dịch token có thể dùng ICS-20 mà không chia sẻ bộ validator. Ngược lại, việc chia sẻ validator không tự động bảo đảm an toàn cho mọi ứng dụng hay token trên consumer.

Tổng quan về Interchain Security · Thuật ngữ Interchain Security

Consumer không nhất thiết sao chép toàn bộ bộ validator của provider. Partial Set Security (PSS) cho phép consumer chọn một tập con. Cấu hình Top N chọn validator theo tỷ lệ voting power xác định trên provider. Cấu hình opt-in cho phép validator đủ điều kiện tự nguyện tham gia một consumer cụ thể. Cần xem cấu hình hiện tại của chain để biết quy tắc nào đang áp dụng.

Power shaping có thể tiếp tục thu hẹp hoặc cân bằng lại bộ validator của consumer. Chain có thể giới hạn số validator tối đa, giới hạn phần voting power mà một validator nắm trên consumer, hoặc áp dụng allowlist và denylist. Các cài đặt này thay đổi bộ validator của consumer, không thay đổi phân bổ stake bị khóa trên provider.

Chain Top N thường cần được quản trị provider phê duyệt vì một số validator có thể bị yêu cầu tham gia. Chain opt-in có thể ra mắt mà không ép validator nào tham gia. Đừng suy đoán cách ra mắt chỉ từ cụm từ “chain Cosmos”. Hãy kiểm tra chain ID và consumer ID, trạng thái ra mắt, quy tắc Top N hay opt-in, tham số power shaping và quy trình quản trị hiện hành của provider; tài liệu và tính năng có thể thay đổi.

Partial Set Security · Power shaping · Permissionless ICS

Validator của provider tham gia consumer thường chạy một node consumer riêng và tuân theo phần mềm cùng hướng dẫn khởi chạy của chain đó. Validator có thể gán consensus key riêng cho từng consumer thay vì dùng lại key của provider. Tách key làm giảm khả năng key ký của provider bị lộ nếu node consumer bị xâm nhập, nhưng không loại bỏ rủi ro vận hành, phần mềm hoặc ký xác nhận.

Quy tắc tham gia quyết định ai cần chạy node consumer. Với Top N, nghĩa vụ có thể tùy thuộc voting power của provider và ngưỡng đã đặt; opt-in thường để validator tự chọn. Giới hạn power hoặc danh sách có thể thay đổi bộ validator cuối cùng. Validator nên kiểm tra điều kiện đủ tư cách, key được gán, hash binary, thời điểm bắt đầu và yêu cầu giám sát cho từng consumer.

Người ủy quyền thường không tự chạy node consumer. Stake của họ trên provider hỗ trợ validator nhận thêm công việc, và hình phạt từ consumer có thể ảnh hưởng stake đó. Vì thế chỉ xem danh tính và uptime của validator trên provider là chưa đủ; cần kiểm tra cả quy tắc tham gia và xử lý vi phạm của từng consumer.

Hướng dẫn validator và trình tự khởi động · Gán key

Khi stake hoặc điều kiện đủ tư cách trên provider thay đổi, bộ validator consumer có thể cần cập nhật. ICS gửi thay đổi qua kênh Cross-Chain Validation (CCV). Relayer chuyển tiếp thông điệp giữa hai chain; mỗi chain kiểm tra trạng thái theo giao thức và tự áp dụng thay đổi của mình. Relayer không phải validator của consumer và không quyết định chữ ký nào hợp lệ.

Việc phối hợp này có thể khiến thời điểm tham gia hoặc rời đi phức tạp hơn so với chain độc lập. Tài liệu thiết kế CCV trước đây mô tả gói thay đổi bộ validator và thông báo maturity để bảo vệ quy trình unbonding giữa các chain. Cách triển khai đã phát triển, vì vậy bài giải thích ICS tổng quát không thể hứa rằng mọi trường hợp undelegate khỏi provider đều có cùng một khoảng chờ bổ sung. Hành vi chính xác tùy thuộc phiên bản giao thức và tham số chain.

Trước khi thay đổi ủy quyền hoặc rút stake, hãy đọc tài liệu hiện hành của provider và consumer, đồng thời kiểm tra các bản ghi unbonding đang chờ. Phân biệt thời gian staking thông thường với khâu phối hợp riêng của ICS. Relayer chậm hoặc client lỗi thời cũng có thể làm chậm gói tin mà không thay đổi quy tắc cơ bản.

Tổng quan CCV trong đặc tả IBC · Hướng dẫn validator

Consumer có thể gửi bằng chứng về hành vi sai phạm của validator tới provider. Tài liệu ICS phân biệt downtime với equivocation như ký hai lần. Quy tắc chain, phiên bản giao thức và tham số infraction của consumer quyết định cách xử lý bằng chứng; kết quả có thể là jail, cắt giảm stake hoặc cả hai.

Không có một mức phạt chung cho mọi chain. Tài liệu chính thức hiện nay cũng không mô tả hoàn toàn thống nhất hậu quả của downtime: hướng dẫn validator nói Hub jail mà không slash, còn trang tính năng slashing mô tả jail và slash theo tham số của consumer. Vì vậy, đừng suy ra hậu quả tài chính chỉ từ nhãn “ICS”; hãy kiểm tra cách triển khai, cấu hình và quy trình bằng chứng của chính chain đó. Bằng chứng ký hai lần hợp lệ có thể dẫn đến slash, jail và tombstone trên provider.

Nếu provider cắt giảm stake, validator và người ủy quyền có thể cùng chịu ảnh hưởng kinh tế theo quy tắc staking của provider. Jail có thể loại validator khỏi bộ hoạt động của provider và do đó khỏi bộ consumer. Đừng cho rằng vi phạm trên consumer chỉ ảnh hưởng phần thưởng bằng token của consumer.

Slashing do consumer khởi tạo · Hướng dẫn validator Interchain Security

Consumer có thể gửi một tỷ lệ nhất định trong phần thưởng block hoặc phí cho provider để đổi lấy bảo mật. Tài sản được chuyển định kỳ qua kênh chuyển IBC. Provider chỉ nhận các denom được đưa vào danh sách cho phép, còn điều kiện nhận phụ thuộc quy tắc của consumer. Tài liệu hiện hành cho biết validator có thể phải tham gia liên tục trong một số epoch nhất định trước khi nhận thưởng; sau đó người ủy quyền có thể được chia theo quy tắc phân phối của provider.

Ví dụ giả định đơn giản: consumer ghi nhận 12.000 đơn vị phí và phần thưởng lạm phát đủ điều kiện trong một kỳ, còn quản trị đặt tỷ lệ dành cho provider là 25%. Phép tính cho ra 3.000 đơn vị được chuyển về phía pool thưởng của provider. Con số này không cho biết giá trị bằng USD, phần phân bổ cuối cùng cho validator, thời điểm phân phối hay lợi nhuận tương lai. Nếu có giới hạn voting power, trọng số phân phối có thể dựa trên voting power đã điều chỉnh ở consumer thay vì mức ban đầu trên provider.

Token thưởng có thể biến động, kém thanh khoản hoặc tốn phí để nhận. APY hiển thị có thể gộp các giả định thay đổi về hoạt động consumer, tỷ lệ thưởng, validator đủ điều kiện, commission, phân phối của provider, denom được chấp nhận và thời gian opt-in. Hãy xem thưởng consumer là dòng giá trị giao thức biến thiên, không phải APY được bảo đảm hay khoản bù chắc chắn cho rủi ro slash.

Quy tắc phân phối phần thưởng · Phần thưởng validator trên consumer

Dùng validator của provider có thể khiến consumer khó bị tấn công hơn so với chỉ dựa vào một bộ validator mới và nhỏ. Tuy nhiên consumer không trở thành bản sao của provider. Consumer vẫn có phần mềm ứng dụng, quản trị, thiết kế kinh tế, IBC client và channel, phụ thuộc vận hành, smart contract hoặc module riêng.

Bộ validator chỉ là một phần của mô hình bảo mật. Tập con trên consumer có thể tập trung hơn hoặc có độ sẵn sàng khác với toàn bộ bộ validator provider. Sự cố client hoặc relayer có thể làm chậm phối hợp; lỗi phần mềm consumer vẫn có thể gây hại dù validator provider hành xử đúng. Quản trị có thể thay đổi tham số, còn giá token có thể giảm độc lập với cơ chế xác thực.

Câu “được Cosmos Hub bảo mật” là điểm bắt đầu để kiểm tra, không phải đánh giá rủi ro đầy đủ. Hãy hỏi provider nào tham gia, validator nào được chọn, voting power được định hình ra sao, bằng chứng nào có thể dẫn đến slash, phần thưởng nào được chuyển và quy trình thoát hoặc chuyển đổi là gì. Mức bảo mật gắn với cấu hình và giai đoạn vận hành cụ thể.

Thuật ngữ và các dạng bảo mật Interchain · Quản trị consumer

Trước tiên, xác nhận đúng chain ID, consumer ID và provider. Kiểm tra chain dùng Top N hay opt-in, power cap hoặc danh sách có làm thay đổi bộ validator không, và danh sách công bố có phản ánh cập nhật mới nhất không. Chỉ nhìn số lượng validator thì không biết voting power được phân bổ ra sao.

Nếu bạn là validator hoặc người ủy quyền, hãy xác minh validator có cần opt-in không, consumer dùng consensus key nào, binary chạy có đúng không, và downtime hay ký hai lần được xử lý thế nào. Đọc tham số jail và slash đang hoạt động. Khi ủy quyền, phân biệt stake bị khóa trên provider với phần thưởng consumer mà ví hiển thị.

Cuối cùng, kiểm tra danh sách denom thưởng được chấp nhận, số epoch cần để đủ điều kiện, quy tắc phân phối và commission, quyền quản trị consumer, trạng thái relayer/client, cùng quy trình undelegation hoặc changeover hiện hành. Đừng gộp những điều này với staking chỉ trên provider hay việc chuyển token; đó là các thao tác khác nhau.

[Ủy quyền và slashing trên Cosmos Hub](/learn/cosmos-staking-delegation-unbonding-slashing-validator-commission-explained) · [Chuyển IBC và rủi ro relayer](/learn/cosmos-ibc-transfer-clients-channels-packet-timeouts-relayer-risks-explained) · Staking crypto so với cho vay DeFi

Nguồn sơ cấp: Tổng quan Interchain Security; thuật ngữ; Partial Set Security; Power shaping; phân phối phần thưởng; slashing do consumer khởi tạo; hướng dẫn validator; đặc tả CCV của IBC.