Tháng trước, tôi đã viết về cách tự xác minh mức "bảo chứng 1:1" của BRL1.p; khi đó tôi chỉ xem một ảnh chụp tại ngày 17 tháng 10. Sau này, chính tôi cũng gửi tiền vào kho dự trữ, nên cứ băn khoăn: ai sẽ theo dõi từng ngày sau thời điểm chụp đó? Tuần này, tôi thiết lập để việc kiểm tra tự động chạy mỗi 6 giờ, đồng thời rà soát từng giao dịch xuyên chuỗi kể từ khi hệ thống đi vào hoạt động. Kết quả là tôi phát hiện thêm hai điều, nhiều hơn dự đoán.
Nói ngắn gọn: chưa đủ. Một lần chụp ảnh chỉ chứng minh rằng các con số ở hai bên bằng nhau tại thời điểm đó. Muốn yên tâm lâu dài, ít nhất cần làm ba việc: dùng mã thông điệp để đối chiếu từng giao dịch xuyên chuỗi trên cả hai blockchain; sắp xếp mọi thay đổi số dư trên hai blockchain thành một dòng thời gian để xem liệu có thời điểm nào lượng phát hành vượt quá số tiền trong kho dự trữ hay không; định kỳ kiểm tra lại ai là người ký duyệt.
Tôi đã thực hiện cả ba việc này với BRL1.p. Kể từ khi đi vào hoạt động, cả 18 giao dịch xuyên chuỗi đều khớp; trong 36 lần thay đổi số dư, lượng lưu hành chưa lần nào vượt quá số dư kho lưu trữ. Nhưng có hai điều mà ảnh chụp lần trước không cho thấy: trong ba bên xác minh bắt buộc phải ký, một bên đã thay khóa ký ngay trong ngày đầu BRL1.p đi vào hoạt động, và sau đó tên trong danh sách đăng ký của LayerZero cũng đổi từ Nethermind thành Twinstake; ngoài ra, cả 54 lần xác minh của ba bên đều được cùng một tài khoản gửi lên chuỗi.
Một ảnh chụp nhanh đã bỏ sót điều gì
BRL1.p là phiên bản của stablecoin BRL1, được neo theo đồng real Brazil, chuyển sang blockchain Rayls. Người dùng gửi BRL1 trên Polygon vào một hợp đồng kho lưu trữ, LayerZero chuyển thông điệp sang Rayls, rồi một lượng BRL1.p tương ứng được phát hành trên Rayls; chiều ngược lại thì token được đốt trước rồi mới mở khóa.
Trong ảnh chụp ngày 17 tháng 10, số dư kho lưu trữ và lượng BRL1.p lưu hành đều là 250,013.482911, khớp chính xác đến từng phần nhỏ nhất. Nhưng bản thân ảnh chụp không thể cho biết điều gì đã xảy ra giữa hai lần chụp. Khi đó, tôi ghép các giao dịch khóa và phát hành dựa trên số tiền, địa chỉ và thứ tự thời gian, chứ không dùng mã thông điệp của LayerZero; nếu ghép nhầm thì cũng không thể phát hiện. Còn về “ba bên xác minh”, ảnh chụp chỉ có ba địa chỉ được cấu hình, chứ không cho biết ai đứng sau các địa chỉ đó hay họ ký bằng khóa nào.
Mã nguồn, bản ghi từng giao dịch và nhật ký của mỗi lần chạy lần này đều được công khai trong thư mục 2026-11-brl1p-monitor của kho hansonhan0520-lang/rayls-verify trên GitHub. GitHub Actions tự động chạy 6 giờ một lần rồi gửi kết quả lên lại kho. Các con số trong bài viết lấy từ một số lần chạy trong khoảng 03:25 đến 03:56 (UTC) ngày 6 tháng 11 năm 2026.
Việc đầu tiên: đối soát từng giao dịch bằng mã thông điệp
LayerZero gán cho mỗi thông điệp xuyên chuỗi một mã GUID duy nhất. Khi gửi, mã này được ghi trong sự kiện OFTSent trên chuỗi nguồn; khi đến nơi, nó được ghi trong sự kiện OFTReceived trên chuỗi đích. Chỉ khi mã ở cả hai bên trùng khớp thì mới tính là cùng một giao dịch.
Kết quả là 18 giao dịch: 16 giao dịch từ Polygon sang Rayls và 2 giao dịch từ Rayls sang Polygon. GUID của từng giao dịch khớp ở cả hai bên; số lượng khóa bằng số lượng phát hành; và mã băm giao dịch ở hai đầu mà trình khám phá thông điệp LayerZero Scan liệt kê cũng khớp với dữ liệu trên chuỗi. LayerZero đánh số tuần tự các thông điệp trên mỗi kênh: 16 giao dịch này được đánh số từ 1 đến 16, còn chiều ngược lại là 1 và 2, không có số nào bị thiếu, nên bảng không bỏ sót thông điệp nào. Tôi cũng kiểm tra theo chiều ngược lại: mọi lần thay đổi số dư kho lưu trữ và lượng BRL1.p lưu hành đều có thông điệp xuyên chuỗi tương ứng; không có lần phát hành thêm hay chuyển đi nào “từ hư không”.
Thời gian đến nơi: các giao dịch từ Polygon sang Rayls mất 248 đến 293 giây, trung vị là 267 giây; chiều ngược lại mất 57 và 63 giây. Lần trước, 13 giao dịch mất từ 248 đến 274 giây; một giao dịch mới vào ngày 28 tháng 10 mất 293 giây, khiến mức tối đa tăng lên.
Việc thứ hai: ghép hai chuỗi thành một dòng thời gian
Một cầu nối khóa-phát hành hoạt động bình thường có một bất biến: lượng BRL1 trong kho lưu trữ luôn phải ít nhất bằng lượng BRL1.p lưu hành. Vì tiền được khóa trước khi phát hành, và bị đốt trước khi mở khóa, trong bốn đến năm phút giao dịch đang đi qua giữa hai chuỗi, kho lưu trữ sẽ có nhiều hơn lượng lưu hành một khoản tương ứng với giao dịch đang trên đường.
Tôi sắp xếp 36 lần thay đổi số dư trên hai chuỗi theo thời gian khối, rồi tính chênh lệch giữa hai bên sau từng lần. Sau mỗi lần thay đổi, chênh lệch đều không nhỏ hơn 0; mức thấp nhất đúng bằng 0, nghĩa là chưa từng có lúc nào lượng lưu hành vượt quá số dư kho lưu trữ. Phía Polygon không chỉ dựa vào suy luận từ sự kiện: tại các khối có 18 lần thay đổi số dư, tôi đọc trực tiếp balanceOf của kho lưu trữ từ hai nút lưu trữ độc lập (drpc và Tenderly). Từng kết quả đều khớp với số liệu suy ra, không có điểm nào sai lệch.
Tôi cũng xem lại quyền quản trị. Từ ngày 14 tháng 10 đến ngày 6 tháng 11, mỗi ngày lúc 00:00 (UTC), tôi đọc chủ sở hữu, hợp đồng ở đầu bên kia, delegate của LayerZero và cấu hình bên xác minh của kho lưu trữ Polygon; cả 24 ngày đều giống nhau. Toàn bộ 18 sự kiện quản trị và cấu hình tìm thấy trên hai chuỗi đều xảy ra trong quá trình triển khai, từ 18:05 đến 18:10 ngày 13 tháng 10; sau đó không có thay đổi nào. Phát hiện lần trước cũng không thay đổi: quyền phát hành và đốt chỉ nằm trong tay bộ chuyển đổi xuyên chuỗi, còn quyền quản trị, tạm dừng, nâng cấp và quyền sở hữu các hợp đồng ở cả hai bên vẫn thuộc cùng một địa chỉ ví thông thường.
Việc thứ ba: rốt cuộc ai ký để thông qua
Năm nay đã xảy ra một sự cố lớn ở lớp này. Tháng 4, cầu nối xuyên chuỗi KelpDAO bị đánh cắp khoảng 292 triệu đô la. Trong báo cáo sự cố tháng 5, LayerZero quy nguyên nhân cho việc các nút RPC bị thao túng, cộng với cấu hình ứng dụng này chỉ dựa vào một bên xác minh. Trong LayerZero, bên xác minh được gọi là DVN. Họ quan sát thông điệp trên chuỗi nguồn, chờ đủ số xác nhận rồi ký để thông qua trên chuỗi đích. Cả hai chiều của BRL1.p đều yêu cầu cả ba DVN ký: LayerZero Labs, Canary và một DVN có id là nethermind.
Trước tiên, hãy xem họ có thực sự ký hay không. Trước khi mỗi thông điệp đến nơi, trên chuỗi đích sẽ có một bản ghi PayloadVerified cho từng DVN. 16 thông điệp từ Polygon sang Rayls có ba bản ghi mỗi thông điệp trên Rayls, tổng cộng 48 bản ghi; 2 thông điệp chiều ngược lại có ba bản ghi mỗi thông điệp trên Polygon, tổng cộng 6 bản ghi. Số xác nhận được ghi trong từng bản ghi đều đúng bằng mức yêu cầu: 120 khối trên Polygon và 10 khối trên Rayls. Các xác minh trên Rayls diễn ra từ 232 đến 253 giây sau khi khóa trên Polygon; phần lớn thời gian hơn bốn phút để chuyển chuỗi là chờ 120 khối trên Polygon.
Tiếp theo, hãy xem ai đã ký. Hợp đồng DVN yêu cầu mỗi lần xác minh phải có chữ ký của đủ số người ký nhất định; các chữ ký này nằm trong dữ liệu đầu vào của giao dịch xác minh, nên có thể khôi phục địa chỉ ký. Tôi khôi phục chữ ký của cả 54 lần xác minh: ngưỡng của LayerZero Labs là 2 trong 3 người ký, và cả 16 giao dịch đều được ký bằng cùng hai khóa; ngưỡng của Canary là 1 trong 1 người ký, và cả 16 giao dịch đều dùng cùng một khóa.
Thay đổi nằm ở bên thứ ba. Bốn giao dịch đầu tiên (ngày 14 tháng 10) được ký bằng khóa 0xbbd4; từ giao dịch thứ năm (ngày 15 tháng 10), khóa được đổi sang 0x86f0, ngoại trừ một giao dịch dùng 0x598c. Bản ghi trên chuỗi cho thấy DVN này đã thêm hai người ký và xóa một người ký cũ trên cả Polygon lẫn Rayls, trong khoảng từ 19:55 ngày 14 tháng 10 đến 00:30 ngày 15 tháng 10 (UTC), đúng vào khoảng giữa giao dịch BRL1.p thứ tư và thứ năm.
Tên cũng thay đổi. Trong nhật ký chạy ngày 17 tháng 10 của tôi, danh sách DVN công khai của LayerZero ghi địa chỉ này là Nethermind; khi đọc lại ngày 6 tháng 11, tên được ghi là Twinstake, nhưng id vẫn là nethermind. Ngày 19 tháng 8, Nethermind thông báo đã ngừng vận hành DVN của LayerZero và chuyển sang vận hành nút Chainlink. Ghép các sự kiện này lại, cách giải thích có khả năng nhất là DVN này của Nethermind đã được bàn giao cho Twinstake vận hành, và khóa ký cũng được thay theo. Đây là suy luận của tôi: trên chuỗi chỉ thấy khóa thay đổi vào ngày 14 tháng 10, chứ không thể biết ai nắm giữ khóa; danh sách đăng ký là nhãn ngoài chuỗi do LayerZero quản lý, và tôi chỉ đọc được các phiên bản của hai ngày nên không biết chính xác thời điểm đổi tên.
Còn có một điểm chung nữa. Cả 54 giao dịch xác minh, bất kể DVN nào hay chuỗi nào, đều được gửi đi bởi cùng một tài khoản 0xb8ff…47cb. Tài khoản này và một tài khoản khác, 0xb52f…f0b6, đều có vai trò quản trị trên cả sáu hợp đồng DVN (mỗi chuỗi có ba hợp đồng). Tài khoản đó đã gửi hơn 8,88 triệu giao dịch trên Polygon. Theo mã hợp đồng và tài liệu LayerZero, quản trị viên chịu trách nhiệm gửi giao dịch, nhưng mỗi lần gửi đều phải kèm đủ chữ ký của người ký; quản trị viên không thể tự mình làm giả xác minh. Vì vậy, tôi hiểu rằng: về mặt bảo mật, ba ổ khóa vẫn là ba nhóm khóa khác nhau; để làm giả một thông điệp, ít nhất phải chiếm được 4 khóa ký (2 cộng 1 cộng 1). Nhưng về tính sẵn sàng, kênh gửi tập trung vào một tài khoản; nếu tài khoản này ngừng hoạt động, giao dịch xuyên chuỗi theo cả hai hướng sẽ bị mắc kẹt trên đường. Vế sau là suy luận dựa trên mã; tôi chưa quan sát thấy tình trạng ngừng hoạt động.
Một trở ngại khi tái lập kết quả: nút chính thức không thể dựng lại lịch sử
Muốn người khác tái lập kết quả thì phải nói rõ dữ liệu đến từ đâu. Nút công khai chính thức của Rayls không giúp được nhiều trong việc này: mọi truy vấn trạng thái lịch sử đều trả về “đã bị cắt tỉa”, thậm chí không đọc được khối ngày 17 tháng 10; truy vấn nhật ký của BRL1.p và bộ chuyển đổi trong phạm vi 1,5 triệu khối trả về 0 kết quả; và không lấy được biên nhận cho bất kỳ giao dịch nào trong 18 giao dịch Rayls. Tuy vậy, có thể tra cứu các giao dịch; dữ liệu đầu vào của cả 16 giao dịch nhận tiền đều chứa GUID tương ứng, địa chỉ người nhận và số tiền, còn dữ liệu của 2 giao dịch gửi đi cũng chứa địa chỉ người nhận và số tiền.
Vì vậy, lịch sử sự kiện phía Rayls chỉ có thể lấy từ trình khám phá khối Rayls. Tôi đối chiếu chéo bằng ba nguồn: bản ghi của LayerZero Scan, dữ liệu đầu vào giao dịch do nút chính thức trả về và lượng lưu hành hiện tại 255,291.961901 đọc được từ nút chính thức. Con số này khớp hoàn toàn với số liệu dựng lại từ sự kiện trên trình khám phá. Phía Polygon, tôi dùng hai nút PublicNode và Tenderly để lấy nhật ký; từng mục đều khớp giữa hai nút.
Lớp dự trữ: báo cáo vẫn là bản cũ
Cầu nối xuyên chuỗi chỉ đảm bảo BRL1.p và BRL1 theo tỷ lệ một đổi một; muốn biết bản thân BRL1 có được bảo chứng bằng đồng real hay không thì phải xem chứng minh dự trữ của đơn vị phát hành. Tính đến ngày 6 tháng 11, bản mới nhất có thể tải từ brl1.io vẫn là bản ngày 1 tháng 10: dự trữ 19,354,372 real, tương ứng với 17,381,384.54 BRL1, tỷ lệ 111.35%; báo cáo ghi rõ do nội bộ lập và chưa được một tổ chức độc lập kiểm toán. Thế nhưng dòng liên kết trên trang web lại ghi “chứng minh dự trữ mới nhất đã được kiểm toán”. Liên kết được ghi là “mới nhất” trên trang “Cách thức hoạt động” trỏ đến báo cáo ngày 14 tháng 4 năm 2025, cũng do nội bộ lập; một liên kết khác yêu cầu đăng nhập Google mới xem được; còn trang dự trữ Fact Finance được liên kết trên trang web trả về lỗi 404.
Tôi đã đối chiếu số lượng token trong cả hai báo cáo có thể đọc được theo số khối ghi trong báo cáo; số liệu từ hai nút lưu trữ đều khớp với báo cáo. Điều này cho thấy phần “nợ phải trả” trong báo cáo khớp với dữ liệu trên chuỗi, còn phần “tài sản” vẫn chỉ là lời khẳng định của chính đơn vị phát hành. Đến ngày 6 tháng 11, đã có 17,882,561.54 BRL1 trên Polygon, tăng 501,177 so với ngày 1 tháng 10; hiện chưa có báo cáo công khai nào bao quát phần dự trữ tương ứng với số tăng thêm này.
Có thể tham khảo hình thức bảo đảm độc lập từ Hoa Kỳ (Đạo luật GENIUS): đơn vị phát hành công bố cơ cấu dự trữ hàng tháng, CEO và CFO ký xác nhận, còn một công ty kế toán bên ngoài thực hiện dịch vụ đảm bảo. BRL1 là stablecoin của Brazil nên không thuộc phạm vi điều chỉnh của luật này; ở đây chỉ dùng làm ví dụ tham khảo. Khi BRL1 thực sự công bố báo cáo độc lập, trước tiên hãy xem người ký có phải là một công ty kế toán độc lập hay không, báo cáo có nêu rõ loại dịch vụ đảm bảo được thực hiện và chuẩn mực làm căn cứ hay không. Bạn có thể dùng por_check.py trong kho để kiểm tra xem số lượng token trong báo cáo có thể đọc được tại khối mà báo cáo nêu hay không.
Những điều chưa làm được
Lịch sử sự kiện phía Rayls phụ thuộc vào trình khám phá khối; nút chính thức chỉ có thể dùng để đối chiếu, chứ không thể dựng lại độc lập. Số liệu hằng ngày trên Polygon chỉ được đọc một lần lúc 00:00, nhưng từng lần thay đổi số dư cũng đã được đối chiếu riêng theo khối. Không thể biết từ dữ liệu trên chuỗi ai nắm giữ khóa ký hay ai vận hành tài khoản 0xb8ff. Việc kiểm tra tự động chỉ bắt đầu từ ngày 6 tháng 11, nên chỉ bao phủ khoảng thời gian sau đó; phần trước được dựng lại từ dữ liệu lịch sử.
Nhận định của tôi
Qua đối chiếu từng giao dịch, bản thân hoạt động xuyên chuỗi rất sạch: cả 18 giao dịch đều khớp, và lượng lưu hành chưa bao giờ vượt quá số dư kho lưu trữ. Lớp ký phức tạp hơn những gì cụm từ “ba bên xác minh” gợi lên: về bảo mật, đúng là có ba nhóm khóa khác nhau, nhưng một nhóm đã thay khóa ngay trong ngày đầu tiên hoạt động, còn kênh gửi chỉ có một. Lớp yếu nhất vẫn là đơn vị phát hành: chứng minh dự trữ mới nhất vẫn là báo cáo nội bộ chưa được kiểm toán.
Tiêu chí đánh giá rất đơn giản. Bất kỳ ai cũng có thể chạy quy trình brl1p-monitor trong kho rayls-verify, hoặc xem trực tiếp kết quả được gửi lên mỗi 6 giờ. Nếu xuất hiện sự kiện quản trị hoặc cấu hình mới, bên xác minh thay người ký, lượng lưu hành dù chỉ một lần vượt quá số dư kho lưu trữ, hoặc BRL1 công bố báo cáo dự trữ được kiểm tra độc lập, tất cả sẽ được ghi lại trong lần chạy tiếp theo.
Nguồn tham khảo:
Mã nguồn của bài viết, bản ghi từng giao dịch và nhật ký chạy (nộp ngày 6 tháng 11 năm 2026): https://github.com/hansonhan0520-lang/rayls-verify/tree/4e37e76f7541fbea2cba1c0b8967c46afa905677/2026-11-brl1p-monitor
Nhật ký chạy của ảnh chụp trước đó (ngày 17 tháng 10 năm 2026): https://github.com/hansonhan0520-lang/rayls-verify/tree/main/2026-10-brl1p-backing
Tài liệu hợp đồng LayerZero DVN: https://docs.layerzero.network/v2/workers/off-chain/dvn-technical-reference
Danh sách đăng ký công khai LayerZero DVN: https://metadata.layerzero-api.com/v1/metadata/dvns
Báo cáo sự cố LayerZero KelpDAO (ngày 18 tháng 5 năm 2026): https://layerzero.network/publications/kelpdao-incident-report.pdf
crypto.news, Nethermind rút khỏi vai trò bên xác minh của LayerZero (ngày 19 tháng 8 năm 2026): https://crypto.news/nethermind-leaves-layerzero-verifier-role-chainlink/
Trang web chính thức của BRL1 và tài liệu chứng minh dự trữ (đọc ngày 6 tháng 11 năm 2026): https://brl1.io/en
Trung tâm Chất lượng Kiểm toán Hoa Kỳ, yêu cầu của Đạo luật GENIUS đối với kế toán viên (ngày 27 tháng 10 năm 2025): https://www.thecaq.org/audit-in-action-what-does-the-genius-act-require-of-accountants
#Rayls $RLS #Stablecoin