Multi-Signatur-Koordination in einer Peer-to-Peer-Welt

Wir lösen die Multi-Signatur-Koordination ohne Server – das schwierige Problem, das die Branche durch Zentralisierung umgangen hat

·

Multi-Signatur-Koordination in einer Peer-to-Peer-Welt hero image

Multi-Signatur-Wallets sind in der Theorie trügerisch einfach. Zwei Freunde, die Transaktionen gemeinsam signieren wollen, eine DAO-Schatzkammer, die eine Genehmigung des Rates erfordert, ein Unternehmen mit mehreren Stakeholdern – das Konzept ist unkompliziert. Das Schwierige ist nicht die Kryptografie oder die On-Chain-Mechanik. Es ist die Koordination.

Wie erfahren die Teilnehmer von einer laufenden Signierungssitzung? Wer sendet die endgültige Transaktion? Was passiert, wenn Alice mitten in der Signierung offline geht, Bobs Koordinator abstürzt und Charlie sich nicht erinnern kann, ob er seine Teilsignatur bereits gesendet hat? Traditionelle Lösungen winken bei diesen Fragen ab: „Verwende einen vertrauenswürdigen Server" oder „koordiniere außerhalb des Protokolls" oder „betreibe einfach deine eigene Infrastruktur."

Das sind keine Lösungen – das sind Ausweichmanöver in Richtung Zentralisierung oder operativer Belastung. Aber Peer-to-Peer-Koordination ist mit sorgfältigem verteiltem Systemdesign lösbar.

Dieser Artikel beschreibt, wie wir eine wirklich dezentrale Multi-Signatur-Koordination für Lotus gebaut haben und warum das für das breitere Kryptowährungs-Ökosystem wichtig ist.

Was ist MuSig2 und warum ist es wichtig?

MuSig2 ist ein Multi-Signatur-Protokoll für Schnorr-Signaturen. Mehrere Parteien arbeiten zusammen, um eine einzelne, aggregierte Signatur zu erzeugen, die kryptografisch nicht von einer Einzelsignatur-Transaktion zu unterscheiden ist.

Die Gewinne bei Datenschutz und Effizienz sind beträchtlich. Traditionelle P2SH-Multi-Signatur für drei Teilnehmer erfordert 99 Bytes an öffentlichen Schlüsseln und 210 Bytes an Signaturen – insgesamt 309 Bytes. MuSig2 mit Taproot verwendet 33 Bytes für den öffentlichen Schlüssel und 64 Bytes für die Signatur – 97 Bytes, eine Reduktion um 69 %. Noch wichtiger: Die Transaktion verrät keine Information darüber, wie viele Parteien beteiligt waren oder wie hoch die Signierungsschwelle war.

Die Sicherheitseigenschaften sind rigoros. MuSig2 verhindert Rogue-Key-Angriffe durch Schlüsselaggregationskoeffizienten, die aus allen Teilnehmerschlüsseln abgeleitet werden. Es verhindert Nonce-Wiederverwendungs-Angriffe (die private Schlüssel preisgeben würden) durch sorgfältiges Sitzungsmanagement und deterministische Nonce-Generierung. Das Schema ist nachweisbar sicher unter der Diskreter-Logarithmus-Annahme, derselben Annahme, die Einzelsignatur-Schnorr und ECDSA absichert.

In Kombination mit Taproot ermöglicht MuSig2 ausgefeilte On-Chain-Verhaltensweisen, die wie einfache Zahlungen aussehen:

  • Payment Channels mit komplexer Streitbeilegung – Alices und Bobs Lightning-artiger Kanal erscheint als Standardadresse
  • DAO-Schatzkammern, die einstimmige Ratsgenehmigung erfordern – eine 3-von-3- oder 5-von-5-Multi-Signatur erscheint als einzelner Schlüssel
  • Tresore mit Zeitschlössern – Mittel, die sechs Monate gesperrt sind, es sei denn, alle Parteien stimmen einer vorzeitigen Freigabe zu
  • Bedingte Ausgaben – „Zahle an Bob, wenn diese Bedingungen erfüllt sind, ansonsten erstatte Alice zurück"

All dies erscheint auf der Blockchain als einfache Einzelsignatur-Transaktionen, es sei denn, der Skriptpfad wird verwendet. Das ist nicht nur Datenschutz-Theater. Wenn ausgefeilte Transaktionen nahtlos mit alltäglicher Aktivität verschmelzen, wird die Blockchain-Analyse grundlegend schwieriger. Alle profitieren davon.

