rayls

$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?

上一篇我把 Rayls 公开的证明代码跑了一遍，测出 6 人匿名集每笔 1.96 秒。但那篇里有三句话是推断不是测量，我自己心里有数。这周把机器换成 2 核，又补了几档数据，就是回去把那三句话补上。
先说清楚这篇和上一篇的关系，免得读者以为是同一篇的重发。上一篇测的是单核环境下 2 人档和 6 人档的证明耗时，这两个数字这次复测了，几乎没变。这篇的全部新内容，是上一篇没能测、只能推的那三件事。
三件事分别是：多核会不会更快、第 6 个参与者为什么特别贵、端到端延迟里证明占多少。下文凡是写「上一篇推断」的，是我自己当时的说法；写「这次测到」的，是这次的结果。
先把测试数据的来源交代清楚
Rayls 的证明服务仓库自带测试数据，但只有 2 人档和 6 人档两组。中间的 3、4、5 档没有，这正是上一篇没法测中间值的原因。自己随便编一组是不行的。电路会当场拒绝，退一步说，就算真凑得出来能通过，读者也没有理由相信它。
所以我写了一个生成器。电路的约束条件写在仓库的 common-checks.go 里，每一项都能反推：发送方的共享密钥是上一轮随机数和私钥的 Poseidon 哈希对 BabyJubJub 子群阶取模，公钥是私钥自哈希取模，随机因子里接收方各取哈希的负值、发送方取接收方之和，交易承诺是金额和随机因子的 Pedersen 承诺。生成器就是把这些规则用仓库自己的原生函数实现一遍。
关键是怎么证明这个生成器没写错。我的办法是：先用它去复现官方那两组数据。把官方数据里所有受约束的字段全部清空，只留种子和其他参与者的公开输入，然后让生成器重新算一遍，再逐字段比对。结果是 6 人档和 2 人档全部字段完全一致。
这两组数据是 Rayls 各自独立发布的，私钥、区块号、余额、转账金额都不一样，能同时被复现，说明生成器实现的就是电路要求的那套规则。之后我才用同一套逻辑，按 6 人档的种子生成 3、4、5 档，每一档都先生成证明、再用对应的验证密钥验过一遍，全部通过。
有一点要说明：这三档沿用了 6 人档的转账金额和参与方，所以它们测的是同一笔交易在不同匿名集大小下的成本，不是三笔不同的业务。
第 6 个人贵在哪里
上一篇我看到 6 人档的计算规模是 131,072，而 2 到 5 档都是 65,536，于是推断从 5 档换到 6 档的代价会比前面几档之间大。当时没有中间档数据，只能停在推断。
这次的单核中位数是：2 人档 0.93 秒，3 人档 1.15 秒，4 人档 1.25 秒，5 人档 1.34 秒，6 人档 1.95 秒。前四档之间每档平均多 139 毫秒，而第 5 档到第 6 档一次多了 610 毫秒，是前面的 4.4 倍。
证明密钥的大小是同一个台阶：2 到 5 档每档稳定增加约 918 KB，到 6 档一次增加约 3.0 MB。约束数本身是完全均匀的，每多一个参与者固定加 8,112 条，从 37,140 条涨到 69,588 条，这条线上看不出任何台阶。
所以台阶不在约束数上，而在证明系统给电路分配的计算空间上，它按 2 的幂次取整，6 人档刚好越过 65,536。耗时和密钥大小在同一个位置一起跳，与这个解释一致。我把这写成一致，而不是写成证明。这次测的只有耗时和体积，证明过程内部各阶段的开销我没有单独拆开量过。
对使用者的意义很直接：如果匿名集大小是可配的，5 和 6 之间不是均匀的一小步。要么停在 5，要么接受一次性的跳变，中间没有折中位置。
多核只快 1.64 倍
上一篇我写过一句：机构服务器通常是多核，耗时会低于单核结果。依据是 gnark 的证明代码按 CPU 核数拆分最重的多标量乘法。这句话方向是对的，但当时那台机器只有 1 个核，倍数是多少我没法说。
这次的机器有 2 个核，同一台机器上只改 GOMAXPROCS，其余全部不变。五档的加速比分别是 1.54、1.65、1.68、1.80、1.52 倍，平均 1.64 倍，没有到 2 倍。
为什么不到 2 倍，代码里能看到一部分原因：多标量乘法确实按核数分任务，但证明过程里还有见证求解和若干串行步骤不随核数缩短。我只能说观察到的结果与此一致，没有逐阶段拆解验证。
这个倍数对部署选型是有影响的，方向还和直觉相反。按 6 人档算，一台单核机每秒能出 0.51 个证明，一台双核机每秒 0.78 个。要同样的吞吐量，用双核机反而要花更多的核，但每笔的等待时间少三分之一。 追吞吐就堆单核工作机更省，追单笔延迟就给每个证明多给核，两者不能同时最优。
上一篇只测了证明函数，没走完整服务，所以我当时把 JSON 解析和网络开销列为未测项。
这次把服务真正编译出来跑起来，用 curl 发真实 HTTP 请求。服务自己带分段计时，输出是：请求绑定 0.1 毫秒，参数解析 0.1 毫秒，证明生成 1,300 毫秒，序列化接近 0。curl 测到的端到端中位数是 1.314 秒，服务端内部合计 1.300 秒，差值在 1 到 14 毫秒之间，占整个请求的百分之一左右。
结论就是这么朴素：对这条路径来说，证明生成时间基本等于端到端延迟，HTTP 那一层可以忽略。上一篇把两者分开列为待测，现在可以合并了。
另外测到一件上一篇完全没提的事：冷启动。 每一档的第一个请求要 2.5 到 4.5 秒，之后才稳定下来，因为服务要把 6 到 12 MB 的证明密钥从磁盘读进内存并缓存。对按需扩容的部署来说，这个时间要算进容量规划，而不是只看稳态。
还有一个体积上的补充。证明本身固定 164 字节，五档都一样；随证明一起公开的数据是线性增长的，从 2 人档 588 字节到 6 人档 1,612 字节，每多一名参与者刚好多 256 字节。
按窗口内的平均速率算：CHAPS 日均 210,483 笔，折合每秒 4.87 笔，用单核工作机需要约 9.5 个核；Fedwire 日均 869,187 笔，每秒 10.97 笔，需要约 21.4 个核。英格兰银行记载的 CHAPS 单日笔数纪录是 2018 年 3 月 29 日的 320,034 笔，按同样窗口折合每秒 7.41 笔，约 14.5 个核。
对比一下就知道口径有多重要：CHAPS 按 24 小时平摊只需 4.8 个核，按真实的 12 小时窗口要 9.5 个，整整差一倍。Fedwire 因为窗口本来就接近全天，两种算法只差 9%。
还没算进去的有几项，读者可以自己加：窗口内的日内峰值高于窗口平均，各机构的负载不是均分的，结算链路上还有证明之外的环节，而且证明由发送方各自生成，负载天然是分散的，不集中在一台机器上。
这次确认了什么，还没有的
确认的是：五档的证明耗时和验证耗时、单核与双核的加速比、跨过计算规模边界那一步的代价、端到端与证明生成的差值、冷启动时间、证明和公开数据的体积、生成器能复现官方两组数据、故意改错的数据会被拒绝。这些照着截图里的命令都能重跑。
还没有的：只测了转账电路，存入、提取和 DvP 是另外几类；2 核仍然是很小的样本，更多核的曲线是什么形状我没有数据；只在一台机器上测，换硬件平台结果会变；生成的三档共用同一笔交易的参数；整条结算链路里证明之外的部分没有碰。上一篇被指出的一处措辞我也在这里改正：本机密钥和官方构建产物大小一致，能说明的是编译出的规模相同，不能说明电路逻辑相同。
我的看法
这次最有用的收获不是任何一个具体数字，而是把三句推断换成了三个可复现的结果，其中一句还被自己的测量修正了：多核会更快是对的，但只快 1.64 倍，不是想当然的 2 倍。
给读者一个可验证的判断标准：下次看到任何隐私方案的性能数字，先问三件事，匿名集或参与方规模是多少，跑在几个核上，这个数字是证明本身还是端到端。三个都答得上来的数字才能拿去做容量规划。这三项恰好也是这篇文章自己回答的三项，命令都在截图里。
参考来源：GitHub raylsnetwork/rayls-sovereign-gnark-api，提交 67c4c26（2026 年 9 月 30 日读取并实测）；Rayls 官方博客《Privacy has a price: the honest math behind confidential settlement at scale》（2026 年 9 月 19 日）；美联储 Fedwire Funds Service 年度统计（2026 年 1 月 26 日更新）；英格兰银行 Payment and settlement statistics、《A brief introduction to RTGS and CHAPS》与 2026 年 5 月延长结算时间咨询文件。
#Rayls $RLS

