Solana in SSP

·7 Min. Lesezeit·Von SSP Editorial Team
SSP-Academy-Titelbild: Solana in SSP

Solana in SSP

Solana ist schnell, günstig und zunehmend der Ort, an dem Stablecoins tatsächlich bewegt werden. Es ist zugleich die Chain, auf der Multisig in Eigenverwahrung historisch am schwersten sauber umzusetzen war — nicht weil die Kryptografie schwierig wäre, sondern weil Solanas Kontenmodell „eine Adresse, die mehrere Parteien kontrollieren“ zu einem viel merkwürdigeren Objekt macht, als es das auf Bitcoin ist.

SSP hält SOL und SPL-Token im selben 2-von-2-Multisig, das du bereits für Bitcoin und Ethereum nutzt: ein Schlüssel in der Browser-Erweiterung, ein Schlüssel auf deinem Telefon, beide für jede Transaktion erforderlich. Dieser Artikel erklärt, was das speziell auf Solana bedeutet — wie die Adresse abgeleitet wird, wer die Gebühren zahlt, was deine Geräte prüfen und welche Teile sich wirklich von den Chains unterscheiden, die du schon kennst.

Die Solana-Chain-Ansicht in SSP Wallet, Dark Mode

Was Solana aus Sicht der Eigenverwahrung ist

Solana ist eine einzige globale Zustandsmaschine, die Transaktionen parallel statt nacheinander verarbeitet. Für jemanden, der selbst verwahrt, zählen drei Eigenschaften mehr als die Durchsatz-Schlagzeile.

Erstens: alles ist ein Konto. Dein Guthaben, das Mint eines Tokens, der Code eines Programms und die von einem Programm gespeicherten Daten liegen alle in Konten mit einer Adresse und einem Eigentümer. Zweitens: Konten kosten Miete. Um on-chain zu existieren, muss ein Konto ein Mindestguthaben an SOL halten, das proportional zu seiner Größe ist. Diese Hinterlegung ist erstattungsfähig, wenn das Konto geschlossen wird, aber sie ist echtes Geld, das irgendwoher kommen muss. Drittens: Transaktionen verfallen schnell — eine normale Solana-Transaktion verweist auf einen aktuellen Blockhash und wird nach etwa einer Minute ungültig.

Jede dieser Eigenschaften hat unmittelbare Folgen für das Signieren mit zwei Geräten, und jede wird in SSP ausdrücklich behandelt statt übertüncht. Solanas eigene Kerndokumentation ist die Primärquelle zum Konten- und Mietmodell, wenn du die Rohfassung willst.

Eine Adresse ohne Ersteller

Bei den meisten Solana-Multisig-Entwürfen muss die Wallet erstellt werden. Jemand sendet eine Transaktion, die sie begründet, und die resultierende Adresse hängt von Eingaben ab, die während dieser Transaktion gewählt werden — typischerweise ein zufälliger Einmalschlüssel. Praktisch heißt das: Die Adresse existiert nicht, bis ein Ersteller sie ins Leben ruft, und kann vorher keine Mittel empfangen.

Das On-Chain-Programm von SSP arbeitet anders. Deine Vault-Adresse ist ein Fingerabdruck aus der sortierten Mitgliedermenge plus der Freigabeschwelle — sonst nichts. Wer die Mitglieder und die Schwelle kennt, kann die Adresse offline berechnen, bevor irgendetwas die Chain berührt. Die Registrierung ist erlaubnisfrei: Das Programm prüft lediglich, ob die von dir vorgelegten Mitglieder tatsächlich zu der beanspruchten Adresse hashen, sodass eine Registrierung nichts daran ändert, wer ausgeben darf.

Deshalb gibt es keinen Ersteller, dem man vertrauen müsste, keinen privilegierten Registrar und keinen Admin-Schlüssel. Ausgaben werden ausschließlich durch die Schwellenprüfung im Programm gesteuert. Wenn du das ganze Bild willst: warum Solana-Multisig-Adressen schwierig sind behandelt das zugrunde liegende Problem, das selbstinitiierende Solana-Multisig das Programm, und SSP gegen Squads V4 ist der direkte Vergleich.

Falls dir das 2-von-2-Modell selbst neu ist, beginne mit was ist 2-von-2-Multisig.

Warum zwei Geräte eine Durable Nonce brauchten

Hier ist das Problem, das der Verfall schafft. Deine Erweiterung baut und signiert eine Transaktion. Dein Telefon muss sie anschließend freigeben. Wenn du den Raum verlässt, isst und zurückkommst, ist der Blockhash, auf den die Transaktion verwies, längst tot und das Ganze muss neu gebaut werden.

SSP löst das mit einem Durable-Nonce-Konto, das aus deiner Multisig-Adresse abgeleitet wird. Statt eines aktuellen Blockhashs verweist die Transaktion auf eine Nonce, die erst weiterzählt, wenn die Transaktion tatsächlich landet. Das Signierfenster ist keine Stoppuhr mehr. Du kannst Minuten oder Stunden später auf dem Telefon freigeben und die Transaktion ist weiterhin gültig — aber sie lässt sich trotzdem nur einmal verwenden, weil ihre Ausführung die Nonce weiterzählt.

Das Nonce-Konto wird beim ersten Senden angelegt und ist eines der beiden Konten, deren Miete in den Kosten deines ersten Sendevorgangs auftaucht. Durable Nonces und Signieren mit zwei Geräten geht tiefer.

