Zum Inhalt springen
Financial Context Wiki

Multi-Signatur-Wallet

Erfahren Sie, wie ein M-of-N-Multisig-Wallet Transaktionsbefugnisse verteilt, wie sich skriptbasierte und Smart-Contract-Multisigs unterscheiden und welche Unterzeichner-, Ausführungs-, Modul- und Wiederherstellungsrisiken bleiben.

Aktualisiert

Nur zu Bildungszwecken; keine Anlage-, Verwahrungs-, Rechts- oder Sicherheitsberatung. Auch ein Multisig kann durch kompromittierte Unterzeichner, bösartige Transaktionen, unsichere Module, Vertragsfehler oder Quorumverlust Geld verlieren oder unbrauchbar werden. Transaktionen mit digitalen Vermögenswerten können unumkehrbar sein.

Direkte Antwort

Ein Multi-Signatur- oder Multisig-Wallet kontrolliert ein Konto oder einen ausgabefähigen Output durch eine Regel, die mindestens M Genehmigungen von N berechtigten öffentlichen Schlüsseln oder Eigentümerkonten verlangt. Eine 2-of-3-Regel akzeptiert beispielsweise zwei beliebige gültige Befugnisse aus einer Menge von drei. Dadurch ist nicht mehr ein privater Schlüssel der einzige Kontrollpunkt, doch nicht jede genehmigte Transaktion wird dadurch sicher.

Konventionelles Multisig teilt nicht einen privaten Schlüssel unter den Unterzeichnern auf. Jeder Unterzeichner kontrolliert gewöhnlich einen eigenen Schlüssel oder ein eigenes Konto, und das Skript oder der Vertrag prüft mehrere Genehmigungen. Schwellenwertsignatur- oder MPC-Systeme können dagegen aus verteilten Schlüsselanteilen eine Signatur erzeugen; ihr On-Chain-Erscheinungsbild und Vertrauensmodell unterscheiden sich.

Die Implementierung ist entscheidend. Bitcoin kann Multisignatur-Ausgabebedingungen in Transaktionsskripten erzwingen. Auf Ethereum und ähnlichen programmierbaren Netzwerken ist ein Multisig häufig ein Vertragskonto, dessen Code Eigentümer, Schwelle, Ausführungsregeln und optionale Erweiterungen festlegt. Anders als ein extern kontrolliertes Konto wird ein Vertragskonto durch seinen Code und nicht durch einen privaten Schlüssel kontrolliert.

Die M-of-N-Schwelle beschreibt sowohl Kompromittierungs- als auch Verfügbarkeitsgrenzen. Ein 3-of-5-System funktioniert weiter, wenn zwei Befugnisse fehlen, aber drei beliebige gültige Befugnisse können Ausgaben genehmigen. Verschiedene Adressen sind nicht unabhängig, wenn eine Person, ein Geräteadministrator, ein Cloud-Konto, ein Sicherungsort oder ein Verwahrer genügend davon kontrollieren kann.

Funktionsweise

  1. Befugnisse vor dem Vorschlag prüfen. Bestätigen Sie Netzwerk und Konto oder Output. Prüfen Sie dann Skript oder bereitgestellten Vertrag, Eigentümermenge, Schwelle, Nonce- oder Sequenzregeln und alle Module, Guards, Fallback-Handler, Wiederherstellungspfade und Upgrade-Befugnisse, die Transaktionen ausführen oder blockieren können.
  2. Exakte Anforderung erstellen und dekodieren. Prüfen Sie Ziel, Vermögenswert, Wert, Calldata oder Skript, Operationstyp, Nonce, Gebühren und jeden Batch-Inhalt. Simulieren Sie komplexe Vertragsaufrufe, wenn verlässliche Werkzeuge verfügbar sind, und sorgen Sie dafür, dass jeder Unterzeichner die tatsächliche Signaturwirkung statt einer Oberflächenbeschriftung prüft.
  3. Genehmigungen in unabhängigen Kontrollbereichen sammeln. Unterzeichner prüfen denselben Transaktions-Digest auf vertrauenswürdigen Geräten und kommunizieren über authentifizierte Kanäle. Kein legitimer Genehmigungsprozess verlangt die Offenlegung einer Seed-Phrase oder eines privaten Schlüssels.
  4. Genehmigte Anforderung ausführen. Das Erreichen der Schwelle kann einen Vorschlag nur ausführbar machen. Ein Ausführender muss ihn noch senden oder einreichen und eventuell eine Netzwerkgebühr zahlen. Eine veraltete Nonce, ein konkurrierender Vorschlag, geänderter Vertragszustand, unzureichende Gebühr oder fehlgeschlagener Aufruf kann die Ausführung verhindern.
  5. Abschluss anhand des Chain-Zustands prüfen. Warten Sie die erforderliche Bestätigungsregel ab, prüfen Sie ausgeführte Nutzlast und Ergebnis und bestätigen Sie je nach Bedarf Salden, Eigentümerkonfiguration und Ereignisse. Bewerten Sie wartende Vorschläge nach jeder Änderung an Eigentümern, Schwelle, Modulen oder Richtlinien neu.

Beispiel

