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

前几篇我一直在测 Rayls 的证明要算多久，但对银行来说还有一个更基本的问题：钱什么时候才算真正到账、再也撤不回来？这周我换了个方向，让 GitHub 的服务器同时盯着以太坊和 Rayls 公链两个小时，看它们自己怎么回答这个问题。
先给短答案。银行说的"到账"有两层意思：法律上不可撤销，和技术上不会被回滚。技术这一层，以太坊节点自己标记"已最终确定"的区块，比最新区块落后 12.6 到 19.2 分钟，中位数 16 分钟；Rayls 公链则在每个区块出来的那一刻就把它标记为最终确定，区块大约 1.35 秒一个。这种"确定性终局"（deterministic finality）也有代价：共识推进不下去时，链会停下来而不是分叉。Rayls 公链上线以来至少停过两次，一次 11.72 小时，一次 9.15 小时，两次恢复后都直接接在停下前的那个区块后面。
两种"终局"，银行两种都要
国际清算银行支付委员会和国际证监会组织 2012 年发布的《金融市场基础设施原则》（PFMI）第 8 条说，金融市场基础设施应当提供"清晰、确定的最终结算"，至少在起息日结束前完成，必要时应做到日内或实时。它的关键考量之一，是系统规则必须清楚定义结算在哪一刻成为最终。欧盟 1998 年的《结算最终性指令》第 5 条也是同一个思路：从系统规则定义的那一刻起，参与者和第三方都不能再撤销转账指令。
这是法律上的终局，靠规则和法律来定。技术上的终局问的是另一件事：这笔交易所在的区块，还有没有可能被替换掉。
公链在这里分两类。比特币属于概率性终局，区块后面接的块越多，被替换的可能就越小，但永远不是零，所以交易所会说"等多少个确认"。确定性终局的链用的是拜占庭容错共识，一个区块只要被足够多的验证者签署，就不会再变。今天的以太坊介于两者之间：最新的区块仍有可能被替换，要等验证者对检查点完成投票，才算最终确定。
两层终局之所以要放在一起看，是因为银行的规则需要一个能写进去的时刻。确定性终局给了这个时刻：区块出来，就是终局。概率性终局只能给出一个风险越来越小的过程。
怎么测的，任何人都能复现
测试代码在公开仓库 hansonhan0520-lang/enygma-bench 的 finality 文件夹里，由 GitHub Actions 运行，结果自动存进仓库。这是我第一次实测终局，前几篇测的都是零知识证明的算力，和本篇没有重叠。
采样脚本同时盯着两条链，每次一小时，连续测了两次：Rayls 公链每 0.25 秒问一次，以太坊每 1 秒问一次。每次用一个批量请求同时取回"最新"、"安全"和"已最终确定"三个区块，保证三者是同一时刻的读数。每个高度第一次出现时的区块哈希都记下来，结束后逐个重新查询，几个小时后又全部再查一遍，看有没有哪个区块被替换过。
两次采样分别是 Actions 运行 40642493952 和 40649630038，时间是 2026 年 10 月 28 日 06:12 到 08:22（UTC）。以太坊用的是 PublicNode 的公共节点，Rayls 用的是官方公共节点 mainnet-rpc.rayls.com。
以太坊：节点自己说，要等大约 16 分钟
两个小时里，以太坊出了 599 个区块，平均约 12 秒一个，其中有三次空了一个时隙。节点标记的"已最终确定"区块始终落后最新区块 62 到 95 个，折合 12.6 到 19.2 分钟，两个小时的中位数都是 16 分钟。"安全"区块落后 30 到 63 个。
这和 ethereum.org 的说法一致：一个以太坊区块大约 15 分钟后才最终确定，因为验证者要跨两个周期（epoch）完成投票。
这两个小时里，以太坊的 605 个区块事后重查，一个都没有被替换。但这不能说明以太坊不会回滚，头部区块被替换本来就少见，两个小时的样本太小，看不出频率。以太坊和 Rayls 真正的差别，在于节点自己愿意承诺什么。
Rayls：区块一出来，就是最终确定
Rayls 这边，两个小时里问了 27,788 次，"已最终确定"区块和最新区块每一次都是同一个，"安全"区块也是。平均每 1.35 秒出一个区块，一共看到 5,325 个高度。采样结束 0.3 到 1.4 小时后全部重查，没有一个哈希变过。
这个结果是节点的设计，不是巧合。Rayls 公链的共识客户端叫 Axyl，代码公开在 GitHub。公共节点报告的版本号 1.4.1（6909618），正好对应公开仓库里的 mainnet-v1.4.1 这个标签。在这个版本的执行流程里，共识层每提交一批结果，节点执行完后先把它设为最新区块，紧接着下一行就调用 finalize_block，把"已最终确定"和"安全"同时指向这个区块。也就是说，节点不会等"再过几个块看看"，共识提交即终局。
还有一个观察者视角的数字：一个 Rayls 区块从它自带的时间戳算起，大约 2 秒后出现在公共节点上，以太坊也在 2 秒左右。区块时间戳只精确到秒，所以这个数字只能看量级。
代价：宁可停下，也不分叉
确定性终局的另一面，是共识推进不下去时，链只能停。Axyl 自己的文档写得很直白：区块顺序和终局，要靠当前活跃的验证者正常工作才能产生，没有它们，什么都不会被提交。
我用二分查找在链上找区块之间最长的空档，找到了两次停摆。第一次从 2026 年 5 月 5 日 21:59:32 到 5 月 6 日 09:42:29（UTC），停了 11.72 小时。第二次从 6 月 21 日 01:05:33 到 10:14:47，停了 9.15 小时。两次停摆后出的第一个区块，父哈希都正好是停摆前最后一个区块，说明链是原地续上的，没有分叉，也没有区块被替换。
第二次停摆，Axyl 仓库里有一份事故报告。原因是第 52 个周期切换时，一批被延后执行的交易建成了最新区块，却带着一个更旧的轮次编号，提议者据此认为执行严重落后，便一直限速，最后 7 个验证者全部停住，重启也没用。修复是提交 3a71a1a。第一次停摆在公开仓库的事故文件夹里没有记录。
这两次是我在两个日期范围里各找的最长空档。我没有逐块扫描整条链，所以不能排除还有更短的停顿。
出块间隔变过两次
回溯整条链的出块节奏，还有一个公开资料里没有的发现。我从创世区块到现在均匀取了 61 段，每段算平均出块间隔：4 月 30 日上线到 9 月 9 日左右，除了包含停摆的两段，稳定在 1.29 到 1.32 秒；9 月 11 日到 10 月 5 日，缩短到 0.69 到 0.70 秒；10 月 7 日以后，又回到 1.33 到 1.38 秒。
这解释了一个旧数字。9 月 12 日我从区块浏览器读到的平均出块时间是 568 毫秒，那正是快的那段时间。今天再引用这个数字，就已经过时了。
变化的原因我没能确定。公开的三个主网版本分别在 7 月 27 日、8 月 25 日和 10 月 2 日发布，第一次变化前后没有新版本；第二次变化前几天有 10 月 2 日的版本，但时间接近不等于就是原因。代码里出块节奏相关的参数由运营方配置，默认值是最长 10 秒、最短 5 秒提议一次，主网实际出块远快于这个默认值。
另外，Rayls 文档里"亚秒级终局"的说法，写在 Sovereign 机构账本的介绍页上。Sovereign 和公链都用 Axyl 共识，但部署方式不同，我测的是公链，这个数字既不能证实也不能否定 Sovereign 的说法。
对银行意味着什么
这一节是推断，不是测量。
第一，确定性终局让规则里那个"最终时刻"可以直接对应到区块上。PFMI 要求系统规则定义结算何时最终，Rayls 公链的区块天然就是这样一个时刻，以太坊则要再等一刻钟左右。
第二，银行要多问的是可用性。英国 CHAPS 每个工作日的结算时间是 06:00 到 18:00，一次 9 到 12 小时的停摆，能占掉大半个结算日。停摆不会让已结算的交易被撤销，但新的结算做不了。所以评估这类网络时，除了终局，还要问停摆的频率、时长和恢复流程，这属于监管在运营韧性上关心的问题。
第三，技术终局不等于法律终局。区块不可替换只是技术事实，交易何时在法律上不可撤销，仍然要靠系统规则和所在地法律来定。
还没定的部分
我测的是 Rayls 公链，不是银行实际使用的 Sovereign 账本和私有网络枢纽。第二次采样快结束时，Rayls 官方公共节点开始返回"请求过多"（HTTP 429），说明它有限流；那一次的 Rayls 读数在此之前已经存下，汇总由原始数据重新计算。根据 Rayls 的资料，枢纽目前仍运行在 Besu 的权威证明网络上，文档还写到跨机构的 Enygma 交易完成最终确认需要几十秒，这两项这次都没有测。观察只来自一个公共节点和一个 GitHub 运行器。以太坊两小时没看到回滚，不代表它的回滚频率可以忽略。停摆只在两个日期范围里各找了最长的一次。
我的看法
"到账"这两个字，在以太坊上要等一刻钟左右才算数；在 Rayls 公链上，区块出来就算数，节点代码也是这么写的。但确定性终局换来的是另一种风险：停下来。Rayls 公链半年里至少停过两次，每次超过 9 小时。
判断标准很简单：任何人都可以在 enygma-bench 仓库运行 finality 和 finality-halt 两个工作流，看 Rayls 的"已最终确定"是否始终等于最新区块，以及链上有没有新的长时间空档。如果 Rayls 公布 Sovereign 和枢纽的终局时间和可用性数据，就可以拿同一套方法去对照。
参考来源：
CPMI-IOSCO《金融市场基础设施原则》第 8 条，2012 年 4 月 16 日：https://www.bis.org/committees/cpmi/pfmi/overview
欧盟《结算最终性指令》98/26/EC，1998 年 5 月 19 日：https://legislation.gov.uk/eudr/1998/26/data.html
ethereum.org，Single slot finality（页面更新于 2026 年 7 月 23 日）：https://ethereum.org/roadmap/single-slot-finality/
Axyl 共识客户端源码，标签 mainnet-v1.4.1（2026 年 10 月 2 日），事故报告 doc/incidents/2026-06-21-mainnet-halt.md：https://github.com/raylsnetwork/axyl
本文采样代码与全部日志，Actions 运行 40642493952、40649630038、事后重查与停摆定位（2026 年 10 月 28 日）：https://github.com/hansonhan0520-lang/enygma-bench
#Rayls $RLS #区块链结算

