Tôi bắt đầu đặt cọc RLS từ giai đoạn cam kết trước, và việc đọc blog chính thức chỉ là thói quen. Bài viết ngày 12 tháng 9 về khả năng kiểm toán: nửa sau liệt kê sáu tiêu chuẩn, nói rằng toán học bắt buộc phải thỏa mãn tất cả bằng cách dựng theo cấu trúc. Câu này thì tôi đồng ý, nhưng “thỏa mãn bằng cách dựng theo cấu trúc” là một cách nói có thể tra được, không phải là thứ chỉ có thể tin. Vì vậy tôi tốn một tuần để lấy các tiêu chuẩn đó và lần lượt tìm trong mã nguồn công khai, tài liệu kỹ thuật và các giao diện trên chuỗi để tìm đúng bằng chứng—sau đó mới chia sẻ với mọi người.
Trước hết nói về việc phân loại. Tôi nghĩ nó hữu ích hơn phần lớn các thảo luận kiểu “riêng tư hay minh bạch”. Có ba con đường để làm khả năng kiểm toán: ép buộc bằng toán học—biên giới nằm trong các cấu trúc mật mã; tin cậy phần cứng—dựa vào tính toàn vẹn của môi trường thực thi tin cậy; và kiểm soát truy cập theo chính sách—ai thấy gì do bên vận hành mạng cấu hình quyết định.
Từ đó, nó đưa ra sáu tiêu chuẩn khả kiểm toán ở cấp tổ chức, rồi nói rằng toán học bắt buộc phải thỏa mãn cả sáu tiêu chuẩn bằng cách dựng lại theo cấu trúc.
Để không nói càng lúc càng “trừu tượng”, tôi cố định một bối cảnh: một ngân hàng tham gia thử nghiệm CBDC của ngân hàng trung ương, kiểm toán viên của ngân hàng trung ương muốn xem các giao dịch của ngân hàng đó trên mạng. Drex của Brazil chính là bối cảnh này, và Rayls đang làm thử nghiệm trong đó. Chỉ có một câu hỏi cần trả lời: kiểm toán viên thấy được những gì thì dựa vào cái gì để tin là đáng tin cậy.
Điều thứ nhất và thứ hai: tiết lộ có chọn lọc và giới hạn theo phạm vi.
Hai điều này rơi vào cùng một thứ: khóa quan sát.
GitHub của Rayls là công khai. Trong thư mục cryptography của kho relayer có file mlkem.go. Trong đó, GenerateSalt dùng phần “đóng gói khóa quan sát công khai ML-KEM-768 của bên nhận” để chia sẻ khóa; RecoverSalt dùng khóa quan sát riêng ML-KEM-768 cục bộ để giải đóng gói; và nó gọi các hàm NewEncapsulationKey768 và NewDecapsulationKey768 của thư viện chuẩn Go. Tên biến viết đúng là view public key và view secret key.
Vì vậy, nền tảng mật mã của “khóa quan sát” là ML-KEM-768—và mục này có thể kiểm chứng được từ tài liệu.
Nói thêm một câu về ý nghĩa của nó. Trong bài viết ngày 30 tháng 8 của Rayls về “chuẩn bị cho lượng tử”, họ nhấn mạnh rằng: nếu một tuyên bố về “an toàn lượng tử” không viết ở mức tham số thì đó không phải là một khẳng định—chỉ là nhãn. Và ví dụ được đưa ra đúng là việc ML-KEM-512 và ML-KEM-1024 không phải là như nhau. Trong phần nói về nâng cấp của chính họ, bài đó chỉ viết “đã được thay bằng ML-KEM”. Còn trong code ghi “768”. Đây không phải là một khiếm khuyết: 768 là “mức tham số chính thức” của NIST, và cũng là giá trị mặc định khuyến nghị của ngành cho triển khai doanh nghiệp. Nó chỉ là một sự thật mà trước đây phải đọc code mới biết, còn bây giờ thì có thể trích dẫn trực tiếp.
Vì các mức đã được xác định, nên có thể tính được chi phí khi đổi mức. FIPS 203 “đóng khung” kích thước: khóa công đóng gói 768 là 1184 byte, bản mã 1088 byte; còn 1024 cho cả hai đều là 1568 byte.
Mấu chốt là tần suất. Và tài liệu về quản lý khóa cũng viết điều này: việc đóng gói được thực hiện một lần cho mỗi cặp bên tham gia khi xây mạng; bản mã được lưu trên trung tâm mạng riêng. Sau đó, mỗi thông điệp chỉ mang theo một thẻ nhỏ. Vì vậy nó không tăng theo lượng giao dịch. Một mạng gồm 30 tổ chức có 435 cặp; chênh lệch giữa hai mức xấp xỉ 215 KB. Ngay cả khi có 60 tổ chức và 1770 cặp, thì phần chênh lệch cũng không tới 1 MB, và đó là chi phí “một lần”.
Lượng này nhỏ đến mức không còn ý nghĩa, và đây chính là nơi kết luận nằm: nếu một bản triển khai cần mức cao hơn, thì trở ngại sẽ không đến từ băng thông hay lưu trữ—đó đơn giản là một lần đổi mã. Trong các thảo luận chuyển đổi hậu lượng tử phổ dụng, việc chọn tham số thường là sự đánh đổi hiệu năng; ở lớp này thì không như vậy.
Giới hạn trong phạm vi điều này: tài liệu kỹ thuật bổ sung nửa còn lại. Năng lực quan sát có thể được giới hạn theo cửa sổ thời gian hoặc theo từng tài khoản.
Điều thứ ba, tách biệt giữa khả năng nhìn thấy và quyền truy cập.
Cách nói của tài liệu kỹ thuật “cứng” hơn blog: khóa chi tiêu và khóa quan sát độc lập với nhau về mặt toán học, không thể suy ra một từ cái kia. Trong phần tóm tắt thẩm định an toàn, câu đó còn trực tiếp hơn: quyền quan sát và quyền chi tiêu được tách bằng mật mã chứ không phải do cấu hình, nên một lỗi cấu hình không thể biến quyền đọc thành quyền ghi.
Tài liệu về quản lý khóa còn sửa lại một giả định mà tôi đã tự hiểu. Tất cả vật liệu khóa phía tổ chức được xử lý thống nhất bởi một thành phần tên là Cryptographic Trust Suite, chạy trong ranh giới do chính tổ chức quản lý; Relayer không bao giờ giữ bất kỳ khóa nào, chỉ được “nhờ” thực hiện mã hóa/giải mã thay. Quyền đọc của kiểm toán viên đến từ: mỗi tổ chức mã hóa khóa quan sát của mình bằng khóa công của bên vận hành, cùng với một mã xác thực được lưu vào trung tâm mạng riêng, như một phần của bản ghi bên tham gia; dịch vụ kiểm toán sẽ lấy lại khi khởi động.
Có một tài liệu phụ mà chính nó tự chỉ ra: tổ chức có thể nhìn thấy trên trung tâm những hồ sơ của các bên tham gia nào tồn tại, tức là biết được những thứ nào của mình bị đặt thành “có thể đọc”. Bản thân việc cấp khả năng hiển thị cũng là thứ có thể nhìn thấy.
Nhân tiện, trang này về bảng ba loại khóa cũng xác nhận điều tôi thấy trong code: khóa ký dùng ECDSA trên secp256k1; khóa quan sát dùng ML-KEM; khóa chi trả dùng Baby JubJub trên BN254. Tài liệu và mã nguồn khớp hoàn toàn.
Điều thứ tư, tính bền vững có thể kiểm chứng.
Blog này dựa vào bằng chứng không kiến thức; Rayls có dịch vụ gnark-api chuyên để tạo và xác thực chứng minh Groth16.
Tài liệu về giao dịch Enygma đưa ra một số tham số cụ thể mà bình thường ít ai trích dẫn. Quy mô tập ẩn danh là 2 hoặc 6: tức là mỗi lần chuyển sẽ được đóng gói cùng với một giao dịch khác hoặc năm giao dịch khác, nên người quan sát không phân biệt được ai là người khởi tạo. Một crossTransfer tối đa hướng tới 5 chuỗi đích và mang theo 5 hành động có thể gọi. Tính nguyên tử của lô batch được bảo đảm bởi hợp đồng Enygma nằm trên trung tâm mạng riêng: nó trước hết xác thực chứng minh của cả lô; chỉ khi đó mới đúc (mint) cho bất kỳ nơi đích nào.
Còn có một chi phí vận hành nữa. Tài liệu viết rất thẳng: gộp lô (batch), tạo chứng minh và xác thực ở trung tâm cộng lại là cỡ vài chục giây, nên phải lập kế hoạch theo đó, chứ không theo độ cuối kiểu dưới mili-giây như giao dịch nội bộ của một tổ chức. Kiểm chứng được tính đúng đắn không phải là miễn phí—“giá” của nó chính là vài chục giây đó.
Nhưng có một chỗ trong cách diễn đạt đáng được nói riêng, vì nó liên quan đến bốn tài liệu.
Tài liệu kỹ thuật nói rằng cam kết Pedersen “ẩn đi một giá trị, đồng thời gắn bên cam kết với giá trị đó, khiến về sau không thể thay đổi”, và coi tính “ràng buộc” như một thuộc tính được thừa nhận trong phần phát biểu. Bài lượng tử của tháng 8 đánh dấu mục này là “không cần xử lý”, tức là vốn đã chống lại lượng tử. Trong code enygma_math.go cho thấy nó dùng hai sinh nguyên độc lập trên đường cong BabyJubJub, tính v nhân G cộng r nhân H—đúng là cấu trúc Pedersen tiêu chuẩn và chính xác. Còn hai bài báo học thuật của Rayls, IACR số 2025/1639 và 2025/1638, mô tả thuật ngữ dùng cho cả thiết kế là “quantum-private”, tức là “riêng tư lượng tử”; giải thích là đối thủ lượng tử không thể suy ra bên thanh toán, bên nhận và số tiền của giao dịch. Đây là một tuyên bố thuần túy về tính bảo mật (confidentiality).
Cách đọc của tôi là: trong bốn tài liệu, chỉ có phần dùng từ trong bài báo là chính xác. BabyJubJub được xây trên miền vô hướng của BN254, nên tính ẩn (hiding) đúng là thuộc phần mà đối thủ lượng tử không thể phá, chính là phần mà bài báo nêu. Tính ràng buộc (binding) phụ thuộc vào bài toán log rời rạc—đó là phần mà bài báo không chủ trương.
Với một tổ chức cần chứng minh được “tình hình tuân thủ” của mình có thể chịu được sự kiểm tra đối đầu, thì “đối thủ lượng tử không thể thấy số dư của tôi” và “đối thủ lượng tử không thể giả mạo một số dư giả” là hai chuyện khác nhau, và trong tài liệu lẫn blog, chúng bị viết như thể là một. Bài báo không gộp hai việc đó làm một.
Điều thứ năm, có thể thu hồi.
Mục này tôi tra rất lâu. Trong tài liệu của Rayls có một trang tên là “Tùy chọn thiết kế mạng riêng”, ở đó tôi tìm được câu trả lời. Nhưng nó không phải là cùng một chuyện với điều blog nói, và tôi cũng thấy cái này thú vị hơn.
Kiểm toán viên là vai trò do bên vận hành chỉ định; song song còn có bên tham gia và bên phát hành. Điểm mấu chốt là khả năng hiển thị của kiểm toán viên không phải công tắc bật/tắt mà là “mức”; tài liệu này dùng ba ví dụ để vẽ ra các mức đó.
Ở lớp mạng tiền tệ kỹ thuật số của ngân hàng trung ương, kiểm toán viên có thể giải mã các giao dịch giữa các nút. Ở lớp nền tảng giao dịch tài sản token hóa, kiểm toán viên giám sát bằng cách xác minh các cam kết Pedersen được các nút công bố lên trung tâm (hub); tài liệu cũng ghi rõ kiểm toán viên không có quyền truy cập trực tiếp vào dữ liệu tải trọng giao dịch mã hóa, chỉ xem các chứng minh chứ không xem nội dung. Ở lớp thị trường NFT do DAO vận hành là trường hợp cực đoan nhất: vai trò kiểm toán do trình xác minh của mạng công đảm nhiệm, mặc định là không có quyền truy cập; chỉ khi việc kiểm chứng chứng minh cho biết gian lận đối với một giao dịch nào đó thì mới bật việc giải mã cho chính giao dịch đó.
Ba tầng được đặt cạnh nhau. Câu trong lớp trình duyệt kiểm toán viên, “mức độ giải mã có thể cấu hình trong giai đoạn triển khai”, được hiện thực hóa ngay tại đó.
Quay lại câu trong blog đó. Blog nói khả năng hiển thị có thể bị thu hồi và việc thu hồi được ép buộc bằng mật mã. Tài liệu lại đưa ra một thiết kế khác: khả năng hiển thị được thiết lập theo mức khi xây mạng, chứ không phải thu hồi sau đó. Đều nhằm giới hạn kiểm toán viên: một cái là ràng buộc trước (pre-constraint), một cái là thu hồi sau (post-revocation).
Thực sự có cách thu hồi từ lớp quản trị: vai trò có thể cập nhật, trạng thái thành viên có thể chuyển thành hoạt động, bị đóng băng, hoặc ngừng hoạt động; việc đóng băng do bên vận hành thực thi thông qua hợp đồng quản trị ParticipantStorage. Tuy nhiên, tôi không tìm thấy mô tả về việc thu hồi khả năng hiển thị mà một kiểm toán viên đã nhận được. Có một chi tiết làm vấn đề này rất cụ thể: tài liệu nói kiểm toán viên nhận được một lần trao đổi khóa Diffie-Hellman mỗi khi một nút mới gia nhập, và năng lực truy cập được cung cấp dưới dạng vật liệu khóa. Việc thu hồi vai trò có thể chặn việc cấp quyền trong tương lai, nhưng liệu có thể làm vật liệu khóa đã được cấp mất hiệu lực hay không thì tôi vẫn đang nghiên cứu.
Điều thứ sáu, tính bền vững.
Mục này trái ngược với điều thứ năm: blog nói “nhẹ” hơn thực tế.
Nó nói rằng tính bền vững thuộc về quản lý khóa, và có thể giải quyết được—đọc lên giống như một chỗ trống. Nhưng tài liệu về quản lý khóa đã biến “có thể giải quyết” thành một phương án cụ thể. Quản lý khóa có thể cắm ghép vào những gì tổ chức đã có: AWS KMS, Google Cloud KMS, Azure Key Vault, HSM tại chỗ; môi trường phát triển thì mới dùng file cục bộ. Mã hóa kiểu “envelope” cho phần tĩnh; thứ được lưu lại để bền vững là bản mã chứ không phải vật liệu khóa.
Quan trọng nhất là câu này. Vì mỗi lần mã hóa/giải mã đều đi qua dịch vụ quản lý khóa của chính tổ chức, nên các vệt kiểm toán do những dịch vụ đó vốn đã tạo ra—việc phủ lên khóa của Rayls cũng giống như việc phủ lên các thứ khác mà tổ chức tự chạy. Kết luận dành cho bộ phận tuân thủ trong tài liệu là: không cần tạo mới một “bề mặt kiểm toán” riêng cho việc này. Đây đúng là thứ mà tính bền vững muốn: vệt kiểm toán nằm trên hệ thống của chính tổ chức, không phải trên nhật ký độc quyền của một nhà cung cấp.
Việc luân chuyển cũng được viết rất chi tiết. Mỗi chuỗi có thể có nhiều khóa ký chữ ký, luân chuyển theo tình trạng sử dụng; mỗi khóa được theo dõi nonce riêng. Các khóa đã dùng để ký cho giao dịch đang chờ xử lý sẽ vẫn còn hiệu lực cho đến khi những giao dịch đó hoàn tất quyết toán. Cách này đúng là xử lý “kẽ hở” dễ gây sự cố nhất trong luân chuyển khóa.
Tuy nhiên có một ranh giới: phần mô tả luân chuyển nói về khóa chữ ký; còn việc luân chuyển khóa quan sát tôi không thấy trong các trang này. Trong khi đó, tính bền vững lại quan tâm đến việc liệu quỹ đạo kiểm toán sau nhiều năm còn đọc được hay không—và điều đó phụ thuộc nhiều hơn vào phía khóa quan sát.
Cái công cụ mà kiểm toán viên thực sự dùng
Phần trước chủ yếu đọc mật mã, nhưng kiểm toán viên thực sự khi ngồi xuống dùng thì dùng một công cụ. Tài liệu ghi rõ trình duyệt kiểm toán viên của mạng riêng chỉ cho phép kiểm toán viên truy cập, bên vận hành và các bên tham gia khác thì không. Nó cung cấp góc nhìn sau khi đã giải mã cho các giao dịch cross-chain.
Giới hạn theo phạm vi: chỉ bao phủ các giao dịch cross-chain được ghi nhận tới trung tâm mạng riêng; các giao dịch xảy ra bên trong sổ cái Sovereign của một tổ chức cụ thể thì kiểm toán viên không truy cập được. Vì vậy, bề mặt “có thể nhìn thấy” cho kiểm toán là giữa các tổ chức, không phải bên trong một tổ chức.
Vậy có tồn tại một ví dụ mà có thể xác minh đầy đủ không.
Có, và chỉ có một, vì bản thân kiến trúc quyết định rằng phần lớn thứ sẽ không thấy được.
Tài liệu chính thức giải thích lý do: giao dịch Enygma phát hành từ sổ Sovereign của từng tổ chức; mỗi tổ chức tự triển khai một trình duyệt để giám sát sổ cái của chính mình. Phần cross-chain được xử lý trên trung tâm mạng riêng và được trình duyệt kiểm toán viên xem. Theo thiết kế, hoạt động của tổ chức không nằm trên chuỗi công khai, nên không thể tìm thấy giao dịch Enygma trên trình duyệt chuỗi công khai—đó không phải là thiếu sót, mà là kết quả tất yếu của kiến trúc ba lớp.
Nhưng hợp đồng khóa khoanh đó của Parfin nằm trên chuỗi công khai, và nó đúng là một ví dụ đầy đủ của “biên giới do toán học bắt buộc”.
Đối tượng bắt đầu bằng địa chỉ 0x1463889D, tên hợp đồng RlsTokenLock. Mã nguồn đã được xác minh và không phải là hợp đồng proxy. Điều này có nghĩa là đây là một trong số ít các đối tượng vừa có thể đọc code vừa có thể tra trạng thái hiện tại. Tôi đã đối chiếu cả hai bên với nhau.
Constructor khai báo totalAmount là 1.070.493.535 RLS. Lượng RLS mà hợp đồng hiện tại thực sự đang nắm giữ là 1.070.493.535. Không thiếu một wei nào—đủ 100%.
Nói đáng kể hơn là lịch trình giải phóng. Trong hàm khởi tạo có 48 mốc thời gian, tôi đã giải mã toàn bộ: mức đầu tiên là ngày 1 tháng 12 năm 2027, sau đó mỗi tháng 1 ngày một mức; mức cuối là ngày 1 tháng 11 năm 2031. Tổng chênh lệch khoảng 3,92 năm; mỗi mức khoảng 22,30 triệu RLS. Các tài liệu công khai trước đó nhấn mạnh khóa đến tháng 12 năm 2027—đó là mức đầu tiên, đúng. Còn hàm khởi tạo cung cấp bức tranh đầy đủ: sau mức đầu tiên còn gần bốn năm được giải phóng theo tháng.
Chú thích nội tại của hợp đồng ghi rất thẳng mục đích thiết kế: không thể nâng cấp, các điều khoản khi triển khai chính là các điều khoản vĩnh viễn; không có giải phóng sớm, mọi khóa đều không thể chuyển sang một mức khác trước ngày hết hạn. Hai điều này tôi đã đối chiếu lần lượt với code: lịch trình được viết trong constructor và không có setter; hợp đồng cũng thực sự không phải là proxy.
Đây là “biên giới do toán học bắt buộc” trông như thế nào trong một ví dụ mà tôi có thể kiểm chứng đầy đủ: lập luận khớp với code và code còn cụ thể hơn cả lời nói. Những thứ trong sáu tiêu chuẩn mà tôi chỉ thấy dấu vết trong mã nguồn và tài liệu—tại đây có thể thấy từ đầu tới cuối.
Ngoài ra còn có hai trích dẫn từ bên ngoài.
Khi nói về TEE, blog cho rằng Intel SGX từng có các lỗ hổng được ghi nhận đã phá vỡ bảo đảm cách ly. Câu này đúng, nhưng nó nói giảm luận điểm của chính mình. Những lỗ hổng loại “phân lập” gồm Foreshadow, Plundervolt, EPIC Leak, SmashEx, các mã lần lượt là CVE-2018-3615, CVE-2019-11157, CVE-2022-21233, CVE-2021-0186 và CVE-2021-33767. Cái thật sự chí mạng là SGAxe của năm 2020: nó dùng CVE-2020-0549 để trích xuất chính khóa xác thực từ enclave xác thực của môi trường sản xuất Intel, sau đó có thể cấp phát các tuyên bố tùy ý mà dịch vụ xác thực do chính Intel phán là hợp lệ.
Luận chứng của blog là: bảo đảm của TEE do phần cứng cung cấp bằng chứng, còn SGAxe tấn công đúng vào khâu tạo ra chứng cứ đó. Lần thất bại nghiêm trọng nhất không phải là dữ liệu bị đánh cắp, mà là chính “bảo đảm” bị giả mạo. Nói cho công bằng, tất cả đều đã được sửa qua cập nhật vi mã và cơ chế khôi phục TCB; SGX ngày nay không còn giống SGX năm 2018. Nói chính xác hơn: căn cứ tin cậy phần cứng có một bề mặt lỗi dạng “lỗ hổng lăn”.
Một chỗ khác là nó nói rằng Project Agora của BIS đang hội tụ về cùng một kiến trúc. Tôi lật báo cáo nguyên mẫu ngày 27 tháng 5 của BIS: về mặt topology thì đúng là giống, cấu trúc hai lớp, có sổ chia sẻ cộng với các sổ độc lập cho từng khu vực tài hạt. Nhưng ranh giới của Agora là được vạch bằng quyền tài hạt (jurisdiction). Báo cáo không giải thích cách thức kiểm soát truy cập bên trong sổ của từng tài hạt hoạt động như thế nào, nên dù sự hội tụ có mở rộng tới tầng mô hình niềm tin (trust model) hay không thì các tài liệu công khai hiện có không cho biết.
Cái nào là được xác nhận, và cái nào là suy đoán của tôi.
Những điều đã xác nhận: ML-KEM-768 dùng cho khóa quan sát, xem relayer/cryptography/mlkem.go; Pedersen dùng cho cấu trúc hai sinh nguyên trên BabyJubJub, xem enygma_math.go; khóa riêng kiểm toán được relayer mã hóa và cấp phát, xem cryptography/service.go của dịch vụ quản trị. Những điều khác cũng thấy trong tài liệu kỹ thuật chính thức: toán học của khóa chi tiêu và khóa quan sát độc lập; phạm vi quan sát có thể giới hạn theo thời gian và theo tài khoản; trình duyệt kiểm toán viên chỉ bao phủ giao dịch cross-chain và “mức độ giải mã” có thể cấu hình ở giai đoạn dựng; Cryptographic Trust Suite giữ thống nhất khóa và Relayer không bao giờ giữ khóa; lưu trữ khóa có thể cắm ghép vào KMS hoặc HSM; mã hóa envelope tĩnh; nhật ký hoạt động kiểm toán cho thao tác khóa là “vệt kiểm toán” mật mã thao tác trên nền hệ thống quản lý khóa riêng của tổ chức, ký hiệu là các khóa chữ ký được luân chuyển theo cách sử dụng và các khóa đã ký cho giao dịch chờ quyết toán vẫn hiệu lực đến khi giao dịch đó hoàn tất; đóng gói được hoàn thành một lần duy nhất khi xây mạng theo khóa của từng bên tham gia; quy mô tập ẩn danh là 2 hoặc 6; crossTransfer đơn lẻ tối đa hướng tới 5 chuỗi đích; tính cuối cùng ở mức vài chục giây; đóng băng phía bên tham gia được thực thi bởi hợp đồng quản trị ParticipantStorage do bên vận hành chạy; tất cả đều thấy trong tài liệu kỹ thuật chính thức. Trạng thái xác thực của RlsTokenLock, thuộc tính không phải proxy, lịch trình 48 mức, và “số tiền được tuyên bố” so với “số dư thực tế” đều được đọc qua giao diện trình duyệt công khai vào ngày 2026-09-12. Các mã số lỗ hổng của SGX đến từ bản ghi CVE và bài báo SGAxe. Cấu trúc và dữ liệu của Agorá đến từ tài liệu công khai của BIS.
Suy đoán của tôi: trong bốn tài liệu thì chỉ bài báo dùng từ về Pedersen là chính xác. Cách mô tả “biên giới do toán học bắt buộc” nói về việc thực thi chứ không phải việc phân phối. SGAxe vững hơn các lỗ hổng kiểu phân lập để chống đỡ luận điểm của blog. Ba mẩu tài liệu này không viết theo kiểu đó.
Không thể xác minh được: cơ chế thu hồi sau đó ở Điều thứ năm. Tôi đã tra các tài liệu về quản lý khóa, trình duyệt kiểm toán viên, nền tảng mật mã Enygma, việc đóng băng thành viên, các tùy chọn thiết kế mạng riêng, và tài liệu của trung tâm mạng riêng—cùng với hai kho mã code relayer và dịch vụ quản trị. Tôi tìm được cấu hình “ba mức” của khả năng hiển thị, cơ chế cấp quyền, và việc đóng băng/ngừng hoạt động phía bên tham gia; nhưng không tìm thấy việc thu hồi khả năng hiển thị đã được cấp đó, và càng không có phần “được ép buộc bằng mật mã”. Luân chuyển dài hạn của khóa quan sát cũng không tìm thấy: phần mô tả luân chuyển khóa trong tài liệu nói về khóa chữ ký.
Cuối cùng, nói một chuyện không liên quan đến kỹ thuật
Cùng trong một tuần với việc viết bài này, phía chính thức công bố rằng 55% các mức đặt cọc sẽ được gia hạn đến ngày 15 tháng 9, và nói rằng trong thời gian điều chỉnh cơ chế đặt cọc, những người ủng hộ sớm sẽ tiếp tục nhận phần lợi nhuận đó; các cập nhật sau này liên quan đến đặt cọc và hơn nữa là kinh tế token rộng hơn bao gồm việc đốt sẽ được công bố riêng.
Từ giai đoạn cam kết trước, tôi đã đặt cọc và tham gia đầy đủ trong ba tháng. Mức đăng ký ban đầu là kết thúc vào ngày 9 tháng 9; trong vài ngày đó, trên giao diện tôi thấy hạn mức đã dùng hết và không thể bổ sung, một lúc tôi tưởng là lỗi giao diện. Giờ xem ra là cơ chế đang được điều chỉnh.
Đoạn này là quan điểm cá nhân của tôi, không phải tuyên bố về sự thật: trong giai đoạn cửa sổ điều chỉnh cơ chế, việc chọn kéo dài chứ không cắt thẳng, và ghi rõ ngày tháng, tôi thấy đó là một cách làm có thiện chí. Thời kỳ điều chỉnh cơ chế rất dễ xuất hiện cách diễn đạt mơ hồ; đưa ra một ngày cụ thể đồng nghĩa là thời hạn đến thì hoặc là thực hiện cam kết, hoặc là lại phải giải thích một lần nữa.
Chỉ là một sự kiện cụ thể như vậy thôi, không phải là phán xét cho bất kỳ kế hoạch dài hạn nào. Tôi không dự đoán lợi nhuận, cũng không khuyên bất kỳ ai ra quyết định dựa trên đó.
Nguồn tham khảo: Blog chính thức của Rayls Auditability without surveillance: why mathematical enforcement beats trusting the code, ngày 2026-09-12; hai trang trong tài liệu kỹ thuật chính thức của Rayls gồm Enygma cryptography foundation và trình duyệt kiểm toán viên mạng riêng; các kho GitHub của tổ chức raylsnetwork gồm rayls-sovereign-relayer và rayls-sovereign-pnh-governance; trình duyệt chuỗi công khai của Rayls explorer.rayls.com, gồm addresses và smart-contracts interface; thời điểm lấy dữ liệu là ngày 2026-09-12; NIST FIPS 203; các bản ghi CVE 2018-3615, 2019-11157, 2020-0549, 2021-0186, 2021-33767, 2022-21233 và bài báo SGAxe; báo cáo nguyên mẫu BIS Project Agorá othp110; hồ sơ điện tử mật mã IACR 2025/1638 và 2025/1639; thông báo từ tài khoản X chính thức của Rayls ngày 2026-09-12.
\u003ct-68/\u003e\u003cc-69/\u003e
