Das XRP Ledger (XRPL) rückt näher an die Aktivierung eines Upgrades heran, das es Organisationen ermöglichen würde, die Kontrolle über ein einzelnes Konto auf mehrere delegierte Konten aufzuteilen und so die Macht jedes einzelnen operativen Schlüssels zu begrenzen.

PermissionDelegationV1_1 wurde für Organisationen entwickelt, die häufig Transaktionen abwickeln, aber keine Schlüssel in alltäglichen operativen Systemen einsetzen möchten, die ein gesamtes Konto kontrollieren könnten. Ein Stablecoin-Emitter benötigt beispielsweise möglicherweise ein System zur Genehmigung von Kundentrustlines (dem Mechanismus des Ledgers zum Halten emittierter Assets), ein weiteres zur Abwicklung von Zahlungen und eine stärker geschützte Einrichtung zur Verwaltung der Kontosicherheit. Die Änderung würde es erlauben, diese Aufgaben auf separate XRPL-Konten aufzuteilen.

Ihr „bankenartiges“ Element ist die Trennung der Verantwortlichkeiten. Sie bedeutet keine regulatorische Genehmigung oder eine bestätigte Übernahme durch eine Bank. Ein kompromittierter Delegierter könnte weiterhin innerhalb seiner zugewiesenen Rolle missbraucht werden, doch der Angreifer würde nicht automatisch jede Befugnis des Hauptkontos erhalten, was den potenziellen Schaden eines einzigen offengelegten operativen Schlüssels verringert.

XRPL würde jede Berechtigung onchain durchsetzen

Gemäß der XLS-75-Spezifikation ist das Konto, die Befugnis vergibt, der Delegierende (Delegator). Es übermittelt eine DelegateSet-Transaktion, die ein zweites Konto und die Aktionen benennt, die dieses Konto ausführen darf. Die Beziehung wird in einem Delegate-Ledger-Eintrag gespeichert.

Der Delegierte signiert mit seinen eigenen Schlüsseln, identifiziert das Konto, für das er handelt, und zahlt die Transaktionsgebühr. XRPL lehnt Anfragen außerhalb der erfassten Befugnis ab, und der Delegierende kann diese Befugnis später aktualisieren oder entfernen.

Die offizielle Dokumentation führt Transaktionstyp-Berechtigungen und engere granulare Berechtigungen auf, wobei jeder Delegierte höchstens zehn erhalten kann. Die verfügbaren granularen Kontrollen sind vordefiniert, sodass Organisationen nicht beliebige Einschränkungen erstellen können. Delegierte müssen zudem mit Mitteln versehene Konten unterhalten, während jede Delegierung ein Onchain-Objekt erzeugt, das die Owner-Reserve-Anforderung des Delegierenden erhöht – das Mindest-XRP-Guthaben, das ein Konto für jedes von ihm besessene Ledger-Objekt halten muss.

Sensible Befugnisse, einschließlich des Wechsels von Signaturschlüsseln oder der Ernennung neuer Delegierter, können nicht delegiert werden. Transaktionen, die nicht sofort in das offene Ledger eintreten können, scheitern ebenfalls, anstatt in die Warteschlange zu gelangen.

Neunundzwanzig Stimmen starteten einen bedingten Countdown

PermissionDelegationV1_1 trat am 21. September in seine 14-tägige Aktivierungsperiode ein, mit Unterstützung von 29 der 35 vertrauenswürdigen Validatoren des XRP Ledger, wie der Live-Änderungs-Tracker zeigt. Änderungen (Amendments) sind der integrierte Mechanismus des Ledgers zur Änderung seiner Regeln, und anhaltende Validator-Unterstützung bringt neuen Protokollcode auf das Mainnet. Mindestens 28 Validatoren müssen die Unterstützung aufrechterhalten; ein Fall darunter würde die Uhr zurücksetzen. CoinDesk berichtete von einer voraussichtlichen Aktivierungszeit am 5. Oktober um 11:18 UTC, sofern die Unterstützung ununterbrochen besteht.