Das Protokoll ist als BIP-327 standardisiert, in Bitcoin Core implementiert und von Kryptografen auditiert. Aber hier liegt der Haken: MuSig2 erfordert zwei Runden interaktiver Kommunikation.

Das Problem der zentralisierten Koordination

MuSig2 ist kein Smart Contract, den man einmal deployed und dann vergisst. Es ist ein interaktives Protokoll, das sorgfältige Orchestrierung erfordert:

Runde 1: Nonce-Austausch Jeder Teilnehmer generiert Nonces mittels deterministischer RFC 6979-Generierung (standardmäßig mit zusätzlicher zufälliger Entropie für Produktionssicherheit) und teilt die öffentlichen Nonces. Jeder muss die öffentlichen Nonces aller anderen erhalten, bevor es weitergeht.

Runde 2: Teilsignatur-Austausch Jeder Teilnehmer erstellt eine Teilsignatur unter Verwendung seines privaten Schlüssels, der aggregierten Nonce und der Transaktionsdaten. Diese Teilsignaturen werden zur endgültigen Signatur kombiniert.

Broadcast Jemand muss die Transaktion an das Netzwerk senden. Wer? Was, wenn er sich weigert? Was, wenn er abstürzt?

Dies erzeugt ein Koordinationsproblem mit mehreren herausfordernden Teilproblemen:

Entdeckung und Sitzungsverwaltung

Wenn Alice von einer 3-von-3-Adresse ausgeben möchte, die sie mit Bob und Charlie teilt, wie teilt ihr Wallet Bob und Charlie mit, dass eine Signierungssitzung begonnen hat? Die Blockchain kann nicht helfen – der ganze Sinn besteht darin, dass nichts auf der Blockchain passiert, bis die Signatur abgeschlossen ist. Traditionelle Ansätze:

  • Zentralisierter Koordinationsserver: Alle verbinden sich mit einem zentralen Dienst, der Nachrichten weiterleitet. Das funktioniert, bis der Server ausfällt, Transaktionen zensiert, kompromittiert wird oder der Betreiber beschließt, Gebühren zu erheben.
  • Manuelle Koordination: „Alice mailt Bob und Charlie den Transaktions-Hex. Bob antwortet mit seiner Teilsignatur. Charlie ist im Urlaub und antwortet drei Tage lang nicht." Das skaliert nicht.
  • Selbst gehostete Infrastruktur: Jeder betreibt einen Server mit öffentlicher IP und koordiniert über direkte Verbindungen. Das schließt mobile Wallets, Nutzer hinter NAT und jeden aus, der keine Serverinfrastruktur verwalten möchte.

Authentifizierung und Sicherheit

Wie verifizieren die Teilnehmer, dass Nachrichten tatsächlich von den erwarteten Mit-Unterzeichnern stammen? In einem dezentralen System ohne zentrale Autorität muss jeder Peer die Nachrichtenauthentizität unabhängig verifizieren. Die Lösung erfordert kryptografischen Beweis: Nachrichten werden mit dem privaten Schlüssel des Absenders signiert, und Empfänger verifizieren die Signatur gegen den beanspruchten öffentlichen Schlüssel, bevor sie die Nachricht verarbeiten.

Replay-Angriffe und Nonce-Wiederverwendung

Was hindert Eve daran, Alices Nonce aus einer früheren Sitzung aufzuzeichnen und erneut abzuspielen? Die Wiederverwendung von Nonces mit verschiedenen Nachrichten legt private Schlüssel offen. Das Protokoll muss strenge Phasenübergänge erzwingen: Man kann keine Teilsignatur einreichen, bevor die Nonces gesammelt sind, kann Nonces nicht über Sitzungen hinweg wiederverwenden und kann nicht verschiedene Transaktionen in derselben Sitzung signieren.

Koordinator-Ausfälle und Failover

Jemand muss die Teilsignaturen aggregieren und die Transaktion senden. Die naheliegende Wahl ist, einen Teilnehmer als Koordinator zu bestimmen. Aber was passiert, wenn er sich abmeldet? Wartet man auf unbestimmte Zeit? Einigen sich die Teilnehmer manuell auf einen neuen Koordinator außerhalb des Protokolls?

Ratenbegrenzung und DoS-Schutz

Was hindert in einem Peer-to-Peer-System böswillige Akteure daran, Signierungssitzungen mit Müll zu überfluten? Man braucht Ratenbegrenzung, Reputationsverfolgung und die Fähigkeit, sich fehlverhaltende Peers zu sperren – aber ohne zentrale Autorität.

