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 #区块链结算

توفر سلاسل الكتل العامة الشفافية، لكن لا يمكن للمصارف التعامل مع كل معاملة مالية كما لو كانت منشورًا على منصة تواصل اجتماعي عامة. فقد تكون أرصدة العملاء ومبالغ المدفوعات والجهات المقابلة حساسة تجاريًا أو شخصيًا.
لذا، فالسؤال الحقيقي ليس ما إذا كان ينبغي للمصارف استخدام سلسلة الكتل، بل كيف يمكنها الاستفادة من مزايا التسوية على السلسلة من دون كشف المعلومات المالية السرية.
1. لماذا تطرح سلاسل الكتل العامة التقليدية تحديًا
في سلسلة كتل شفافة تقليدية، قد تكشف المعاملات عن عناوين المحافظ ومبالغ الرموز وأنماط النشاط المالي. وحتى عندما لا تُربط الأسماء الحقيقية مباشرةً بالعناوين، قد تساعد المعاملات المتكررة أحيانًا المراقبين على ربط النشاط بجهات معينة.

إذا فشل التحويل في Rayls، فهل ستعود رموزي؟
إذا فشلت معاملة الوجهة في تحويل بين سلسلتين، فماذا يحدث للرموز التي عولجت في المصدر؟ $RLS
عند نقل الرموز إلى سلسلة أخرى، قد تُقفل الأصول أو تُحرق في سلسلة المصدر. لكن إذا فشلت المعالجة في الوجهة، فستكون هناك حاجة إلى إجراء لاستعادة حالة الأصول.
تشرح وثائق Rayls الرسمية آلية استعادة للتعامل مع هذا الوضع. لكن عند الاطلاع على الشيفرة المتاحة للعامة، تظهر نقاط إضافية تحتاج إلى التحقق منها.

ما توصلت إليه عند البحث في آلية الإجماع لدى Rayls، وبنية التسوية، وإيصالات المعاملات.
بدأت بسؤال بسيط:
إذا وعدت سلسلة بلوكتشين بنهائية المعاملات في أقل من ثانية، فهل يعني ذلك أن المعاملة بأكملها تكتمل في أقل من ثانية؟
قد تبدو الإجابة واضحة للوهلة الأولى. تُؤكَّد المعاملة، وتتوصل الشبكة إلى الإجماع، وتنتهي العملية.
لكن البنية التحتية المالية أكثر تعقيدًا من ذلك.
يمكن إتمام معاملة على دفتر أستاذ بينما تظل عملية أكبر معتمدة على دفتر أستاذ آخر، أو جهة ترحيل، أو التحقق من الإثبات، أو التنفيذ على الجانب المستقبِل.

$RLS
وأثناء مراجعة كود Rayls Relayer لاحظت ملاحظة غريبة واحدة.
إذا كان Relayer هو الجهة التي تُمرِّر الرسالة، فهل يجب أن يمتلك صلاحية RELAYER أيضًا في "executeMessage()"؟
لكن عند تتبّع الكود الفعلي تبيّن أن الأمر ليس كذلك.
بل إن Rayls كان قد فصل صلاحية تمرير الرسالة عن التنفيذ الفعلي.
في Public Chain، المكان الذي يدخل فيه Relayer لأول مرة هو "PublicRNEndpoint.receivePayload()".
هنا لا يقوم بتنفيذ الرسالة مباشرةً،

تمنح تقنية البلوك تشين المؤسسات المالية ما هي في أمسّ الحاجة إليه: تسوية قابلة للتحقق من دون الاعتماد كليًا على قاعدة بيانات مغلقة.
لكن هناك مشكلة واضحة.
لا يمكن للبنوك ببساطة وضع تفاصيل كل معاملة على سلسلة كتل عامة.
قد يلزم أن تظل الأرصدة والأطراف المقابلة ومبالغ المعاملات وغيرها من المعلومات الحساسة خاصة، في حين لا يزال المنظّمون والأطراف المقابلة والشبكة بحاجة إلى أدلة كافية للتحقق من وقوع المعاملة فعلًا.
فكيف يمكن تحقيق الخصوصية وإمكانية التحقق في الوقت نفسه؟