Wer die Gebühren zahlt

Auf Solana ist das Konto, das die Gebühr einer Transaktion trägt, der Fee Payer, und es muss signieren. Für ein frisches Multisig entsteht daraus ein unangenehmes Startproblem: Der Vault braucht SOL, um die Transaktion zu bezahlen, die sein SOL bewegen würde, und die Konten, die Miete benötigen, existieren noch gar nicht.

SSP verwendet einen Paymaster. Das SSP-Relay betreibt ein Konto, das als Fee Payer signiert, die Netzwerkgebühr und jede Miete vorstreckt und von deinem Vault innerhalb derselben Transaktion erstattet wird. Es gibt keinen separaten Schritt, keinen eingeräumten Kredit und keine Möglichkeit, dass die Erstattung ohne deine beiden Signaturen geschieht — sie fährt in dem Vorschlag mit, den deine Geräte freigeben.

Zwei Konsequenzen lohnt es sich zu verinnerlichen:

  • Du musst keine Adresse vorab mit SOL für Gas befüllen. SOL empfangen, SOL senden. Beim ersten Senden werden die Konten angelegt.
  • Dein erster Sendevorgang kostet mehr als die danach. Er zahlt die dauerhafte Miete für das Multisig-Konto und das Nonce-Konto; spätere Sendevorgänge zahlen kaum mehr als die Netzwerkgebühr. Die genauen Zahlen stehen im Gebührenartikel dieser Serie.

Falls dir Paymaster als Konzept neu sind: Gas-Sponsoring und Paymaster, erklärt behandelt das allgemeine Muster — SSP nutzt dieselbe Idee bereits auf EVM-Chains, beschrieben in Ethereum in SSP.

Was du halten kannst

Solana in SSP unterstützt natives SOL und SPL-Token. Ab Werk gehören dazu Circles offizielles USDC-Mint und FLUX auf Solana; weitere SPL-Token, die SSP in deinem Vault findet, löst es zusätzlich auf.

Die Unterscheidung, über die viele stolpern: Auf Solana hältst du einen Token nicht an deiner Hauptadresse. Jeder Token lebt in seinem eigenen assoziierten Token-Konto, das deiner Adresse gehört — eines pro Mint. Auch dieses Konto braucht Miete, weshalb das Senden eines SPL-Tokens an jemanden, der diesen Token nie gehalten hat, etwas mehr kostet: Du bezahlst dafür, dessen Token-Konto überhaupt entstehen zu lassen. SSP legt es automatisch als Teil der Überweisung an, statt mit einem Fehler abzubrechen, und der Artikel zu Token-Konten in dieser Serie entfaltet die Details.

Eine Solana-Überweisung in SSP Wallet zusammenstellen, Dark Mode

Was deine Geräte vor dem Signieren prüfen

Solana-Transaktionen sind auf eine Weise undurchsichtig, wie es Bitcoin-Transaktionen nicht sind. Was eine Transaktion tut, steckt in den Instruktionsdaten, und eine Wallet muss diese Daten dekodieren, bevor sie dir irgendetwas Wahres darüber sagen kann. Eine Wallet, die schlicht anzeigt, was ein Server ihr mitgeteilt hat, verlangt von dir, dem Server zu vertrauen.

SSP dekodiert die Transaktion auf deinen eigenen Geräten, Byte für Byte, mithilfe der quelloffenen Bibliothek @runonflux/solana-multisig. Empfänger, Betrag und Token-Mint werden aus den Rohbytes gelesen und mit dem verglichen, was angezeigt wird. Stimmen sie nicht überein, wird das Signieren vollständig blockiert — eine Abweichung an dieser Stelle deutet auf einen aktiven Angriff hin, nicht auf einen Darstellungsfehler. Bei SPL-Überweisungen sind die Dezimalstellen des Tokens in der signierten Instruktion selbst eingebettet, sodass ein Mint mit abweichenden Dezimalstellen dazu führt, dass das On-Chain-Programm die Transaktion ablehnt.

Dasselbe Prinzip gilt für das Programm: Mainnet-Builds sind aus dem veröffentlichten Quelltext reproduzierbar, sodass der unter SSPWVu7dtTDkZYmDx73StqV46PioSmdiNE7igpjHK1r bereitgestellte Bytecode unabhängig neu gebaut und verglichen werden kann. Eine Sicherheitsaussage ist nur so viel wert wie deine Möglichkeit, sie selbst zu überprüfen.

Erste Schritte

Aktualisiere SSP Wallet und SSP Key auf die neueste Version und aktiviere Solana im Chain-Auswahlmenü. Mit dem Batch-Sync von v2 kannst du sie zusammen mit beliebigen anderen Chains per einer einzigen Freigabe auf dem Telefon aktivieren. Falls du SSP noch gar nicht eingerichtet hast, ist deine erste SSP-Wallet einrichten der Anfang.

Von da an verhält sich Solana wie jede andere Chain in SSP: Sie zählt zu deiner Portfolio-Summe, Überweisungen folgen demselben Ablauf aus Zusammenstellen → Prüfen → Freigeben mit der vollständigen Empfängeradresse auf dem Bildschirm, und jede Transaktion wird von deinen beiden Geräten gemeinsam signiert. Die Ankündigung zum Mainnet-Start beschreibt, was wann ausgeliefert wurde.

Diesen Artikel teilen

Verwandte Artikel