Die Lotusia-Lösung

Unser Ansatz kombiniert drei bewährte Muster verteilter Systeme zu einer kohärenten Peer-to-Peer-Koordinationsschicht:

1. Mehrstufige Entdeckung

Wir verwenden die bewährte Infrastruktur von libp2p mit drei komplementären Entdeckungsmechanismen:

DHT (Verteilte Hashtabelle): Sitzungsankündigungen werden in der Kademlia-DHT (mit k=20 Replikation) unter einer Sitzungskennung gespeichert, die aus den teilnehmenden Unterzeichnern und der Nachricht abgeleitet wird. Wenn Alice eine Signierungssitzung erstellt, veröffentlicht sie eine Ankündigung in der DHT. Bob und Charlie können sie entdecken, indem sie die DHT mit der Sitzungs-ID abfragen. Dies bietet persistenten, dezentralen Speicher ohne zentralen Server – Sitzungen bleiben auffindbar, selbst wenn der Ersteller offline geht.

GossipSub: Für die Echtzeit-Unterzeichner-Entdeckung veröffentlichen Teilnehmer Anzeigen in PubSub-Topics, die nach Transaktionstyp organisiert sind (z. B. musig2:signers:SWAP). Wenn Bob seine Verfügbarkeit für Atomic Swaps anzeigt, erhält Alice die Benachrichtigung in 10-100 ms, wenn sie dieses Topic abonniert hat. Dies bietet sofortige Peer-Entdeckung ohne DHT-Abfrageverzögerungen.

Direktnachrichtenprotokoll: Sobald sich die Teilnehmer gefunden haben, werden Koordinationsnachrichten (Nonces, Teilsignaturen) über das Nachrichtenprotokoll von libp2p mit Peer-to-Peer-Routing gesendet. Nachrichten werden mit dem Noise-Protokoll von libp2p verschlüsselt und durch das Netzwerk an bestimmte Peers geleitet, anstatt global zu senden.

Der mehrschichtige Ansatz bewältigt unterschiedliche Szenarien: DHT für persistente Sitzungsspeicherung und Entdeckung von Offline-Teilnehmern, GossipSub für Echtzeit-Unterzeichner-Anzeigen und direkte Peer-Nachrichten für die eigentlichen Signierungsrunden.

2. Durchgehende kryptografische Sicherheit

Jede Protokollnachricht wird kryptografisch mit Schnorr-Signaturen signiert. Sitzungsankündigungen, Unterzeichner-Anzeigen, Signierungsanfragen und Teilnehmerbeitritte tragen alle Signaturen, die beweisen, dass der Absender seinen beanspruchten privaten Schlüssel kontrolliert. Diese Authentifizierungsschicht verhindert DHT-Poisoning, Identitätsdiebstahl und Nachrichtenmanipulation.

Die Sicherheitsarchitektur implementiert Verteidigung in der Tiefe durch mehrere unabhängige Schichten:

Ratenbegrenzung: Peers können höchstens eine Anzeige pro 60 Sekunden senden. Verstöße lösen automatische Eskalation aus – 10 Verstöße führen zu permanenter Sperrung.

Sybil-Resistenz: Jeder Peer kann standardmäßig höchstens 10 öffentliche Schlüssel anzeigen (50 für verifizierte Identitäten, 100 für institutionelle Nutzer). Dies verhindert, dass einzelne Akteure das Netzwerk mit gefälschten Teilnehmern überfluten.

Peer-Reputationsverfolgung: Das System führt Blacklists (permanente Sperren) und Graylists (temporäre Suspendierungen) basierend auf dem Verhalten. Ungültige Signaturen, Ratenbegrenzungsverstöße und Spam-Versuche tragen alle zu Reputationswerten bei, die die Behandlung der Peers bestimmen.

Protokollphasen-Durchsetzung: Zustandsmaschinen stellen die korrekte Nachrichtenreihenfolge sicher. Nonces können nicht vor der Sitzungseinrichtung eingereicht werden. Teilsignaturen können nicht vor Abschluss der Nonce-Aggregation gesendet werden. Transaktionen können nicht vor der Signaturfinalisierung gesendet werden.

Nachrichtenwiederholungsschutz: Jede Nachricht enthält eine streng aufsteigende Sequenznummer pro Unterzeichner und Sitzung. Doppelte oder außer der Reihe liegende Sequenznummern lösen Ablehnung und Reputationsstrafen aus.

