rayls

前几篇我一直在测 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 #区块链结算

Öffentliche Blockchains bieten Transparenz, aber Banken können nicht jede Finanztransaktion wie einen öffentlichen Social-Media-Beitrag behandeln. Kundenguthaben, Zahlungsbeträge und Gegenparteien können geschäftlich oder persönlich sensibel sein.
Die eigentliche Frage ist also nicht, ob Banken Blockchain nutzen sollten. Es geht darum, wie sie die Vorteile der On-Chain-Abwicklung nutzen können, ohne vertrauliche Finanzinformationen offenzulegen.
1. Warum gewöhnliche öffentliche Blockchains eine Herausforderung darstellen
Auf einer typischen transparenten Blockchain können Transaktionen Wallet-Adressen, Token-Beträge und Muster finanzieller Aktivitäten offenlegen. Auch wenn Adressen nicht direkt mit echten Namen verknüpft sind, können wiederholte Transaktionen Beobachtern mitunter dabei helfen, Aktivitäten bestimmten Akteuren zuzuordnen.

Bekomme ich meine Token zurück, wenn eine Übertragung bei Rayls fehlschlägt?
Was geschieht mit den auf der Ausgangsseite verarbeiteten Token, wenn eine Zieltransaktion bei einer Cross-Chain-Übertragung fehlschlägt? $RLS
Beim Transfer von Token auf eine andere Chain können die Vermögenswerte auf der Ausgangsseite gesperrt oder verbrannt werden. Schlägt die Verarbeitung auf der Zielseite fehl, ist jedoch ein Verfahren erforderlich, um den Zustand der Vermögenswerte wiederherzustellen.
Die offizielle Dokumentation von Rayls beschreibt einen Wiederherstellungsmechanismus für diesen Fall. Ein Blick auf den veröffentlichten Code zeigt jedoch weitere Punkte, die geprüft werden müssen.

Was ich bei der Untersuchung des Konsensmechanismus, der Abwicklungsarchitektur und der Transaktionsbelege von Rayls herausgefunden habe.
Ich begann mit einer einfachen Frage:
Wenn eine Blockchain eine Finalität innerhalb von weniger als einer Sekunde verspricht, bedeutet das dann, dass die gesamte Transaktion in weniger als einer Sekunde abgeschlossen ist?
Auf den ersten Blick mag die Antwort offensichtlich erscheinen. Eine Transaktion wird bestätigt, das Netzwerk erzielt Konsens und der Vorgang ist abgeschlossen.
Doch die Finanzinfrastruktur ist komplizierter als das.
Eine Transaktion kann auf einem Ledger festgeschrieben werden, während ein größerer Vorgang noch von einem anderen Ledger, einem Relayer, der Verifizierungsprüfung oder der Ausführung auf der Zielseite abhängt.

$RLS
Als ich mir den Rayls-Relayer-Code erneut ansah, fiel mir etwas Merkwürdiges auf.
Wenn der Relayer die Nachricht übermittelt, müsste er dann nicht auch die RELAYER-Berechtigung für "executeMessage()" haben?
Als ich mir jedoch den tatsächlichen Code ansah, stellte sich heraus: nein.
Rayls trennt vielmehr die Berechtigung zum Übermitteln einer Nachricht von ihrer tatsächlichen Ausführung.
Auf der Public Chain ist "PublicRNEndpoint.receivePayload()" die erste Stelle, an der der Relayer ins Spiel kommt.
An dieser Stelle wird die Nachricht nicht direkt ausgeführt, sondern

Die Blockchain bietet Finanzinstituten etwas, das sie dringend benötigen: nachweisbare Abwicklung, ohne vollständig auf eine geschlossene Datenbank angewiesen zu sein.
Aber es gibt ein offensichtliches Problem.
Banken können nicht einfach alle Transaktionsdetails auf einer öffentlichen Blockchain speichern.
Kontostände, Gegenparteien, Transaktionsbeträge und andere vertrauliche Informationen müssen möglicherweise privat bleiben – während Aufsichtsbehörden, Gegenparteien und das Netzwerk dennoch genügend Nachweise benötigen, um zu überprüfen, dass tatsächlich etwas geschehen ist.
Wie lassen sich also Datenschutz und Nachweisbarkeit gleichzeitig erreichen?