في المرة السابقة شغلت كود إثباتات Rayls المنشور، ووجدت أن فئة الـ6 أشخاص تحتاج 1.96 ثانية لكل إثبات. لكن في تلك المقالة كانت هناك ثلاث جمل استنتاج وليست قياسًا، وأنا كنت أعرف ذلك. هذه الأسبوع بدّلت الجهاز إلى 2 نواة وأضفت عدة شرائح بيانات، وبذلك رجعت لإكمال تلك الجمل الثلاث.
أوضح أولًا العلاقة بين هذه المقالة وتلك السابقة، حتى لا يظن القارئ أنها إعادة نشر لنفس المقالة. المقالة السابقة قيست زمن إثبات فئة الـ2 أشخاص وفئة الـ6 أشخاص في بيئة أحادية النواة، وتمت إعادة قياس الرقميْن هذه المرة تقريبًا بدون تغيير. المحتوى الجديد الكامل هنا هو تلك الأمور الثلاث التي لم تتمكن المقالة السابقة من قياسها بل كانت تضطر إلى استنتاجها.

أعتقد أن إعلانات الإقفال عادةً لا تهتم إلا بأمر واحد، وهو ما إذا كان يمكن التحقق من هذا التعهد. في أغلب المشاريع، ينتهي "إقفال الفريق" في النهاية إلى جملة واحدة؛ فلا خيار لك سوى أن تصدّق أو لا تصدّق. وهذه المرة الأمر مختلف قليلًا، لذلك قمت بالتحقق على السلسلة.
لنضع الحقائق أولًا بشكل واضح. Parfin هي الجهة التقنية الأساسية خلف Rayls، وهي مسؤولة عن تطوير عقد الخصوصية والعقد/الشبكة الخاصة وإطار Enygma للخصوصية وسلسلة Rayls العامة. وكمقابل عن العمل الذي تم قبل TGE، حصلت على 1,070,493,535 من رموز RLS، أي حوالي 11% من إجمالي المعروض الأولي البالغ 10 مليارات.
تم تخزين هذه الدفعة من الرموز المميزة سابقًا لدى جهة حافظة لدى مؤسسة على شبكة الإيثيريوم. والسبب عملي جدًا: خلال حدث TGE، لم تكن سلسلة بلوكتشين Rayls قد انطلقت بعد، لذلك كان لا بد من الإيداع لدى جهة حافظة. والآن أصبحت السلسلة العامة متاحة، تم نقل هذه الدفعة من الرموز إلى سلسلة Rayls العامة، وتم حبسها في عقد ذكي يمكن التحقق منه علنًا، كما تم تأجيل وقت فكّ القفل من ديسمبر 2026 إلى ديسمبر 2027.

بصراحة، أول مرة رأيت هذه الاختصارات الثلاثة مصطفّة معًا، ظننت أنها ثلاثة حلول لمسألة واحدة: أيّها أسرع، وأيّها أكثر أمانًا، اختر واحدًا وانتهى الأمر. لكنني فهمت لاحقًا أن ترتيبها معًا يشبه سؤال: "أيّ أفضل: مطرقة أم مفك براغي أم مفتاح ربط؟" فالإجابة تعتمد على ما إذا كانت لديك مسمارًا أم برغيًا أم صامولة برغيّ.
إن كلّ واحدٍ منها يحل في الواقع ثلاثة مسائل تمّ خلطها معًا.
المسألة الأولى هي: أريد أن أبرهن أن شيئًا ما صحيح، لكن البيانات المطلوبة لإجراء البرهان حسّاسة للغاية، ولا أريد أن أُظهرها لك. يريد البنك إبلاغ الجهة التنظيمية أن "هذه المعاملة قانونية، وأن التفويض صحيح، ولا توجد عمليات مكررة"، لكنه لا يرغب في إدراج المبالغ وأطراف الدفع/الاستلام في السجلات. إن هذا النوع من البرهنة على الحقيقة دون كشف البيانات هو الساحة المفضلة لـ ZK. جمالها يكمن في أن الضمان يأتي من الرياضيات، لا من عبارة من قبيل: "أعدك أنني لن أطلع على الأمر". يمكن للجهة التنظيمية أو المدقق التي تحصل على مفاتيح التحقق أن تتحقق من النتيجة، لكنها لا تتمكن من الوصول إلى البيانات الأساسية. أما الثمن فواضح أيضًا: فهي تتفوق في إثبات خصائص البيانات، لكنها لا تجيد احتساب النتيجة بحيث تعمل عدة جهات معًا وهي جميعًا لا تملك بيانات كاملة، كما أنها أكثر استهلاكًا للحوسبة من النص الصريح.

إخوتي، لقد كنت أتمركز في كمين داخل مجتمع Rayls باستمرار. أعرف أن الجميع غير راضٍ جدًا عن الفريق، وأنا أيضًا غير راضٍ، لكن الفريق يعمل حقًا ويجتهد دائمًا. فقط فريق Rayls يسير على طريق الامتثال. إخوتي، لا يجب أبدًا أن تستسلموا، ودعوا كل شيء للوقت. أؤمن أن فريق Rayls في النهاية سيُسلّم لنا ورقة/اختبارًا تكون مرضية لنا. سأشارككم الآن بعض الأخبار الجيدة. سأخبركم خبرًا سارًا: وهو أن فريق Rayls مؤخرًا قام بربط RPC. هذه مسألة مهمة جدًا!!
نظرة سريعة
ما هو RPC
يمكنك فهم RPC على أنه خط هاتفي مخصص بين التطبيق والبلوكشين.

