Die Solana-Multisig-Wallet, deren Adresse die Mitgliedergruppe ist
Eine Multisig-Wallet braucht zwei oder mehr Schlüssel, um jede Ausgabe zu genehmigen. Bei Bitcoin ist die Wallet-Adresse einfach ein Hash ihrer eigenen Regeln: die Liste der öffentlichen Schlüssel und die Zahl, „wie viele Signaturen erforderlich sind". Sie können diese Adresse auf einem Notizblock berechnen, weitergeben und Mittel empfangen, lange bevor irgendjemand die Blockchain berührt.
Solana kann das traditionell nicht. Wie der erste Artikel dieser Serie erklärt, verlangen die dominierenden Solana-Multisigs, dass Sie eine Erstellungstransaktion mit vom Ersteller gewähltem Zufall ausführen, bevor die Wallet-Adresse überhaupt existiert. SSPs eigenes Solana-Multisig-Programm verfolgt stattdessen den Bitcoin-Ansatz. Es ist selbstinitialisierend: Die Wallet-Adresse ist die Mitgliedergruppe.
Ein Hinweis vorweg: SSPs Solana-Multisig-Programm ist quelloffen (RunOnFlux/Solana-Multisig) und läuft derzeit nur auf dem Devnet — Solanas Testnetzwerk. Eine Mainnet-Bereitstellung hängt von einem externen Sicherheitsaudit ab.
Zwei Adressen: die Multisig und der Vault
SSPs Design verwendet zwei getrennte Adressen für jede Multisig-Wallet.
Die Multisig-Adresse hält die Regeln — die sortierte Liste der Mitgliederschlüssel, den Schwellenwert (das M in „M-von-N") und einen Zähler vorgeschlagener Transaktionen. Sie gehört SSPs Programm.
Die Vault-Adresse hält das Geld — SOL und SPL-Token. Sie gehört Solanas integriertem System Program und speichert keine eigenen Daten. Der Vault ist die Einzahlungsadresse: diejenige, die Sie jedem geben, der Sie bezahlen möchte.
Beide sind eine Program Derived Address, kurz PDA — eine Adresse ohne privaten Schlüssel, bewusst außerhalb der kryptografischen Kurve platziert, sodass kein Schlüssel sie je kontrollieren könnte. Nur das Programm, das sie abgeleitet hat, kann Bewegungen von ihr autorisieren. Dieses Detail wird am Ende wichtig.
Wie die Adresse aus den Mitgliedern berechnet wird
Genau dieser Teil macht die Wallet selbstinitialisierend. Um die Multisig-Adresse abzuleiten, in einfachen Worten: Man nehme die wörtliche Bezeichnung multisig, einen SHA-256-Hash der sortierten Mitgliederliste und den Schwellenwert; dann gebe man diese zusammen mit SSPs Programm-ID in Solanas Adressableitungsfunktion. Drei Details verdienen Aufmerksamkeit.
Die Mitglieder werden zuerst sortiert und dedupliziert. Eine 2-von-3-Wallet mit den Mitgliedern A, B, C ergibt genau dieselbe Adresse, ob Sie sie als C, A, B oder B, C, A auflisten. Die Reihenfolge spielt keine Rolle; nur die Gruppe zählt.
Der vollständige 32-Byte-Hash wird verwendet — niemals eine gekürzte Version. Den Hash zu kürzen würde einen echten Angriff eröffnen: Ein Angreifer könnte nach einer anderen Mitgliedergruppe suchen, die zum selben gekürzten Wert hasht, dann seine eigenen Mitglieder an Ihrer Adresse registrieren und alle Mittel abräumen, die Sie vorab eingezahlt haben. Der vollständige 32-Byte-Hash macht diese Suche astronomisch teuer, also geschieht das nie.
Der Schwellenwert ist Teil der Adresse. Eine 2-von-3-Wallet und eine 3-von-3-Wallet mit genau denselben Mitgliedern sind verschiedene Wallets an verschiedenen Adressen. Die Regeln sind in die Identität eingebrannt.
Die Vault-Adresse wird dann aus der Multisig-Adresse plus einer kleinen Indexnummer abgeleitet (SSP verwendet stets Index 0), sodass auch der Vault vollständig durch die Mitgliedergruppe und den Schwellenwert bestimmt ist.
Das praktische Ergebnis: Jeder kann beide Adressen offline berechnen, bevor eine einzige Transaktion gesendet wird. Sie können die Vault-Adresse weitergeben und Mittel in eine Wallet empfangen, die On-Chain noch nicht existiert — die Bitcoin-Eigenschaft, nach Solana gebracht.
Erlaubnisfreie Registrierung: Jeder kann sie einschalten
Die Wallet-Adresse existiert in dem Moment, in dem Sie die Mitglieder kennen. Aber um daraus zu zahlen, müssen die Regeln irgendwann On-Chain geschrieben werden — das Programm nennt diesen Schritt initialize.
Bei den meisten Solana-Multisigs kann nur ein privilegierter Ersteller den entsprechenden Schritt ausführen. In SSPs Programm ist die Initialisierung erlaubnisfrei: Jeder kann sie ausführen. Kein Erstellerkonto, keine Mitgliedersignatur, keine besondere Erlaubnis. Üblicherweise zahlt SSPs Relay-Dienst die kleine Mietgebühr und schaltet die Wallet ein, aber es spielt wirklich keine Rolle, wer es tut.
Das klingt alarmierend, bis Sie die Sicherheitsprüfung sehen. Wenn jemand die Wallet initialisiert, berechnet das Programm den SHA-256-Hash der gelieferten Mitgliederliste neu und lehnt die Transaktion ab, sofern dieser Hash nicht mit dem in die Adresse eingebrannten übereinstimmt. Solanas Konto-Framework bindet die Adresse unabhängig an denselben Hash. Zusammen bedeuten diese beiden Prüfungen: Die kanonische Adresse kann nur die kanonische Mitgliedergruppe halten. Niemand kann Ihre Adresse mit einer Mitgliederliste seiner Wahl registrieren — der Hash würde nicht übereinstimmen, und die Transaktion schlägt fehl.
Warum ein Fremder, der Ihre Wallet initialisiert, Ihnen nicht schaden kann
Gehen wir durch, was ein Angreifer tatsächlich versuchen könnte.
Er initialisiert mit einer anderen Mitgliedergruppe. Eine andere Gruppe hasht zu einem anderen Wert, der eine andere Adresse ableitet. Der Angreifer hat schlicht seine eigene, unverbundene Wallet anderswo auf Solana erstellt — keine Verbindung zu Ihrem Vault, kein Anspruch auf Ihre Mittel.
Er initialisiert mit Ihrer Mitgliedergruppe. Der Hash stimmt überein, also gelingt die Transaktion — aber alles, was er getan hat, ist, Ihre Mietgebühr für Sie zu zahlen. Die Wallet ist nun genau mit den Regeln registriert, die Sie erwartet haben, und der Angreifer ist kein Mitglied, also kann er nichts vorschlagen, genehmigen oder ausführen. Geld liegt nie an der Multisig-Adresse selbst — es liegt im Vault, der dem System gehört und nicht gekapert werden kann. Wer auch immer die Wallet initialisiert und wann immer er es tut, das Ergebnis ist dieselbe kanonische, korrekt geregelte Wallet.
Der Schwellenwert wird beim Ausgeben geprüft, nicht beim Registrieren
Dies ist dasselbe Modell, das Bitcoins P2WSH-Multisig verwendet, und es lohnt sich, es klar zu sagen: Der M-von-N-Schwellenwert wird nur durchgesetzt, wenn Mittel sich bewegen — niemals bei der Registrierung.
Die Registrierung hält bloß fest: „Dies sind die Mitglieder, dies ist der Schwellenwert." Sie verlangt keine Signaturen, weil sie keinen Schaden anrichten kann. Das eigentliche Tor ist der Ausgabefluss, wo das Programm die Genehmigungen zählt und sich weigert zu handeln, bis genügend Mitglieder zugestimmt haben. Die Adresse ist der Hash der Regeln; jeder kann sie finanzieren; nur gültige Signaturen können ausgeben. Zur Auffrischung, was „M-von-N" bedeutet, siehe 2-von-2 vs 2-von-3 vs M-von-N Multisig.
Der vollständige Lebenszyklus, von Anfang bis Ende
Setzt man die Teile zusammen, sieht das Leben einer SSP-Solana-Multisig-Wallet so aus:
- Ableiten. Jeder berechnet die Multisig- und Vault-Adressen offline aus den Mitgliedern und dem Schwellenwert. Keine Blockchain, keine Kosten.
- Vorab finanzieren. Jeder sendet SOL oder Token an die Vault-Adresse — das funktioniert sogar, bevor die Wallet registriert ist.
- Initialisieren. Jeder, üblicherweise SSPs Relay, reicht die erlaubnisfreie Registrierungstransaktion ein. Das Programm verifiziert den Mitglieder-Hash und schreibt die kanonischen Regeln On-Chain.
- Vorschlagen. Ein Mitglied erstellt einen Transaktionsvorschlag, kompakt auf einem eigens dafür vorgesehenen Vorschlagskonto gespeichert.
- Genehmigen. Jedes Mitglied genehmigt den Vorschlag, jeweils einmal. Genehmigungen sammeln sich On-Chain.
- Ausführen. Sobald die Genehmigungen den Schwellenwert erreichen, kann jeder die Ausführung auslösen. Das Programm markiert den Vorschlag zuerst als ausgeführt — ein bewusster Schutz, damit er nie zweimal läuft — und führt dann jede Anweisung aus, wobei der Vault selbst als Unterzeichner auftritt.
Dieser letzte Schritt ist es, wo sich die schlüssellose Vault-Adresse auszahlt. Da der Vault eine PDA ohne privaten Schlüssel ist, kann weder ein Mensch noch ein Programm seine Mittel durch Signieren auf gewöhnliche Weise bewegen. Der einzige Weg hinaus ist, dass SSPs Programm einen genehmigten, schwellenwert-erreichten Vorschlag ausführt — es „signiert" für den Vault, indem es das Ableitungsrezept des Vaults der Solana-Laufzeit vorlegt, eine Erlaubnis, die es allein deshalb erhält, weil es Eigentümer der Adresse ist.
Kein Ersteller, kein Admin, keine Schlüsselrotation an Ort und Stelle
Zwei letzte Eigenschaften binden das Design zusammen.
Die Mitgliedergruppe und der Schwellenwert sind unveränderlich. Sobald eine Wallet initialisiert ist, kann keine Anweisung im Programm ihre Mitglieder oder ihren Schwellenwert ändern — dafür gibt es keinen Codepfad. Um zu ändern, wer eine Wallet kontrolliert — was andere Systeme lose „Schlüsselrotation" nennen — erstellen Sie eine neue Multisig mit der neuen Mitgliedergruppe und verschieben die Mittel dorthin. Die alte Adresse behält ihre alten Regeln für immer.
Es gibt keine Erstellerrolle und keinen Admin-Schlüssel, niemals. Viele Multisig-Designs behalten ein privilegiertes Konto, das die Mitglieder überstimmen oder die Konfiguration ändern kann. SSPs Programm hat keines — nichts zu kompromittieren, kein Admin-Schlüssel zum Phishing, kein Ersteller zum Nötigen. Die Mitglieder und der Schwellenwert sind die ganze Geschichte.
Dieser Minimalismus ist ein bewusster Kompromiss: SSP baute ein kleines, deterministisches Primitiv statt einer funktionsreichen Governance-Plattform. Der nächste Artikel, SSPs Solana-Multisig vs Squads, vergleicht dieses Design ehrlich mit Squads V4 — der reifen, auditierten, dominierenden Solana-Multisig. Für den Produktkontext beschreibt die Ankündigung der Solana-Unterstützung, was in SSP Wallet v1.39.0 ankam.
Die Kernidee ist klein genug, um sie im Kopf zu behalten: Bei SSPs Solana-Multisig ist die Wallet-Adresse ein Fingerabdruck ihrer eigenen Regeln. Kennen Sie die Mitglieder und den Schwellenwert, kennen Sie die Adresse. Nichts weiter wird benötigt, und nichts weiter wird vertraut.