In der vorherigen Arbeit habe ich den von Rayls veröffentlichten Beweiscode einmal durchlaufen lassen und gemessen: Bei einem Anonymitätsset von 6 Personen dauert es pro Beweis 1,96 Sekunden. Aber in dem Artikel gibt es drei Sätze, die eher Schlussfolgerungen als Messungen sind – das weiß ich in meinem Kopf. Diese Woche habe ich die Maschine auf 2 Kerne umgestellt und noch ein paar zusätzliche Messdaten nachgereicht, und bin dadurch zurückgegangen, um diese drei Sätze zu ergänzen.
Zuerst klarstellen, wie diese Arbeit zur vorherigen steht, damit Leser nicht denken, es sei ein erneutes Hochladen desselben Artikels. In der vorherigen Arbeit habe ich die Beweiszeiten in einer Single-Core-Umgebung für die 2-Personen- und die 6-Personen-Stufe gemessen. Diese beiden Zahlen wurden hier erneut gemessen und sind fast unverändert. Alles Neue in diesem Artikel sind genau die drei Dinge, die in der vorherigen Arbeit nicht gemessen werden konnten und nur geschlussfolgert wurden.

Ich denke, bei Ankündigungen zu Sperrungen geht man meistens nur einer Frage nach: Ob sich dieses Versprechen irgendwie verifizieren lässt. Bei den meisten Projekten endet das „Team-Sperrung“ letztlich bei einem einzigen Satz – man kann nur glauben oder nicht glauben. Diesmal ist es etwas anders, also habe ich mir das On-Chain angesehen.
Zuerst die Fakten klarstellen: Parfin ist der zentrale Technologiepartner hinter Rayls. Es entwickelt die Privacy-Nodes, das private Netzwerk, das Enygma-Privacy-Framework und die Rayls-Blockchain. Als Vergütung für die Arbeit vor dem TGE erhielt es 1.070.493.535 RLS-Token, etwa 11% der anfänglichen Gesamtmenge von 1 Milliarde Token.
Diese Tokens wurden zuvor bei einer institutionellen Verwahrstelle auf Ethereum aufbewahrt. Der Grund ist ganz praktisch: Zum Zeitpunkt des TGE lief die Rayls-Chain noch nicht, sodass die Tokens zunächst verwahrt werden mussten. Jetzt ist die Chain verfügbar, und diese Tokens wurden auf die Rayls-Chain migriert, in einen öffentlich verifizierbaren Smart Contract gesperrt und gleichzeitig wurde die Entsperrzeit von Dezember 2026 auf Dezember 2027 verschoben.

Ganz ehrlich: Als ich diese drei Abkürzungen zum ersten Mal nebeneinander gesehen habe, dachte ich, sie wären drei Antworten auf dieselbe Aufgabe – wer ist am schnellsten, wer am sichersten, man wählt einfach eine aus und fertig. Später habe ich verstanden, dass es, sie zusammen zu bewerten, ist wie die Frage: „Welches Werkzeug ist am besten – Hammer, Schraubendreher oder Schraubenschlüssel?“ Die Antwort hängt davon ab, ob du einen Nagel, eine Schraube oder eine Bolzenverbindung hast.
Die jeweils gelösten Probleme sind eigentlich drei, die man fälschlicherweise miteinander vermengt hat.
Das erste Problem lautet: Ich möchte beweisen, dass etwas wahr ist, aber die Daten, die man dafür braucht, sind sehr sensibel, und ich will sie dir nicht zeigen. Die Bank möchte gegenüber der Aufsicht darlegen: „Diese Transaktion ist rechtmäßig, die Genehmigungen sind korrekt und es gibt keine doppelten Posten“, aber sie möchte weder den Betrag noch die Zahlungsparteien in die Buchführung aufnehmen. Dieses Bedürfnis, dass das Ergebnis wahr ist, ohne die Daten offenzulegen, ist das Spielfeld von ZK. Der Clou daran ist, dass die Gewähr aus der Mathematik kommt und nicht aus „Ich verspreche dir, dass ich es dir zeige, aber du darfst es nicht sehen“; die Aufsicht oder ein Audit, das den Verifikationsschlüssel erhält, kann das Ergebnis prüfen, aber es kommt nicht an die zugrunde liegenden Daten. Der Preis ist ebenso real: ZK ist stark darin, Eigenschaften von Daten zu beweisen, aber es ist nicht gut darin, dass mehrere Parteien gemeinsam rechnen, obwohl jede Partei keine vollständigen Daten hat, und es ist rechenintensiver als Klartext.