Blockchain publik menawarkan transparansi, tetapi bank tidak dapat memperlakukan setiap transaksi keuangan seperti unggahan di media sosial yang dapat dilihat publik. Saldo nasabah, jumlah pembayaran, dan pihak lawan transaksi dapat memuat informasi sensitif secara komersial atau pribadi.
Jadi, pertanyaan sebenarnya bukanlah apakah bank sebaiknya menggunakan blockchain. Pertanyaannya adalah bagaimana bank dapat memperoleh manfaat penyelesaian transaksi onchain tanpa mengungkap informasi keuangan yang rahasia.
1. Mengapa blockchain publik biasa menimbulkan tantangan
Di blockchain transparan yang umum, transaksi dapat mengungkap alamat dompet, jumlah token, dan pola aktivitas keuangan. Meskipun nama asli tidak dicantumkan langsung pada alamat, transaksi yang berulang terkadang dapat membantu pengamat mengaitkan aktivitas dengan entitas tertentu.

Jika transfer di Rayls gagal, apakah token saya akan kembali?
Apa yang terjadi pada token yang telah diproses di chain asal jika transaksi di chain tujuan gagal dalam transfer lintas chain? $RLS
Saat memindahkan token ke chain lain, aset di chain asal dapat dikunci atau dibakar. Namun, jika pemrosesan di chain tujuan gagal, diperlukan prosedur untuk memulihkan status aset.
Dokumentasi resmi Rayls menjelaskan mekanisme pemulihan untuk situasi ini. Namun, setelah meninjau kode publiknya, muncul beberapa hal tambahan yang perlu dikonfirmasi.