يوجد تسع صفوف في جدول مقارنة مورّدي Rayls في الموقع، وقد اخترتُ الصف بعنوان «الخصوصية». والسبب بسيط جدًا: الخصوصية مهمة، وBesu مفتوح المصدر، ويمكنني مراجعة توثيقه وكوده.
في جدول المقارنة، يضع Rayls علامة في السطرين «الخصوصية المعزولة» و«الخصوصية التشفيرية»، بينما يضع Besu علامة في السطر الأول فقط. كنت أنوي التحقق عبر وثائق الطرف الآخر، لذلك بحثتُ في وثائق Besu، ثم حمّلت كوده وعددتُ الأسطر/الأجزاء بدقة مرةً أخرى.
الاستنتاج ليس «أن Besu لا يصلح». الفرق الحقيقي هو أن الشركتين تضعان الخصوصية في طبقات مختلفة، وأن Besu نقل ذلك في وقت أبكر مما يظن الكثيرون.

يمكنك كل أسبوع في عالم التشفير أن ترى ”عملاقًا ماليًا تقليديًا ما“ يدخل إلى عالم البلوك تشين. أنا الآن أرى أن هذا النوع من العناوين غالبًا ما يتم تمريره سريعًا؛ لأن الغالبية في النهاية تتوقف عند مختبرات الابتكار، وتنشر بيانًا صحفيًا ثم لا يحدث شيء بعدها. للتحقق من الحقيقة، يوجد معيار بسيط جدًا: هل يستطيع العميل العادي، من تطبيقه الخاص، أن يقوم بفتحه مباشرة ويستخدمه؟
شركة XP Inc. لقد اجتازت هذا المعيار هذه المرة.
أولًا، يجب توضيح هذه الشركة، لأن حجمها يحدد وزن هذه المسألة. شركة XP هي منصة استثمار برازيليّة مدرجة في بورصة ناسداك، ورمز السهم هو XP. تحققتُ من صفحة علاقات المستثمرين لديها من بيانات الربع الأول لعام 2026: إجمالي أصول العملاء حوالي 1,529 مليار ريال برازيلي؛ ودقيقةً هي 1.529 تريليون ريال. عدد مستشاري الاستثمار يتجاوز 18,000 شخص. وإجمالي الإيرادات خلال الاثني عشر شهرًا الماضية يبلغ 19.8 مليار ريال برازيلي، بينما الأرباح قبل الضريبة تبلغ 5.8 مليار ريال برازيلي.

19 سبتمبر، أرسل رايلز مقالًا (الخصوصية لها ثمن)، والعنوان فيه كلمة honest math. وفي كامل المقال، لم يقدم سوى نطاقًا للأرقام: كم تستغرق عملية إثبات واحدة من بضع مئات من الملّي ثانية إلى بضع ثوانٍ. لقد واظبت لأسابيع على كتابة مخطط/معمارية خصوصية رايلز، وهذه المرة أشارككم محتوى جديدًا. لقد قمت بسحب كود إثباته الذي نشره وتشغيله فعليًا عشرات المرات، وسأشارككم هذا الاستنتاج المثير للاهتمام!
لنبدأ بما الذي تحدث عنه في المدونة. يمكن تلخيص حجته الأساسية في جملتين. الجملة الأولى تتناول أين تكمن التكلفة: المعاملات السرّية أغلى من المعاملات الشفافة؛ ويقع هذا الغلاء في توليد إثباتات المعرفة الصفرية، بينما يكون التحقق أرخص. فإثبات تحويل سرّي أساسي على عتاد تجاري عادي يحتاج إلى عدة مئات من الملّي ثانية إلى بضع ثوانٍ. الجملة الثانية تقول ما الذي ينبغي السؤال عنه: لا ينبغي للمؤسسات أن تكتفي بسؤال TPS، بل يجب أن تسأل عن الإنتاجية ضمن مستوى الخصوصية والتدقيق/المراجعة الذي تحتاجه، وبمواجهة أحمال العمل الفعلية. وتعتقد المدونة أن حجم تسويات البنوك بين بعضها ليس كبيرًا، وأنه يقع بالكامل ضمن قدرات أنظمة التسوية السرية.

