rayls

@Rayls 의 스테이킹 APY를 볼 때 단순히 표시된 수익률만 확인하면 충분할까?
실제 수익률을 이해하려면 한 가지를 더 살펴봐야 한다.
수익이 어떻게 기록되고, APY로 계산되며, 실제 보상 지급까지 연결되는가?
이번에는 Rayls 공식 저장소의 "RewardCurve"와 "RewardDistributor" 코드를 직접 비교해 봤다.
1. 스테이킹 APY에 네트워크 수익이 자동으로 반영될까?
"RewardCurve"는 기본 월간 배출량과 변동 배출량을 합산해 연간 APY를 계산하도록 설계돼 있다.
여기서 중요한 부분은 "recordRevenue()"다.
이 함수는 네트워크 수익을 자동으로 가져오는 기능이 아니다. "REVENUE_REPORTER_ROLE" 권한을 가진 계정이 직접 호출해야 변동 배출량에 반영된다.
즉, 수수료를 처리하는 "FeeAggregator"가 존재한다고 해서 그 수익이 자동으로 "RewardCurve"에 기록되는 것은 아니다.
수익 처리와 APY 계산에 반영하는 과정은 별개다.
2. 계산된 APY가 실제 보상 지급액을 보장할까?
그렇지는 않다.
"RewardCurve"는 APY를 계산하지만 RLS를 직접 보관하거나 지급하지 않는다.
실제 보상 분배는 "RewardDistributor"가 담당한다.
코드를 보면 보상 목표액을 계산한 뒤, 부족한 경우 "RLSAccumulator"에 있는 사용 가능한 잔액으로 보충을 시도한다.
따라서 APY가 계산된다는 사실만으로 해당 수익률이 그대로 지급된다고 볼 수는 없다.
실제 지급은 보상 재원과 분배 조건에도 영향을 받는다.
3. 그렇다면 RewardCurve는 실제 메인넷에 적용됐을까?
이번 분석에서 가장 중요했던 부분이다.
Rayls 공식 저장소의 RewardCurve 배포 안내서를 확인해 보니, 해당 문서에는 RewardCurve가 고정된 배포 주소와 "deployments.json" 등록 항목을 갖고 있지 않으며, 아직 어디에도 배포되지 않았다고 명시돼 있다.
또한 배포 스크립트는 Rayls 메인넷에서 실행을 거부하도록 작성돼 있다.
물론 "RewardDistributor"에는 RewardCurve 주소를 연결하는 설정 기능이 존재한다.
하지만 코드에 연결 기능이 있다는 것과 실제 메인넷에서 연결돼 작동한다는 것은 다른 이야기다.
따라서 공개 저장소만으로 현재 메인넷에서 수익 연동 APY가 활성화됐다고 판단할 수는 없다.
4. 이번 코드 분석으로 확인한 내용
- 코드에서 확인: RewardCurve는 기본 배출량과 변동 배출량을 바탕으로 APY를 계산한다.
- 코드에서 확인: 수익 기록과 월간 초기화에는 별도 권한을 가진 계정의 호출이 필요하다.
- 코드에서 확인: 실제 보상 분배는 RewardDistributor가 담당한다.
- 공식 문서에서 확인: RewardCurve의 배포 상태에 관한 안내와 메인넷 배포 제한이 기록돼 있다.
- 아직 확인하지 못한 것: 현재 메인넷에서 RewardCurve가 실제로 배포되고 RewardDistributor에 연결돼 있는지 여부다.
이번에 코드를 살펴보면서 느낀 점은 명확하다.
스테이킹 APY를 평가할 때는 숫자만 보는 것이 아니라, 그 숫자가 어떤 데이터로 계산되는지, 실제 보상 재원은 어디서 나오는지, 그리고 해당 기능이 실제 네트워크에 적용됐는지까지 확인해야 한다.
코드가 존재한다는 것과 실제로 작동한다는 것은 다르다.
이 차이를 구분하는 것이 스테이킹 수익률을 제대로 이해하는 첫걸음이라고 생각한다.
참고 자료
RewardCurve 코드
https://github.com/raylsnetwork/axyl/blob/main/rayls-contracts/src/fees/RewardCurve.sol
RewardDistributor 코드
https://github.com/raylsnetwork/axyl/blob/main/rayls-contracts/src/fees/RewardDistributor.sol
RewardCurve 공식 배포 안내서
https://github.com/raylsnetwork/axyl/blob/main/rayls-contracts/script/interactions/reward-curve/README.md
RewardCurve 배포 도구 관련 PR
https://github.com/raylsnetwork/axyl/pull/174
#Rayls $RLS

