RippleX arbeitet an einem Privacy-Upgrade f\u00fcr den XRP Ledger, das vertraulichere Zahlungen erm\u00f6glichen soll, ohne die Grundlogik des Netzwerks aufzugeben. Im Mittelpunkt stehen Zero-Knowledge-Technologien, vertrauliche Transfers f\u00fcr Multi-Purpose Tokens und eine Architektur, die Privacy, Auditierbarkeit und Performance miteinander verbinden soll. In Episode 25 von Krippenreiter TV erl\u00e4uterte Aanchal Malhotra, Head of Research bei RippleX, wie das Forschungsteam diese Themen einordnet und welche technischen Grenzen auf dem XRPL ber\u00fccksichtigt werden m\u00fcssen.<\/p>\n
Aanchal Malhotra, Head of Research bei RippleX, beschreibt die Arbeit am XRP Ledger als langfristig angelegte Grundlagenarbeit. Ihr Team besch\u00e4ftigt sich mit Kryptografie, Privacy, Konsens, Protokolldesign, Interoperabilit\u00e4t und DeFi. \u201eNachhaltige Wirkung entsteht nicht dadurch, dass man Hype hinterherl\u00e4uft\u201c, sagte Malhotra in dem Gespr\u00e4ch. \u201eSie entsteht durch Bauen, durch Fokus auf Sicherheit und auf die Grundlagen. Genau daran arbeiten wir.\u201c<\/p>\n
Der Privacy-Fokus ist dabei Teil einer breiteren Strategie, den XRPL f\u00fcr k\u00fcnftige Anforderungen vorzubereiten. Malhotra verwies auf kryptografische Primitive, Privacy-Grundlagen und Post-Quantum-Readiness. \u201eEin gro\u00dfer Teil unserer Arbeit besteht darin, den XRP Ledger zukunftssicher zu machen\u201c, sagte sie. \u201eWir denken dar\u00fcber nach, ob die richtigen kryptografischen Bausteine vorhanden sind, ob die Privacy-Fundamente stimmen und ob wir f\u00fcr die Post-Quantum-\u00c4ra bereit sind.\u201c<\/p>\n
Gleichzeitig betonte Malhotra, dass RippleX die urspr\u00fcnglichen Designentscheidungen des XRPL nicht als Altlast versteht. Der Ledger sei 2012 f\u00fcr schnelle, g\u00fcnstige und transparente Zahlungen konzipiert worden. \u201eDie architektonischen Entscheidungen, die damals getroffen wurden, waren f\u00fcr diesen Zweck richtig\u201c, sagte sie. \u201eMan h\u00e4tte damals nicht f\u00fcr kryptografische Primitive bauen sollen, die zu diesem Zeitpunkt noch gar nicht existierten. Jetzt haben sich die Dinge weiterentwickelt, und wir befinden uns an einem anderen Punkt.\u201c<\/p>\n
Zero-Knowledge-Proofs sollen auf dem XRPL nicht als Selbstzweck eingef\u00fchrt werden, sondern konkrete Funktionen erm\u00f6glichen. Malhotra erkl\u00e4rte das Prinzip anhand eines einfachen Beispiels: Wer eine Wohnung mieten wolle, m\u00fcsse heute oft Kontoausz\u00fcge offenlegen und damit mehr Informationen preisgeben als n\u00f6tig. \u201eZero-Knowledge-Proofs erlauben es, dieselbe Frage zu beantworten: Ja, ich habe genug Mittel\u201c, sagte sie. \u201eUnd man kann das mathematisch beweisen, ohne irgendetwas anderes offenzulegen. Das ist die St\u00e4rke der Kryptografie.\u201c<\/p>\n
F\u00fcr den XRPL geht es dabei vor allem um vertrauliche Transfers bei Multi-Purpose Tokens. Malhotra unterschied klar zwischen Privacy und vollst\u00e4ndiger Undurchsichtigkeit. \u201ePrivacy ist nicht der Feind, Opazit\u00e4t ist es\u201c, sagte sie. \u201eFinanzsysteme brauchen Schutz f\u00fcr sensible Informationen, aber sie brauchen zugleich \u00fcberpr\u00fcfbare Regeln und unabh\u00e4ngige Auditierbarkeit.\u201c Bei vertraulichen MPTs sollen Betr\u00e4ge und Balances verborgen werden k\u00f6nnen, w\u00e4hrend die Gesamtmenge eines Tokens \u00f6ffentlich \u00fcberpr\u00fcfbar bleibt. Auch Auditoren sollen Transaktionen unabh\u00e4ngig pr\u00fcfen k\u00f6nnen, sofern entsprechende Schl\u00fcssel vorgesehen sind.<\/p>\n
Technisch setzt RippleX f\u00fcr diesen spezifischen Anwendungsfall auf Bulletproofs, eine Form von Zero-Knowledge-Proofs. Der Grund liegt in ihren Eigenschaften: Sie ben\u00f6tigen kein Trusted Setup, sind f\u00fcr Range Proofs geeignet und gelten als gut erforscht. Malhotra machte aber deutlich, dass Bulletproofs nicht f\u00fcr alle ZK-Anwendungen passen. \u201eF\u00fcr diesen sehr spezifischen Use Case war Bulletproofs die richtige Wahl\u201c, sagte sie. \u201eAber es gibt einen Trade-off: Sie sind nicht gut f\u00fcr General Purpose. Dort kommen SNARKs ins Spiel.\u201c<\/p>\n
SNARKs sind f\u00fcr RippleX vor allem deshalb relevant, weil sie kompakte Nachweise f\u00fcr komplexe Offchain-Berechnungen erm\u00f6glichen. \u201eDie transformativere Eigenschaft von ZKPs ist die K\u00fcrze und die verifizierbare Berechnung\u201c, erkl\u00e4rte Malhotra. \u201eMan kann einen sehr kleinen Beweis f\u00fcr eine komplexe Offchain-Berechnung erzeugen und ihn anschlie\u00dfend effizient Onchain pr\u00fcfen.\u201c Dadurch k\u00f6nnten Layer-2-\u00e4hnliche Architekturen entstehen, bei denen komplexe Ausf\u00fchrung au\u00dferhalb des Mainnets stattfindet, w\u00e4hrend der XRPL als Settlement- und Verifikationsschicht dient.<\/p>\n
Gerade hier sieht Malhotra eine M\u00f6glichkeit, die St\u00e4rken des XRPL zu erhalten. Der Ledger schlie\u00dft alle drei bis f\u00fcnf Sekunden ein neues Ledger und ist auf niedrige Kosten ausgelegt. Teure Onchain-Berechnungen w\u00fcrden deshalb schlecht zur bestehenden Architektur passen. \u201eWenn man versucht, alles auf Layer 1 zu machen, vergr\u00f6\u00dfert man die Angriffsfl\u00e4che und verschlechtert die Performance\u201c, sagte sie. \u201eLayer 2 kann eine gute Antwort sein, wenn komplexe Teile ausgelagert und nur die Beweise auf Layer 1 gepr\u00fcft werden.\u201c<\/p>\n
Die Integration bleibt jedoch anspruchsvoll. Der XRPL unterst\u00fctzt klassische Signaturschemata wie secp256k1 und Ed25519, die f\u00fcr schnelle Zahlungen geeignet sind, aber nicht ideal f\u00fcr heutige ZK-Systeme. Auch bestehende Hash-Funktionen k\u00f6nnen in ZK-Circuits ineffizient sein. RippleX arbeitet deshalb an nativen Bausteinen, etwa vorkompilierten Operationen f\u00fcr pairing-freundliche Kurven, damit Entwickler ZK-Verifier effizienter bauen k\u00f6nnen. \u201eWir wollen nicht eine bestimmte Art von Verifier festschreiben\u201c, sagte Malhotra. \u201eWir wollen die grundlegenden mathematischen Operationen bereitstellen, damit unterschiedliche Verifier darauf aufbauen k\u00f6nnen.\u201c<\/p>\n