昨天不是刚亏吗 今天怎么又亏

前两篇我在一台云服务器上测了 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

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.

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.

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.

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.

Ich habe mit dem Staken von RLS bereits in der Phase der zugesicherten Vorbereitungen begonnen; offizielle Blogs zu lesen ist für mich mittlerweile Gewohnheit. Am 12. September gab es in diesem Beitrag über Nachprüfbarkeit einen Teil, in dem sechs Kriterien aufgelistet wurden—dort heißt es, dass die Mathematik alles durch Konstruktion vollständig erzwingt. Ich stimme dem zu, aber „vollständig durch Konstruktion erfüllt“ ist eine überprüfbare Aussage, kein nur zu glaubendes Argument. Deshalb habe ich eine Woche lang jede der sechs Punkte einzeln in öffentlich verfügbaren Quellcodes, technischen Dokumentationen und On-Chain-Schnittstellen nach den entsprechenden Belegen gesucht. Jetzt teile ich das mit euch.
Zuerst zu seiner Einordnung: Ich finde, das ist hilfreicher als die meisten Diskussionen darüber, ob Privatsphäre „entweder vorhanden oder transparent“ sein soll. Für Nachprüfbarkeit gibt es drei Wege: mathematisches Erzwingen—die Bedingungen sind in kryptografischen Konstruktionen enthalten; Hardware-Vertrauen—dabei geht es um die Integrität vertrauenswürdiger Ausführungsumgebungen; und Richtlinien-Zugriffskontrolle—wer was sehen kann, wird von den Konfigurationen des Betreibers bestimmt.

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 geschrieben, warum Banken nicht bereit sind, ein gemeinsames Hauptbuch mit Wettbewerbern zu führen. Nachdem ich damit fertig war, kam mir selbst eine Frage: Wenn jede Bank ihr eigenes Hauptbuch hütet – wie wird dann eigentlich eine Transaktion zwischen zwei Banken abgewickelt? Geld und Vermögenswerte werden jeweils in zwei Bücher eingetragen, die nicht miteinander verbunden sind. Das klingt so, als ließe sich das überhaupt nicht umsetzen. In diesem Beitrag möchte ich genau diesen konkreten Prozess erklären.
Den Link zum vorherigen Beitrag findest du hier: 《为什么银行不愿意和友商共用一个账本》
Zuerst muss die Situation klar festgelegt werden, sonst wird es zu abstrakt.
Nehmen wir an, es gibt zwei Banken innerhalb desselben Rechtsgebiets. Bank A will zahlen und nutzt dafür selbst ausgegebene tokenisierte Einlagen. Bank B muss einen tokenisierten Vermögenswert liefern. Beide Parteien sind nicht bereit, die Kundendaten, die Salden und die Geschäftslogik an die jeweils andere Seite zu übergeben – und auch nicht an irgendeinen externen Treuhänder. Das ist die typischste Form einer „Wert gegen Zahlung“-Transaktion, also das, was in der Branche als DvP bezeichnet wird.

Wenn Blockchain-Projekte über den Einsatz bei Institutionen sprechen, geht es normalerweise darum, dass „unsere Technik besonders fortschrittlich ist“. Dieses Mal ist Rayls’ Blogtext anders: Er verwendet den Großteil des Platzes darauf, Kundenbeschwerden darzustellen — und die sind ziemlich unmissverständlich. Nach dem Lesen habe ich das Gefühl, dass nicht die Produktliste das wirklich Wichtige ist, sondern dass das Unternehmen eine Sache anerkennt, die die Branche nur ungern zugibt.
Zuerst einmal gibt es an dieser Veröffentlichung selbst etwas Ungewöhnliches.
Rayls brachte am 25. August Sovereign heraus, eine private Blockchain für Finanzinstitute. Laut offizieller Darstellung läuft die zugrunde liegende Plattform jedoch seit Juni 2024 bereits in einer Produktionsumgebung; mehr als 30 Finanzinstitute seien damit bereits belegt und nutzen sie. Sovereign ist eine zuvorige Version von Rayls Privacy Node, die so gründlich umgebaut wurde, dass sie seinen Namen geändert hat.

监管新闻我一般扫一眼就过,因为大多和普通持有者没什么关系。这次英国这套规则我读完却改了看法,因为它有一个不太显眼的机制,会实实在在影响机构未来选择用哪条链。
先把时间线摆清楚,因为这决定了紧迫程度。
英国议会在 2026 年 2 月 4 日通过了相关法规,FCA 在 6 月 30 日发布了这套制度的核心内容,一共五份政策文件。授权通道在 9 月 30 日开启,而受监管活动的完整范围要到 2027 年 10 月 25 日才全面生效。

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

Die meisten Projekte sprechen von einem Mechanismus zur Vernichtung: „Wir werden wie viel davon verbrennen.“ Viel interessanter für mich ist jedoch der vorgelagerte Teil: Woher stammen diese verbrannten Token ursprünglich? Die Antwort auf dieses Design von Rayls hat mich etwas überrascht – ihr Ursprung ist tatsächlich eine Fiat-Zahlung.
Zuerst das Fazit. Der Startpunkt der gesamten Kette ist nicht die Krypto-Welt, sondern eine Fiat-Zahlung, die eine Institution in ihrem eigenen Land ausstellt.
Wenn Institutionen über Datenschutz-/Privacy-Nodes auf Rayls Geschäfte abwickeln, entstehen dafür Gebühren. Der zentrale Punkt ist, dass sie entweder direkt mit Fiat abrechnen oder sich dafür entscheiden können, mit USDr oder RLS zu zahlen.

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.

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.

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.

Ganz ehrlich: News zum Thema Kooperation überfliege ich normalerweise nur kurz und wische weiter. Neun von zehn sind ohnehin nur gegenseitiges Logo-Aufhängen. Aber diese hier habe ich stehen lassen und zu Ende gelesen, weil sie genau den banalsten – und teuersten – Abschnitt im Bereich grenzüberschreitender Zahlungen trifft.
Überweisungen ins Ausland dauern langsam, viele denken, es liege an „Netzwerk-Langsamlkeit“. Der eigentliche Grund ist jedoch noch banaler: Das Geld wird nicht „rübergeschickt“, sondern ist längst „dort geparkt“. Wenn eine Bank einem bestimmten Land zahlen möchte, muss sie üblicherweise im Voraus ein Konto bei der örtlichen Bank eröffnen und eine große Summe vorab einzahlen; Fachjargon: Nostro-Konto. Jede Zahlungsroute weltweit muss erst etwas Geld „festklemmen“, so wie man bei jedem Freund eine ganze Lage Bargeld hinterlegt, für den Fall, dass man eines Tages vorbeikommt und es braucht. Das Geld liegt auf dem Konto und bewegt sich nicht. Die Wechselkursschwankungen trägt man selbst. Eine grenzüberschreitende Zahlung ist oft erst nach ein paar Tagen abgeschlossen.

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.