Rayls 官网的供应商对比表里有九行，我挑了「隐私」这一行。原因很简单：隐私很重要并且 Besu 是开源的，它的文档和代码我都能查。
对比表里，Rayls 在「隔离式隐私」和「密码学隐私」两行都打勾，Besu 只在前一行打勾。我打算去对方自己的文档核实，所以我去查了 Besu 的文档，然后把它的代码拉下来数了一遍。
结论不是「Besu 不行」。真正的差别是：这两家把隐私放在了不同的层，而 Besu 挪走的时间比很多人以为的要早。
Besu 那边：从文档到代码
Besu 官方文档里，隐私相关的页面顶部现在都挂着同一条横幅：基于 Tessera 的隐私功能自 24.12.0 版本起弃用。
真正的移除发生在 25.6.0。这个版本的发行说明把它列为破坏性变更，条目是移除 Tessera 隐私功能，编号 #8369，同一批还移除了链上权限管理。
我自己核实的部分是这样做的。先用三个版本号去取同一个文件：25.4.0 里 PrivateTransaction.java 和 Enclave.java 都返回 200，25.6.0 和 26.2.0 都返回 404。再看接口：25.4.0 的 RpcMethod 枚举里有 23 个 priv_、eea_、privx_ 开头的方法，26.2.0 的同一个文件里一个都没有。命令行也一样，25.4.0 有 12 个 --privacy 开头的启动参数，26.2.0 的 BesuCommand.java 里连 privacy 这个词都搜不到。规模上，25.4.0 里与隐私和 enclave 相关的非测试 Java 文件有 153 个，合计 17,875 行。
Besu 为什么要这么做
这一段必须写，否则就成了挑刺。
Besu 维护者在 2024 年 9 月 24 日的公告里给了理由：代码库变成了一把臃肿的瑞士军刀，Tessera 这类功能在它本来要解决的场景里性能不够，而应用层已经有成熟和新兴的方案。公告里还提到，一个面向 EVM 的可编程隐私开源项目即将提交给 LF Decentralized Trust 实验室。
那个项目就是 Paladin，现在已经从实验室升为 LF Decentralized Trust 的正式项目，Apache 2.0 许可，用零知识证明或发行方预验证两种方式实现隐私代币，跑在任何 EVM 链之上。
所以准确的说法是：Besu 没有放弃隐私，它把隐私从客户端移到了应用层。
两种放法，各自的价钱
Rayls 的做法是把隐私放进协议：Enygma 用 AES-256 加密交易内容、用 Pedersen 承诺记录余额、用 Groth16 证明这笔账是对的，走的是普通交易路径。
这条路的价钱可以量出来。上一篇我实测过证明生成，单核环境下 6 人匿名集每笔 1.96 秒。今天我又量了另一件事：证明本身只有 164 字节，而且 2 人档和 6 人档一样大，因为 Groth16 的证明是定长的。但随证明一起公开的数据不是定长的：2 人档 588 字节，6 人档 1,612 字节。
这个数字顺带纠正了一个常见说法。离开私有环境的不只是「一个证明」，而是加密载荷、证明和必要的公开数据，内容保持隐藏，同时系统仍然能验证和结算。
顺便说一下对比表另一行的事。Rayls 在「隔离式隐私」上打勾，靠的是部署结构：每家机构的 Sovereign 账本装在自己的边界内，官网的说法是私有数据不离开该实例，只有完成一笔交易所必需的最小载荷才会发往外部网络。所以这两行对 Rayls 来说是两层东西，机构之间靠部署隔离，跨机构结算靠密码学。这一点我只看了官网和文档，没有实际部署过。
许可这边也要摆出来。Rayls 的开放栈是 Apache 2.0，但 Enygma 和 Axyl 两个模块是 BUSL 1.1，测试免费、生产需授权，每个版本发布四年后自动转为 Apache 2.0。Paladin 则是 Apache 2.0。
这对一家机构意味着什么
如果一家机构的私有网络跑在 Besu 上，并且用了 priv_ 或 eea_ 接口，那么升到 25.6.0 这一步不是升级，是迁移。23 个接口和 12 个启动参数同时消失，隐私逻辑要搬到应用层重写；不搬就只能停在 25.4 系列，之后所有性能改进和安全修复都与你无关。
如果选 Rayls，隐私和账本属于同一套东西，版本、审计和支持是一条线，不用自己拼。代价是每笔机密交易都要先算证明，匿名集越大公开的数据越多，以及 Enygma 那部分要按 BUSL 授权。
那个「越多」有多多，可以估一下，下面是我算的。一笔 6 人档的机密转账，证明加公开数据合计约 1,776 字节。按英国 CHAPS 2025 年日均 210,483 笔的规模去套，一天约 374 MB，一年约 136 GB。对机构存储来说这不算什么，但它是随笔数线性增长的固定开销，而且匿名集是可调的：降到 2 人档，每笔只有 752 字节。这里假设每笔交易只产生一个证明，没有算存入、提取和 DvP 那几类电路。
从这一行里能抽出来的通用问题只有三个字：在哪层。问供应商隐私功能住在哪一层、由谁维护、它的生命周期和账本是不是绑在一起。Besu 这两年的变化说明，答案会变，而且变起来是破坏性的。
我确认了什么，我推断了什么
确认的部分：文件在不同版本里的存在与否、接口和启动参数的数量、官方公告和发行说明的内容、证明与公开数据的字节数、上一篇的证明耗时。这些都能照着截图里的命令重跑。
推断的部分：升级会中断现有隐私业务，这是从接口消失推出来的，我没有真的把一个 25.4 的私有网络升到 25.6 去试。Paladin 能不能接住某一家机构的具体场景，我也没有评估。
范围上，我只看了转账电路和隐私这一行。Besu 的用户完全可以自己维护分支或写插件，这是它的许可允许的。对比表的其他八行我没有碰。
我的看法
对比表是一张静态的图，而开源项目的能力是会移动的。这一行两年内从「客户端内置」变成了「应用层自理」，表格却只能显示一个勾。
所以我更愿意把这类表当成检查清单的起点：每一行都去对方的仓库里看一眼当前版本。这次花的时间不到一小时，命令都在截图里。下次 Rayls 更新这张表时，值得看的是它是否给 Besu 那一栏加上版本说明。
参考来源：Rayls 官网 Sovereign 产品页与供应商对比表；Besu 官方文档隐私章节的弃用横幅；Besu 25.6.0 发行说明，条目 #8369；LF Decentralized Trust 2024 年 9 月 24 日公告《Sunsetting Tessera and Simplifying Besu》与 Paladin 项目公告；hyperledger/besu 仓库 25.4.0、25.6.0、26.2.0 三个标签（2026 年 9 月 24 日读取）；raylsnetwork/rayls-sovereign-gnark-api 提交 67c4c26（本机实测）。
#Rayls $RLS

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.

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.

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.

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

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.

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.

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.

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.

