Zum Inhalt springen
In EntwicklungTier APrivatsphäre

ConfidentialTransfer XLS-96

MPT-Salden und Transferbeträge sollen öffentlich verborgen und autorisiert prüfbar werden. ConfidentialTransfer ist laut xrpl.org in Entwicklung und noch nicht als Mainnet-Abstimmung gelistet. Eine stabile rippled-Version und die Validatorabstimmung stehen noch aus.

Fachlich geprüft am 31.07.2026 · Autor: Philip F. Schmitt

Status
In Entwicklung
XLS
XLS-96
Version
Offen
Aktiviert
Keine Angabe

Was ist der Entwicklungsstand?

Warum wird diese Funktion entwickelt?

Institutionelle MPT-Anwendungen benötigen nicht öffentliche Salden und Beträge, sollen aber autorisierten Parteien weiterhin überprüfbare Compliance-Nachweise geben.

Wie soll der Mechanismus funktionieren?

EC-ElGamal verschlüsselt Salden und Transferbeträge parallel für Halter, Emittent und optional einen Auditor. Kompakte Sigma-Proofs binden diese Chiffrate an denselben Wert, Bulletproofs belegen nicht negative Beträge, ohne sie offenzulegen. Ein getrennter Spending- und Inbox-Saldo verhindert veraltete Beweise; der Empfänger führt die Inbox vor dem Ausgeben ausdrücklich zusammen.

Was fehlt bis zum Mainnet?

Nach Implementierung und Tests muss die Änderung in einer stabilen rippled-Version erscheinen. Erst dann kann die Mainnet-Abstimmung beginnen.

Was ändert sich gegenüber dem Vorgänger?

VorherNachher
MPT-Salden und Überweisungsbeträge waren öffentlich lesbar.Eine dafür konfigurierte MPT-Ausgabe kann öffentliche und vertrauliche Salden parallel führen, während Gesamtmenge und Nachweisregeln prüfbar bleiben.

Für wen ist die Änderung relevant?

XRP-Halter und Nutzer

Halter können MPT-Beträge vertraulich senden, müssen aber einen separaten ElGamal-Schlüssel sichern und eingehende Beträge vor dem Ausgeben zusammenführen. XRP selbst wird nicht privat.

Wallets und App-Entwickler

Wallets erzeugen fünf neue Transaktionstypen, Chiffrate und Zero-Knowledge-Proofs. Sie müssen Inbox-Merge, Versionszähler und einen vom XRPL-Kontoschlüssel getrennten ElGamal-Schlüssel verwalten.

Börsen und Emittenten

Emittenten behalten Freeze- und Clawback-Optionen, wenn sie diese bei der Ausgabe vorbereiten. Ein optionaler Auditor-Key erlaubt unabhängiges Entschlüsseln von Haltersalden für Compliance.

Node-Betreiber

Validatoren prüfen Chiffrate, Sigma-Proofs, Bulletproofs und öffentliche Mengeninvarianten. Die Referenzmessung nennt ungefähr 19,6 Millisekunden für eine Proof-Verifikation im Mittel.

Welche Grenzen und Risiken bleiben?

  • Die Funktion gilt nur für entsprechend konfigurierte MPTs und nicht für XRP oder den gesamten Ledger.
  • Vertrauliche MPTs sind in dieser Fassung nicht mit DEX, AMM, Escrow oder Checks integriert.
  • Eine MPT-Ausgabe kann nicht gleichzeitig vertrauliche Transfers und eine positive TransferFee verwenden.
  • Der Protokollentwurf unterstützt nur einen optionalen On-Ledger-Auditor.
  • Der Emittent selbst darf keine vertraulichen Bestände seiner eigenen Ausgabe halten. Dafür braucht er ein separates normales Halterkonto.
  • Eingänge landen in einer Inbox und bleiben bis zum ausdrücklichen ConfidentialMPTMergeInbox nicht ausgebbar.
  • Der Verlust des ElGamal-Private-Keys macht den vertraulichen Bestand für den Halter unentschlüsselbar und unspendbar.
  • EC-ElGamal auf secp256k1 ist nicht quantensicher.
  • Das Aktivieren vertraulicher Beträge ist eine Einbahnstraße und kann danach nicht abgeschaltet werden.
  • Das Amendment ist ein Draft. Kryptografie, Gebühren und Implementierungsdetails können sich vor Mainnet ändern.