Brüder, ich habe mich schon lange in der Rayls-Community versteckt. Ich weiß, dass viele von euch mit dem Team sehr unzufrieden sind. Genauso bin auch ich unzufrieden, aber das Team macht wirklich seine Arbeit und gibt sein Bestes. Nur geht das Rayls-Team den Weg der Compliance. Brüder, gebt auf keinen Fall auf. Überlasst alles der Zeit. Ich glaube, dass das Rayls-Team am Ende die Prüfungsarbeit liefern wird, die uns zufriedenstellt. Ich möchte euch noch gute Nachrichten teilen: Es geht darum, dass das Rayls-Team kürzlich RPC angebunden hat. Das ist eine sehr wichtige Sache!!
Schneller Überblick
Was ist RPC
Du kannst RPC so verstehen, als eine spezielle Direktleitung, die Anwendung und Blockchain miteinander verbindet.

Im Lieferantenvergleich von Rayls gibt es neun Zeilen, und ich habe die Zeile „Datenschutz“ ausgewählt. Der Grund ist ganz einfach: Datenschutz ist wichtig, und Besu ist Open Source—seine Dokumentation und seinen Code kann ich nachschlagen.
Im Vergleichsblatt setzt Rayls in den beiden Zeilen „isolationsernder Datenschutz“ und „kryptografischer Datenschutz“ jeweils ein Häkchen, während Besu nur in der ersten Zeile ein Häkchen hat. Ich wollte das in der eigenen Dokumentation des jeweiligen Anbieters verifizieren, also habe ich die Dokumentation von Besu nachgeschlagen und dann seinen Code heruntergeladen und die Zahlen durchgezählt.
Die Schlussfolgerung lautet nicht „Besu geht nicht“. Der wirkliche Unterschied ist: Diese beiden Anbieter setzen den Datenschutz auf unterschiedliche Ebenen, und Besu hat den Zeitpunkt dafür viel früher verlagert, als viele Menschen denken.

In der Krypto-Szene kann man jede Woche „irgendein bekannter Großanleger aus dem traditionellen Finanzsektor dringt in die Blockchain ein“ sehen. Ich wische solche Schlagzeilen im Grunde zuerst weg, denn die überwältigende Mehrheit endet am Ende in einem Innovationslabor: Pressemitteilung raus, danach gibt es nichts mehr. Ob das stimmt oder nicht, hat einen ziemlich schlichten Maßstab: Kann ein normaler Kunde in seiner eigenen App direkt darauf klicken und es nutzen?
XP Inc. Diese Standards wurden diesmal erfüllt.
Zuerst muss man diese Firma klar einordnen, denn die Größe bestimmt das Gewicht der Sache. XP ist eine in den Nasdaq gelistete brasilianische Investmentplattform, die Aktie läuft unter dem Ticker XP. Ich habe die Daten auf der Investor-Relations-Seite geprüft: für das 1. Quartal 2026. Kundenvermögen im Bereich von rund 152,9 Milliarden BRL, genauer gesagt 1,529 Billionen BRL; Berater über 18.000; im letzten 12-Monats-Zeitraum Gesamterlöse von 19,8 Milliarden BRL, Gewinn vor Steuern 5,8 Milliarden BRL.