Trong vài bài viết trước, tôi liên tục đo xem Rayls mất bao lâu để tính toán bằng chứng. Nhưng với ngân hàng, còn có một câu hỏi cơ bản hơn: khi nào tiền mới thực sự được ghi có và không thể thu hồi nữa? Tuần này, tôi đổi hướng: để máy chủ GitHub theo dõi đồng thời Ethereum và Rayls Public Chain trong hai giờ, xem chính chúng trả lời câu hỏi này như thế nào.
Trước tiên, câu trả lời ngắn gọn. Khi ngân hàng nói tiền đã “được ghi có”, điều đó có hai nghĩa: không thể hủy ngang về mặt pháp lý và không thể bị hoàn tác về mặt kỹ thuật. Ở khía cạnh kỹ thuật, các nút Ethereum tự đánh dấu khối là “đã hoàn tất cuối cùng” (finalized) chậm hơn khối mới nhất từ 12.6 đến 19.2 phút, với trung vị là 16 phút; còn Rayls Public Chain đánh dấu mỗi khối là đã hoàn tất cuối cùng ngay khi khối được tạo ra, cứ khoảng 1.35 giây lại có một khối. Tính “chung cuộc xác định” (deterministic finality) này cũng có cái giá của nó: khi đồng thuận không thể tiến triển, chuỗi sẽ dừng lại thay vì phân nhánh. Kể từ khi ra mắt, Rayls Public Chain đã dừng ít nhất hai lần: một lần trong 11.72 giờ và một lần trong 9.15 giờ. Sau khi hoạt động trở lại, cả hai lần đều tiếp tục trực tiếp từ khối ngay trước lúc dừng.

Blockchain công khai mang lại tính minh bạch, nhưng ngân hàng không thể xem mọi giao dịch tài chính như một bài đăng trên mạng xã hội công khai. Số dư của khách hàng, số tiền thanh toán và các bên giao dịch có thể chứa thông tin nhạy cảm về mặt thương mại hoặc cá nhân.
Vì vậy, câu hỏi thực sự không phải là liệu ngân hàng có nên sử dụng blockchain hay không. Mà là làm thế nào để họ hưởng lợi từ quyết toán trên chuỗi mà không làm lộ thông tin tài chính bí mật.
1. Vì sao blockchain công khai thông thường tạo ra thách thức
Trên một blockchain minh bạch điển hình, giao dịch có thể làm lộ địa chỉ ví, số lượng token và các mô hình hoạt động tài chính. Ngay cả khi tên thật không được gắn trực tiếp với địa chỉ, các giao dịch lặp lại đôi khi vẫn có thể giúp người quan sát liên kết hoạt động đó với một tổ chức cụ thể.

Nếu giao dịch chuyển token trên Rayls thất bại, token của tôi có được hoàn lại không?
Nếu giao dịch ở chuỗi đích thất bại trong quá trình chuyển tài sản xuyên chuỗi, điều gì sẽ xảy ra với token đã được xử lý ở chuỗi nguồn? $RLS
Khi chuyển token sang chuỗi khác, tài sản ở chuỗi nguồn có thể bị khóa hoặc đốt. Tuy nhiên, nếu giao dịch ở chuỗi đích thất bại thì cần có quy trình khôi phục trạng thái tài sản.
Tài liệu chính thức của Rayls mô tả cơ chế khôi phục để xử lý tình huống này. Tuy nhiên, khi xem xét cả mã nguồn công khai, chúng ta sẽ thấy một số điểm cần xác minh thêm.

Những gì tôi tìm hiểu được khi xem xét cơ chế đồng thuận, kiến trúc thanh toán và biên nhận giao dịch của Rayls.
Tôi bắt đầu với một câu hỏi đơn giản:
Nếu một blockchain cam kết đạt tính chung cuộc trong chưa đầy một giây, điều đó có nghĩa là toàn bộ giao dịch hoàn tất trong chưa đầy một giây không?
Thoạt đầu, câu trả lời có vẻ hiển nhiên. Một giao dịch được xác nhận, mạng lưới đạt đồng thuận và hoạt động hoàn tất.
Nhưng cơ sở hạ tầng tài chính phức tạp hơn thế.
Một giao dịch có thể được xác nhận trên một sổ cái trong khi một hoạt động lớn hơn vẫn phụ thuộc vào một sổ cái khác, bên chuyển tiếp, việc xác minh bằng chứng hoặc quá trình thực thi ở phía đích.

