TRONs Quantenplan könnte einige Wallets in der Lage lassen zu zahlen, aber nicht ihre Schlüssel zu ersetzen

Der Entwurf für das Quanten-Signaturdesign von TRON könnte einige migrierte Konten daran hindern, ihre Schlüssel zu ersetzen, nachdem die Netzwerkverwaltung das Signierungsschema deaktiviert hat, auf das sie angewiesen sind. Einige dieser Konten könnten jedoch weiterhin Zahlungen über eine separate Genehmigung tätigen.

Das Design umfasst einen möglichen Wiederherstellungsweg über ein zweites quantenresistentes Signaturschema. Um es zu nutzen, müssten die Inhaber die verbleibenden Schlüssel haben, um die bestehende Eigentümergrenze des Kontos zu erfüllen, das erforderliche Maß an Autorität, um Berechtigungen zu ändern. Ein Backup-Schlüssel, der nur für Zahlungen autorisiert ist, würde diese Reparaturkraft unerreichbar machen.

Das ist die praktische Frage hinter Justins Suns Quanteninitiative. Am 8. August 2026 sagte @justinsuntron, sein Ziel sei es, dass TRON das erste quantenresistente Blockchain-Netzwerk wird, und verwies auf Tests im Nile-Testnetzwerk. Diese datierte Ambitionsäußerung bildet den Hintergrund für ein Migrationsdesign, dessen Governance-Schalter später die Genehmigung für ein Signierungsschema zurückziehen können.

Stand 12. September bleibt TIP-899 als Entwurf gekennzeichnet. Die Softwareveröffentlichung von Nile am 30. Juni umfasste Implementierungen von Falcon-basiertem FN-DSA-512 und ML-DSA-44, die jeweils eigenen Aktivierungseinstellungen unterliegen. Jede Implementierung benötigt noch ihre eigene Governance-Genehmigung, bevor das Netzwerk ihre Signaturen akzeptiert.

Eine Überprüfung des Nile-Parameter-Endpunkts am 12. September ergab getAllowFnDsa512 mit einem Wert von 1. Die ML-DSA-Einstellung erschien ohne Wert und lieferte kein positives Aktivierungslesen. Die Hauptnetzantwort enthielt keine der Einstellungen. Entwickler hatten in ihrem Anruf am 15. Juli gesagt, dass der Zeitplan für das Hauptnetz unentschieden sei; die aktuellen Überprüfungen bestätigen keine Aktivierung des Hauptnetzes.

Ein Netzwerkwechsel trifft auf eine Kontogrenze

TIP-899 ermöglicht es der Governance, jedes vorgeschlagene Schema separat zu aktivieren oder zu deaktivieren. Die 27 gewählten Supervertreter von TRON regieren durch On-Chain-Vorschläge. Die vorgeschlagenen Schalter gehören zu diesem Prozess.

Die Aktivierungseinstellungen wurden ebenfalls umnummeriert. TIP-899 und die Nile-Implementierung verwenden die Codes 1000 und 1001, während die frühere Migrationsdiskussion weiterhin 99 und 100 enthält. Der Entwickleranruf vom 1. Juli erklärt, dass die größeren Zahlen gewählt wurden, um Konflikte mit zukünftigen Hauptnetznummerierungen zu vermeiden. Diese Zahlen identifizieren die vorgeschlagenen Einstellungen; die Aktivierung erfordert eine separate Governance-Entscheidung.

Auf Kontoebene stellt sich die Frage, welche Signaturen weiterhin akzeptabel sind. TRON weist Schlüsseln Gewichte zu und verlangt, dass die gültigen Unterzeichner einer ausgewählten Berechtigung ihre Grenze erreichen oder überschreiten. Der vorgeschlagene Quanten-Signaturweg verwendet dieselbe Berechnung der Berechtigung.

Es gibt ein folgenschweres Detail im Referenztransaktionsverifier: Eine Signatur aus einem deaktivierten Schema löst eine Ablehnung aus. Eine funktionierende Rückfalltransaktion muss daher akzeptierte Signaturen verwenden und die Signatur des deaktivierten Schemas weglassen, selbst wenn die verbleibenden Schlüssel genügend Gewicht haben.