Temuan saya saat menelusuri konsensus Rayls, arsitektur penyelesaian, dan tanda terima transaksi.
Saya memulai dengan sebuah pertanyaan sederhana:
Jika sebuah blockchain menjanjikan finalitas dalam waktu kurang dari satu detik, apakah itu berarti seluruh transaksi selesai dalam waktu kurang dari satu detik?
Sekilas, jawabannya mungkin tampak jelas. Sebuah transaksi dikonfirmasi, jaringan mencapai konsensus, dan operasi pun selesai.
Namun, infrastruktur keuangan lebih rumit daripada itu.
Sebuah transaksi dapat disahkan di satu ledger sementara operasi yang lebih besar masih bergantung pada ledger lain, relayer, verifikasi bukti, atau eksekusi di sisi tujuan.

$RLS
Saat meninjau kembali kode Relayer Rayls, saya menemukan satu hal yang terasa janggal.
Jika Relayer adalah pihak yang meneruskan pesan, bukankah Relayer seharusnya juga memiliki izin RELAYER untuk "executeMessage()"?
Namun, setelah menelusuri kode yang sebenarnya, ternyata tidak demikian.
Sebaliknya, Rayls memisahkan izin untuk meneruskan pesan dari eksekusi yang sebenarnya.
Di Public Chain, tempat pertama Relayer masuk adalah "PublicRNEndpoint.receivePayload()".
Di sini, tanpa mengeksekusi pesan secara langsung,