$RLS
Khi xem lại mã Relayer của Rayls, tôi phát hiện một điểm bất thường.
Nếu Relayer là chủ thể truyền thông điệp thì chẳng phải nó cũng cần quyền RELAYER đối với "executeMessage()" sao?
Nhưng khi lần theo mã thực tế, tôi phát hiện ra rằng không phải vậy.
Ngược lại, Rayls đã tách biệt quyền truyền thông điệp khỏi việc thực thi thực tế.
Trên Public Chain, nơi đầu tiên Relayer đi vào là "PublicRNEndpoint.receivePayload()".
Thay vì trực tiếp thực thi thông điệp tại đây,

Blockchain mang đến cho các tổ chức tài chính điều họ đang rất cần: khả năng quyết toán có thể xác minh mà không phải hoàn toàn dựa vào một cơ sở dữ liệu khép kín.
Nhưng có một vấn đề hiển nhiên.
Các ngân hàng không thể đơn giản đưa mọi chi tiết giao dịch lên một blockchain công khai.
Số dư, đối tác giao dịch, số tiền giao dịch và các thông tin nhạy cảm khác có thể cần được giữ kín — trong khi cơ quan quản lý, đối tác giao dịch và mạng lưới vẫn cần đủ bằng chứng để xác minh rằng giao dịch thực sự đã diễn ra.
Vậy làm thế nào để vừa bảo đảm quyền riêng tư, vừa có thể xác minh?

Ở bài trước, tôi đã chạy thử mã chứng minh Rayls công khai và đo được thời gian 1,96 giây cho mỗi giao dịch với tập ẩn danh gồm 6 người. Nhưng trong bài đó có ba câu là suy luận chứ không phải kết quả đo, và tôi biết rõ điều đó. Tuần này, tôi đổi máy sang loại 2 nhân, bổ sung thêm vài mức dữ liệu, rồi quay lại để bổ sung số liệu cho ba câu ấy.
Trước tiên, cần nói rõ mối liên hệ giữa bài này và bài trước, để độc giả khỏi tưởng đây là bài cũ đăng lại. Bài trước đo thời gian tạo chứng minh trong môi trường một nhân ở mức 2 người và 6 người. Lần này tôi đo lại hai con số đó, và chúng gần như không thay đổi. Toàn bộ nội dung mới của bài này là ba điều mà bài trước chưa thể đo, chỉ có thể suy luận.

Nhìn chung, khi xem thông báo khóa lượng, người ta chỉ quan tâm đến một điều: cam kết này có thể được kiểm chứng hay không. Phần lớn các dự án về “khóa lượng của đội ngũ” cuối cùng đều dừng ở một câu nói, bạn chỉ có thể chọn tin hay không tin. Lần này thì có chút khác, nên tôi đã tự tra trên chuỗi.
Trước hết, nói rõ các sự kiện. Parfin là đối tác công nghệ cốt lõi đứng sau Rayls, chịu trách nhiệm phát triển node bảo mật, mạng riêng, framework bảo mật Enygma và blockchain Rayls. Như một khoản thù lao cho công việc thực hiện trước TGE, họ đã nhận được 1,070,493,535 đồng RLS, tương đương khoảng 11% trên tổng cung ban đầu 10 tỷ đồng.
Lô token này trước đó được lưu trữ tại một bên được ủy thác cho một tổ chức trên Ethereum. Lý do khá thực tế: trong thời điểm TGE, blockchain công khai Rayls vẫn chưa hoạt động, nên chỉ có thể tạm thời ủy thác. Hiện nay blockchain đã sẵn sàng, lô token này đã được chuyển sang blockchain Rayls, được khóa trong một hợp đồng thông minh có thể kiểm chứng công khai, đồng thời thời gian mở khóa cũng được dời từ tháng 12 năm 2026 sang tháng 12 năm 2027.