Welche Gebühren- und Performancewerte nennt die Spec?

  • ConfidentialMPTSend trägt mit Auditor rund 1.276 Byte reine Kryptodaten, ohne Auditor rund 1.210 Byte. Transaktionsheader und Metadaten sind darin nicht enthalten.
  • Der aggregierte Bulletproof ist 754 Byte groß. Das Proof-Bundle einer Send-Transaktion umfasst 946 Byte.
  • Die Referenzimplementierung misst etwa 44,8 Millisekunden für die Proof-Erzeugung und im Mittel etwa 19,6 Millisekunden für die Verifikation auf einer Laptop-CPU.
  • Die Referenzimplementierung berechnet für jede vertrauliche MPT-Transaktion das Zehnfache der normalen Basisgebühr.
Technische Details: Transaktionen, Felder, Codes und Invarianten

Transaktionen

  • ConfidentialMPTConvert (Typ 85)
  • ConfidentialMPTMergeInbox (Typ 86)
  • ConfidentialMPTConvertBack (Typ 87)
  • ConfidentialMPTSend (Typ 88)
  • ConfidentialMPTClawback (Typ 89)
  • MPTokenIssuanceSet

Ledger-Objekte

  • MPTokenIssuance
  • MPToken

Felder und Flags

  • IssuerEncryptionKey / AuditorEncryptionKey (33 Byte)
  • HolderEncryptionKey
  • ConfidentialOutstandingAmount
  • ConfidentialBalanceSpending / ConfidentialBalanceInbox
  • IssuerEncryptedBalance / AuditorEncryptedBalance
  • SenderEncryptedAmount / DestinationEncryptedAmount
  • AmountCommitment / BalanceCommitment
  • BlindingFactor
  • ZKProof
  • CB_S_Version
  • lsfMPTCanHoldConfidentialBalance 0x00000080
  • lsmfMPTCannotEnableCanHoldConfidentialBalance 0x00000080
  • tmfMPTSetCanHoldConfidentialBalance 0x00000040

Ergebnis-Codes

  • temMALFORMED
  • temBAD_CIPHERTEXT
  • temBAD_TRANSFER_FEE
  • tecBAD_PROOF
  • tecNO_PERMISSION
  • tecNO_AUTH
  • tecINSUFFICIENT_FUNDS
  • tecLOCKED
  • tecOBJECT_NOT_FOUND

Invarianten

  • ConfidentialOutstandingAmount liegt zwischen null und OutstandingAmount.
  • Convert und ConvertBack ändern den vertraulichen Gesamtbetrag exakt entgegengesetzt zum öffentlichen MPT-Betrag.
  • Vertrauliche Holder-Felder und der verschlüsselte Emittentenspiegel müssen gemeinsam vorhanden sein.
  • Ein initialisiertes MPToken-Objekt bleibt auch bei verschlüsseltem Nullsaldo ein Löschblocker.

Wie sieht ein konkreter Ablauf aus?

Ein Halter wandelt einen sichtbaren MPT-Betrag in einen verschlüsselten Inbox-Saldo um, führt ihn in den Spending-Saldo zusammen und sendet später mit einem Proof. Der Empfänger sieht den Betrag mit seinem Schlüssel, während Außenstehende nur gültige Chiffrate und die öffentliche Gesamtmenge prüfen.

Wie hängt dieses Amendment mit anderen zusammen?

Jede direkte Verbindung besitzt einen Typ, eine Erklärung und eine Primärquelle.

Wie geht es mit diesem Amendment weiter?

ConfidentialTransfer ist laut xrpl.org in Entwicklung und noch nicht als Mainnet-Abstimmung gelistet. Eine stabile rippled-Version und die Validatorabstimmung stehen noch aus.

Nach Implementierung und Tests muss die Änderung in einer stabilen rippled-Version erscheinen. Erst dann kann die Mainnet-Abstimmung beginnen.

Wo steht es in seiner Amendment-Familie?

Multi-Purpose Tokens: Protokollfolge

  1. MPTokensV1Aktiviert · ab rippled 2.3.0
  2. TokenEscrowAktiviert · ab rippled 2.5.0
  3. PermissionedDEXAktiviert · ab rippled 2.5.0
  4. fixMPTDeliveredAmountAktiviert · ab rippled 3.0.0
  5. fixTokenEscrowV1Aktiviert · ab rippled 3.0.0
  6. fixCleanup3_2_0Aktiviert · ab rippled 3.2.0
  7. DynamicMPTIn Entwicklung
  8. ConfidentialTransferIn Entwicklung
  9. MPTokensV2In Entwicklung

Welche Primärquellen belegen die Angaben?

← Alle XRPL-Amendments und XLS-Spezifikationen