Blockchain memberi institusi keuangan sesuatu yang sangat mereka butuhkan: penyelesaian transaksi yang dapat diverifikasi tanpa sepenuhnya bergantung pada basis data tertutup.
Namun, ada masalah yang jelas.
Bank tidak bisa begitu saja mencatat setiap detail transaksi di blockchain publik.
Saldo, pihak lawan transaksi, jumlah transaksi, dan informasi sensitif lainnya mungkin harus tetap bersifat privat—sementara regulator, pihak lawan transaksi, dan jaringan tetap membutuhkan bukti yang cukup untuk memverifikasi bahwa sesuatu benar-benar terjadi.
Jadi, bagaimana cara mendapatkan privasi sekaligus verifiabilitas?

Di paragraf sebelumnya, saya sudah menjalankan kode bukti yang dipublikasikan Rayls, dan mengukur bahwa tier anonimitas 6 orang membutuhkan 1,96 detik per bukti. Namun di artikel itu ada tiga kalimat yang bersifat inferensi, bukan pengukuran; saya tahu itu. Minggu ini saya ganti mesinnya menjadi 2 core, menambahkan beberapa tier data, dan dengan itu saya kembali untuk melengkapi tiga kalimat tersebut.
Pertama jelaskan hubungan artikel ini dengan paragraf sebelumnya, agar pembaca tidak mengira ini kiriman ulang yang sama. Paragraf sebelumnya mengukur waktu pembuatan bukti untuk tier 2 orang dan tier 6 orang di lingkungan single-core; dua angka itu kali ini diukur ulang dan hampir tidak berubah. Konten baru artikel ini adalah tiga hal yang di paragraf sebelumnya tidak bisa diukur dan hanya bisa disimpulkan.

