Ở bài viết trước, tôi đã nói vì sao ngân hàng không muốn dùng chung một sổ cái với đối tác/đồng ngành. Viết xong thì tôi tự đặt một câu hỏi: nếu mỗi bên giữ sổ riêng, thì giao dịch giữa hai ngân hàng rốt cuộc được thực hiện như thế nào? Tiền và tài sản được ghi vào hai cuốn sổ không thông nhau, nghe qua thì dường như không thể làm được. Bài này muốn giải thích rõ quá trình cụ thể đó.

Liên kết bài trước để ở đây: (vì sao ngân hàng không muốn dùng chung một sổ cái với đối tác/đồng ngành)

Trước tiên phải chốt sẵn bối cảnh, không thì sẽ nói rất hời hợt.

Giả sử trong cùng một khu vực tài phán có hai ngân hàng. Ngân hàng A muốn thanh toán, sử dụng khoản tiền gửi token hóa do chính mình phát hành. Ngân hàng B cần giao một tài sản token hóa. Cả hai bên đều không muốn chia sẻ thông tin khách hàng, số dư và logic nghiệp vụ cho nhau, cũng không muốn giao cho bất kỳ bên thứ ba lưu ký nào. Đây là ví dụ điển hình của giao dịch “chứng khoán đổi lấy tiền” (DvP) — trong ngành gọi là DvP.

Cách làm truyền thống hoặc là tìm một bên trung gian để chuyển ghi thay, hoặc là mỗi bên tự ghi sổ rồi đối soát. Cách thứ nhất đưa vào rủi ro đối tác và rủi ro đối thủ vì phải tin một bên thứ ba; cách thứ hai sẽ xuất hiện “cửa sổ” nơi một bên đã cung cấp còn bên kia thì chưa.

Ba lớp lần lượt làm gì

Cách làm của Sovereign là tách việc này ra ba lớp, mỗi lớp có nhiệm vụ khác nhau.

Lớp thấp nhất là sổ kế toán riêng của chính các tổ chức. Nó nằm trong cloud hoặc trung tâm dữ liệu tại chỗ của tổ chức; tổ chức là bên vận hành duy nhất. Danh tính khách hàng, số dư, chi tiết giao dịch và logic nghiệp vụ đều được giữ ở lớp này, không đưa ra ngoài. Khoản tiền gửi token hóa của ngân hàng A được phát hành trên sổ riêng của mình; tài sản token hóa của ngân hàng B được phát hành trên sổ riêng của mình; hoàn toàn không nhìn thấy lẫn nhau.

Trung gian ở đây là mạng riêng tư (Rayls private network). Các tổ chức tham gia trong cùng khu vực tài phán kết nối vào lớp này. Thanh toán xuyên tổ chức diễn ra tại đây, và thứ rời khỏi sổ của mỗi bên chỉ là thông tin thiết yếu đã được mã hóa kèm theo các bằng chứng; ví dụ chính thức đưa ra là chứng minh không kiến thức (zero-knowledge proof). Nói cách khác, ngân hàng B không cần biết khách hàng của ngân hàng A là ai, trên sổ còn lại bao nhiêu, vẫn có thể xác nhận rằng khoản thanh toán này đã hợp lệ.

Phần cao nhất là Rayls public chain (chuỗi công). Các tổ chức kết nối theo nhu cầu với thanh khoản công khai. Lớp này là tùy chọn: một khoản thanh toán thuần túy giữa hai tổ chức trong cùng một khu vực tài phán không cần đi qua public chain.

Rốt cuộc tính nguyên tử (atomicity) được đảm bảo nhờ điều gì

Ý nghĩa của thanh toán nguyên tử rất đơn giản: tiền và tài sản hoặc là cùng chuyển động, hoặc là cùng không chuyển động; không tồn tại trạng thái trung gian kiểu “một bên đã tới, bên kia chưa”.

Điểm then chốt không phải là gộp hai cuốn sổ kế toán thành một, mà là buộc hai hành động được thực hiện trong cùng một lần thanh toán, hoàn tất cùng trong một khối được xác nhận. Bất kỳ bên nào không đáp ứng thì toàn bộ giao dịch cũng không thành; hai bên đều không để lại trạng thái dở dang trên sổ của riêng mình.

Đó cũng là lý do khiến kiểu “tính cuối cùng” mang tính quyết định đặc biệt quan trọng trong bối cảnh tổ chức. Nếu một chuỗi chỉ cung cấp tính cuối cùng theo xác suất, thì trước khi việc thanh toán được xem là đủ an toàn, các tổ chức phải tiếp tục treo khoản phơi nhiễm và số vốn này trên sổ sách; điều đó vừa là rủi ro, vừa là chi phí vốn bị khóa. Trong phần giới thiệu Sovereign, Rayls chính thức đã nêu rõ tính cuối cùng theo xác suất là một vấn đề của các nền tảng hiện có. Tính cuối cùng mang tính quyết định nghĩa là khi thanh toán hoàn tất thì coi như hoàn tất; phần vốn và kiểm soát rủi ro có thể được giải phóng ngay lập tức.