Der Code existiert bereits in der XRPL-Serversoftware, kann aber vor der Aktivierung nicht im Mainnet verwendet werden. Die separate Änderung Batch V1.1 folgt demselben Zweiwochenprozess, betrifft jedoch verknüpfte Transaktionen und nicht die Kontobefugnis.

Delegierung ist kein Ersatz für Multisigning

Multisigning legt fest, wie viele genehmigte Parteien eine Aktion autorisieren müssen, während die Berechtigungsdelegierung begrenzt, welche Aktionen ein operatives Konto anfordern darf. Eine Organisation könnte beides kombinieren, indem sie einen Delegierten auf Zahlungen beschränkt und zugleich die Genehmigung jeder Zahlung durch mehrere Personen verlangt.

Nach einer Schlüsselkompromittierung kann Multisigning verhindern, dass ein einzelner gestohlener Signaturer das Genehmigungsschwellenwert erreicht, während die Delegierung die dem Angreifer verfügbaren Transaktionstypen selbst dann einschränken kann, nachdem das delegierte Konto kompromittiert wurde. Keine der beiden Kontrollen überprüft, ob die Geschäftsanweisung legitim ist.

Die ursprüngliche Version scheiterte vor dem Erreichen des Mainnets

Ein Community-Tester stellte fest, dass die erste PermissionDelegation-Implementierung unter bestimmten Bedingungen eine Transaktionsgebühr einem anderen Konto in Rechnung stellen konnte, selbst wenn die delegierte Transaktion unsachgemäß signiert war. Wiederholte Einreichungen mit hohen Gebühren könnten das XRP-Guthaben des Opfers reduziert haben, ohne dessen privaten Schlüssel offenzulegen.

Der Fehler wurde während der Tests entdeckt, und die Änderung wurde nie im Mainnet aktiviert. Die offizielle Sicherheitslücken-Disclosure meldete keinen Verlust von Live-Nutzermitteln.

Coindoo untersuchte bereits, warum Permission Delegation in überarbeiteter Form mit den xrpld-3.3.0-Änderungen zurückkehrte. Die neue Abstimmung zeigt, dass die Validatoren nun bereit sind, die Aktivierung des Ersatz-Features zu erwägen.

Die Aktivierung allein begründet keine institutionelle Übernahme

Wallets und Custody-Anbieter müssen weiterhin Schnittstellen zum Erstellen, Überprüfen und Widerrufen delegierter Befugnisse entwickeln. Es wurde keine namentlich genannte Bank-Implementierung angekündigt, und Institutionen bleiben dafür verantwortlich zu entscheiden, welche Konten welche Berechtigung erhalten.

Compliance-Entscheidungen würden ebenfalls außerhalb des Ledgers bleiben. Ein Unternehmen würde Identitätsprüfungen, Sanktionsprüfungen und Risikobewertungen weiterhin über eigene Systeme durchführen. XRPL würde durchsetzen, welcher Delegierte die resultierende Autorisierung übermitteln darf; es würde nicht bestimmen, ob der Kunde hätte genehmigt werden sollen.

Die Nutzung der Funktion würde über öffentliche Delegate-Einträge sichtbar sein, wobei die Verknüpfung einer Adresse mit einem Unternehmen freiwillige Offenlegung erfordern kann. Delegierte-Konten benötigen ebenfalls XRP für Reserven und Gebühren, doch die Aktivierung begründet kein Nutzungsvolumen oder eine automatische Nachfrage nach dem Token.

Die produktive Nutzung der nächste Test sein

Wenn die Validator-Unterstützung hält, werden die Belege aus Wallet-Integrationen, neuen Delegate-Einträgen und namentlich genannten Implementierungen kommen. Diese Signale werden zeigen, ob Organisationen eine Protokollebene-Trennung zwischen Kontoeigentum und alltäglichen Abläufen benötigen.

Die Abstimmung macht eingeschränkten Kontozugriff möglich. Ihr Wert hängt davon ab, wie eng die Organisationen diese Berechtigungen konfigurieren und ob sie die Funktion außerhalb von Demonstrationen nutzen.

Dieser Artikel dient ausschließlich Informationszwecken und stellt keine Finanz-, Rechts- oder Sicherheitsberatung dar. Validator-Unterstützung und Aktivierungszeiten können sich ändern.