Tôi bắt đầu stake RLS từ giai đoạn cam kết trước. Việc đọc tài liệu chính thức chỉ là thói quen. Sau khi cái tên Sovereign xuất hiện, phần lớn cuộc thảo luận dừng lại ở câu: “chỉ là đổi tên thôi sao”. Tôi nghĩ câu hỏi này đang hỏi ngược. Tên không quan trọng; quan trọng là phía dưới đã được thay đổi gì và một tổ chức khi làm due diligence có thể lấy được bao nhiêu thứ có thể tự kiểm chứng. Mỗi con số trong bài này, tôi đều đưa ra nguồn xuất xứ chính xác; bạn có thể tái hiện lại y như vậy.
Trước hết, tôi muốn nói một điều: vì tuần trước tôi đã viết một bài về tính kiểm toán được (auditability), nên một số độc giả có thể đã đọc.
Hầu hết nội dung trong bài này là mới, đến từ kho mã code của Axyl, thư mục audits trong kho và trang tài liệu về benchmark hiệu năng của Axyl; ba chỗ này trước đây tôi chưa từng đụng. Chỉ có một tiểu mục nhỏ nói về việc lưu ký khóa là tiếp nối kết luận của bài trước—tôi sẽ đánh dấu ở đó. Tách “mới và cũ” là vì “tuần này tôi tra được gì” và “trước đây tôi đã tra được gì” nên để người đọc tự phân biệt.
Trước hết, hãy sắp xếp lại dòng thời gian cho đúng.
Không phải là đổi tên.
Axyl được lên mainnet chuỗi công khai Rayls vào cuối tháng 4/2026 trước; việc di chuyển Sovereign sang Axyl diễn ra vào tháng 7/2026, xảy ra sau khi đã có chain công khai. Tài liệu chính thức nêu rõ quá trình di chuyển được thực hiện theo từng giai đoạn; trong thời gian đó, tổ chức vẫn vận hành bình thường. Sau khi thay xong phần nền, mới có tên mới.
Mục What changed trong phần tài liệu liệt kê năm hạng mục; bên dưới tôi chọn nói về hai hạng mục, vì hai thay đổi này ảnh hưởng đến hoàn cảnh vận hành của tổ chức, chứ không chỉ là tham số của ngăn xếp kỹ thuật.
Thay đổi 1: từ một node thành một ủy ban
Nguyên văn trong tài liệu: sổ cái Rayls Sovereign phiên bản sớm hơn hoạt động dưới dạng một node Geth đơn lẻ và một validator đơn lẻ. Axyl chạy cơ chế đồng thuận chịu lỗi Byzantine xuyên ủy ban; rủi ro về tính khả dụng của một node đơn lẻ không còn áp dụng. Cùng một đoạn cũng viết rằng node EVM đã chuyển từ Geth sang Reth, Clique authority proof chuyển sang Axyl.
Tôi vào kho để kiểm tra xem Axyl là gì. Đó là một client giao thức viết bằng Rust; một binary duy nhất rayls-network chạy đồng thời hai phần: lớp đồng thuận là hiện thực của Narwhal và Bullshark, chạy theo QUIC của libp2p; lớp thực thi được xây trên reth và alloy, tạo ra các khối chuẩn cho Ethereum EVM. Node chia thành validator và observer; observer theo dõi chuỗi thông qua đồng bộ trạng thái nhưng không tham gia ủy ban. Toolchain khóa chặt Rust 1.91.
Đối với một ngân hàng, ý nghĩa của mục này không nằm ở throughput, mà nằm ở độ bền vững trong vận hành (operational resilience). Sổ cái của một node/validator đơn lẻ: chỉ cần một lần hỏng máy là sổ cái dừng hoạt động, không có dự phòng. Đây lại chính là loại thiết kế khó nhất để giải trình với cơ quan quản lý. Khi chuyển sang mô hình ủy ban, vấn đề này từ chỗ không có câu trả lời trở thành có câu trả lời theo chuẩn; dung sai lỗi Byzantine là ngôn ngữ mà cả quản trị rủi ro lẫn cơ quan giám sát đều đã quen.
Chi phí cũng rất cụ thể. README của kho đưa cấu hình tối thiểu khuyến nghị là 8 lõi vật lý, 16 GiB RAM, 500 GiB ổ SSD, băng thông từ 10 Gbps trở lên; và đây là yêu cầu cho mỗi thành viên ủy ban, không phải cho một máy. Tài liệu cũng đưa cấu hình triển khai hai cấp của sổ cái Sovereign: mức nhẹ là 2 vCPU, 4 GB, 100 GB; mức doanh nghiệp là từ 4 lõi trở lên, 16 GB, 500 GB.
Còn một chỗ dễ sót: trung tâm điều phối mạng riêng tư không được đổi theo; tài liệu giải thích riêng rằng nó tiếp tục chạy Besu và chứng minh thẩm quyền, không bị ảnh hưởng bởi quá trình di chuyển Axyl. Lớp do tổ chức vận hành hiện tại là dung sai lỗi Byzantine, còn lớp giữa các tổ chức vẫn là chứng minh thẩm quyền; mô hình tin cậy của hai lớp khác nhau, khi đánh giá phải nhìn tách biệt.
Thay đổi 2: khóa được chuyển khỏi thành phần truyền tải
Mục này là phần tiếp nối kết luận của bài trước, không phải phát hiện mới trong tuần. Đặt ở đây là vì yêu cầu brief cần nêu hai thay đổi, và mục này đúng là một trong năm hạng mục đó.
Mục trong tài liệu đó viết rằng module quản lý khóa đã trở thành Cryptographic Trust Suite, một thành phần lưu ký khóa tách rời (decoupled). Relayer không còn xử lý hoặc lưu trữ khóa trực tiếp nữa. Tôi đã đối chiếu dòng đó trong mã nguồn; thư mục cryptography của hai kho relayer và governance service có thể khớp.
Ý nghĩa đối với một tổ chức có hai điểm. Thứ nhất, Relayer là thành phần giao tiếp ra bên ngoài, phần “lộ diện” nhất; trong cấu trúc cũ nó đồng thời chạm vào khóa, còn trong cấu trúc mới nó không lấy được khóa nữa—việc tầng truyền bị tấn công không còn đồng nghĩa với việc khóa bị tấn công. Điểm thứ hai là việc lưu trữ khóa có thể cắm thêm (plug-in) vào KMS hoặc module bảo mật phần cứng mà chính tổ chức đó đã đang dùng; vì vậy dấu vết kiểm toán sẵn có của tổ chức bao phủ các thao tác khóa của Rayls, không cần phải tạo mới một “bề mặt kiểm toán” cho việc này.
Mẹo/tài liệu mới thực sự trong tuần này: thư mục audits.
Trong kho Axyl có một thư mục audits/; bên trong có một README và ba file PDF. Tôi đã đọc xong README đó; nội dung cụ thể hơn rất nhiều so với câu “đã làm kiểm toán bên thứ ba”.
Cả ba báo cáo đều do Halborn xuất bản; cửa sổ thực hiện nằm trong khoảng 2/2026 đến 3/2026; việc tái kiểm tra sau khắc phục hoàn tất vào 4/2026 đến 5/2026.
Tên tệp về giao thức đồng thuận là halborn-2026-03-consensus-protocol.pdf; phạm vi là các đường dẫn mã Rust liên quan đến đồng thuận, đồng bộ chứng chỉ, xử lý gossip và quản lý khóa của validator; thời gian thực hiện từ 2/3 đến 20/3; 5 phát hiện, trong đó 1 nghiêm trọng, 3 trung bình, 1 thấp; tất cả đều đã được khắc phục.
Bản dành cho node mạng: halborn-2026-03-network-node.pdf; phạm vi là các module mạng, worker, đồng bộ trạng thái, thực thi, điều phối và lưu trữ; thời gian thực hiện từ 18/2 đến 24/3; 22 phát hiện, trong đó 1 nghiêm trọng, 2 cao, 7 trung bình, 6 thấp, 6 mang tính gợi ý; 20 đã được khắc phục, chấp nhận 2 rủi ro mức thấp.
Hợp đồng thông minh: halborn-2026-03-smart-contracts.pdf; phạm vi là các hợp đồng trong rayls-contracts/src/ như ConsensusRegistry, StakeManager, DelegationPool và các hợp đồng phân bổ phí; thời gian thực hiện từ ngày 2/3 đến 13/3; 15 phát hiện, trong đó 1 nghiêm trọng, 2 cao, 7 trung bình, 2 thấp, 3 mang tính gợi ý; 14 đã được khắc phục, chấp nhận 1 rủi ro ở mức trung bình.
Tổng cộng là 42 phát hiện: 3 nghiêm trọng, 4 cao, 17 trung bình, 9 thấp, 9 mang tính gợi ý. 39 đã được khắc phục, 3 chấp nhận rủi ro. Ba mức nghiêm trọng đều đã được giải quyết.
Tôi liệt kê từng con số một là vì với việc mua sắm, “có từng làm kiểm toán hay không” và “đã kiểm toán cái gì, mất bao lâu, phát hiện bao nhiêu, có bao nhiêu cái chưa sửa” là hoàn toàn khác nhau. Câu hỏi thứ nhất hầu như dự án nào cũng trả lời là “có”. Câu hỏi thứ hai thì không có nhiều câu trả lời, nhưng ở đây từng mục đều có thể kiểm chứng công khai. Ba mức nghiêm trọng đều đã được sửa hết—đó là một sự thật tích cực có thể kiểm tra trực tiếp.
Trong cùng một README còn tiết lộ một việc nữa
Đoạn này tôi cho là hữu ích nhất cho due diligence trong toàn bài.
Phần README đó có một mục riêng nói về vấn đề “submission record” và tham chiếu pull request. Ý của bản gốc là: các cuộc kiểm toán này được thực hiện cho kho riêng tư chưa công khai; khi dự án mở nguồn, lịch sử kho được nén thành một lần “commit khởi tạo” duy nhất. Vì vậy, trong báo cáo, các mã băm commit và liên kết pull request được trích dẫn như bằng chứng cho việc khắc phục thì tại kho công khai này không thể giải mã/tra ra được.
Rayls đồng thời cũng nêu rằng: mọi việc khắc phục đã được Halborn kiểm chứng đều được bao gồm trong commit khởi tạo của kho công khai, và thời điểm của commit đó muộn hơn so với lần tái kiểm tra khắc phục. PDF được phát hành đúng nguyên văn theo Halborn, không chỉnh sửa.
Với một tổ chức đi due diligence, đây là một giới hạn rất cụ thể và rất thật: báo cáo có thể đọc được, không bị sửa đổi, nhưng chuỗi bằng chứng về việc khắc phục mà báo cáo dẫn tới lại không thể đi thông trong kho công khai. Bạn có thể thấy Halborn nói rằng một vấn đề đã được sửa, nhưng bạn lại không thể lần theo liên kết mà họ đưa để xem thay đổi mã nguồn thực tế của lần sửa đó.
Tôi muốn nhấn mạnh rằng đây không phải là hành động che giấu; ngược lại, chính Rayls đã chủ động viết rõ trong README của mình, đồng thời nêu lý do và phần bù/đền bù. Tôi đưa điều đó vào bài, chỉ vì đây chính là câu hỏi đầu tiên mà đội an toàn sẽ hỏi, và câu trả lời đã có sẵn ở đó—nhưng trong một tệp mà đa số người không mấy khi mở.
Con số throughput đó, và điều kiện cũng là công khai.
Mục này tôi nói riêng, vì trong tổng kết cộng đồng tháng 8 đã có người điểm danh: có hai con số TPS đang được lan truyền, và mọi người hay trích dẫn con số “lớn hơn”.
Tôi đã rà lại ba chỗ nguồn. Tài liệu chính thức khi nói về hiệu năng của Sovereign viết là Axyl đạt 15.000+ TPS dưới tính cuối cùng mức cận dưới một giây. README của kho Axyl viết mục tiêu giao thức là 10.000+ TPS; cách dùng từ là targets (mục tiêu), chứ không phải số đo thực tế (real measurement). Còn điều kiện nằm ở chỗ thứ ba: một trang tài liệu tên Axyl Performance Benchmarks. Trang đó ghi rõ đây là bộ benchmark thử nghiệm cho “nguyên mẫu lớp đồng thuận”; điều kiện ghi nhận là ủy ban bốn node, giao dịch 512 byte, kích thước batch 500 KB, độ trễ batch tối đa 50 mili giây. Ngoài ra, trang đó cũng đưa dữ liệu đồng thuận trên mạng thử nghiệm.
Vì vậy, biểu đạt đầy đủ nên là: benchmark nguyên mẫu của lớp đồng thuận trong bốn điều kiện này, chứ không phải đo đạc “sản xuất đầu cuối” (end-to-end) thực tế. Cần nói rõ rằng các giá trị cụ thể của trang đó được cho dưới dạng hình; tôi không đọc được các con số trong hình, nhưng tôi có thể xác nhận chính bản thân các điều kiện.
Thêm một dẫn chứng phụ mà tôi tự chạy ra. Ngày 12/9, tôi gọi interface stats của trình duyệt blockchain công khai; thời gian tạo khối trung bình trả về vào khoảng 500 mili giây. Điều này phù hợp với nhận định ở mức dưới một giây, và bất kỳ ai gọi cùng một interface cũng có thể tự xem. Thời gian tạo khối không đồng nghĩa với tính cuối cùng của giao dịch, nhưng ít nhất đó là một giá trị đo đạc thực tế lấy độc lập được, chứ không phải lời kể lại.
Một chi tiết mà bộ phận mua sắm sẽ hỏi nhưng rất hiếm khi được nhắc tới
Giấy phép của Axyl là BUSL-1.1, giấy phép mã nguồn thương mại, không phải mã nguồn mở theo nghĩa thông thường.
Phần giấy phép kho lưu trữ được viết rất cụ thể: mục đích sử dụng sản xuất được cho phép là chạy các node trên mainnet chuỗi công khai Rayls và các mạng thử nghiệm chính thức của nó, bao gồm bốn loại: validator, observer, relayer và RPC; các mục đích sử dụng sản xuất khác cần giấy phép thương mại. Sau bốn năm kể từ lần công bố công khai đầu tiên của mỗi phiên bản sẽ là ngày thay đổi; đến lúc đó sẽ chuyển sang Apache 2.0.
Đọc tiếp theo, một ngân hàng chạy Axyl trong phần triển khai Sovereign của chính họ—đây là một mục đích sử dụng sản xuất khác.
Không phải là lời phê bình. Rayls trước nay đã nói rõ: nền tảng lõi là mã nguồn mở, còn Axyl và Enygma là các thành phần thương mại; việc dùng BUSL và sau 4 năm chuyển sang Apache cũng là cách làm đã trưởng thành trong ngành. Viết ra chỉ vì trong quá trình lan truyền, từ “open source” (mã nguồn mở) thường bị hiểu là “muốn dùng sao thì dùng”, trong khi ranh giới về quyền đã được ghi rất rõ trong tài liệu giấy phép.
Code đến từ đâu—kho tự nói rồi
Phần lời cảm ơn trong kho Axyl thì thẳng thắn đến mức hiếm thấy. Phần đồng thuận trong workspace Rust là dẫn xuất từ Telcoin Network; mà Telcoin Network lại được xây trên Narwhal và Bullshark của Sui. Rayls dựa trên nền đó thực hiện tái cấu trúc và sửa đổi lớn; phần hiện thực Bullshark cũng dẫn xuất rất nhiều từ bộ mã Sui của Mysten Labs, theo giấy phép Apache 2.0. Lớp thực thi dùng reth và alloy; interface OFT của LayerZero giữ nguyên giấy phép MIT gốc.
Ghi rõ “dòng dõi” (lineage) sẽ dễ được đội kỹ thuật tin hơn là khẳng định “tự nghiên cứu tất cả”, vì bên kiểm toán có thể lần theo đường đó để xem mức độ trưởng thành của phần upstream.
Cái nào là mới, cái nào là tiếp nối, và cái nào tôi không thể đối chiếu được
Thông tin mới tôi tự kiểm tra trong tuần này: toàn bộ nội dung README của kho Axyl, bao gồm kiến trúc, vai trò, cấu hình, giấy phép và lời cảm ơn; bảng ba báo cáo trong audits/README.md và phần mô tả lịch sử commit bị nén; doc/index.md phần tổng quan hệ thống; điều kiện benchmark trên trang Axyl Performance Benchmarks; trang Rayls Sovereign của tài liệu chính thức, mục What changed (5 hạng mục) và cấu hình triển khai hai cấp.
Tiếp nối bài trước: ranh giới khóa của Cryptographic Trust Suite, và việc Relayer không nắm giữ khóa—đó là điều tôi đã đối chiếu trong mã nguồn hai kho relayer và governance service tuần trước. Mục này không có bằng chứng mới.
Giả định của tôi: giá trị chính của việc chuyển từ một node sang một ủy ban nằm ở độ bền vững vận hành chứ không phải throughput; việc chuỗi bằng chứng khắc phục không đi thông được trong kho công khai là một giới hạn thực tế ở cấp due diligence; việc ghi rõ “dòng dõi” của mã nguồn là điều tích cực.
Tín hiệu. Trong ba tài liệu này không hề viết như vậy.
Không thể xác minh được: tôi không có bất kỳ bằng chứng nào cho thấy một tổ chức cụ thể đã vận hành thật cấu hình đó. Toàn bộ những gì bài này nói là năng lực được ghi trong tài liệu và mã nguồn.
Đường dẫn để tái hiện: GitHub tìm raylsnetwork/axyl; hai tệp ở thư mục gốc là README và audits/README.md bao phủ phần lớn các con số trong bài này; tài liệu chính thức tìm Rayls Sovereign và Axyl Performance Benchmarks (hai trang); chỉ cần xem /api/v2/stats của trình duyệt blockchain công khai về thời gian tạo khối.