Thành thật mà nói, lần đầu tiên tôi thấy ba chữ viết tắt này được đặt cạnh nhau, tôi cứ nghĩ chúng là ba câu trả lời cho cùng một bài toán: ai nhanh hơn, ai an toàn hơn, chọn một là xong. Mãi sau đó tôi mới hiểu, việc xếp chúng chung một bảng xếp hạng, cũng giống như hỏi "cái búa, cái vít, hay cờ-lê cái nào dùng tốt hơn", đáp án sẽ phụ thuộc vào việc trong tay bạn là đinh, là ốc, hay là bu-lông.
Các vấn đề mà từng cái giải quyết, thật ra là ba vấn đề bị trộn lẫn với nhau.
Vấn đề thứ nhất là: Tôi muốn chứng minh một điều gì đó là đúng, nhưng việc chứng minh cần dùng dữ liệu nhạy cảm, tôi không muốn cho bạn xem. Ngân hàng muốn báo cáo với cơ quan quản lý rằng "giao dịch này hợp pháp, ủy quyền không sai, không có giao dịch trùng lặp", nhưng lại không muốn ghi khoản tiền và bên chi trả/nhận vào sổ cái. Nhu cầu chứng minh là đúng nhưng không công khai dữ liệu này, chính là thế mạnh của ZK. Điểm hay của nó là: đảm bảo được tính đúng đắn đến từ toán học, chứ không phải kiểu "tôi hứa với bạn là tôi không xem"; cơ quan quản lý hoặc kiểm toán nhận được khóa xác thực có thể kiểm chứng kết luận, nhưng không thể chạm tới dữ liệu gốc. Cái giá cũng khá rõ: nó rất giỏi chứng minh các thuộc tính của dữ liệu, nhưng lại không giỏi giúp nhiều bên cùng tính toán khi không bên nào có đủ dữ liệu, và nó còn tiêu tốn năng lực tính toán hơn cả bản rõ.

Anh em ơi, tôi vẫn luôn mai phục trong cộng đồng Rayls. Tôi biết mọi người rất không hài lòng với đội nhóm. Còn tôi cũng vậy. Nhưng đội nhóm đang thật sự làm việc, họ vẫn luôn cố gắng. Chỉ là đội ngũ Rayls đi theo lộ trình tuân thủ quy định. Anh em nhất định đừng bỏ cuộc. Mọi chuyện cứ để thời gian quyết định. Tôi tin rằng đội ngũ Rayls cuối cùng sẽ bàn giao cho chúng ta một đề thi khiến chúng ta hài lòng. Tôi muốn chia sẻ một tin vui với anh em: liên quan đến việc gần đây đội ngũ Rayls đã kết nối RPC. Đây là một việc rất quan trọng！！
Xem nhanh
RPC là gì
Bạn có thể hiểu RPC như một đường dây riêng giữa ứng dụng và blockchain.

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ĩ.

Giới mã hóa mỗi tuần đều có thể lướt thấy “một ông trùm tài chính truyền thống nào đó” tiến vào blockchain. Bây giờ tôi nhìn thấy loại tiêu đề như vậy là cơ bản gạt đi trước, vì đa phần cuối cùng chỉ dừng ở mức các phòng thí nghiệm đổi mới, phát xong thông cáo báo chí rồi không thấy có diễn tiến gì thêm. Việc đánh giá đúng hay sai thật ra có một tiêu chuẩn rất đơn giản: một khách hàng bình thường trong ứng dụng của chính họ, có thể bấm trực tiếp vào để dùng hay không.
XP Inc. Lần này đã đạt chuẩn này.
Trước tiên hãy nói rõ công ty này, vì quy mô quyết định mức độ quan trọng của việc đó. XP là một nền tảng đầu tư của Brazil niêm yết trên NASDAQ, mã cổ phiếu XP. Tôi đã đối chiếu dữ liệu ở trang quan hệ nhà đầu tư của họ cho quý 1 năm 2026: tổng tài sản khách hàng ở mức khoảng R$1.529 tỷ reais (chính xác là R$1.529 nghìn tỷ); nhân sự tư vấn đầu tư hơn 18.000 người; tổng doanh thu trong mười hai tháng gần đây R$198 tỷ reais, lợi nhuận trước thuế R$58 tỷ reais.

Ngày 19 tháng 9, Rayls đăng một bài (Privacy has a price)，trong tiêu đề có chữ honest math, nhưng cả bài chỉ đưa ra một khoảng số: một chứng minh cần từ vài trăm mili giây đến vài giây. Mấy tuần liền mình viết về kiến trúc quyền riêng tư của Rayls, lần này mình chia sẻ thêm nội dung mới: mình tải mã nguồn chứng minh mà họ công khai, chạy thực tế vài chục lần và chia sẻ kết luận thú vị này với mọi người!
Trước hết nói xem blog đã nói gì. Lập luận cốt lõi của họ có thể nén thành hai câu. Câu 1 là chi phí nằm ở đâu: giao dịch bí mật đắt hơn giao dịch minh bạch, cái đắt nằm ở việc tạo chứng minh zero-knowledge; còn xác minh lại rẻ, một chứng minh cho một bản chuyển tiền bí mật cơ bản trên phần cứng thương mại phổ thông cần vài trăm mili giây đến vài giây. Câu 2 là phải hỏi gì: tổ chức không nên chỉ hỏi TPS, mà phải hỏi throughput của mình dưới mức riêng tư và kiểm toán mà mình cần khi đối diện với tải công việc nghiệp vụ thực—blog cho rằng khối lượng thanh toán giữa các ngân hàng không lớn, hoàn toàn nằm trong phạm vi năng lực của hệ thống thanh toán bảo mật.

