Eine Wallet-Adresse wirkt wie etwas Einfaches: eine Zeichenkette, die man kopiert, einfügt und an die man Geld sendet. Bei Bitcoin ist sie fast so einfach. Bei Solana ist es überraschend schwierig, eine geteilte Wallet — ein Multisig — hinter eine Adresse zu stellen. Dieser Artikel erklärt, warum, und stellt die Frage, die der Rest dieser Serie beantwortet.
Was eine Multisig-Adresse versprechen muss
Eine Multisig-Wallet wird von mehreren Schlüsseln kontrolliert, von denen eine feste Anzahl zustimmen muss, bevor Geld bewegt wird. Ein „2-von-3"-Multisig zum Beispiel hat drei Schlüssel und benötigt, dass zwei beliebige eine Zahlung freigeben. Der Zweck ist, einzelne Ausfallpunkte zu beseitigen: Sie verlieren einen Schlüssel, oder ein Schlüssel wird gestohlen, und Ihr Guthaben ist trotzdem sicher.
Damit das nützlich ist, muss die Adresse zwei Versprechen halten. Erstens muss sie im Voraus bekannt sein — Sie wollen jemandem eine Einzahlungsadresse geben, bevor Sie die Einrichtung abgeschlossen haben. Zweitens muss sie ehrlich sein: Wer Geld an diese Adresse sendet, soll darauf vertrauen können, dass nur die vereinbarte Gruppe von Schlüsseln, nach der vereinbarten Regel, jemals daraus ausgeben kann. Behalten Sie diese zwei Versprechen im Kopf. Sie sind der rote Faden durch alles, was folgt.
Bei Bitcoin ist die Adresse die Regel
Bitcoin lässt das einfach erscheinen. Ein Bitcoin-Multisig wird durch ein kleines Skript beschrieben: die Liste der öffentlichen Schlüssel plus die „M-von-N"-Regel. Um die Adresse zu erhalten, nimmt man dieses Skript und hasht es. Die Adresse (eine P2WSH-Adresse) ist buchstäblich der Hash der Ausgaberegeln.
Das hat eine still wirkende, kraftvolle Folge. Jeder kann die Adresse offline berechnen, auf einem Laptop ohne Internet, bevor eine einzige Transaktion gesendet wird. Es gibt keinen Schritt „die Wallet erstellen" — die Wallet muss nicht im Netzwerk existieren, um Geld zu empfangen. Das Skript wird erst später offengelegt, beim Ausgeben der Mittel, und das Netzwerk prüft, ob das offengelegte Skript zur Adresse passt und ob genügend gültige Signaturen vorliegen. Adresse im Voraus bekannt: ja. Ehrlich: ja — weil die Adresse aus der Regel selbst abgeleitet ist, ergibt ein anderer Satz von Schlüsseln eine andere Adresse.
Bei Solana ist eine Adresse ein Konto, das erstellt werden muss
Solana funktioniert anders. Bei Solana ist alles ein Konto — ein Speicherplatz on-chain mit einem Eigentümer. Ihr Guthaben lebt in Konten, Programme leben in Konten, und die Konfiguration eines Multisig lebt ebenfalls in einem Konto. Entscheidend ist, dass Konten nicht kostenlos ins Dasein treten. Ein Konto muss ausdrücklich erstellt und bezahlt werden: jemand finanziert es mit einer kleinen Menge SOL, „Miete" genannt, damit das Netzwerk seine Daten speichert.
Ein Multisig auf Solana ist daher nicht nur eine Adresse — es ist ein programmgesteuertes Konto, das die Mitgliederliste und den Schwellenwert enthält. Und dieses Konto muss durch eine Transaktion erstellt werden, bevor das Multisig irgendetwas tun kann. Das ist die Wurzel der Schwierigkeit: Eine geteilte Wallet auf Solana hat einen Einrichtungsschritt, den Bitcoin schlicht nicht hat.
PDAs: Adressen ohne privaten Schlüssel
Solana hat durchaus ein elegantes Werkzeug dafür, die Program Derived Address, kurz PDA. Eine normale Solana-Adresse hat einen passenden privaten Schlüssel — wer den Schlüssel besitzt, kontrolliert die Adresse. Eine PDA ist absichtlich so gebaut, dass sie außerhalb der Kurve liegt: Sie ist eine gültig aussehende Adresse, für die kein privater Schlüssel existiert und keiner existieren kann. Niemand kann persönlich für sie signieren.
Stattdessen wird eine PDA deterministisch abgeleitet. Man nimmt einige Eingabewerte — „Seeds" genannt — plus die ID eines Programms, schickt sie durch eine Einwegfunktion, und heraus kommt die Adresse. Dieselben Seeds und dasselbe Programm ergeben stets dieselbe PDA, sodass jeder sie reproduzieren kann. Und weil es keinen privaten Schlüssel gibt, kann nur das besitzende Programm Aktionen für diese Adresse autorisieren — über einen Mechanismus namens programmübergreifender Aufruf mit invoke_signed: Das Programm legt die Seeds der Solana-Laufzeit vor, und die Laufzeit gewährt ihm Signierbefugnis für die PDA. Es wird nie eine kryptografische Signatur erzeugt — das Recht zu handeln kommt aus der Kenntnis der Seeds, nicht aus dem Besitz eines Schlüssels.
Eine PDA ist genau das richtige Zuhause für ein Multisig: eine Adresse, die von Programmlogik statt von einer einzelnen Person kontrolliert wird. So weit, so gut. Das Schwierige ist, was als Seeds gewählt wird.
Das Problem des Finanzierens vor dem Erstellen
Hier geraten die vorherrschenden Solana-Multisigs in Schwierigkeiten. Anders als beim deterministischen Bitcoin-Modell leiten die meistgenutzten Solana-Multisigs — Squads V4 ist das führende Beispiel, ausgereift und stark auditiert — die Adresse des Multisig aus einem frisch erzeugten Zufallswert ab, der zum Erstellungszeitpunkt gewählt wird, und nicht aus dem Mitgliedersatz. In Squads V4 heißt dieser Wert create_key, ein flüchtiger Schlüssel, der entsteht, wenn ein Ersteller die Erstellungstransaktion ausführt.
Die Adresse aus einem zufälligen create_key abzuleiten, ist eine bewusste, vernünftige Designentscheidung — sie umgeht einen unbequemen Grenzfall, in dem zwei verschiedene Gruppen genau dieselbe Mitgliederzusammensetzung wünschen. Sie hat aber zwei Folgen, die man klar verstehen sollte:
- Sie können die Adresse nicht im Voraus kennen. Der Seed existiert erst, wenn jemand die Erstellungstransaktion ausführt, also auch die Adresse nicht. Es gibt keine Möglichkeit, eine Einzahlungsadresse auszudrucken und sie vor der Einrichtung zu finanzieren — das Problem des Finanzierens vor dem Erstellen. Das erste Versprechen bricht.
- Der Ersteller ist ein einzelner Vertrauenspunkt bei der Einrichtung. Ein bestimmtes Konto muss diese Erstellungstransaktion ausführen und diesen Zufallswert wählen. Für das kurze Fenster der Einrichtung vertrauen Sie darauf, dass diese Partei es korrekt tut.
Nichts davon macht Squads V4 unsicher — es ist das kampferprobteste Multisig auf Solana und sichert sehr große Summen. Es ist schlicht eine andere Form von Vertrauen als bei Bitcoin. Die Adresse ist nicht mehr „der Hash der Regel"; sie ist „was auch immer die Erstellungstransaktion hervorgebracht hat".
Ethereum fand einen Mittelweg
Ethereum stand vor einem ähnlichen Problem und beantwortete es mit einer Funktion namens CREATE2. Sie erlaubt es, die Adresse eines Smart Contracts vor dessen Bereitstellung aus festen Eingaben zu berechnen. Wallets wie Safe nutzen das, um Ihnen eine sogenannte kontrafaktische Adresse zu geben: eine echte, finanzierbare Adresse, die Sie teilen und an der Sie Geld empfangen können, während der eigentliche Vertrag verzögert bereitgestellt wird — erst wenn Mittel zum ersten Mal bewegt werden müssen. Der neuere Standard zur Kontoabstraktion, ERC-4337, formalisiert dieselbe Idee. Ethereum gewinnt so das Versprechen „im Voraus bekannt" zurück, obwohl es, wie Solana, letztlich ein On-Chain-Objekt benötigt.
Die Frage, die diese Serie beantwortet
Legen Sie die drei Modelle nebeneinander. Bitcoin: Die Adresse ist der Hash der Regel — offline berechenbar, ehrlich durch Konstruktion, kein Erstellungsschritt. Ethereum: eine kontrafaktische Adresse — im Voraus bekannt, mit aufgeschobener Bereitstellung. Solanas allgemeine Multisigs: Die Adresse stammt aus Zufall des Erstellungszeitpunkts — nicht im Voraus bekannt, mit einem Ersteller, dem man bei der Einrichtung vertrauen muss.
Hier also die Frage. Solana braucht Konten, und Konten müssen erstellt werden — das wird nicht verschwinden. Aber muss ein Solana-Multisig die Bitcoin-Eigenschaft aufgeben? Könnte die Adresse stattdessen rein aus dem Mitgliedersatz und dem Schwellenwert — der Regel selbst — abgeleitet werden, sodass sie offline berechenbar, vor der Einrichtung finanzierbar und ehrlich ist, weil eine andere Gruppe von Schlüsseln eine andere Adresse ergibt?
Genau diese Eigenschaft hat das SSP-Team in sein eigenes Solana-Multisig-Programm eingebaut. Der nächste Artikel zeigt, wie: eine Adresse, die der Mitgliedersatz ist, ein Tresor, den Sie finanzieren können, bevor irgendetwas on-chain registriert ist, und ein Registrierungsschritt, der überhaupt keinen Ersteller braucht. Das Design wurde zusammen mit der Solana-Unterstützung in SSP Wallet ausgeliefert — siehe die Release-Ankündigung — und im Einklang damit, wie SSP mit Sicherheit umgeht, ist das Programm derzeit nur auf Devnet und wartet vor dem Mainnet auf eine externe Prüfung. Wenn Multisig selbst für Sie noch neu ist, beginnen Sie mit was ein Multisig ist und warum es wichtig ist; andernfalls lesen Sie weiter.