Saya melihat pengumuman penguncian token biasanya hanya peduli pada satu hal: apakah komitmen ini bisa diverifikasi. Kebanyakan proyek “penguncian tim” pada akhirnya hanya berhenti pada satu kalimat—Anda hanya bisa memilih untuk percaya atau tidak. Kali ini tidak seperti itu, jadi saya cek langsung ke blockchain.
Pertama, jelaskan faktanya. Parfin adalah pihak teknologi inti di balik Rayls, yang bertanggung jawab mengembangkan node privasi, jaringan privat, kerangka privasi Enygma, dan blockchain Rayls. Sebagai kompensasi untuk pekerjaan sebelum TGE, mereka menerima 1,070,493,535 unit RLS, sekitar 11% dari total suplai awal sebanyak 10 miliar unit.
Rangkaian token ini sebelumnya disimpan di kustodian institusi di jaringan Ethereum. Alasannya cukup praktis: pada saat TGE, blockchain publik Rayls belum berjalan, jadi token ini hanya bisa dititipkan terlebih dahulu. Sekarang blockchain publik sudah siap, token ini dipindahkan ke blockchain Rayls, dikunci dalam sebuah smart contract yang dapat diverifikasi secara publik, sekaligus jadwal pelepasannya ditunda dari Desember 2026 menjadi Desember 2027.

Jujur saja, saat pertama kali melihat tiga singkatan ini ditaruh berdekatan, saya mengira itu adalah tiga jawaban untuk satu soal yang sama—siapa yang paling cepat, siapa yang paling aman, tinggal pilih satu saja. Tapi kemudian saya paham: menaruh semuanya dalam satu peringkat, seperti bertanya "mana yang terbaik: palu, obeng, atau kunci inggris", jawabannya tergantung di tangan Anda sedang ada paku, sekrup, atau baut.
Mereka masing-masing sebenarnya menyelesaikan tiga masalah yang selama ini dicampuradukkan.
Masalah pertama adalah: saya ingin membuktikan sesuatu itu benar, tetapi data yang dibutuhkan untuk membuktikannya sangat sensitif, dan saya tidak ingin memperlihatkannya kepada Anda. Bank ingin menjelaskan kepada regulator bahwa "transaksi ini sah, otorisasinya benar, dan tidak ada duplikasi", tetapi mereka tidak mau menuliskan rincian jumlah dan pihak penerima/pembayar di dalam pembukuan. Kebutuhan agar pembuktian tetap benar tanpa membuka data adalah arena utamanya ZK. Kehebatannya adalah: kesimpulan berasal dari matematika, bukan dari "saya berjanji pada Anda, saya tidak akan melihat"; regulator atau auditor yang memperoleh kunci verifikasi bisa memeriksa kesimpulannya, tetapi tidak bisa menyentuh data dasarnya. Harganya juga nyata: ia jago membuktikan sifat data, tetapi kurang jago membuat beberapa pihak bisa menghitung bersama ketika tidak ada yang memiliki data lengkap, dan ia juga lebih haus daya komputasi dibanding data terbuka (plaintext).

Saudara-saudara, aku telah lama mengintai di komunitas Rayls. Aku tahu kalian semua sangat tidak puas dengan tim. Aku juga demikian. Namun, tim ini benar-benar bekerja, terus berupaya. Hanya saja tim Rayls menjalankan jalur yang sesuai dengan aturan. Saudara-saudara, jangan pernah menyerah. Serahkan semuanya pada waktu. Aku percaya tim Rayls pada akhirnya akan menyerahkan soal ujian yang membuat kita puas. Aku ingin membagikan kabar baik kepada saudara-saudara: ini tentang baru-baru ini tim Rayls menghubungkan RPC. Ini adalah hal yang sangat penting!!
Ringkasan cepat
Apa itu RPC
Kamu bisa mengartikan RPC sebagai telepon jalur khusus antara aplikasi dan blockchain.