Lần trước khi viết bài về XP, tôi vẫn luôn tò mò một câu hỏi: sau khi một loại stablecoin kiểu “USDXP” do một tổ chức phát hành ra thì rốt cuộc nó tham gia vào việc thanh toán xuyên biên giới thực sự như thế nào? Bài này là để giải đáp cho thắc mắc đó, đồng thời cũng giúp tôi lần đầu hiểu rõ một thuật ngữ: “sandwich stablecoin” (stablecoin ba-mính-tê—“ba lớp bánh kẹp”).
Trước hết, giải thích từ này: nó thực sự rất hình tượng. Một khoản thanh toán xuyên biên giới: hai đầu là nội tệ, ở giữa là một lớp stablecoin công khai. Bên thanh toán đổi nội tệ sang stablecoin USD, stablecoin được dùng để hoàn tất thanh toán xuyên biên giới trên blockchain, rồi bên nhận lại đổi nó về nội tệ của mình. Nghe có giống hai lát bánh mì kẹp ở giữa không? Đây chính là cách ngành bắt đầu dùng để mô tả cách stablecoin thực hiện thanh toán xuyên biên giới.

Tôi đã bắt đầu stake từ đợt cam kết dự trước vào tháng 6, nên quy trình này tôi đã đi qua một lần rồi. Lần này mở cho tất cả mọi người, xung quanh tôi có khá nhiều người hỏi tôi nên thao tác thế nào, cần lưu ý điều gì, nên thôi thì viết rõ ràng một lần cho xong.
Trước hết, hãy nói về bản thân sự thay đổi.
Rayls sử dụng Proof of Stake ủy quyền: người xác thực chạy node, tạo khối và đảm bảo an toàn cho blockchain, còn người nắm giữ thông thường không cần tự chạy node. Bạn có thể ủy quyền RLS trong tay cho một người xác thực nào đó để chia sẻ một phần phần thưởng staking.
Cơ chế này đã được triển khai từ tháng 6, nhưng lúc đó chỉ mở cho các ví tham gia chương trình cam kết dự trước và hoạt động hạt giống thanh khoản. Nhóm đó đã khóa coin trước khi mainnet ra mắt; phía chính thức đã cộng thêm lãi suất hằng năm 55% trong 3 tháng, thậm chí còn gửi 1 USDr vào mỗi ví đủ điều kiện để họ khỏi phải tốn gas luôn.

Từ giai đoạn cam kết trước, tôi đã bắt đầu thế chấp RLS. Thường ngày tôi đọc blog chính thức, phần nhiều là để biết vị thế của mình có bị ảnh hưởng hay không. Bài viết về lượng tử vào ngày 30 tháng 8 thì khác: suốt bài chủ yếu dạy các tổ chức cách mua sắm, không liên quan trực tiếp gì đến kiểu như tôi—một nhà đầu tư cá nhân. Nhưng tôi vẫn đọc hết, vì ngay từ đầu nó đã đặt ra một quy tắc khá cứng, và về sau quy tắc đó lại kéo tôi quay về chính nội dung của bài viết.
Quy định đó là như thế này: một cách nói “an toàn lượng tử”, nếu không nêu rõ cụ thể nó dùng thuật toán chuẩn hóa nào và ở mức tham số nào, thì nó không phải là một khẳng định, chỉ là một nhãn.

Ở bài trước, tôi đã nói về việc mở tính năng thế chấp (staking) cho mọi người. Nhưng trong phần phản hồi, nhiều anh em ở hậu trường lại hỏi nhiều nhất lại là cùng một câu: cụ thể phải làm như thế nào? Vì vậy lần này tôi đi lại toàn bộ quy trình từ đầu đến cuối, ghi chép lại từng bước và cả những chỗ dễ bị kẹt. Bạn chỉ cần làm theo là được.
Đường link của bài trước đặt ở đây: 质押开放给所有人了,但有几件事最好先知道
Trước hết, hãy nói rõ bài viết này dành cho ai. Nếu bạn hoàn toàn chưa từng tiếp xúc với Rayls, thậm chí còn không quá quen với các từ như ví (wallet) hay cầu nối (bridge), thì bài này chính là để viết cho bạn. Mỗi thuật ngữ chuyên ngành, tôi sẽ tiện giải thích thêm một câu.