Có một chi tiết rất dễ bị hiểu ngược

Trên mạng riêng tư và Privacy Node, các giao dịch như vậy không thu gas.

Điểm này đáng nói riêng, vì nhiều người sẽ mặc định rằng “làm giao dịch trên blockchain thì phải dùng token của nó để trả phí (fee/gas)”. Trong kiến trúc của Rayls, hoạt động của tổ chức trên sổ riêng và mạng riêng tư không cần trả gas cho từng giao dịch. Cái cần gas là Rayls public chain, và token gas trên public chain là USDr, chứ không phải RLS.

Phân biệt rõ hai việc này thì mới hiểu đúng chi phí sử dụng thực tế của các tổ chức trong hệ thống này.

Kết quả thực tế là gì

Tác động tới hoạt động có thể quy về ba điểm rất cụ thể.

Thanh toán không còn cần một bên trung gian đáng tin cậy. Không ai trong hai ngân hàng đưa sổ cái cho bên kia, cũng không ai thấy dữ liệu khách hàng của bên còn lại, nhưng giao dịch này vẫn có thể hoàn tất theo cách nguyên tử.

Cơ quan giám sát sẽ lấy được những thứ họ cần. Cách nói chính thức là tính tuân thủ và quyền truy cập giám sát được xây ngay ở lớp giao thức lõi, chứ không phải thêm một lớp kiểm tra sau này. Điều này có nghĩa là khả năng kiểm toán không phụ thuộc vào việc các tổ chức tự giác nộp báo cáo, mà kiến trúc ngay từ đầu đã hỗ trợ xem theo phạm vi được ủy quyền.

Nâng cao hiệu quả sử dụng vốn. Tính cuối cùng mang tính quyết định khiến thanh toán hoàn tất là được giải phóng ngay, không cần dự trữ thêm vốn và hạn chế phơi nhiễm rủi ro chỉ để chờ xác nhận theo xác suất.

Đã đi vào hiện thực đến mức nào

Kiến trúc này không phải thiết kế trên giấy, nhưng mức độ trưởng thành giữa các trường hợp khác nhau lại rất khác nhau; nếu trộn lẫn để nhìn chung thì dễ đánh giá quá cao.

Đã triển khai trong môi trường sản xuất là USDXP, stablecoin USD được XP phát hành trên Sovereign. Ngoài ra, phía chính thức có một câu có thể trích dẫn: Khách hàng tổ chức tại Brazil mỗi tháng xử lý hàng chục nghìn tài sản token hóa trên các Privacy Nodes đã được triển khai; nền tảng cơ sở đi vào sản xuất từ tháng 6/2024 và hiện đã có hơn 30 tổ chức tài chính triển khai.

Đang ở giai đoạn thí điểm là Drex của Ngân hàng Trung ương Brazil: 16 ngân hàng lớn của Brazil tự triển khai từng bộ instance của riêng mình, dùng CBDC để thanh toán trái phiếu chính phủ và các tài sản khác. Cách diễn đạt ở đây là “pilot” (thí điểm).

Những gì đã từng chạy thử nghiệm là Kinexys của JPMorgan trong Project EPIC đã thử dùng Sovereign như một lớp quyền riêng tư và danh tính. Thử nghiệm không đồng nghĩa với đưa vào sản xuất.

Những gì đã cam kết nhưng chưa được giao là khoản tín dụng tư nhân 1 tỷ USD do kế hoạch AmFi mang lại, và tối đa 100 tỷ USD tài sản năng lượng & hàng hóa mà Nimofast cam kết. Hai con số này là quy mô cam kết, không phải là tài sản đã được phát hành thông qua Sovereign.

Sau khi tách bốn lớp này ra, nhìn vào danh sách đó: sức thuyết phục nằm ở chỗ thành phần tổ chức đa dạng, từ ngân hàng trung ương, ngân hàng thương mại cho tới bên phát hành tài sản, chứ không phải ở việc cộng tổng quy mô cam kết.

Tóm tắt trong một câu

Mỗi bên giữ sổ riêng, và vẫn cùng làm ăn, không hề mâu thuẫn. Điểm mấu chốt là đưa việc thanh toán vào lớp trung gian đó, để thứ rời khỏi sổ của mỗi bên chỉ là bằng chứng/chứng minh, chứ không phải dữ liệu.

Để xem phần mô tả đầy đủ chính thức về Sovereign, có thể vào trang sản phẩm của Rayls trên rayls.com/products/sovereign

Nguồn tham khảo: blog chính thức của Rayls (Introducing Rayls Sovereign: the onchain gateway for institutions) (Peter Bidewell, 25/08/2026); tài liệu về Rayls public chain: https://www.rayls.com/blog/introducing-rayls-sovereign-the-onchain-gateway-for-institutions