Di tabel perbandingan pemasok di situs Rayls terdapat sembilan baris, dan saya memilih baris “Privasi”. Alasannya sangat sederhana: privasi itu penting, dan Besu bersifat open source—saya bisa memeriksa dokumentasi dan kodenya.
Di tabel perbandingan, Rayls memberi tanda centang pada dua baris: “privasi terisolasi” dan “privasi kriptografi”, sedangkan Besu hanya memberi tanda centang pada baris yang pertama. Saya berencana memverifikasi dengan dokumentasi milik mereka sendiri, jadi saya mencari dokumentasi Besu, lalu mengunduh kodenya dan menghitungnya satu per satu.
Kesimpulannya bukan “Besu tidak bisa”. Perbedaannya yang nyata adalah: kedua pihak menempatkan privasi pada lapisan yang berbeda, dan Besu memindahkannya lebih cepat daripada yang banyak orang kira.

Setiap minggu, komunitas kripto selalu bisa melihat ”beberapa raksasa keuangan tradisional masuk ke blockchain”. Sekarang, saya biasanya langsung menggeser judul-judul seperti itu, karena pada akhirnya sebagian besar berhenti di lab inovasi, lalu setelah merilis press release tidak ada kelanjutannya. Menilai benar atau tidaknya sebenarnya punya standar sederhana: di aplikasi mereka sendiri, apakah pelanggan biasa bisa langsung membuka dan menggunakannya.
XP Inc. Kali ini sudah lolos standar tersebut.
Pertama, jelaskan perusahaan ini, karena skala menentukan bobotnya. XP adalah platform investasi asal Brasil yang terdaftar di Nasdaq, kode saham XP. Saya mengecek laman hubungan investor-nya untuk data kuartal I tahun 2026: aset nasabah sekitar R$1.529 miliar real—lebih tepatnya R$1,529 triliun; jumlah penasihat investasi lebih dari 18.000 orang; total pendapatan dalam 12 bulan terakhir R$198 miliar real, dan laba sebelum pajak R$58 miliar real.

19 September Rayls mengirim sebuah artikel berjudul (Privacy has a price). Di judulnya tertulis honest math, namun seluruh artikel hanya memberikan satu rentang angka: sebuah pembuktian memerlukan ratusan milidetik hingga beberapa detik. Saya sudah menulis tentang arsitektur privasi Rayls selama beberapa minggu; kali ini saya ingin berbagi konten baru. Saya menurunkan kode bukti yang dipublikasikannya, menjalankannya beberapa puluh kali, lalu berbagi kesimpulan menarik ini untuk kalian!
Pertama, mari kita bahas tentang apa yang diceritakan di blog itu. Argumen intinya bisa diringkas menjadi dua kalimat. Kalimat pertama menjelaskan di mana biayanya: transaksi rahasia lebih mahal daripada transaksi transparan—mahalnya ada pada proses pembuatan bukti zero-knowledge, sementara verifikasinya justru lebih murah. Untuk sebuah bukti dari transfer rahasia dasar, dibutuhkan ratusan milidetik hingga beberapa detik pada perangkat keras komersial biasa. Kalimat kedua menjelaskan apa yang seharusnya ditanyakan: institusi tidak semestinya hanya menanyakan TPS, melainkan menanyakan throughput pada tingkat privasi dan kebutuhan audit yang mereka inginkan, saat menghadapi beban kerja bisnis yang nyata. Blog berpendapat bahwa volume penyelesaian antarbank tidak besar, sehingga sepenuhnya masih berada dalam kapasitas sistem penyelesaian yang bersifat rahasia.