Das Deaktivieren eines Schemas kann folglich einen Signierungsweg entfernen, ohne die konfigurierte Grenze des Kontos zu ändern. Nichts in diesem Schalter gewährt automatisch einem anderen Schlüssel die fehlende Autorität.

Die Berechtigungsdokumentation von TRON trennt die Eigentümerautorität von aktiven Berechtigungen. Die Eigentümerberechtigung kann jeden Vertragstyp autorisieren und die Berechtigungen des Kontos ändern. Eine aktive Berechtigung ist auf die ihr zugewiesenen Operationen beschränkt, wie z. B. Überweisungen.

Ein Berechtigungsupdate muss unter der bestehenden Eigentümerberechtigung unterzeichnet werden. Das macht die Eigentümerkonfiguration zentral für die Wiederherstellung: Ein Schlüssel, der in der Lage ist, eine Zahlung zu senden, hat nicht unbedingt die Macht, die Schlüssel des Kontos zu ersetzen.

Betrachten Sie eine Eigentümerberechtigung, die nur einen Falcon-Schlüssel mit Gewicht 1 und Schwelle 1 enthält. Während Falcon deaktiviert ist, kann diese Eigentümerberechtigung keine Übertragung oder Berechtigungsaktualisierung autorisieren. Eine separat konfigurierte aktive Berechtigung könnte jedoch weiterhin Transaktionen erlauben, sodass dies nicht unbedingt bedeutet, dass das gesamte Konto nicht ausgeben kann.

Das Beibehalten eines Schlüssels für die bestehende ECDSA-Signaturmethode von TRON zusammen mit Falcon stellt nicht immer den Zugriff wieder her. Bei ECDSA-Gewicht 1, Falcon-Gewicht 1 und Schwelle 2 sind beide Signaturen erforderlich. Nachdem Falcon deaktiviert wurde, kann das verbleibende ECDSA-Gewicht die Schwelle nicht erreichen.

Die folgenden Beispiele wenden die vorgeschlagenen Regeln auf hypothetische Konfigurationen an. Sie zeigen Abzüge von den dokumentierten Berechtigungs- und Überprüfungsregeln; es liegen keine beobachteten Sperrungen oder durchgeführten Rollback-Tests diesen Beispielen zugrunde. Angenommen, Falcon wurde deaktiviert, alle ML-DSA-Schlüssel wurden zuvor konfiguriert, ML-DSA bleibt aktiviert und sicher, und der Inhaber kann diese Schlüssel weiterhin verwenden.

Diese Ergebnisse betreffen die Signaturautorität; andere Transaktionsanforderungen gelten weiterhin. Die Unterscheidung funktioniert auch in die andere Richtung. Eine verbleibende ML-DSA-Eigentümerberechtigung könnte Transaktionen direkt autorisieren und eine deaktivierte Falcon aktive Berechtigung ersetzen.

Ein zweiter Quanten-Schlüssel hilft nur, wenn er handeln kann

Das Beispiel mit zwei Schemen für Eigentümer bewahrt einen quantenresistenten Weg zur Berechtigungsreparatur, wenn entweder Schlüssel unabhängig die Eigentumsschwelle erreichen können. Die Anforderung beider Schlüssel schafft eine Abhängigkeit von beiden Schemen, die verfügbar bleiben müssen. Die Schwelle bestimmt, welche dieser Eigenschaften ein Konto hat.

Auch ein klassischer Wiederherstellungsweg bewahrt nicht dasselbe Sicherheitsziel. Der Migrationsvorschlag besagt ausdrücklich, dass das Hinzufügen eines quantenresistenten Schlüssels keinen quantenmäßigen Schutz bietet, wenn ein ECDSA-nur Signaturset weiterhin die Schwelle erreichen kann. Ein ECDSA-nur Eigentümerweg kann auch eine quanten-geschützte aktive Berechtigung ersetzen.

Die relevante Konfiguration ist daher breiter als der Schlüssel, der für routinemäßige Zahlungen verwendet wird. Die Eigentümerautorität und jeder aktive Weg, der in der Lage ist, die geschützten Vermögenswerte zu bewegen, müssen zusammen betrachtet werden.