Tôi đã xem qua tài liệu Rayls, và một điều lúc đầu khiến tôi thấy khó hiểu là sự khác nhau giữa Privacy Node, Private Network và Public Chain.
Sau khi tìm hiểu cách chúng kết nối với nhau, tôi thấy việc hiểu chúng dễ dàng hơn rất nhiều.
Mỗi bên đều có một vai trò khác nhau.
1. Privacy Node: blockchain riêng của tổ chức
Rayls Privacy Node là một chuỗi tương thích với EVM do một tổ chức duy nhất vận hành.
Điều gì diễn ra bên trong tổ chức sẽ được giữ lại trong môi trường riêng của mình.
Nó có thể phát hành token, quản lý số dư, chạy các hợp đồng thông minh và xử lý hoạt động nội bộ của nó tại đây.

Nói thật, các tin tức dạng hợp tác tôi thường chỉ lướt một cái rồi trượt đi; mười cái thì chín cái chỉ là treo logo qua lại. Nhưng bài này tôi đã dừng lại đọc xong, vì nó chạm vào khâu “lỗi thời” và cũng “đắt đỏ” nhất trong thanh toán xuyên biên giới.
Chuyển tiền xuyên biên giới chậm, nhiều người tưởng là do “mạng chậm”. Thực sự nguyên nhân lại rất “trần trụi”: tiền không phải là “đẩy” đi ngay, mà từ trước đã “để sẵn” ở đó. Ngân hàng muốn thanh toán cho một quốc gia nào đó, thường phải mở tài khoản tại ngân hàng địa phương trước, nạp trước một khoản tiền lớn; thuật ngữ gọi là tài khoản nostro. Mỗi hành lang thanh toán trên toàn cầu đều phải “tạm ứng” một cục, giống như khi bạn đến nhà mỗi người bạn đều gửi trước một xấp tiền mặt để đó, đề phòng hôm nào đi ngang ghé dùng. Tiền nằm yên trên tài khoản không chuyển động, biến động tỷ giá tự bạn “chịu”; và một khoản thanh toán xuyên biên giới hoàn tất thường mất vài ngày.

Rayls là một dự án mà tôi đã theo dõi từ rất lâu. Gần đây họ vừa ra mắt dự án cộng đồng The Rail, lối chơi cũng không giống nhiều với các "hoạt động cày điểm" thường thấy. Dự án này không khen thưởng việc spam liên tục, mà là ghi nhận những người thật sự nỗ lực và duy trì đóng góp lâu dài. Nói đơn giản thì hãy nghe tôi kể nó vận hành thế nào nhé! Các bạn ơi, nếu bạn cũng thấy hay thì hãy cùng vào ở và điền vào form để lên tàu thôi nào.
https://tally.so/r/dWgdrA
1. The Rail là gì
The Rail là dự án Đại sứ Cộng đồng của Rayls, với mục đích ghi nhận những đóng góp có ý nghĩa và chuyển đổi chúng thành danh tính, quyền hạn và phần thưởng. Định vị chính thức là "một cộng đồng được xây dựng dựa trên đóng góp thực sự, chứ không phải là trò chơi cày điểm"; được ví như "một căn phòng nhỏ mà mọi người thật sự quan tâm lẫn nhau". Cơ chế vận hành là: bạn đóng góp → kiếm điểm → nâng cấp vai trò → được ghi nhận.

Tin tức quản lý tôi thường lướt qua thôi, vì đa phần không liên quan gì nhiều tới người nắm giữ thông thường. Lần này, tôi đọc xong bộ quy tắc của Vương quốc Anh thì lại đổi quan điểm, vì nó có một cơ chế không quá dễ nhận ra—nhưng sẽ ảnh hưởng thật sự tới việc các tổ chức trong tương lai sẽ chọn dùng chuỗi nào.
Đầu tiên, cứ sắp xếp rõ dòng thời gian, vì điều đó quyết định mức độ gấp rút.
Ngày 4/2/2026, Quốc hội Vương quốc Anh đã thông qua các quy định liên quan; ngày 30/6, FCA công bố nội dung cốt lõi của chế độ này, gồm tổng cộng năm tài liệu chính sách. Kênh ủy quyền sẽ mở vào ngày 30/9, trong khi phạm vi đầy đủ của các hoạt động được quản lý phải đến ngày 25/10/2027 mới có hiệu lực hoàn toàn.