Eine Treasury nutzt ein 3-of-5-Smart-Account-Multisig mit den Eigentümern A, B, C, D und E in getrennten Kontrollbereichen. Für eine Zahlung von 10,000 USDC erfasst der Vorschlag das richtige Netzwerk, Konto, den Empfänger, Token-Vertrag, Betrag, Calldata, die Nonce und Gebührenrichtlinie. A, C und E dekodieren die gleiche Anforderung unabhängig vor ihrer Genehmigung.

Die Genehmigungen allein bewegen kein Geld. Ein Ausführender reicht die Transaktion ein; nach Bestätigung prüft das Team Transaktionsergebnis und Treasury-Saldo, statt sich auf eine Meldung der Wallet-Oberfläche zu verlassen. Vorschlag, Genehmigungen, Transaktionshash und Prüfnachweise bleiben als Audit-Trail erhalten.

Wird später vermutet, dass Bs Schlüssel kompromittiert ist, folgt das übrige nicht kompromittierte Quorum dem Eigentümerrotationsverfahren des bereitgestellten Kontos und prüft die endgültige Eigentümermenge auf der Chain. Außerdem prüft das Team wartende Vorschläge, Module, Allowances, Wiederherstellungsrechte und andere Chains, denn das Entfernen von B macht frühere Transaktionen nicht rückgängig und widerruft keine anderweitig gewährten Rechte.

Risiken und Kontrollen

  • Korrelierte Verwahrung. Mehrere Schlüssel können gemeinsam ausfallen, wenn sie Person, Gerät, Passworttresor, Administrator, Standort, Anbieter oder Wiederherstellungsgeheimnis teilen. Erfassen Sie Kontrollbereiche und testen Sie Wiederherstellung, ohne genügend Befugnisse für die Schwelle zu zentralisieren.
  • Bösartige oder missverstandene Nutzlasten. Ein gültiges Quorum kann eine Angreiferadresse, unbegrenzte Token-Genehmigung, einen Delegate Call oder schädlichen Batch korrekt genehmigen. Dekodieren und prüfen Sie die gesamte Anforderung unabhängig; Transaktionssimulation ist ein Beleg, keine Garantie.
  • Quorumverlust und Verzögerung. Verlorene Schlüssel, unerreichbare Personen, Streit, Netzwerkausfälle oder eine zu hohe Schwelle können dringende Maßnahmen blockieren oder Vermögenswerte dauerhaft sperren. Pflegen Sie authentifizierte Kontakte, dokumentierte Nachfolge, getestete Sicherungen und ein klares Wiederherstellungsdesign.
  • Verborgene oder umgehende Befugnisse. Module, Guards, Fallback-Handler, Sitzungsschlüssel, Relayer, Wiederherstellungsverträge und Upgrade-Administratoren können die normale Eigentümerschwelle umgehen oder ihre Ausführung verhindern. Erfassen Sie diese Pfade und behandeln Sie jede Berechtigungsänderung als Hochrisikotransaktion.
  • Vertrags- und Bereitstellungsrisiko. Fehler, unsichere Initialisierung, Proxy- oder Upgrade-Fehler und eine Bereitstellung im falschen Netzwerk können die beabsichtigte Richtlinie aushebeln. Prüfen Sie Adressen und Code, bewerten Sie Audits im Kontext, minimieren Sie Erweiterungen und überwachen Sie Konfigurationsänderungen.
  • Kompromittierungsrennen und unvollständiges Offboarding. Ein kompromittierter Unterzeichner kann vor Bestätigung seiner Entfernung handeln; das Entfernen eines Eigentümers widerruft weder ausgeführte Aktionen noch externe Rechte. Nutzen Sie einen Incident-Plan, überwachen Sie den Zustand laufend und widerrufen Sie organisatorische und On-Chain-Zugänge getrennt.

Häufige Irrtümer

  • „Mehr Unterzeichner bedeuten immer mehr Sicherheit.“ Eine größere Menge kann Konzentration verringern, erhöht aber Koordinations-, Phishing- und Verfügbarkeitsrisiken. Wählen Sie Eigentümermenge und Schwelle anhand von Bedrohungsmodell und Betriebskapazität.
  • „Ein 3-of-5-Wallet wird von fünf unabhängigen Personen kontrolliert.“ Die Chain zählt gültige Schlüssel oder Eigentümerkonten, nicht Menschen. Gemeinsame Geräte, Sicherungen, Administratoren oder Verwahrer können nominell getrennte Eigentümer zu einem Kontrollbereich machen.
  • „Multisig ist dasselbe wie Zwei-Faktor-Authentifizierung oder MPC.“ Diese Ansätze können Kontrolle verteilen, unterscheiden sich aber bei Zugangsdaten, Prüfpfaden, On-Chain-Nachweisen und Wiederherstellungsannahmen.
  • „Nach Erreichen der Schwelle ist die Übertragung abgeschlossen.“ Genehmigung, Ausführbarkeit, Einreichung, Aufnahme und Bestätigung sind getrennte Zustände. Die Anforderung kann warten oder fehlschlagen.
  • „Multisig verhindert Diebstahl und Vertragsangriffe.“ Es begrenzt nur die in seiner Implementierung codierten Befugnispfade. Ein gültiges Quorum, privilegiertes Modul, anfälliger Vertrag oder unsicherer Wiederherstellungspfad kann weiterhin unumkehrbare Verluste verursachen.

Verwandte Themen

Quellen

Navigation

Wiki durchsuchen...