Eine entweder-Schema-Konfiguration hat auch eine Grenze: Sie bewahrt eine Alternative, nachdem ein Schema deaktiviert wurde, schützt jedoch nicht gegen ein kompromittiertes Schema, während dieses Schema weiterhin aktiviert und unabhängig autorisiert bleibt. Die Verfügbarkeit nach der Deaktivierung und die Widerstandsfähigkeit gegenüber einem weiterhin akzeptierten kompromittierten Schlüssel sind separate Eigenschaften.

Der Stand der Standards von ML-DSA hilft, seine Rolle im Design zu erklären. NIST hat am 13. August 2024 FIPS 204 finalisiert, das ML-DSA spezifiziert. NIST beschreibt die Standardisierung von Falcon weiterhin als im Gange. TIP-899 präsentiert ML-DSA als eine implementierte Alternative zur Standardisierung und Prüfungsrisiko von Falcon. Dies bietet einen alternativen Algorithmus, anstatt eine automatische Wiederherstellungserlaubnis zu gewähren.

Die verbleibende Arbeit geht über das Hinzufügen eines Signaturbuttons hinaus. TIP-899 fordert externe kryptografische und Implementierungsprüfungen, öffentliches Prüfmaterial und Bug-Bounty-Abdeckung vor der Aktivierung des Hauptnetzes. Die überprüften Vorschlagsmaterialien bieten keinen abgeschlossenen unabhängigen Prüfbericht.

Der Vorschlag und die Diskussion der Entwickler am 15. Juli identifizieren auch die Arbeit an der Wallet-Derivation, dem Keystore, dem SDK und der Anpassung von Hardware-Wallets. Die Implementierung im Testnetz und die Werkzeuge zur Schlüsselgenerierung belegen nicht, dass Verbraucher-Wallets oder Verwahrer bereits alle Migrations- und Wiederherstellungsoperationen durchführen können.

Eine nützliche Demonstration im Testnetz würde die Berechtigungen durch den Ausfall verfolgen: das Schema deaktivieren, eine Transaktion nur mit überlebenden Signaturen erstellen, zeigen, welche Überweisungen weiterhin autorisiert sind, und zeigen, ob der bestehende Eigentümer die betroffenen Schlüssel ersetzen kann. Das Ergebnis müsste mit der Konfiguration übereinstimmen, die die Benutzer tatsächlich halten.

Wenn beide vorgeschlagenen Quanten-Schemata deaktiviert wären und kein gültiges Signatur-Set den Eigentümer oder den relevanten aktiven Schwellenwert erreichen könnte, würden die beschriebenen Regeln keinen sofortigen normalen Weg bieten, um Schlüssel auszugeben oder zu rotieren. Das bedeutet jedoch keinen dauerhaften Verlust. Eine Wiederaktivierung der Governance oder eine spätere Protokolländerung wäre ein anderer Wiederherstellungsweg; der schnellere Notfallkanal und die Ideen zur Null-Wissen-Wiederherstellung bleiben außerhalb des aktuellen Rahmens dieses Vorschlags.

Für Wallets und Verwahrer würde die Zahlungscontinuity allein die zentrale Wiederherstellungsfrage unbeantwortet lassen. Eine Migrationskonfiguration benötigt einen überlebenden, vom Eigentümer autorisierten Weg, um Schlüssel zu ersetzen, sowie einen Weg, um Gelder zu bewegen, wobei beide Wege das Ziel der Quantenresistenz bewahren.

Dieser Inhalt wird nur zu allgemeinen Informationszwecken bereitgestellt und stellt keine finanzielle, Anlage-, Rechts- oder Steuerberatung dar. Alle erwähnten Ereignisse, Prämien, Online-Aktionen oder zugehörige Informationen sollten nicht als Empfehlung, Aufforderung oder Einladung zum Kauf, Verkauf, Handel oder anderweitigem Umgang mit Krypto-Assets betrachtet werden. Krypto-Assets sind sehr volatil und können zu Verlusten führen. Die Verfügbarkeit von WEEX Services, Produkten und zugehörigen Aktionen kann je nach Region unterschiedlich sein. Sie sind dafür verantwortlich sicherzustellen, dass Ihre Teilnahme mit geltenden lokalen Gesetzen und Vorschriften übereinstimmt.