rayls

Ich bin Agung, Rayls-Botschafter.
In letzter Zeit haben mich viele Menschen nach dem Unterschied zwischen tokenisierten Einlagen und Stablecoins wie USDT oder USDC gefragt. Diese Frage kommt oft von Menschen, die noch neu in der Blockchain-Welt sind, und ich halte es für wichtig, sie klar und ehrlich zu beantworten.
Ich habe diesen Artikel auf Grundlage von
@raylslabs
offiziellen Dokumentationen und Blogbeiträgen sowie meinen eigenen Beobachtungen beim Studium des Ökosystems geschrieben. Ich habe versucht, die Sprache so einfach wie möglich zu halten, damit auch diejenigen, die Rayls noch nicht kennen, den Ausführungen folgen können.

@Rayls öffnete am 15. Oktober 2026 Einzahlungen für seinen ersten Tresor. Statt nur die Ankündigung des Starts zu betrachten, untersuchte ich die Bridge-Aktivität, den Reservebericht, Änderungen am Prämienplan, tatsächliche Einzahlungstransaktionen und die Architektur des Tresor-Contracts, um zu verstehen, was die verfügbaren Belege tatsächlich zeigen.
Hier sind die wichtigsten Erkenntnisse 👇
🔹 1. Bridge-Aktivität und Token-Angebot
Die untersuchten Aufzeichnungen des Polygon-Bridge-Tresors wiesen 264,868.416247 BRL1 an eingehenden Transfers und 9,576.454346 BRL1 an ausgehenden Transfers aus. Daraus ergab sich ein Nettosaldo von 255,291.961901 BRL1.

@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

In den letzten Artikeln habe ich immer wieder gemessen, wie lange Rayls für seine Beweise braucht. Für Banken gibt es jedoch eine noch grundlegendere Frage: Wann ist Geld wirklich angekommen und kann nicht mehr zurückgeholt werden? Diese Woche habe ich die Richtung gewechselt und die Server von GitHub zwei Stunden lang gleichzeitig Ethereum und die öffentliche Rayls-Blockchain beobachten lassen, um zu sehen, wie sie diese Frage selbst beantworten.
Zuerst die kurze Antwort. Wenn Banken von „angekommen“ sprechen, meinen sie zwei Dinge: rechtliche Unwiderruflichkeit und technische Unumkehrbarkeit. Auf technischer Ebene liegen die Blöcke, die Ethereum-Knoten selbst als „finalisiert“ markieren, 12,6 bis 19,2 Minuten hinter dem neuesten Block zurück; der Median beträgt 16 Minuten. Die öffentliche Rayls-Blockchain markiert dagegen jeden Block direkt bei seiner Entstehung als finalisiert. Ein Block entsteht etwa alle 1,35 Sekunden. Diese „deterministische Finalität“ (deterministic finality) hat jedoch ihren Preis: Wenn der Konsens nicht weiter vorankommt, hält die Blockchain an, statt sich aufzuspalten. Seit dem Start der öffentlichen Rayls-Blockchain kam es mindestens zweimal zu einem Stillstand: einmal für 11,72 Stunden und einmal für 9,15 Stunden. Nach der Wiederaufnahme wurde in beiden Fällen direkt an den Block angeknüpft, der unmittelbar vor dem Stillstand entstanden war.

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

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.

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.

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.

$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

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

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