Sàn giao dịch của bạn nhận được một khoản nạp 1.000 USDT qua XRP Ledger. Hệ thống đọc field Amount, ghi có 1.000 USDT cho khách hàng. Mọi thứ hiển thị bình thường. Nhưng khi bạn đối soát ví lạnh, số dư thực tế chỉ tăng 100 USDT. 900 USDT biến mất. Kẻ gửi tiền chỉ mất phí giao dịch vài trăm XRP. Bạn không bị hack. Bạn không bị khai thác lỗ hổng smart contract. Bạn chỉ đơn giản là đọc nhầm field.
Chào mừng đến với thế giới của XRP Ledger Partial Payments — một "tính năng" đã tồn tại từ rất lâu, mà theo lời tác giả của bài viết gốc: "không phải bug".
Tuyên bố đó đúng về mặt kỹ thuật. Nhưng trong bảo mật, thứ gọi là "không phải bug" thường là nơi nguy hiểm nhất. Kẻ tấn công không cần phá vỡ giao thức. Chúng chỉ cần khai thác sự thiếu hiểu biết của người tích hợp.
Bối cảnh: Partial Payments thực sự là gì?
XRPL là một Layer 1 tập trung vào thanh toán. Ra đời từ 2012, thiết kế của nó đi trước nhiều nền tảng khác trong việc xử lý thanh toán xuyên biên giới. Một trong những công cụ đó là cờ tfPartialPayment trên transaction type Payment.
Bình thường, khi bạn gửi tiền trên blockchain, giao dịch thành công hoặc thất bại. Không có chuyện "gần đủ thì vẫn chuyển". Nhưng XRPL cho phép điều đó.
Khi cờ Partial Payment được bật, giao dịch có thể thành công ngay cả khi số tiền thực nhận nhỏ hơn Amount — field khai báo số tiền mong muốn. Hệ thống XRPL gọi đây là một tính năng để tăng tỷ lệ thành công của các khoản thanh toán qua path, khi thanh khoản từng chặng không đủ để chuyển đủ số tiền chính xác. Thay vì thất bại toàn bộ, giao dịch vẫn chạy và người nhận nhận được "càng nhiều càng tốt".
Ví dụ: Bạn muốn gửi 1.000 USD từ nguồn XRP, xuyên qua vài bước chuyển đổi. Giữa đường, thanh khoản thiếu, thay vì hủy cả giao dịch, XRPL chuyển thành công với số tiền thực nhận 990 USD. Điều này đúng với mục đích ban đầu: không để thanh toán bị chặn vì trượt giá nhỏ.
Với mục đích đó, tính năng này có ý nghĩa.
Điểm mù kỹ thuật nằm ở field bạn chọn để tin tưởng
Toàn bộ vấn đề không nằm ở giao thức, mà nằm ở nơi các bên tích hợp đọc dữ liệu để cập nhật số dư.
Trong XRP Ledger, mỗi giao dịch Payment đều có hai trường dữ liệu quan trọng:
Amount(hoặcDestination Amount): Số tiền mà người gửi tuyên bố muốn chuyển.delivered_amount: Số tiền thực tế mà người nhận nhận được, được ghi trong metadata của giao dịch sau khi hoàn tất.
Với các giao dịch không bật Partial Payment, hai giá trị này luôn bằng nhau. Người ta dần quen với việc dùng Amount làm cơ sở ghi có. Nhưng khi Partial Payment bật, delivered_amount có thể nhỏ hơn Amount. Và nếu hệ thống của bạn không kiểm tra delivered_amount, bạn sẽ ghi có theo số tiền công bố — tức là bạn tự bù lỗ cho kẻ gửi.
Trong các cuộc audit smart contract mà tôi từng thực hiện, đây là class lỗi quen thuộc: tin tưởng vào tham số đầu vào thay vì trạng thái thực tế sau khi thực thi. Nó giống hệt như một hợp đồng DeFi dùng msg.value làm số tiền cập nhật số dư thay vì dùng balanceOf sau khi cộng dồn. Lỗi này không phải do EVM hay Solidity tạo ra. Nó đến từ developer không hiểu rõ contract họ đang viết — hoặc trong trường hợp này, integrator không hiểu rõ giao thức họ đang kết nối.
Khi bạn tin `Amount` thay vì `delivered_amount`, bạn không "hiểu nhầm" giao thức. Bạn đang chủ động tạo ra một lỗ hổng.
Kẻ tấn công có thể gửi một giao dịch hợp lệ với Amount: 1.000 USDT nhưng bật cờ Partial Payment và điều chỉnh đường đi (path) khiến delivered_amount chỉ còn 100 USDT. Nạn nhân — thường là sàn giao dịch hoặc cổng thanh toán — đọc Amount và ghi có 1.000 USDT. Kẻ tấn công sau đó rút tiền và rời đi.
Vụ việc này đã từng xảy ra trong thực tế, với nhiều loại token khác nhau trên XRPL. Nó không phải lỗ hổng của riêng XRP mà áp dụng cho mọi token phát hành trên ledger.
Tại sao "không phải bug" không đồng nghĩa với "không có rủi ro"
Câu khẳng định "đây là tính năng, không phải bug" là đúng về mặt thiết kế giao thức. Partial Payments được đưa vào XRPL một cách có chủ đích, có tài liệu, có flag riêng. Không có gì sai ở đây.
Nhưng trong thực tế vận hành, câu nói này trở thành một cái bẫy nguy hiểm.
Có một sự khác biệt tinh tế giữa "một tính năng có chủ đích" và "một tính năng được thiết kế để an toàn trong mọi ngữ cảnh sử dụng". Partial Payments sinh ra để phục vụ nhu cầu xử lý thanh toán linh hoạt, nhưng nó không được thiết kế để ngăn chặn việc bị lạm dụng bởi người nhận cố ý đọc sai dữ liệu.
Hãy nhìn cách các giao thức khác xử lý vấn đề tương tự. Bitcoin và Ethereum không có khái niệm "partial payment" trong lớp cơ sở. Stellar, một giao thức có nhiều điểm tương đồng với XRPL, có path payment nhưng lại yêu cầu xác định chính xác DestAmount — hoặc chấp nhận DestMin với một mức tối thiểu rõ ràng. Tức là, nếu không đủ điều kiện "tối thiểu", giao dịch thất bại. Đó là một thỏa hiệp thiết kế khác: ưu tiên sự rõ ràng cho người nhận hơn là sự linh hoạt cho người gửi.
XRPL chọn ưu tiên tính khả dụng của thanh toán. Điều đó có lý. Nhưng nó đặt gánh nặng lên vai integrator: nếu bạn không biết, bạn sẽ mất tiền.
Một hệ thống chỉ an toàn khi nơi yếu nhất của nó được thiết kế có chủ đích.
Trách nhiệm đổ lên ai: Giao thức hay integrator?
Người ta có thể lập luận rằng sàn giao dịch đáng bị mất tiền vì không đọc tài liệu. Ở một mức độ nào đó, điều đó đúng. Bất kỳ ai tích hợp XRPL đều có trách nhiệm đọc tài liệu chính thức, và tài liệu đó hoàn toàn có đề cập delivered_amount là field bắt buộc phải sử dụng khi kiểm tra kết quả thanh toán.
Nhưng với tư cách là một người từng làm audit bảo mật nhiều năm, tôi nghĩ cách đặt vấn đề này đang lảng tránh một câu hỏi lớn hơn. Nếu một tính năng có thể dễ dàng bị biến thành phương tiện trộm cắp chỉ vì một integrator đọc nhầm field, thì thiết kế của nó đã đủ tốt chưa?
Chúng ta từng thấy những vụ tấn công tương tự trên Ethereum: token không chuẩn ERC20 trả về false khi chuyển khoản, và các sàn tích hợp không kiểm tra giá trị trả về. Kẻ tấn công gửi token "rác", cầu nối ghi có token thật. Cộng đồng lúc đó đã không nói "đó là lỗi của integrator". Họ đã xây dựng các thư viện kiểm tra tiêu chuẩn như SafeERC20, và các cầu nối phải nâng cấp.
Trong trường hợp này, một integrator trung bình — không phải chuyên gia bảo mật — có thể vô tình để lộ hàng triệu đô la vì một field sai. Vậy câu hỏi đặt ra cho XRPL và hệ sinh thái là: tại sao đến nay vẫn chưa có một tiêu chuẩn tích hợp an toàn rõ ràng, và tại sao các đơn vị vận hành vẫn chưa bị buộc phải tuân thủ?
Tôi không nói rằng giao thức nên thay đổi. Tôi đang nói rằng cộng đồng cần làm nhiều hơn việc phát hành một bài viết khẳng định "đây không phải bug". Cần có các công cụ kiểm tra tự động, các checklist tích hợp, và có thể là các smart detector trên ledger để cảnh báo khi giao dịch có flag Partial Payment bật.
Góc nhìn từ kinh nghiệm cá nhân
Tôi bắt đầu sự nghiệp bảo mật bằng việc đọc từng dòng mã Solidity từ các ICO năm 2017. Những bài học tôi học được từ EtherLend, từ YieldFarm, từ hàng chục contract khác đều dẫn về cùng một chân lý:
Khi bạn thiết kế một hệ thống xử lý tiền, câu hỏi đầu tiên không phải là "nó có hoạt động không" mà là "nó có thể bị lạm dụng ở đâu".
Các hệ thống tài chính không được xây dựng cho người tốt. Chúng được xây dựng cho người xấu nhất có thể tưởng tượng. Partial Payments là một ví dụ hoàn hảo về một design decision không sai, nhưng không lường trước được cách nó bị vũ khí hóa.
Vào năm 2022, khi tôi nghiên cứu zk-rollup và bảo mật các hệ thống thanh toán lớp 2, tôi từng mô phỏng một vụ tấn công tương tự trên testnet của một cầu nối: gửi giao dịch với amount đầy đủ, nhưng dùng điều kiện khiến số thực nhận chỉ còn 30%. Hệ thống ghi có dựa trên amount khai báo. Phát hiện này giúp nhóm phát triển vá lỗi trước khi lên mainnet.
Nhưng không có gì đảm bảo rằng mọi nhóm phát triển đều có một kỹ sư bảo mật chăm chăm tìm cách phá hệ thống của họ.
Điều gì sẽ xảy ra tiếp theo?
Partial Payments sẽ không biến mất. Đó là một tính năng cốt lõi của XRPL. Nhưng tôi cho rằng, trong vòng 6–12 tháng tới, chúng ta sẽ bắt đầu thấy ba thay đổi:
Thứ nhất, các sàn giao dịch lớn sẽ siết chặt quy trình kiểm tra giao dịch XRPL đến bằng cách yêu cầu delivered_amount trong callback và tự động gắn cờ các giao dịch bật Partial Payment.
Thứ hai, sẽ xuất hiện các công cụ phân tích on-chain chuyên phát hiện các giao dịch Partial Payment liên quan đến nền tảng thanh toán — tương tự như những gì đã xảy ra với các vụ tấn công reentrancy trên Ethereum, nơi các công ty bảo mật bắt đầu phát triển bot giám sát thời gian thực.
Thứ ba, và đáng chú ý nhất, sẽ có một cuộc tranh luận về việc liệu XRPL có nên thêm một flag an toàn mặc định — ví dụ như yêu cầu delivered_amount phải được xác nhận trong receipt trước khi giao dịch được coi là "hoàn tất" cho mục đích kế toán.
Có hai loại người trong crypto: người đọc `delivered_amount` và người mất tiền.
Bài viết "Partial Payments not a bug" đúng về mặt kỹ thuật, nhưng nó chỉ mới nói được một nửa câu chuyện. Nửa còn lại là trách nhiệm của integrator — và là cơ hội cho kẻ tấn công.
Trong bảo mật, "không phải bug" chỉ là khởi đầu của cuộc đối thoại, không phải kết luận. Và kết luận thực sự sẽ đến khi một vụ trộm lớn xảy ra. Vào lúc đó, chúng ta sẽ không còn bận tâm đến việc gán nhãn tính năng hay lỗi. Chúng ta chỉ cần hỏi: ai là người đã xây hệ thống mà không đọc delivered_amount?
Câu trả lời là: những người đã mất tiền.