Burn-basierte Identität (optional): Teilnehmer können ihre Identität an Blockchain-Transaktionen verankern, indem sie nachweisbar XPI in einem bestimmten LOKAD-getaggten Format verbrennen. Diese Identitäten ermöglichen Schlüsselrotation ohne Reputationsverlust – die Identität ist an (txId, outputIndex) gebunden, nicht an ephemere Schlüssel, und erfordert Reifungsperioden (144 Blöcke für die Registrierung, 6 Blöcke für die Rotation), um zeitliche Angriffe zu verhindern. In einer zukünftigen Implementierung könnte dies eine erforderliche Komponente für den Aufbau von Peer-Reputation werden.

3. Deterministische Koordinatorwahl

Dies ist das Puzzleteil, das Failover elegant funktionieren lässt. Anstatt manuell einen Koordinator zu bestimmen, führen alle Teilnehmer denselben deterministischen Algorithmus aus.

Die Standard-Wahlmethode ist lexikografische Sortierung:

function electCoordinator(signers: PublicKey[]): ElectionResult {
  // Sort public keys by binary buffer comparison
  const sorted = signers
    .map((pk, idx) => ({
      originalIndex: idx,
      publicKey: pk,
      buffer: pk.toBuffer(),
    }))
    .sort((a, b) => a.buffer.compare(b.buffer))

  // First in sorted order becomes coordinator
  return {
    coordinatorIndex: 0,
    coordinatorPublicKey: sorted[0].publicKey,
    sortedSigners: sorted.map(item => item.publicKey),
    // ... index mappings and election proof
  }
}

Alle stellen dieselben öffentlichen Schlüssel bereit, alle sortieren sie identisch, alle wählen den ersten – keine Abstimmung, keine Kommunikation, keine Mehrdeutigkeit. Die Sortierung entspricht exakt der Reihenfolge, in der MuSig2-Schlüsselaggregation die Teilnehmer ordnet, und stellt so Konsistenz im gesamten Protokoll sicher.

Wenn der Koordinator abstürzt oder die Transaktion nicht senden will? Das System wechselt automatisch zum nächsten Teilnehmer in sortierter Reihenfolge. Dies setzt sich fort bis zu N-1 Ausfällen, was bedeutet, dass eine 3-von-3-Multi-Signatur nur dann nicht reagiert, wenn alle drei Teilnehmer gleichzeitig offline sind.

Der Determinismus ist entscheidend. In verteilten Systemen ist Konsens teuer. Aber wenn man eine Entscheidung ohne Koordination treffen kann – weil jeder unabhängig dieselbe Antwort berechnet – eliminiert man ganze Klassen von Fehlermodi. Die Implementierung unterstützt auch hash-basierte, Erst-Unterzeichner- und Letzt-Unterzeichner-Wahlmethoden für spezifische Anwendungsfälle.

Was dies ermöglicht

Diese Muster kombinieren sich, um Anwendungsfälle zu unterstützen, die zuvor zentralisierte Infrastruktur erforderten:

Multi-Signatur-Schatzkammern: Von 2-von-2-Gemeinschaftskonten bis zu 10-von-10-Ratsschatzkammern (alle n-von-n), mit automatischem Koordinator-Failover, das die Ausgabefähigkeit auch bei teilweisen Ausfällen gewährleistet.

Payment Channels: Zwei-Parteien-Kanäle (Alice ↔ Bob), bei denen jede Partei Kanalaktualisierungen initiieren kann und der Kanal funktionsfähig bleibt, selbst wenn die Koordinator-Software einer Partei abstürzt.

Atomic Swaps: Echte Peer-to-Peer-Cross-Chain-Swaps, bei denen die Teilnehmer die gleichzeitige Signierung beider Seiten des Swaps ohne Drittpartei koordinieren.

Zeitgesperrte Tresore: Mittel, die die Signatur aller Teilnehmer vor einem Timeout erfordern, danach eine einzelne Signatur – wobei die Multi-Signatur-Koordination nahtlos im Hintergrund abläuft.

SwapSig-Datenschutzprotokoll: Unser CoinJoin-Äquivalent, bei dem mehrere Parteien koordinieren, um eine einzelne Transaktion mit zusammengeführten Ein- und Ausgaben zu erstellen, die die On-Chain-Rückverfolgbarkeit unterbricht und gleichzeitig die individuelle Signaturverifizierung beibehält. Ein zukünftiger Blogartikel wird eine tiefgehende Analyse von SwapSig liefern.

Die Infrastruktur ist universell einsetzbar. Alles, was interaktive Mehrparteien-Signierung erfordert, kann sie nutzen.