Am 19. September schickte Rayls einen Beitrag mit dem Titel „(Privacy has a price)“. Darin stand im Titel „honest math“, aber der ganze Text lieferte nur einen Zahlenbereich: Ein Beweis braucht von ein paar hundert Millisekunden bis zu ein paar Sekunden. Ich schreibe seit Wochen an Rayls’ Privacy-Architektur, und diesmal teile ich mit euch neue Inhalte. Ich habe mir den veröffentlichten Beweiscode heruntergeladen, ihn praktisch ein paar Dutzend Mal laufen lassen und teile mit euch dieses spannende Ergebnis!
Zuerst: Worum ging es im Blog? Die Kernthese lässt sich auf zwei Sätze verdichten. Der erste Satz lautet: Wo entstehen die Kosten? Vertrauliche Transaktionen sind teurer als transparente – teuer ist vor allem die Generierung von Zero-Knowledge-Beweisen; das Verifizieren ist hingegen günstiger. Ein Beweis für eine grundlegende vertrauliche Überweisung dauert auf gewöhnlicher, kommerzieller Hardware ein paar hundert Millisekunden bis zu ein paar Sekunden. Der zweite Satz lautet: Was sollte man fragen? Institutionen sollten nicht nur nach TPS fragen, sondern danach, wie hoch der Durchsatz ist, wenn man den eigenen Bedarf an Privatsphäre und Prüf-/Auditierbarkeit sowie echte Workloads berücksichtigt. Der Blog meint, dass das Volumen zwischen Banken nicht groß ist und damit völlig im Rahmen der Leistungsfähigkeit von Systemen für vertrauliche Abwicklung liegt.

Als ich das letzte Mal den XP-Artikel geschrieben habe, hatte ich eine Frage, die mich nie losgelassen hat: Wie genau nimmt ein institutioneller Stablecoin wie USDPX nach seiner Ausgabe eigentlich an einer echten grenzüberschreitenden Abwicklung teil? Dieser Beitrag soll diese Lücke schließen und mir nebenbei auch geholfen, zum ersten Mal einen Begriff zu verstehen: „Stablecoin-Dreischichtung“.
Erst mal diesen Begriff erklären: Er ist eigentlich sehr anschaulich. Eine grenzüberschreitende Zahlung: An beiden Enden gibt es die jeweilige Landeswährung, in der Mitte befindet sich eine Schicht aus sogenannten öffentlich gehandelten Stablecoins. Der Absender tauscht seine Landeswährung in einen USD-Stablecoin, der Stablecoin erledigt dann die grenzüberschreitende Abwicklung direkt auf der Blockchain, und der Empfänger tauscht ihn anschließend wieder in seine eigene Landeswährung um. Sieht das nicht aus wie zwei Scheiben Brot mit dieser Schicht dazwischen? So wird diese Formulierung in der Branche verwendet, um die grenzüberschreitende Abwicklung von Stablecoins zu beschreiben.

Ich habe mit dem Staken angefangen, seit der Charge an zugesagten Vorab-Zugängen im Juni. Daher bin ich diesen Prozess bereits einmal durchgegangen. Diesmal wird er für alle geöffnet. In meiner Umgebung haben viele gefragt, wie man das macht und worauf man achten sollte – also schreibe ich es gleich einmal komplett und klar auf.
Erst einmal zu den Veränderungen selbst.
Rayls nutzt ein delegiertes Proof-of-Stake: Verifizierer betreiben Knoten, produzieren Blöcke und sorgen für die Sicherheit der öffentlichen Kette. Normale Inhaber müssen keine eigenen Knoten betreiben. Sie können ihre RLS, die sie halten, an einen bestimmten Verifizierer delegieren und einen Teil der Staking-Belohnungen teilen.
Dieses Mechanismus ging schon im Juni online, aber damals war er nur für Wallets verfügbar, die am Pre-Commitment-Programm und an den Liquiditäts-Seed-Aktivitäten teilgenommen hatten. Diese Gruppe hatte ihre Coins sogar schon vor dem Mainnet gesperrt. Offiziell gab es für drei Monate eine Zusatzvergütung von 55% jährlicher Rendite – sogar wurden 1 USDr an jedes Wallet mit erfüllten Voraussetzungen ausgegeben, damit sie nicht einmal Gas dafür brauchen.