Saya mulai melakukan staking dari batch pre-commit bulan Juni, jadi saya sudah melewati alur proses ini sekali. Kali ini dibuka untuk semua orang. Banyak orang di sekitar saya bertanya bagaimana caranya, apa yang perlu diperhatikan, jadi saya tulis semuanya sekaligus.
Pertama, jelaskan perubahan itu sendiri.
Rayls menggunakan proof-of-stake berbasis delegasi. Validator menjalankan node, membuat blok, dan menjaga keamanan blockchain, sedangkan pemegang biasa tidak perlu menjalankan node sendiri. Anda bisa mendelegasikan RLS yang Anda miliki ke validator tertentu dan membagikan sebagian dari imbalan staking.
Mekanisme ini sudah diluncurkan sejak bulan Juni, tetapi saat itu hanya dibuka untuk wallet yang ikut serta dalam rencana pre-commit dan aktivitas seed likuiditas. Wallet pada batch tersebut mengunci token mereka sebelum mainnet; pihak resmi memberi tambahan APY 55% selama tiga bulan. Bahkan, mereka mengirimkan 1 USDr ke setiap wallet yang memenuhi syarat, supaya para peserta itu bahkan tidak perlu khawatir tentang gas.

Saat menulis artikel tentang XP yang lalu, saya terus penasaran dengan satu pertanyaan: setelah stablecoin institusional seperti USDXP diterbitkan, bagaimana sebenarnya stablecoin itu ikut berperan dalam settlement lintas negara yang nyata? Artikel ini sekaligus menjawab rasa penasaran saya, dan sekalian membuat saya untuk pertama kalinya memahami sebuah istilah: “stabilcoin sandwich” (sandwich stablecoin).
Pertama, jelaskan kata ini. Sebenarnya, itu sangat menggambarkan: satu transaksi pembayaran lintas negara, dua ujungnya adalah mata uang fiat, dan di tengah ada lapisan stablecoin yang “dibuka” (public). Pihak pengirim menukarkan mata uang fiat menjadi stablecoin dolar, lalu stablecoin tersebut menyelesaikan settlement lintas negara di blockchain. Setelah itu, pihak penerima menukarkannya kembali menjadi mata uang fiat mereka sendiri. Mirip tidak seperti dua lembar roti yang menjepit lapisan di tengah? Itulah ungkapan yang mulai digunakan industri untuk mendeskripsikan settlement lintas negara dengan stablecoin.

Saya mulai melakukan staking RLS sejak fase prakomit, biasanya saya membaca blog resmi, lebih sering untuk tahu apakah posisi saya akan terpengaruh. Tapi artikel tentang kuantum pada 30 Agustus itu berbeda: isinya sepanjang mengajari institusi bagaimana melakukan pengadaan, tidak ada hubungan langsung dengan saya sebagai investor ritel. Namun tetap saja saya baca sampai selesai, karena di awal ia menetapkan satu aturan yang cukup tegas, dan aturan itu kemudian membawa saya kembali ke diri saya sendiri—ke artikel itu sendiri.
Begini aturan itu: istilah “keamanan kuantum”, jika tidak ditulis dengan jelas algoritma standarisasi spesifik yang digunakan, dan pada tingkat parameter yang mana, maka itu bukanlah sebuah klaim, melainkan sekadar label.

Di artikel sebelumnya, aku membahas tentang pembukaan staking itu sendiri. Di balik layar, banyak saudara bertanya hal yang paling sering ditanyakan dengan kalimat yang sama: bagaimana cara mengoperasikannya secara spesifik. Jadi kali ini, aku menelusuri seluruh alur dari awal sampai akhir lagi, mencatat setiap langkah dan setiap bagian yang mudah tersangkut. Kamu tinggal ikuti saja.
Tautan artikel sebelumnya ada di sini: 质押开放给所有人了,但有几件事最好先知道
Pertama, jelaskan dulu untuk siapa artikel ini. Jika kamu sama sekali belum pernah bersentuhan dengan Rayls, bahkan belum terlalu familiar dengan istilah seperti wallet dan bridging, artikel ini memang ditulis untukmu. Setiap istilah profesional akan kuberi penjelasan singkat sekalian.