Auswirkungen auf das breitere Kryptowährungs-Ökosystem

Diese Implementierung ist kryptowährungsunabhängig. Die Koordinationsschicht arbeitet unabhängig vom Blockchain-Konsens – reines P2P-Networking und kryptografische Nachrichtenübermittlung. Bitcoin kann es für Taproot-Multi-Signatur übernehmen. Ethereum kann es für Schwellensignaturen in der Kontoabstraktion nutzen. Jede Kryptowährung, die Schnorr-Signaturen unterstützt, kann diese Infrastruktur integrieren. Lightning Channels, Atomic Swaps, Datenschutzprotokolle, DAO-Governance und DeFi-Operationen erfordern alle interaktive Mehrparteien-Koordination. Dieselbe Infrastruktur löst all diese Probleme.

Noch wichtiger: Dies beweist, dass dezentrale Koordination für Produktionssysteme praktikabel ist. Die Branche hat sich nicht deshalb für zentralisierte Koordinatoren entschieden, weil P2P-Koordination unmöglich ist, sondern weil niemand eine funktionierende Implementierung ausgeliefert hat. Wenn wiederverwendbare Infrastruktur existiert – wie TCP/IP für Netzwerke oder TLS für Verschlüsselung – hören Entwickler auf, das Problem als optional zu behandeln. Dies verändert die Grunderwartung: Dezentrale Koordination wird zum Standard statt zur Ausnahme.

Implementierungsstatus und nächste Schritte

Die Implementierung ist abgeschlossen und funktioniert. Über 91 Tests validieren die Protokollimplementierung, Koordinatorwahl, Failover-Szenarien, Nachrichtenauthentifizierung und Wiederholungsschutz. Der Code befindet sich seit Wochen in aktiver Entwicklung und behandelt Grenzfälle, die wir durch umfangreiche Tests entdeckt haben.

Das Verbindungsmanagement ist ordnungsgemäß isoliert. Ihr Wallet unterhält allgemeine P2P-Verbindungen zum Lotus-Netzwerk, und diese sind von sitzungsspezifischen Signierungsverbindungen getrennt. Wallet-Verbindungslimits blockieren keine Multi-Signatur-Sitzungen, und Multi-Signatur-Aktivität erschöpft nicht Ihre allgemeinen Peer-Slots.

Der aggregierte öffentliche MuSig2-Schlüssel wird zum internen Taproot-Schlüssel. Komplexe Skriptbäume (für Fallback-Bedingungen oder Zeitschlösser) bleiben verborgen, es sei denn, sie werden über den Skriptpfad ausgegeben, wobei nur der verwendete Zweig offengelegt wird.

Die Implementierung befindet sich in lotus-sdk, unserem modernen TypeScript-SDK für Lotus. Funktionierende Beispiele demonstrieren:

  • Grundlegendes 2-von-2-Signieren mit automatischer Entdeckung
  • Mehrparteien-Koordinatorwahl und Failover
  • Taproot-Integration mit Key-Path- und Script-Path-Ausgaben
  • Sitzungsverwaltung und Wiederholungsschutz

Die technische Dokumentation behandelt Architekturentscheidungen, Sicherheitsüberlegungen, API-Nutzung und Testverfahren.

Der Weg voraus

MuSig2 hat das mathematische Problem der Mehrparteien-Schnorr-Signaturen elegant und beweisbar gelöst, aber die Koordinationsinfrastruktur blieb zentralisiert. Diese Implementierung beweist, dass Peer-to-Peer-Koordination praktikabel ist. Die Infrastruktur ist universell einsetzbar und wiederverwendbar – einmal bauen, überall nutzen. Technologie sollte menschliche Beziehungen verbessern, nicht behindern oder ersetzen.

Jetzt kommt der entscheidende Teil: Experimentieren und Iterieren. Software reift durch echte Nutzung, nicht durch Spekulation. Sehen Sie, wie die Community-Reputation in der Praxis funktioniert, auf den sozialen Profilen von Lotusia, oder lesen Sie über wie wir Inhalte ranken. Installieren Sie lotus-sdk, experimentieren Sie mit den Beispielen, testen Sie das Protokoll bis an seine Grenzen, melden Sie Probleme. Reale Nutzung wird Grenzfälle aufdecken und die nächste Iteration informieren. Lotus hat sich immer darauf konzentriert, Dinge richtig zu machen. Die Lotusianische Schildkröte bewegt sich langsam, aber zielstrebig, dem Sieg entgegen; ein bedachter Schritt nach dem anderen.

Ressourcen:

Gemeinschaft: