rls

An Analysis of Compensating Transactions, Partial Settlement, and the Limits of Atomicity in Cross-Chain Payments
Many institutions and developers still treat a successful transaction receipt on the sender’s chain as proof that a payment is complete. In cross-chain systems, that is often not the case.
From reviewing technical documentation and observing basic behavior in controlled environments, one pattern consistently appears: the debit on the source chain can commit successfully, while the destination can still fail at a later step. When that happens, the funds do not automatically return. The system typically executes a **compensating transaction**.
Partial Atomicity
The official Rayls documentation (*Send Enygma Transactions* and *How Enygma Works*) describes the boundaries of atomicity clearly:
- The source call is atomic — the burn and the transfer request succeed or fail together.
- Each individual destination leg is atomic — the mint and any program steps on that leg succeed or fail together.
- All legs of a single payment are **not** atomic. Legs can settle independently.
The documentation states explicitly that “Failures are reversed, not rolled back.” The Hub transaction and the mint on the destination chain are separate transactions. If the mint or a program step fails on the destination, the relayer runs a compensating transaction to return the value to the sender. It is not one atomic transaction across chains.
Until the refund actually lands, the sender’s balance on the source chain remains reduced by the failed amount.
What Is a Compensating Transaction?
A compensating transaction is a **new and separate** transaction created to correct a failure. It is not a rollback of the original transaction.
According to the RaylsEnygmaHandler documentation, if any program step reverts, the entire leg (including the mint) fails. The relayer then returns the value to the sender on the source chain through a compensating mechanism. The refund appears under the **same reference ID** and is recorded as status `RECEIVED` on the source chain, rather than as a pure revert of the original debit.
A simple example consistent with the documented behavior:
- The source debits 10.
- One destination successfully receives 4.
- Another destination fails during execution.
- A separate compensating transaction returns 6 to the sender.
The final result is 4 delivered + 6 returned = 10. The original source transaction remains recorded as successful.
Diagrams
Basic flow:
Atomic vs Multi-Leg:
Partial Settlement Example:
Practical Risks Worth Noting
From the documentation and observations in controlled environments, several points are often overlooked:
1. Refunds are not instant
The Rayls documentation itself notes that until the refund lands, the sender’s balance remains reduced. Delays in the relayer or issues with proof generation can leave funds in a pending state longer than expected.
2. Reconciliation must be done per leg
A single source receipt is not enough. One must match what left the source, what arrived at each destination, what failed, and what was actually returned via the compensating transaction (typically under the same reference ID).
3. Dependence on off-chain components
Failure detection and refund initiation often rely on relayers. Even in local testing, warnings related to balance commitments or proof generation can appear. These risks are higher in production.
4. Controlled results ≠ production guarantees
Clean behavior in a lab with deliberately triggered failures does not automatically translate to production environments with concurrent load, network issues, or state inconsistencies.
Conclusion
A successful receipt on the source chain only proves that the debit committed. It does not prove that every destination received the funds, nor does it prove that any failed portion has been returned.
Successful source execution, destination settlement, and compensating refunds are related events, but they are **not the same event**. Understanding this distinction matters when designing or operating cross-chain settlement flows.
The official Rayls documentation already describes this compensating pattern openly. The important point is not to treat results from controlled environments as full proof of production reliability.
---
Disclaimer:
This article is an analysis based on publicly available Rayls documentation and technical observations in controlled environments. It is not a formal audit, investment advice, or a guarantee of any system’s behavior in production. Readers should verify details directly against the official documentation.
Sources
- Send Enygma Transactions: https://docs.rayls.com/docs/send-enygma-transactions
- How Enygma Works: https://docs.rayls.com/docs/how-enygma-works
- RaylsEnygmaHandler: https://docs.rayls.com/docs/raylsenygmahandler
#RLS $RLS

Rayls의 Sovereign Contracts 저장소를 살펴보면서 Private Network Hub(PNH)의 역할별 권한 설정을 확인했다.
단순히 각 역할이 어떤 기능을 수행하는지 소개하는 대신, 실제 구현 코드와 권한 설정 스크립트, 공식 문서가 서로 일치하는지 비교해 봤다.
권한 관리 시스템에서는 역할 이름만 아는 것으로 충분하지 않다. 코드가 어떤 권한을 지원하는지, 설정 스크립트가 어떤 매핑을 실행하는지, 문서가 이를 어떻게 설명하는지까지 함께 살펴봐야 하기 때문이다.
비교 과정에서 확인할 만한 지점 세 가지를 발견했다.
1. 복수 역할 매핑을 지원하는 구현과 주석의 차이
먼저 "src/privateHub/AccessControl/libraries/AccessManagerRoleConfigLib.sol"을 살펴봤다.
이 파일의 "addFunctionAllowedRoles()" 구현은 전달받은 여러 역할 ID를 순회하면서 해당 함수 선택자에 대한 역할 비트맵을 갱신한다.
즉, Rayls의 커스텀 권한 관리 구현은 하나의 함수에 여러 역할을 연결할 수 있는 구조다.
그런데 역할을 활성화하는 "hardhat/tasks/interact/access-control/activate-business-roles-pnh.ts"에는 하나의 함수에 하나의 역할만 매핑할 수 있다는 취지의 주석이 나온다.
여기서 중요한 점은 주석과 실제 구현을 구분해서 읽어야 한다는 것이다.
주석의 설명만 보면 복수 역할 매핑에 제한이 있는 것처럼 이해할 수 있지만, 실제 구현에서는 여러 역할 ID를 처리하는 로직을 확인할 수 있다.
따라서 이 부분은 설정 스크립트의 설명과 실제 권한 관리 구현을 함께 대조해야 하는 지점이다.
2. TOKEN_MANAGER의 권한 설명이 문서마다 다르다
두 번째는 "TOKEN_MANAGER"의 권한 설명이다.
Rayls의 공식 Private Network Roles 문서는 "TOKEN_MANAGER"에 매핑된 함수가 없다고 설명한다.
반면 저장소의 역할 참조 문서에는 "TokenRegistry.updateStatus()"와 "TOKEN_MANAGER"의 연결이 기재되어 있다.
같은 역할을 설명하는 문서 사이에 차이가 존재하는 것이다.
이 차이는 단순한 표현의 문제가 아니다.
개발자가 역할별 권한을 확인하거나 운영자가 설정을 검토할 때, 어느 문서를 기준으로 판단해야 하는지 혼란이 생길 수 있다. 특히 문서만 보고 권한을 파악한다면 실제 코드나 설정과 다른 이해를 할 가능성이 있다.
다만 문서가 서로 다르다는 사실만으로 어느 쪽이 현재 배포 환경의 권한을 정확하게 반영하는지 단정할 수는 없다.
확실하게 말할 수 있는 것은 두 문서의 설명이 서로 일치하지 않으며, 기준이 되는 권한 정보를 명확히 할 필요가 있다는 점이다.
3. TeleportV1.setLockTime()의 출력 요약과 실제 매핑 목록
세 번째는 권한 활성화 스크립트의 출력 요약이다.
"activate-business-roles-pnh.ts"의 마지막 콘솔 출력 요약에는 다음과 같은 매핑이 표시된다.
"TeleportV1.setLockTime() → PRIVATE_NETWORK_OPERATOR"
그런데 스크립트에서 실제 매핑 작업을 담고 있는 "mappingTxs" 목록에서는 이 매핑을 수행하는 호출을 확인할 수 없다.
여기서는 출력 메시지와 실제 실행 작업을 구분해야 한다.
콘솔에 특정 권한 매핑이 표시된다고 해서 그 문구만으로 실제 매핑 트랜잭션이 실행됐다고 판단할 수는 없다. 실행하려는 작업 목록과 결과를 설명하는 출력 요약은 서로 다른 역할을 하기 때문이다.
따라서 이 항목은 설정 스크립트의 출력과 실제 매핑 목록을 대조해 볼 필요가 있는 사례다.
다만 이 코드만으로 실제 배포된 네트워크에서 "TeleportV1.setLockTime()" 권한이 설정되어 있는지, 또는 설정되어 있지 않은지까지 결론 내릴 수는 없다. 그 부분은 별도의 온체인 조회로 검증해야 한다.
세 가지 발견에서 공통으로 보이는 점
이번에 비교한 내용은 서로 다른 유형의 불일치다.
- 구현과 주석: 실제 코드가 지원하는 구조와 주석의 설명을 대조해야 한다.
- 문서와 문서: 같은 역할에 대해 서로 다른 권한 정보를 제공하고 있다.
- 출력 요약과 실행 목록: 표시된 설명만으로 실제 실행 여부를 판단해서는 안 된다.
이 세 가지를 같은 종류의 오류라고 단정할 수는 없다. 하지만 모두 권한 설정을 검토할 때 설명 문구만 읽는 것으로는 충분하지 않다는 점을 보여준다.
코드가 지원하는 기능, 설정 스크립트가 실행하는 작업, 문서가 설명하는 권한은 서로 연결되어 있어야 한다. 이 정보가 어긋나면 개발자와 운영자가 의도된 권한 구조를 정확하게 이해하기 어려워질 수 있다.
결론
이번 조사의 핵심은 Rayls의 권한 관리 시스템에 문제가 있다고 단정하는 것이 아니다.
실제 구현 코드와 설정 스크립트, 문서를 비교해 어디에서 설명이 서로 달라지는지 구체적으로 찾아냈다는 것이다.
그리고 소스 코드에서 확인한 사실과 별도의 검증이 필요한 사항을 구분하는 것도 중요하다. 저장소에서 불일치를 발견했다고 해서 실제 배포 환경에서도 동일한 문제가 발생한다고 볼 수는 없기 때문이다.
인프라를 제대로 이해하려면 기능 설명을 읽는 데서 멈추지 않고, 코드와 설정을 직접 대조해야 한다.
이번 비교를 통해 다시 확인한 것도 바로 그 점이다.
#RLS

Rayls에서 전송이 실패하면 내 토큰은 돌아올까?
크로스체인 전송에서 목적지 거래가 실패하면 출발지에서 처리된 토큰은 어떻게 될까? $RLS
토큰을 다른 체인으로 옮길 때 출발지에서는 자산이 잠기거나 소각될 수 있다. 그런데 목적지에서 처리가 실패하면 자산 상태를 복구하는 절차가 필요하다.
Rayls의 공식 문서는 이 상황에 대응하는 복구 메커니즘을 설명한다. 하지만 공개 코드를 함께 살펴보면 추가로 확인해야 할 부분이 드러난다.
Public Chain 전송과 관련된 기존 계약 코드에도 폐기 표시가 있기 때문이다.
그렇다면 Rayls의 토큰 복구 기능은 현재 어떻게 구현돼 있을까?
공식 문서와 공개 코드를 비교해 봤다.
1. 공식 문서가 설명하는 토큰 복구 방식
Rayls의 공식 문서는 Sovereign과 Public Chain 사이의 전송 방식과 실패 처리 절차를 설명한다.
공식 문서:
https://docs.rayls.com/docs/connecting-rayls-sovereign-to-the-public-chain
이 경로는 Private Network Hub를 거치는 기관 간 전송 경로와 구분된다. Public Chain 경로는 별도의 계약 구성과 Public Relayer를 사용하며, RN 계열 계약을 통해 메시지를 처리한다.
전송 방향에 따라 자산 처리 방식도 달라진다.
Sovereign → Public Chain
• 출발지에서 토큰을 잠근다.
• 목적지에서 대응하는 토큰을 발행한다.
• 목적지 거래가 실패하면 복구 데이터를 이용해 출발지의 토큰을 해제하는 절차를 진행한다.
Public Chain → Sovereign
• 공개 체인에서 토큰을 소각한다.
• 목적지에서 기존에 잠겨 있던 토큰을 해제한다.
• 목적지 거래가 실패하면 공개 체인에서 토큰을 다시 발행하는 복구 절차를 진행한다.
공식 문서에 따르면 Public Relayer는 전송 과정에서 복구 데이터를 준비하고 저장한다. 이후 목적지 거래의 영수증 상태를 확인해 실행 실패가 확인되면, 저장된 복구 데이터를 사용해 출발지에서 복구 절차를 진행한다.
따라서 Rayls의 공식 문서에는 Public Chain 전송 실패에 대응하는 구체적인 복구 설계가 명시돼 있다.
하지만 문서에 설계가 설명돼 있다는 사실만으로 현재 메인넷에서 사용되는 구현과 실제 복구 성공 여부까지 확인할 수 있는 것은 아니다.
2. 공개 코드에서 발견한 폐기 표시
다음으로 Rayls Sovereign Contracts 저장소의 `RaylsErc20Handler.sol`을 살펴봤다.
코드:
https://github.com/raylsnetwork/rayls-sovereign-contracts/blob/main/src/rayls-protocol-sdk/tokens/RaylsErc20Handler.sol
이 파일에는 Public Chain 전송과 관련된 함수가 구현돼 있다.
• `teleportToPublicChain()` — Public Chain으로 토큰을 보내는 전송 경로
• `receiveTeleportFromPublicChain()` — Public Chain에서 온 전송을 처리하고 잠긴 토큰을 해제하는 경로
• `revertTeleportToPublicChain()` — 목적지에서 전송 처리가 완료되지 않았을 때 잠긴 토큰을 복구하는 경로
특히 `revertTeleportToPublicChain()`의 주석은 목적지에서 토큰 수령을 완료할 수 없는 경우 잠긴 토큰을 복구한다고 설명한다. 함수 내부에서도 잠긴 잔액을 해제하고 토큰을 원래 보낸 주소로 돌려주는 로직을 확인할 수 있다.
그런데 이 함수에는 다음과 같은 폐기 관련 주석이 붙어 있다.
`@custom:deprecated Decommissioning Teleport (vanilla, atomic).`
같은 파일의 다른 Teleport 관련 함수에도 유사한 표시가 존재한다.
즉, 폐기 표시가 기존 Private Network의 Teleport 코드에만 있는 것은 아니다. 공개된 기존 `RaylsErc20Handler`의 Public Chain 관련 함수에서도 확인된다.
이 부분은 현재 공식 문서와 함께 살펴볼 필요가 있다. 공식 문서는 Public Chain 경로의 복구 절차를 설명하지만, 공개된 기존 계약 코드에는 해당 전송과 복구를 처리하는 함수에 폐기 표시가 있기 때문이다.
그렇다고 곧바로 현재 Public Chain 복구 기능이 폐기됐다고 결론 내릴 수는 없다. 주석이 붙은 코드의 버전과 현재 운영 환경에서 사용되는 구현이 일치하는지 확인해야 하기 때문이다.
여기서 중요한 질문은 폐기 표시의 존재 자체가 아니라, 그 표시가 현재 운영 중인 Public Chain 전송 경로에 어떻게 적용되는가다.
3. 문서와 코드의 차이만으로 운영 상태를 판단할 수 있을까?
현재 확인한 자료는 세 가지로 나눌 수 있다.
① 공식 문서
Public Chain 전송 실패 시 복구 데이터를 이용해 토큰 상태를 복구하는 절차를 설명한다.
② 공개 계약 코드
기존 `RaylsErc20Handler.sol`에 전송 및 복구 로직이 구현돼 있다. 다만 관련 함수에는 폐기 표시도 존재한다.
③ 실제 운영 환경
공개된 코드와 현재 메인넷에 배포된 계약의 관계는 아직 입증하지 못했다.
이 자료만으로 복구 기능이 중단됐다고 판단하는 것은 성급하다. 폐기 주석만으로 현재 메인넷에서 어떤 계약과 버전이 사용되는지 알 수 없기 때문이다.
반대로 공식 문서에 복구 절차가 설명돼 있다는 이유만으로 현재 운영 환경에서 모든 실패가 성공적으로 복구된다고 보장할 수도 없다.
실제 운영 상태를 판단하려면 다음 항목을 연결해서 확인해야 한다.
• 현재 메인넷에서 사용되는 계약 주소
• 해당 주소에 배포된 계약의 구현 버전
• 실제 운영 중인 Public Relayer의 버전과 처리 경로
• 목적지 실행 실패와 출발지 복구 거래를 연결하는 실제 기록
이번 조사에서는 공식 문서의 복구 설계와 공개 코드의 관련 함수 및 폐기 표시를 확인했다. 그러나 운영 계약 주소와 구현 버전을 연결하고, 실제 실패 거래가 복구 완료까지 이어졌다는 메인넷 거래 사례를 입증하지는 못했다.
따라서 현재 근거로는 복구 기능이 정상 운영 중이라고 확정할 수도, 폐기됐다고 확정할 수도 없다.
결론: 복구 설계는 문서에 명시돼 있지만, 운영 상태는 추가 검증이 필요하다.
이번 조사에서 확인한 사실은 두 가지다.
첫째, Rayls의 공식 문서는 Public Chain 전송 실패에 대응하는 복구 절차를 설명한다.
둘째, 공개된 기존 `RaylsErc20Handler.sol`에는 관련 복구 로직이 구현돼 있지만, Public Chain 전송 및 복구와 관련된 함수에도 폐기 표시가 있다.
이 두 사실을 함께 살펴보면 현재 운영 상태를 판단하기 위해 무엇을 추가로 확인해야 하는지 분명해진다. 공개된 코드의 주석만으로 기능의 현재 상태를 단정하지 말고, 실제 배포 계약과 구현 버전, 복구 거래까지 연결해서 확인해야 한다.
현재 자료로 내릴 수 있는 결론은 Rayls의 공식 문서에 복구 설계가 명시돼 있고, 공개 코드에 관련 구현과 폐기 표시가 함께 존재한다는 것이다. 현재 메인넷에서 해당 기능이 어떤 버전으로 운영되는지, 실제 실패 거래에서 복구가 완료됐는지는 아직 입증하지 못했다.
토큰 전송의 안전성을 평가할 때는 복구 기능이 문서에 있다는 사실만으로 판단해서는 안 된다. 해당 기능이 현재 어떤 코드와 배포 환경에서 실행되는지까지 확인해야 한다.
참고 자료
• Rayls 공식 문서 — Connecting Rayls Sovereign to the Public Chain
https://docs.rayls.com/docs/connecting-rayls-sovereign-to-the-public-chain
• Rayls 공식 문서 — RaylsErc20Handler
https://docs.rayls.com/docs/raylserc20handler
• Rayls Sovereign Contracts — RaylsErc20Handler.sol
https://github.com/raylsnetwork/rayls-sovereign-contracts/blob/main/src/rayls-protocol-sdk/tokens/RaylsErc20Handler.sol
• Rayls Sovereign Relayer
https://github.com/raylsnetwork/rayls-sovereign-relayer
#RLS #Rayls

前两篇我在一台云服务器上测了 Rayls 的证明代码，但数字只来自一种机器，测试代码也没放在读者能直接复现的地方。这次我把测试代码公开到 GitHub，让 GitHub 自己的服务器替我跑，换了三种 CPU，日志谁都能点开看。
先给短答案。以 Rayls Enygma 隐私转账电路的 6 人匿名集为例，一笔转账的零知识证明只用 1 个 vCPU 时要 1.55 到 1.95 秒，在 4 个 vCPU 上要 0.63 到 0.71 秒，验证这个证明只要 1 毫秒左右。服务第一次处理某一档转账时，还要额外花 1.9 到 2.9 秒把证明密钥读进内存。按串行处理请求算，一台 4 vCPU 的云服务器每秒能出 1.4 到 1.6 个证明。
下面讲这些数字是怎么来的、在哪里能复现，以及它们对一家机构要准备多少机器意味着什么。
隐私转账为什么要"算"
零知识证明可以理解成一张数学凭证：付款方不公开余额、金额和对手方，也能向网络证明这笔账是对的。代价在生成这张凭证上。Rayls 的 Enygma 用的是 Groth16 证明系统，它的特点是证明很小、验证很快，生成却要做大量椭圆曲线运算。所以"隐私要多少算力"这个问题，实际问的是生成证明要多久。
这里的 k 是匿名集大小。一笔转账会给 k 个参与方各生成一个金额承诺，真正的收款方藏在其中，旁人看不出是谁付给了谁。k 越大藏得越深，电路也越大。Rayls 仓库自带的压力测试脚本用的是 k=6，所以下文主要看 k=6。
这些结论不只适用于 Rayls。凡是用 Groth16 做隐私转账的系统，成本都落在同样的环节上，只是电路规模不同。
怎么测的，任何人都能复现
被测的是 Rayls 开源的证明服务 rayls-sovereign-gnark-api，提交 67c4c26。电路和证明代码一行没改。我的测试代码放在公开仓库 hansonhan0520-lang/enygma-bench，脚本会自动拉取这个提交，把测试文件放进它的电路目录，调用仓库自己的证明函数。
测试代码放进仓库后，由 GitHub 自己的云服务器（GitHub Actions）运行。每次运行的完整日志都自动提交到仓库的 results 文件夹，读者点 Actions 页面的 Run workflow 就能在自己的账号下再跑一遍。GitHub 文档写明，公开仓库的标准 Linux 运行器是 4 个 CPU、16 GB 内存，分 x64 和 arm64 两种。
本文用到三台机器，每台的 CPU 拓扑都由日志里的 lscpu 记录：
GitHub x64 运行器，Intel Xeon Platinum 8573C，4 个 vCPU，实为 2 个物理核、每核 2 个线程。
GitHub arm64 运行器，ARM Neoverse-N2，4 个 vCPU，4 个物理核、每核 1 个线程。
我自己的云端环境，Intel Xeon 2.1GHz，2 个物理核。
每台机器上，k=2 到 6 每一档先生成一个证明并用验证密钥验过，再连续计时 20 次取中位数，分别把可用的 vCPU 限定为 1 个、2 个、4 个各测一遍，我那台只有 2 个。GitHub 两台的数字来自 Actions 运行 37741247183，第三台来自同一天的本地运行，全文的数字和两张图都从同一份数据文件生成。
哪些是新的，这里说清楚。k=3 到 5 的测试数据沿用我上一篇写的生成器，它先逐字段复现了 Rayls 官方发布的 k=2 和 k=6 两组数据才被采用，这次没有改。这篇新增的是：公开可复现的测试仓库，两种新 CPU 上的 4 vCPU 测量，以及密钥加载时间的单独计时。
换 CPU 差多少
k=6 只用 1 个 vCPU 时的证明时间，Intel 8573C 是 1.55 秒，Neoverse-N2 是 1.81 秒，我那台 2.1GHz Xeon 是 1.95 秒，最慢的比最快的多 26%。用满全部 vCPU 后，两台 GitHub 机器分别是 0.71 秒和 0.63 秒，我那台用满 2 个 vCPU 是 1.37 秒。
验证时间在三台机器上都在 1 毫秒左右，从 0.98 到 1.28 毫秒。证明本身固定 164 字节，随证明一起传递的公开数据在 k=6 时是 1,612 字节，三台机器完全一致。
多核能快多少，取决于是不是真的核
这是这次最意外的结果。从 1 个 vCPU 到 2 个，两台 GitHub 机器都快了 1.88 到 1.89 倍，接近翻倍。但从 2 个到 4 个，两台分道扬镳：Neoverse-N2 又快了 1.51 倍，Intel 8573C 只快了 1.17 倍。
两台机器的差别在 lscpu 里写得很清楚。Neoverse-N2 的 4 个 vCPU 是 4 个物理核，Intel 8573C 的 4 个 vCPU 是 2 个物理核各跑 2 个线程。所以在 Intel 这台上，"从 2 个 vCPU 到 4 个"其实没有增加物理核，只是让每个核多跑一个线程。加速比和物理核数对得上，这是我从拓扑记录推出的解释，不同 CPU 的缓存和频率差异没有单独拆开。
同一个 x64 运行器标签，两次运行分到的硬件也不一样。同一天早些时候的一次运行分到的是 AMD EPYC 9V45，从 2 个 vCPU 到 4 个同样只快了 1.18 倍，但那次没记录拓扑，所以我不把它算作证据。读者自己复现时，x64 那台可能分到别的 CPU，看日志开头的 lscpu 就知道是哪种。
这条也修正了我自己。上一篇在我的云端环境测到 2 个 vCPU 平均只快 1.64 倍，当时没有说明这可能只是那台机器的情况。这次同一环境下 k=6 只快 1.43 倍，而两台 GitHub 机器接近 1.9 倍。所以"翻倍资源快不到两倍"更像是那台云端机器的特点，在另外两种 CPU 上并不成立。
第 6 个参与者的台阶，换了 CPU 还在
上一篇在单台机器上测到，k=5 到 k=6 这一步比前面每一步贵得多。这次三台机器都复现了。只用 1 个 vCPU 时，k=2 到 5 之间每加一个参与者平均多花 114 到 143 毫秒，而 k=5 到 6 这一步要多花 451 到 619 毫秒，是前面平均值的 3.5 到 5.0 倍。
原因和上一篇一样：约束数每多一个参与者固定增加 8,112 条，但证明系统按 2 的幂次分配计算空间，k=2 到 5 都在 65,536 以内，k=6 越过了这条线，计算空间变成 131,072。三台机器、两种指令集上，这个计算空间的数值完全相同，这次多出来的信息是：台阶出在电路本身，和 CPU 无关。
冷启动慢在哪
上一篇我测到服务第一次处理某一档请求要多花 2.5 到 4.5 秒，并把原因归到加载证明密钥上，但没有单独测量。评审指出了这一点。
这次我单独计时了服务首次请求时调用的两个加载函数，一个读约束系统，一个读证明密钥，和服务代码 handler.go 里用的是同一组函数。k=6 时，读证明密钥在三台机器上要 1.94 到 2.94 秒，读约束系统只要 0.05 到 0.08 秒。
把加载时间加上一次热请求的耗时，和实测的冷请求相比，两台 GitHub 机器相差 22 毫秒和 12 毫秒，我那台相差 0.2 秒。所以冷启动基本就是读证明密钥的时间。对部署的意义很直接：服务启动时预先加载五档密钥，或者先发一轮预热请求，第一笔真实交易就不会多等这 2 到 3 秒。
一家机构要准备几台机器
这一节是推算，不是测量。按串行处理请求，一台 4 vCPU 机器在 k=6 下每秒能出 1.41 个（Intel 8573C）到 1.58 个（Neoverse-N2）证明。
英国 CHAPS 在 2025 财年平均每天处理 210,483 笔，结算时间是每个工作日 06:00 到 18:00，摊到 12 小时里约每秒 4.87 笔，需要 3.1 到 3.4 台这样的机器。英格兰银行 2021 年 12 月的 RTGS 与 CHAPS 介绍里记载的单日纪录，是 2018 年 3 月 29 日的 320,034 笔，按同样窗口约每秒 7.41 笔，需要 4.7 到 5.3 台。美国 Fedwire 2025 年平均每天 869,187 笔，按每天 22 小时的运行时间约每秒 10.97 笔，需要 6.9 到 7.8 台。
这些数字只是证明生成算力的一阶估算，不是 Rayls 的结算吞吐量。它们没有计入日内高峰、网络和账本的开销，也没有测试同一台机器上多个证明并行跑的情况。另外，证明由发起转账的机构各自生成，负载分散在各家机构，而不是集中在一台服务器上。
还没定的部分
这次只测了转账电路，存款、取款和 DvP 电路没有测。密钥是用仓库自己的 groth16.Setup 在本地生成的，Rayls 仓库的说明也写明，仓库里那套密钥同样是单方生成的开发测试产物，生产部署需要另做多方可信设置；证明时间取决于电路结构，和密钥的具体数值无关。Rayls 生产环境用的是什么硬件、匿名集大小设为多少，公开资料里我没有找到，所以上面的机器数只能说明量级。
我的看法
一笔零知识隐私转账的算力账，量级其实不大：1 个 vCPU 两秒以内，4 个 vCPU 不到一秒，验证的开销几乎可以忽略。真正要留意的有两处。一是匿名集大小越过 2 的幂次那一档时，成本会突然跳一截。二是第一次请求要先读两三秒的密钥。
判断标准也很简单：任何人都可以打开 enygma-bench 仓库的 Actions 页面再跑一遍，看自己拿到的 CPU 上数字是否落在同样的范围。如果 Rayls 将来公布生产环境的证明硬件，就可以直接拿这套测试去对照。
参考来源：
Rayls 证明服务源码，raylsnetwork/rayls-sovereign-gnark-api，提交 67c4c26（2026 年 8 月 20 日）：https://github.com/raylsnetwork/rayls-sovereign-gnark-api/commit/67c4c26696016b48e70950e284ae1a51b7d0cf0e
本文测试代码与全部日志，Actions 运行 37741247183（2026 年 10 月 8 日）：https://github.com/hansonhan0520-lang/enygma-bench
GitHub 托管运行器规格（2026 年 10 月 8 日查阅）：https://docs.github.com/en/actions/reference/runners/github-hosted-runners
Fedwire Funds 2025 年统计（页面更新于 2026 年 1 月 26 日）：https://www.frbservices.org/resources/financial-services/wires/volume-value-stats/annual-stats.html
英格兰银行支付与结算统计，CHAPS 2025 财年日均笔数：https://www.bankofengland.co.uk/payment-and-settlement/payment-and-settlement-statistics
英格兰银行《RTGS 与 CHAPS 简介》（2021 年 12 月），CHAPS 单日纪录：https://www.bankofengland.co.uk/-/media/boe/files/payments/rtgs-chaps-brief-intro.pdf
#RLS #零知识证明 $RLS

我是从六月那批预承诺开始质押的,所以这套流程我已经走过一遍。这次开放给所有人,身边不少人问我该怎么操作、要注意什么,干脆一次写清楚。
先说变化本身。
Rayls 用的是委托权益证明,验证者跑节点、出块并保障公链安全,而普通持有者不需要自己跑节点,可以把手里的 RLS 委托给某个验证者,分享一部分质押奖励。
这个机制从六月就上线了,但当时只对参加过预承诺计划和流动性种子活动的钱包开放。那批人在主网之前就锁了币,官方给了三个月 55% 的加成年化,甚至往每个符合条件的钱包里发了 1 个 USDr,免得他们连 gas 都没有。
从 8 月 13 日周四开始,这扇门对每一个 RLS 持有者打开。
三步走,第二步最容易被忽略
流程本身不复杂。先通过 Stargate 把 RLS 跨链到 Rayls,然后在 Rayls dApp 上领取 USDr 作为 gas,最后到质押面板选验证者、输入数量、在钱包里确认交易。
中间那一步值得单独拎出来说。Rayls 公链的 gas 用的是 USDr,不是 RLS。所以你就算把币桥过来了,手里没有 USDr 一样发不出交易。官方当初给早期用户发 1 个 USDr,就是为了绕开这个卡点。现在轮到你自己去 dApp 的 gas 页面领。
两个费率档位
规则很直接。预承诺用户是 55%,普通用户是 18%。
促销档的 55% 绑定当初做预承诺的那个钱包地址,上限是你当初承诺的数量,预计跑三个月,到 9 月 9 日结束。到达上限之后,这个钱包不能再按促销档追加,多出来的 RLS 换一个钱包按通用档质押就行。
通用档就是现在开放给所有人的这一档,当前年化 18%,没有上限。官方说 18% 是刻意设在一个可持续的水平,之后会改成动态曲线:质押的人多、总量大,费率自然往下走;参与度低的时候费率上升,以此激励更多人来保障网络安全。
委托出去的币,到底在谁手里
这是我觉得最该讲清楚的一点,因为它直接关系到你敢不敢按下确认。
按官方说明,你委托的 RLS 会被锁进质押合约,并标记为分配给你选的那个验证者,它不会被转到验证者的钱包里。也就是说验证者拿不到你的本金,他能影响的是你的收益,以及在他作恶或掉线时可能触发的惩罚。
奖励从下一个奖励周期开始计算,用 RLS 发放。之后你可以随时回到面板领取奖励、追加质押,或者开始解押。
选验证者该看什么,以及我看到的
官方建议看几个指标:自质押量、已委托总量、剩余容量、当前年化、佣金比例。
我在 dApp 的质押面板上翻了一遍,当时看到的几个验证者自质押都是 500 万 RLS,委托量在 1948 万到 2303 万之间,年化都显示约 18%,佣金 0.00%,惩罚记录 0 次。节点位置分别标着俄亥俄、俄勒冈和东京。
佣金 0% 意味着现在验证者不从你的奖励里抽成,这个未必会一直维持,值得留意。剩余容量则决定了你能不能委托进去,热门节点满了就得换一个。
按确认之前,先看清这三件事
第一,解押不是即时的。你要先发起解押,这部分立刻停止计息,然后进入 14 天的解绑期,期满再回面板提取。这半个月里资金既不产生收益也动不了,这是最需要提前想清楚的一点。
第二,惩罚风险真实存在。官方在免责声明里写得很直白:如果你选的验证者作恶或长时间离线,你委托的 RLS 可能因罚没条件而损失。所以验证者不是随便点一个。
第三,年化会变。18% 不是承诺,官方明确说了奖励不保证、年化可能调整,而且后面还要转成动态曲线。
一点我自己的实际情况
我在实际操作时遇到一个小插曲,写出来供参考。
我用的钱包在把 Rayls 网络加进去之后,尝试连接时弹出了”该钱包不支持此网络”的提示,几个钱包条目都显示不可用,交易签不出去,自然也就没法完成委托。而在此之前,同样的操作是可以正常签名和质押的。
我没法判断这是钱包端的兼容问题还是别的原因,所以不下结论。如果你也遇到类似情况,可以换一个支持 Rayls 网络的钱包试试,或者到官方社区问一下当前的推荐配置。工具层面的问题通常比协议层面的好解决。
最后
这次开放本身的意义,官方那句话说得挺准:Rayls 是为银行和金融机构建的,但网络最终要由一个足够广的持有者群体来保障和拥有。从只对早期支持者开放,到所有人都能参与,这是朝那个方向走的一步。对普通持有者来说,它第一次提供了一个直接的方式,让手里的币参与到网络安全里,而不只是躺在钱包里等价格。
前提是你把上面那几件事看明白了再动手。
参考来源:Rayls 官方博客《Rayls staking opens to everyone this Thursday》(Alex Buelau,2026 年 8 月 11 日);Rayls 质押面板实际界面
#Rayls #RLS $RLS