Bảng so sánh nhà cung cấp trên trang web chính thức của Rayls có chín hàng, và tôi chọn hàng «Quyền riêng tư». Lý do rất đơn giản: quyền riêng tư rất quan trọng, còn Besu là mã nguồn mở nên tôi có thể kiểm tra cả tài liệu lẫn mã nguồn.
Trong bảng so sánh, Rayls được đánh dấu ở cả hai hàng «Quyền riêng tư biệt lập» và «Quyền riêng tư bằng mật mã», còn Besu chỉ được đánh dấu ở hàng đầu tiên. Tôi định kiểm chứng bằng tài liệu của chính họ, nên đã tìm đọc tài liệu Besu rồi tải mã nguồn về và đếm thử.
Kết luận không phải là «Besu không tốt». Khác biệt thực sự nằm ở chỗ hai bên đặt quyền riêng tư ở các lớp khác nhau, và Besu đã loại bỏ lớp đó sớm hơn nhiều người nghĩ.
Phía Besu: từ tài liệu đến mã nguồn
Trong tài liệu chính thức của Besu, trên cùng các trang liên quan đến quyền riêng tư hiện đều có một biểu ngữ: các tính năng bảo mật dựa trên Tessera đã bị ngừng hỗ trợ kể từ phiên bản 24.12.0.
Việc gỡ bỏ thực sự diễn ra ở phiên bản 25.6.0. Ghi chú phát hành của phiên bản này liệt kê đây là một thay đổi gây gián đoạn: loại bỏ tính năng bảo mật Tessera, mục số #8369. Cùng đợt đó, tính năng quản lý quyền trên chuỗi cũng bị loại bỏ.
Tôi đã tự xác minh bằng cách này. Trước tiên, dùng ba số phiên bản để truy cập cùng một tệp: trong 25.4.0, PrivateTransaction.java và Enclave.java đều trả về mã 200; trong 25.6.0 và 26.2.0, cả hai đều trả về mã 404. Tiếp theo là các API: trong enum RpcMethod của 25.4.0 có 23 phương thức bắt đầu bằng priv_, eea_ hoặc privx_; trong cùng tệp ở 26.2.0 thì không có phương thức nào. Dòng lệnh cũng tương tự: 25.4.0 có 12 tham số khởi chạy bắt đầu bằng --privacy, còn trong BesuCommand.java của 26.2.0 thậm chí không tìm thấy từ privacy. Về quy mô, 25.4.0 có 153 tệp Java không phải tệp kiểm thử liên quan đến quyền riêng tư và enclave, tổng cộng 17.875 dòng.
Vì sao Besu làm vậy
Đoạn này nhất định phải viết, nếu không bài sẽ chỉ toàn bắt bẻ.
Trong thông báo ngày 24 tháng 9 năm 2024, những người bảo trì Besu đã nêu lý do: kho mã nguồn đã biến thành một con dao đa năng Thụy Sĩ cồng kềnh; các tính năng như Tessera không đủ hiệu năng trong những tình huống mà chúng vốn được tạo ra để giải quyết, trong khi tầng ứng dụng đã có các giải pháp trưởng thành và mới nổi. Thông báo cũng đề cập một dự án bảo mật có thể lập trình hướng EVM, mã nguồn mở, sắp được gửi tới phòng thí nghiệm LF Decentralized Trust.
Dự án đó chính là Paladin; hiện dự án đã được nâng từ phòng thí nghiệm thành dự án chính thức của LF Decentralized Trust. Dự án dùng giấy phép Apache 2.0, triển khai token bảo mật bằng chứng minh không tiết lộ thông tin hoặc xác minh trước từ bên phát hành, và chạy trên bất kỳ chuỗi EVM nào.
Vì vậy, cách diễn đạt chính xác hơn là: Besu không từ bỏ quyền riêng tư; họ chuyển quyền riêng tư từ máy khách lên tầng ứng dụng.
Hai cách triển khai, mỗi cách có cái giá riêng
Rayls đưa quyền riêng tư vào giao thức: Enygma dùng AES-256 để mã hóa nội dung giao dịch, dùng cam kết Pedersen để ghi nhận số dư, dùng bằng chứng Groth16 để chứng minh sổ sách là chính xác, và hoạt động theo luồng giao dịch thông thường.
Có thể đo lường cái giá của phương thức này. Trong bài trước, tôi đã thử nghiệm thời gian tạo bằng chứng: với tập ẩn danh 6 người, mỗi giao dịch mất 1,96 giây trên môi trường một lõi. Hôm nay tôi đo thêm một khía cạnh khác: bản thân bằng chứng chỉ có 164 byte, và kích thước ở cấp độ 2 người cũng bằng cấp độ 6 người, vì bằng chứng Groth16 có độ dài cố định. Nhưng dữ liệu công khai đi kèm bằng chứng thì không cố định: cấp độ 2 người là 588 byte, cấp độ 6 người là 1.612 byte.
Con số này cũng tiện thể đính chính một nhận định phổ biến. Thứ rời khỏi môi trường riêng tư không chỉ là «một bằng chứng», mà còn gồm tải dữ liệu mã hóa, bằng chứng và dữ liệu công khai cần thiết; nội dung vẫn được giữ kín, trong khi hệ thống vẫn có thể xác minh và quyết toán.
Nhân tiện, nói thêm về một dòng khác trong bảng so sánh. Rayls được đánh dấu ở mục «bảo mật cô lập» nhờ cấu trúc triển khai: sổ cái Sovereign của mỗi tổ chức được cài đặt trong phạm vi riêng của họ. Theo thông tin trên trang web chính thức, dữ liệu riêng tư không rời khỏi phiên bản đó; chỉ tải dữ liệu tối thiểu cần thiết để hoàn tất giao dịch mới được gửi ra mạng bên ngoài. Vì vậy, với Rayls, hai dòng này tương ứng với hai tầng: các tổ chức được cô lập nhờ triển khai riêng, còn quyết toán liên tổ chức dựa vào mật mã học. Tôi chỉ xem trang web chính thức và tài liệu, chưa triển khai thực tế.
Cũng cần nêu rõ vấn đề giấy phép. Ngăn xếp mở của Rayls sử dụng Apache 2.0, nhưng hai mô-đun Enygma và Axyl dùng BUSL 1.1: miễn phí cho thử nghiệm, cần giấy phép cho môi trường sản xuất; mỗi phiên bản sẽ tự động chuyển sang Apache 2.0 sau bốn năm kể từ ngày phát hành. Paladin thì dùng Apache 2.0.
Điều này có ý nghĩa gì với một tổ chức
Nếu mạng riêng tư của một tổ chức chạy trên Besu và sử dụng các API priv_ hoặc eea_, thì nâng cấp lên 25.6.0 không phải là nâng cấp, mà là di trú. 23 API và 12 tham số khởi chạy cùng lúc biến mất; logic bảo mật phải được chuyển lên tầng ứng dụng và viết lại. Nếu không, bạn chỉ có thể ở lại dòng 25.4; mọi cải tiến hiệu năng và bản sửa lỗi bảo mật về sau sẽ không còn dành cho bạn.
Nếu chọn Rayls, quyền riêng tư và sổ cái thuộc cùng một hệ thống; phiên bản, kiểm toán và hỗ trợ đi cùng một hướng, không cần tự ghép nối. Đổi lại, mỗi giao dịch bảo mật phải tính bằng chứng trước; tập ẩn danh càng lớn thì dữ liệu công khai càng nhiều; và phần Enygma cần được cấp phép theo BUSL.
Cái «nhiều hơn» ấy nhiều đến mức nào? Có thể ước tính được; dưới đây là phép tính của tôi. Một giao dịch chuyển tiền bảo mật ở cấp độ 6 người có tổng dung lượng bằng chứng và dữ liệu công khai khoảng 1.776 byte. Nếu lấy quy mô trung bình 210.483 giao dịch mỗi ngày của CHAPS tại Anh năm 2025, thì tương đương khoảng 374 MB mỗi ngày, khoảng 136 GB mỗi năm. Với dung lượng lưu trữ của một tổ chức, con số này không đáng kể, nhưng đó là chi phí cố định tăng tuyến tính theo số giao dịch, và tập ẩn danh có thể điều chỉnh: giảm xuống cấp độ 2 người thì mỗi giao dịch chỉ còn 752 byte. Ở đây giả định mỗi giao dịch chỉ tạo ra một bằng chứng; chưa tính các mạch dùng cho nạp tiền, rút tiền và DvP.
Câu hỏi chung có thể rút ra từ dòng này chỉ gói gọn trong ba từ: ở tầng nào. Hãy hỏi nhà cung cấp tính năng bảo mật nằm ở tầng nào, ai bảo trì, vòng đời của nó và sổ cái có bị ràng buộc với nhau hay không. Những thay đổi của Besu trong hai năm qua cho thấy câu trả lời có thể thay đổi, và sự thay đổi ấy có thể gây gián đoạn.
Những gì tôi xác nhận và những gì tôi suy luận
Phần đã xác nhận: sự tồn tại hay vắng mặt của tệp giữa các phiên bản, số lượng API và tham số khởi chạy, nội dung thông báo chính thức và ghi chú phát hành, số byte của bằng chứng và dữ liệu công khai, cùng thời gian tạo bằng chứng trong bài trước. Bạn có thể chạy lại tất cả bằng các lệnh trong ảnh chụp màn hình.
Phần suy luận: việc nâng cấp sẽ làm gián đoạn hoạt động bảo mật hiện có; tôi suy ra điều này từ việc các API biến mất, chứ chưa thực sự nâng một mạng riêng tư phiên bản 25.4 lên 25.6 để thử. Tôi cũng chưa đánh giá được Paladin có đáp ứng được tình huống cụ thể của một tổ chức nào hay không.
Về phạm vi, tôi chỉ xem xét mạch chuyển tiền và dòng bảo mật này. Người dùng Besu hoàn toàn có thể tự duy trì nhánh riêng hoặc viết plugin; giấy phép của Besu cho phép điều đó. Tôi không đụng đến tám dòng còn lại trong bảng so sánh.
Quan điểm của tôi
Bảng so sánh là một bức ảnh tĩnh, còn năng lực của dự án mã nguồn mở thì luôn thay đổi. Trong hai năm, dòng này đã chuyển từ «tích hợp sẵn trong máy khách» thành «tự xử lý ở tầng ứng dụng», nhưng bảng chỉ có thể hiển thị một dấu kiểm.
Vì vậy, tôi muốn xem những bảng kiểu này là điểm khởi đầu cho một danh sách kiểm tra: hãy vào kho mã nguồn của bên kia và kiểm tra phiên bản hiện tại ở từng dòng. Lần này tôi mất chưa đến một giờ; các lệnh đều có trong ảnh chụp màn hình. Lần tới khi Rayls cập nhật bảng này, điều đáng xem là họ có bổ sung thông tin phiên bản vào cột Besu hay không.
Nguồn tham khảo: trang sản phẩm Sovereign trên trang web Rayls và bảng so sánh nhà cung cấp; biểu ngữ thông báo ngừng hỗ trợ trong phần bảo mật của tài liệu chính thức Besu; ghi chú phát hành Besu 25.6.0, mục #8369; thông báo ngày 24 tháng 9 năm 2024 của LF Decentralized Trust (Sunsetting Tessera and Simplifying Besu) và thông báo về dự án Paladin; ba thẻ phiên bản 25.4.0, 25.6.0 và 26.2.0 trong kho hyperledger/besu (truy cập ngày 24 tháng 9 năm 2026); commit 67c4c26 của raylsnetwork/rayls-sovereign-gnark-api (đã thử nghiệm thực tế trên máy của tôi).