في المرة السابقة عندما كتبت مقال XP، ظلّت لدي فضولية حول سؤال واحد: بعد أن يتم إصدار عملات مستقرة مؤسسية مثل USDXP، كيف تشارك فعلًا في التسوية الحقيقية عبر الحدود؟ هذا المقال بمثابة إجابة على تلك الحيرة، وبالمناسبة جعلني أفهم للمرة الأولى كلمةً تُسمّى «ساندويتش العملات المستقرة».
أولاً اشرح هذا المصطلح؛ إنه فعليًا تصويري جدًا. تحويل دفع عبر الحدود بخط واحد: طرفا العملية هما العملة المحلية، وبينهما توجد طبقة من العملات المستقرة العامة. يقوم المُرسل بتحويل العملة المحلية إلى عملة مستقرة مرتبطة بالدولار، ثم تُنجز العملة المستقرة التسوية عبر السلسلة (البلوك تشين) للمعاملة عبر الحدود، وبعد ذلك يقوم المُستلم بتحويلها مرة أخرى إلى عملته المحلية. ألا يشبه ذلك شريحتين من الخبز تفصل بينهما طبقة في الوسط؟ هذا هو التعبير الذي بدأ المجال يستخدمه لوصف التسوية عبر الحدود باستخدام العملات المستقرة.

أنا بدأت بعملية الإيداع/الرهان (staking) من مجموعة يونيو الخاصة بالالتزامات المسبقة، لذا فهذه العملية مررت بها بالفعل مرة. هذه المرة تم فتحها للجميع؛ وفي محيطي كثيرون يسألونني كيف تتم العملية وما الذي ينبغي الانتباه له، لذا كتبتها مرة واحدة لتكون واضحة تمامًا.
قل أولاً التغيير نفسه.
يستخدم Rayls إثبات الحصة المفوّضة (delegated proof of stake)؛ حيث يقوم المدقّق بتشغيل العقد والتحقق وبناء الكتل وضمان أمان السلسلة العامة، بينما لا يحتاج مالكو الحصص العاديون إلى تشغيل العقد بأنفسهم. يمكنهم تفويض RLS الموجود لديهم إلى أحد المدققين، ومشاركة جزء من عوائد/مكافآت الرهان.
تم تشغيل هذه الآلية منذ يونيو، لكن في ذلك الوقت كانت متاحة فقط لمحافظ شاركت في خطة الالتزامات المسبقة وأنشطة سيولة البذور. تلك المجموعة قامت بقفل العملات قبل إطلاق الشبكة الرئيسية، وقدمت الجهة الرسمية نسبة سنوية إضافية قدرها 55% لمدة ثلاثة أشهر، وحتى أرسلت لهم 1 USDr لكل محفظة تستوفي الشروط، حتى لا يفتقروا إلى تكاليف الـ gas.

بدأتُ رهن RLS منذ مرحلة التعهّد المسبق، وأقرأ المدونة الرسمية عادةً فقط لأعرف ما إذا كانت مراكزي ستتأثر. أما المقال المنشور في 30 أغسطس عن الكمّيات فكان مختلفًا؛ إذ كان يشرح للمؤسسات، من البداية إلى النهاية، كيف تقوم بالشراء، ولم تكن له علاقة مباشرة بشخص مثلي من المستثمرين الأفراد. ومع ذلك قرأته حتى النهاية، لأنه وضع في بدايته قاعدة صارمة جدًا، وهذه القاعدة هي التي أعادتني لاحقًا إلى المقال نفسه.
القاعدة هي كالتالي: إذا كان هناك ادعاء بـ”الأمان الكمي“، ولم يُذكر بوضوح أي خوارزمية معيارية استُخدمت، وعلى أي مستوى من المعلمات، فهو ليس ادعاءً بل مجرد وسم.

في المقالة السابقة كتبت عن فتح/إتاحة الرهن نفسه. لكن في الخلفية، كان أكثر سؤال يتكرر من الإخوة هو الجملة التالية: كيف يتم ذلك عمليًا بالضبط؟ لذا هذه المرة، سلكتُ العملية من البداية إلى النهاية مرةً أخرى، ودوّنت كل خطوة وكل نقطة قد تسبب تعثّرًا. اتبع ما كتبته فقط.
رابط المقالة السابقة موجود هنا: 质押开放给所有人了,但有几件事最好先知道
أولاً، حدِّد لمن تم تقديم هذه المقالة. إذا لم تكن قد تعاملت مطلقًا مع Rayls، وحتى أنك غير معتاد على كلمات مثل المحفظة والجسر (bridging)، فهذه المقالة مكتوبة لك. سأشرح باختصار كل مصطلح تقني أثناء المرور عليه.