XRP Ledger (XRPL) đưa bản nâng cấp phân quyền vào vòng bỏ phiếu validator

Bản sửa đổi “PermissionDelegationV1_1” trên XRP Ledger (XRPL) đã chính thức bước vào quy trình bỏ phiếu của các validator. Bản cập nhật này đã được đưa vào phiên bản xrpld 3.3.0, tuy nhiên việc kích hoạt trên mainnet vẫn chưa được xác nhận.

Quỹ XRPL (XRPL Foundation) cho biết đã tích hợp “PermissionDelegationV1_1” vào xrpld 3.3.0, công bố ngày 6 tháng 8. Bản sửa đổi mới thay thế cho “PermissionDelegation” trước đó, được thiết kế để chủ tài khoản có thể ủy quyền một phần quyền giao dịch cho tài khoản khác.

Về bản chất, cơ chế ủy quyền này gần giống mô hình kiểm soát truy cập theo vai trò, cho phép phân chia quyền hạn theo từng tài khoản. Chủ tài khoản có thể cấp cho một tài khoản vận hành quyền xử lý một số loại giao dịch nhất định, trong khi khóa chủ (master key) nắm toàn quyền vẫn có thể được cất giữ ngoại tuyến.

Cách làm này giúp giới hạn phạm vi quyền hạn của những khóa phải tiếp xúc với môi trường trực tuyến. Bên ủy quyền có thể cấp các mức quyền khác nhau cho nhiều tài khoản đại diện, hoặc thu hồi quyền bất cứ khi nào cần.

Các đơn vị phát hành stablecoin cũng được nhắc đến như một ví dụ ứng dụng. Những tác vụ lặp lại như phê duyệt trust line cho từng người dùng có thể giao cho tài khoản vận hành với quyền hạn giới hạn, trong khi các thao tác nhạy cảm như phát hành token vẫn tách riêng và do khóa chủ đảm nhiệm.

Bản sửa đổi mới được xem xét kỹ về bảo mật do tính năng cũ từng bộc lộ lỗ hổng. XRPL Foundation cho biết trong báo cáo lỗ hổng công bố tháng 9 năm 2025 rằng do lỗi quyền hạn được xử lý trước bước xác minh chữ ký, một giao dịch ủy quyền dù không được cấp phép vẫn có thể khiến tài khoản bị ảnh hưởng phải chịu phí giao dịch.

Tính năng cũ chưa từng được kích hoạt trên mainnet, và quỹ đã đề nghị các validator bỏ phiếu phản đối bản sửa đổi ban đầu. Sự cố này được phát hiện trong môi trường phát triển vào ngày 15 tháng 9 năm 2025.

Cốt lõi của lỗi nằm ở thứ tự xử lý giữa bước kiểm tra quyền hạn và bước xác minh chữ ký. Khi kiểm tra quyền hạn diễn ra trước xác minh chữ ký, một giao dịch chưa được cấp phép dù thất bại vẫn có thể bị trừ phí. “PermissionDelegationV1_1” được phát triển nhằm khắc phục đúng cấu trúc này.

Trong mã nguồn hiện tại, “PermissionDelegationV1_1” đã được đánh dấu là tính năng được hỗ trợ, nhưng giá trị bỏ phiếu mặc định vẫn là “DefaultNo”. Việc một tính năng đã có trong mã nguồn và việc tính năng đó được kích hoạt trên mạng lưới là hai bước hoàn toàn khác nhau.

Theo quy định của XRPL, mọi bản sửa đổi đều phải trải qua vòng bỏ phiếu của validator. Trong một bài viết trước đó, TokenPost cũng đã đưa tin về việc bản sửa đổi ủy quyền quyền hạn này vẫn còn đang chờ hoàn tất thủ tục bỏ phiếu validator.

Validator có tên “Vet” cho biết trên X ngày 8 rằng “tôi đã bỏ phiếu ủng hộ Permission Delegation”. Đây chỉ là phát biểu thể hiện quan điểm ủng hộ của một validator đơn lẻ, không đồng nghĩa với kết quả bỏ phiếu chung của toàn bộ validator hay việc bản sửa đổi đã đủ điều kiện kích hoạt.

Về mặt kiểm định chất lượng, đội ngũ phát triển RippleX cho biết đã thực hiện 179 bài test chuyên biệt liên quan đến tính năng ủy quyền cùng 5.088 bài test hồi quy cho toàn bộ xrpld. Báo cáo ghi nhận tại thời điểm đó không phát hiện lỗi nghiêm trọng nào chưa được xử lý, song đây chỉ là kết quả trên phạm vi mã nguồn đã được kiểm thử, không phải sự bảo đảm về độ ổn định vận hành lâu dài trên mainnet hay việc bản sửa đổi sẽ được kích hoạt.

Điểm đáng chú ý của lần này không nằm ở việc bổ sung tính năng mới, mà ở việc mô hình ủy quyền từng bị tạm dừng vì lỗ hổng bảo mật nay được thiết kế lại. Việc phân tách quyền hạn theo tài khoản giúp tách bạch giữa tác vụ vận hành thường ngày và thao tác có quyền hạn cao, nhưng việc có được áp dụng trên thực tế hay không vẫn phụ thuộc vào kết quả bỏ phiếu của mạng lưới.

Cũng như các bản sửa đổi khác trong xrpld 3.3.0, việc một tính năng được đăng ký trong mã nguồn không nên bị hiểu đồng nhất với việc nó đã được phản ánh trên mainnet. TokenPost trước đó cũng đã đưa tin về quy trình xác thực cũng như giai đoạn trước khi kích hoạt mainnet của các bản sửa đổi trong 3.3.0.

Tính đến thời điểm hiện tại, những gì được xác nhận là “PermissionDelegationV1_1” đã được đưa vào xrpld 3.3.0 và một số validator đã bày tỏ sự ủng hộ. Kết quả bỏ phiếu toàn phần cũng như việc bản sửa đổi có được kích hoạt trên mainnet hay không sẽ được xác nhận sau khi quy trình bỏ phiếu validator hoàn tất.