Ich habe schon in der Vorab-Commit-Phase damit begonnen, RLS zu staken. Unter der Woche lese ich meistens die offiziellen Blogs, um herauszufinden, ob sich meine Position wohl verändert. Der Artikel über Quanten vom 30. August ist anders: Er erklärt durchgehend, wie Institutionen Beschaffungen durchführen—mit meiner Situation als Privatanleger hat das nichts direkt zu tun. Aber ich habe ihn trotzdem bis zum Ende gelesen, weil er gleich am Anfang eine ziemlich harte Regel aufstellt, und diese Regel hat mich später wieder zurück auf den Artikel über mich selbst gebracht.
Diese Regel ist wie folgt: Eine Behauptung über „Quanten­sicherheit“ ist keine echte Aussage, wenn nicht klar angegeben wird, welcher konkrete Standardisierungs-Algorithmus verwendet wird und auf welcher Parameter-Ebene—dann ist es nur ein Etikett.

Im vorherigen Beitrag habe ich erklärt, worum es beim Staken und beim Open-Pool selbst geht. In den Rückmeldungen fragten viele Brüder jedoch immer wieder dieselbe Sache: Wie macht man das ganz konkret? Deshalb bin ich diesmal den kompletten Ablauf von Anfang bis Ende noch einmal Schritt für Schritt durchgegangen, habe mir jede einzelne Etappe und auch alle Stellen notiert, an denen es leicht hakt – du musst es einfach so nachmachen.
Hier ist der Link zum vorherigen Beitrag: 质押开放给所有人了,但有几件事最好先知道
Sag zuerst klar, für wen dieser Artikel gedacht ist. Wenn du Rayls noch nie genutzt hast und mit Begriffen wie Wallet und Bridging noch nicht wirklich vertraut bist, dann ist dieser Artikel genau für dich geschrieben. Zu jedem Fachbegriff erkläre ich dir nebenbei noch kurz, was er bedeutet.

Ich habe mit dem Staking von RLS schon in der Phase der Zusagen begonnen; es war einfach zur Gewohnheit geworden, die offiziellen Materialien durchzugehen. Nachdem der Name „Sovereign“ aufkam, blieb die Diskussion größtenteils bei der Frage: „Ist das nicht nur ein neuer Name?“ Ich finde, die Frage ist falsch gestellt. Der Name ist nicht wichtig; wichtig ist, was darunter ausgetauscht wurde, und wie viel eine Institution bei der Due Diligence selbst prüfen und nachvollziehen kann. In diesem Beitrag habe ich jedes einzelne Zahlenbeispiel mit einer konkreten Quelle versehen. Du kannst das Ganze Schritt für Schritt genau so replizieren.
Zuerst eine Sache vorweg: Letzte Woche habe ich einen Artikel über Prüfbarkeit/„Auditability“ geschrieben. Es ist möglich, dass manche Leser ihn gesehen haben, daher hier noch ein Hinweis.
Der Großteil dessen, was in diesem Beitrag steht, ist neu: es stammt aus dem Code-Repository von Axyl, den Audit-Verzeichnissen innerhalb des Repos sowie aus der Dokumentseite zu den Axyl-Performance-Benchmarks. Diese drei Stellen hatte ich zuvor nicht berührt. Nur das kleine Kapitel zur Key-Delegation knüpft an die Schlussfolgerungen aus dem vorherigen Beitrag an; dort werde ich es entsprechend markieren. Ich trenne Neu und Alt, weil die Leser selbst zwischen „Was ich diese Woche herausgefunden habe“ und „Was ich vorher bereits recherchiert habe“ unterscheiden können sollen.