Nur zu Bildungszwecken; keine Anlage-, Rechts- oder Sicherheitsberatung. Ein Fehler bei der Unterzeichnerrotation kann die Kontrolle übertragen, ausstehende Genehmigungen ungültig machen oder ein Multisig-Konto dauerhaft sperren.
Direkte Antwort
Die Rotation von Multisig-Unterzeichnern ändert die Konten, die Transaktionen genehmigen dürfen. In der Regel sind weder eine neue Wallet-Adresse noch eine Vermögensübertragung nötig: Die Eigentümermenge des Kontos und manchmal sein Genehmigungsschwellenwert werden durch eine privilegierte Transaktion geändert. Implementierungen unterscheiden sich. Prüfen Sie daher den bereitgestellten Vertrag und den aktuellen On-Chain-Zustand, statt anzunehmen, dass Beschriftungen der Oberfläche die Befugnisse korrekt wiedergeben.
Eine sichere Rotation weist zuerst die Kontrolle über jeden neuen Unterzeichner nach, erhält während der Änderung ein ausführbares, aber nicht konzentriertes Quorum, entfernt den alten Unterzeichner und prüft den Endzustand auf der Chain. Geht das erforderliche Quorum vor der Ausführung verloren, kann eine normale Eigentümerrotation unmöglich werden. Eine aus Bequemlichkeit gesenkte Schwelle kann ein Übernahmefenster öffnen.
Person, Signiergerät, privater Schlüssel und On-Chain-Eigentümeradresse sind getrennte Datensätze. Dokumentieren Sie die genaue Adresse, den Verwahrer, den unabhängigen Kontrollbereich, den Sicherungsstatus und den Rotationsgrund. Bei keiner legitimen Rotation muss jemand eine Seed-Phrase oder einen privaten Schlüssel offenlegen.
Funktionsweise
- Aktuelle Befugnisse erfassen. Lesen Sie ausgehend von einer unabhängig geprüften Chain und Kontoadresse die bereitgestellte Implementierung, Eigentümerliste, Schwelle, Nonce, aktivierten Module, Guards, den Fallback-Handler, Wiederherstellungspfad und jeden Timelock aus. Ein Modul oder Wiederherstellungsmechanismus kann außerhalb der normalen Eigentümerschwelle ausführen, während ein restriktiver Guard eine sonst gültige Rotation blockieren kann.
- Zielzustand vor dem Signieren festlegen. Halten Sie die genaue Eigentümermenge und Schwelle nach der Änderung fest. Bestätigen Sie, dass die Schwelle die Eigentümerzahl nicht übersteigt und mindestens ebenso viele unabhängige Unterzeichner betriebsbereit bleiben. Räumliche Trennung ist keine Unabhängigkeit, wenn eine Person, ein Passworttresor, ein Cloud-Konto oder ein Administrator alle Geräte kontrolliert.
- Neuen Unterzeichner registrieren und authentifizieren. Erzeugen oder restaurieren Sie den neuen Schlüssel in seiner vorgesehenen Verwahrungsumgebung, prüfen Sie die Adresse auf einem vertrauenswürdigen Gerät und weisen Sie die Kontrolle durch eine vereinbarte Challenge oder Testsignatur nach. Bestätigen Sie die Adresse über einen zweiten authentifizierten Kanal; verlassen Sie sich nicht allein auf kopierten Chattext oder eine Wallet-Oberfläche.
- Reihenfolge mit sicheren Zwischenzuständen wählen. Manche Verträge können einen Eigentümer atomar ersetzen. Safe stellt beispielsweise
swapOwnersowieaddOwnerWithThreshold,removeOwnerundchangeThresholdbereit. Benötigt eine Implementierung mehrere Transaktionen, analysieren Sie Eigentümermenge und Schwelle nach jedem Schritt. Fügen Sie Kapazität hinzu und prüfen Sie sie vor dem Entfernen, sofern eine aktive Kompromittierung diese Reihenfolge nicht unsicher macht. - Exakte Transaktion dekodieren und simulieren. Prüfen Sie unabhängig Chain-ID, Kontoadresse, Ziel, Funktionsselektor, alte und neue Eigentümeradresse, resultierende Schwelle, Nonce, Wert und Operationstyp. Behandeln Sie
delegatecall, Batching, Moduländerungen und Guard-Änderungen als getrennte Hochrisikowirkungen. Jeder Unterzeichner sollte dieselbe dekodierte Nutzlast und denselben Transaktionshash genehmigen. - Mit bestehender Befugnis ausführen. Das aktuell gültige Quorum genehmigt die Rotation, sofern ein dokumentierter Wiederherstellungspfad nichts anderes vorsieht. Stimmen Sie sich im Notfall nur über authentifizierte Kontakte ab und verwenden Sie nicht kompromittierte Unterzeichner. Ist weder das normale Quorum noch eine vorkonfigurierte Wiederherstellungsbefugnis verfügbar, kann ein standardmäßiger Eigentümerverwaltungsaufruf den Zugriff nicht wiederherstellen.
- Änderung prüfen und abschließen. Fragen Sie nach der Bestätigung Eigentümermenge und Schwelle direkt ab, untersuchen Sie je nach Implementierung ausgegebene Ereignisse oder Traces und bestätigen Sie, dass die alte Adresse nicht mehr berechtigt ist. Lassen Sie den neuen Unterzeichner an einer genehmigten risikoarmen oder wertlosen Transaktion teilnehmen, welche die vorgesehene Schwelle erfordert. Prüfen Sie ausstehende Transaktionen, widerrufen Sie Off-Chain-Zugänge und Sicherungen des ehemaligen Unterzeichners und archivieren Sie Vorschlag, Signaturen, Transaktionshash, Block und Endzustand.
Durchgerechnetes Beispiel
Angenommen, ein 3-of-5-Konto hat die Eigentümer A, B, C, D und E, und B soll durch F ersetzt werden. Das Team prüft zuerst, dass F die genaue vorgeschlagene Adresse kontrolliert und von den anderen Eigentümern unabhängig bleibt. Für eine kompatible Safe-Bereitstellung bereitet es swapOwner(prevOwner, B, F) vor. Der Aufruf ist selbst eine Safe-Transaktion und benötigt daher 3 gültige Bestätigungen aus der aktuellen Eigentümermenge. Das dekodierte Ergebnis sollte eine Eigentümerzahl von 5 und eine Schwelle von 3 erhalten.
Nach der Bestätigung liest das Team getOwners und getThreshold, prüft, dass B fehlt und F vorhanden ist, und lässt F mit zwei weiteren Eigentümern einen genehmigten Test mit dem Wert 0 ausführen. Es prüft außerdem ausstehende Transaktionen: Eine Signatur oder Vorabgenehmigung von B erfüllt nach dessen Entfernung möglicherweise die Eigentümerprüfung nicht mehr. Betroffene Vorschläge müssen daher storniert oder neu erstellt werden, statt sie als ausführbar anzusehen.
Könnte B kompromittiert sein, fordert das Team von ihm keine Genehmigung der Entfernung an. Drei andere nicht kompromittierte Eigentümer führen den Austausch aus und prüfen anschließend Module, Wiederherstellungsrechte, Allowances, Sitzungsschlüssel und bereits ausgeführte Transaktionen. Das Entfernen von B macht frühere Aktionen nicht rückgängig und widerruft keine über einen anderen Pfad erteilten Rechte. Sind weniger als 3 nicht kompromittierte Eigentümer verfügbar, kann nur ein zuvor eingerichteter Wiederherstellungs- oder Verwaltungspfad helfen. Seed-Phrasen zu teilen oder einem unaufgeforderten „Wiederherstellungsdienst“ zu vertrauen, ersetzt kein Quorum.
Risiken und Kontrollen
- Falsches Konto oder falsche Adresse. Prüfen Sie Chain-ID, Multisig-Adresse, Implementierung und neue Eigentümeradresse auf unabhängigen Geräten und anhand unabhängiger Quellen. Address Poisoning und Kopierfehler können einem Angreifer die Kontrolle geben.
- Quorumverlust. Modellieren Sie jeden Zwischenzustand. Wird ein Eigentümer zu früh entfernt, die Schwelle über die Zahl verfügbarer Unterzeichner angehoben oder werden mehrere korrelierte Geräte gemeinsam rotiert, kann das Konto unbenutzbar werden.
- Vorübergehende Konzentration. Eine niedrigere Schwelle oder ein neu hinzugefügter Unterzeichner kann einen Zeitraum schaffen, in dem weniger Parteien das Konto kontrollieren. Bevorzugen Sie einen atomaren Austausch, wenn er unterstützt wird, und senken Sie die Schwelle nicht nur zur Vereinfachung der Zeremonie.
- Korrelierte Verwahrung. Verschiedene Adressen sind nicht unabhängig, wenn ihre Seeds, Geräte, Sicherungen, Kommunikationswege oder Administratoren dieselbe Ausfalldomäne teilen. Testen Sie die Wiederherstellung, ohne Geheimnisse zu zentralisieren.
- Verborgene Befugnisse. Module, Guards, Fallback-Handler, Sitzungsschlüssel, Timelocks und Wiederherstellungsverträge können den Eigentümerpfad umgehen oder blockieren. Erfassen und prüfen Sie sie vor und nach der Rotation.
- Wettrennen mit kompromittiertem Unterzeichner. Vor Bestätigung der Entfernung kann ein verdächtiger Unterzeichner vorauseilen, Vermögenswerte abziehen, die Konfiguration ändern oder eine andere Transaktion genehmigen. Nutzen Sie Incident-Verfahren, gegebenenfalls private Transaktionsübermittlung und laufende Zustandsüberwachung. Nehmen Sie nicht an, eine eingereichte Transaktion habe das Rennen gewonnen.
- Veraltete ausstehende Genehmigungen. Änderungen an Eigentümern und Schwelle können gesammelte Signaturen ungültig machen oder verändern, welche Genehmigungen ausreichen. Bewerten Sie jede wartende Transaktion anhand des Endzustands neu und stornieren Sie überholte Vorschläge.
- Falscher Abschluss. Eine Erfolgsmeldung der Oberfläche beweist nicht den beabsichtigten Zustand. Warten Sie die vorgeschriebene Bestätigungsregel ab, lesen Sie dann den Vertragszustand und prüfen Sie Transaktionsnutzlast, Ereignisse und Ausführungsergebnis.
- Unvollständiges Offboarding. Das Entfernen eines On-Chain-Eigentümers löscht keine kopierten Schlüssel, Organisationszugänge, Relayer-Zugangsdaten, Passworttresoreinträge oder Rechte in anderen Verträgen und Chains. Widerrufen Sie jedes Element separat und bewahren Sie einen Prüfpfad auf.
Häufige Irrtümer
- „Rotation bedeutet, alle Vermögenswerte in eine neue Wallet zu verschieben.“ Viele Smart-Account-Multisigs aktualisieren Eigentümer unter derselben Kontoadresse. Eine Migration ist ein anderer Vorgang und wird möglicherweise nur von einer bestimmten Implementierung oder einem Incident-Plan verlangt.
- „Den neuen Unterzeichner zuerst hinzuzufügen ist immer sicher.“ Das schützt die Verfügbarkeit, kann aber die berechtigte Menge vorübergehend vergrößern. Bei einer aktiven Kompromittierung kann ein atomarer Austausch oder eine andere Notfallreihenfolge sicherer sein.
- „Eine
3-of-5-Schwelle bedeutet, dass drei beliebige benannte Personen verfügbar sind.“ Der Vertrag zählt gültige Eigentümerkonten, nicht Personen, Abteilungen oder Geräte. Gemeinsame Verwahrung und unzugängliche Schlüssel verringern die effektive Unabhängigkeit und Verfügbarkeit. - „Das Entfernen eines kompromittierten Eigentümers macht den Schaden rückgängig.“ Nach Bestätigung verhindert es die künftige Nutzung dieses Eigentümerpfads; ausgeführte Transaktionen oder anderswo geschaffene Rechte werden nicht rückgängig gemacht.
- „Die Wallet-Oberfläche ist Beweis genug.“ Oberflächen und Indexdienste können veraltet, falsch konfiguriert oder bösartig sein. Dekodieren Sie die Transaktion und lesen Sie den endgültigen Vertragszustand über einen unabhängig geprüften Endpunkt.
- „Ohne Quorum kann der Support die Wallet zurücksetzen.“ Ein selbstverwahrtes Multisig besitzt nur die auf der Chain codierten oder zuvor konfigurierten Befugnispfade. Ohne gültiges Quorum oder Wiederherstellungspfad kann der Zugriff dauerhaft verloren sein.
Verwandte Themen
- Hardware-Wallet
- Multisig-Wallet
- Verwaltung privater Schlüssel
- Wiederherstellungsrisiko für Smart-Account-Eigentümer
- Transaktionssimulation
Quellen
- Wie funktionieren Safe Smart Accounts? - Safe Documentation (abgerufen: 2026-08-21)
- addOwnerWithThreshold - Safe Documentation (abgerufen: 2026-08-21)
- removeOwner - Safe Documentation (abgerufen: 2026-08-21)
- swapOwner - Safe Documentation (abgerufen: 2026-08-21)
- changeThreshold - Safe Documentation (abgerufen: 2026-08-21)
- OwnerManager.sol - Safe Ecosystem Foundation (abgerufen: 2026-08-21)
- Empfehlung für Schlüsselverwaltung: Teil 1 - Allgemeines - NIST (abgerufen: 2026-08-21)