Was eine Transaktion wirklich aufhält
Jedes Verwahrungsprodukt hat eine Funktionsseite mit einer Liste von Kontrollen: Whitelists, Ausgabelimits, Zeitsperren, Freigabe-Workflows, IP-Beschränkungen. Sie sind alle real, und sie sind alle nützlich. Aber sie sind nicht alle dieselbe Art von Sache, und sie als austauschbar zu behandeln ist der Weg, auf dem Organisationen mit einem Sicherheitsmodell enden, das schwächer ist, als das Marketing nahelegte.
Es gibt eine Frage, die sie sauber trennt: wenn jedes Stück Software im System falsch oder feindselig wäre, würde diese Kontrolle dann noch halten?
Für den größten Teil der Liste lautet die Antwort nein. Für genau eine lautet sie ja. In diesem Artikel geht es darum, sie auseinanderzuhalten.
Drei Schichten, nicht eine
Zwischen dem Wunsch, Mittel zu bewegen, und dem tatsächlichen Bewegen der Mittel hat SSP Enterprise drei verschiedene Barrieren. Sie versagen unterschiedlich, und zu wissen, welche welche ist, ist der ganze Punkt.
Die Schichten sind nicht nach Nützlichkeit geordnet. Sie sind danach geordnet, was es braucht, sie zu überwinden.
Schicht 1: die Koordinationsschicht
Das ist die Richtlinien-Engine, und dort lebt der Großteil der Funktionen. SSP Enterprise unterstützt Adress-Whitelists, Beschränkungen nach Zieltyp, Zeitsperren, die Transaktionen oberhalb einer Wertschwelle verzögern, Regeln, die ab einem bestimmten Betrag eine Admin-Freigabe verlangen, und IP-Beschränkungen für den Organisationszugang. Richtlinienvorlagen liefern sinnvolle Voreinstellungen, die sich anschließend als echte, bearbeitbare Regeln materialisieren.
Diese leisten echte Arbeit. Eine Whitelist verhindert, dass eine vertippte Adresse überhaupt zu einem Vorschlag wird. Eine Zeitsperre gibt einem Treasury-Team ein Fenster, um etwas Falsches zu bemerken. Eine Freigaberegel macht aus einer großen Überweisung ein Gespräch zu zweit statt des Nachmittags einer einzelnen Person.
Was sie nicht sind, ist Verwahrungsdurchsetzung. Diese Regeln leben in SSPs Software und werden von SSPs Servern ausgewertet. Sie sind nicht Teil der Vault-Adresse, und die Blockchain hat nie von ihnen gehört. Würde die Richtlinien-Engine umgangen — durch einen Fehler, einen kompromittierten Server oder einen feindseligen Betreiber —, dann würden die Regeln schlicht nicht greifen.
Wir sagen das deutlich, weil die Alternative schlimmer ist. Ein Team, das seine Whitelist für eine Verwahrungsgarantie hält, wird seine Schwelle entsprechend bemessen, und genau dieser Fehler macht aus einem überlebbaren Vorfall einen nicht überlebbaren.
Schicht 2: deine Geräte
Die zweite Barriere ist das Gerätepaar, das jeder Signierende hält, und sie ist in einem wichtigen Punkt stärker als die erste: sie vertraut auch SSP nicht.
Erreicht ein Vorschlag einen Signierenden, dekodieren dessen Geräte die Rohbytes der Transaktion lokal und vergleichen das Ergebnis mit dem, was angezeigt wird. Empfänger, Betrag, Token — aus den Bytes gelesen, nicht aus der Beschreibung des Servers übernommen. Auf Solana ist dieser Vergleich ausdrücklich und unnachgiebig: Widersprechen die dekodierten Bytes der angezeigten Nutzlast, wird das Signieren hart blockiert statt bloß gewarnt, denn eine Abweichung dort deutet auf einen laufenden Angriff und nicht auf einen Darstellungsfehler.
Die Geräte erzwingen außerdem eine eigene, unabhängige Obergrenze für Gebührenerstattungen. Das Relay schlägt die Gebühr vor; die Wallet weigert sich, eine oberhalb eines fest einprogrammierten Maximums zu signieren, ganz gleich, was das Relay behauptet — das begrenzt jeden über Gebühren geleiteten Abfluss, selbst wenn das Relay vollständig feindselig ist. Auch die Simulation läuft vor der Freigabe und führt den Vorschlag gegen den aktuellen Chain-Zustand aus, damit der Prüfbildschirm zeigen kann, was die Transaktion tatsächlich täte; das kam mit Transaktionssimulation und Risikowarnungen.
Diese Schicht besiegt einen kompromittierten Server. Was sie nicht besiegen kann, ist ein kompromittiertes Gerät oder eine Person, die ohne Lesen freigibt. Sie verlangt außerdem beide Geräte eines Signierenden, und genau deshalb zählt das 2-von-2 pro Person: Schicht 2 ist nur so stark wie das schwächere der beiden Geräte, und sie sind bewusst verschiedene Arten von Hardware.
Schicht 3: die Chain
Die dritte Barriere ist die einzige, die hält, wenn alles andere versagt hat.
Die Adresse eines Vaults leitet sich aus dem Signierendenkreis und der Freigabeschwelle ab. Eine Transaktion, die nicht die erforderliche Anzahl gültiger Signaturen trägt, ist keine abgelehnte Transaktion — sie ist eine ungültige. Jeder Knoten im Netzwerk kommt unabhängig zum selben Schluss, und kein noch so weitreichender Zugang zu SSPs Infrastruktur ändert diese Arithmetik.
Deshalb verdient die Schwelle beim Anlegen eines Vaults das meiste Nachdenken, und deshalb lässt sie sich danach nicht ändern. Deinen ersten Enterprise-Vault einrichten behandelt die Mechanik; 2-von-2 vs. 2-von-3 vs. m-von-n behandelt die Wahl der Zahl.
Wo jede Schicht versagt
Die Ausfallmodi nebeneinanderzulegen macht die Entwurfsaufgabe offensichtlich.
| Szenario | Koordinationsschicht | Deine Geräte | Die Chain |
|---|---|---|---|
| Ein Signierender vertippt eine Adresse | Stoppt es | Stoppt es, wenn gelesen wird | Interessiert es nicht |
| Ein Signierender wird zur Freigabe gephisht | Stoppt es, wenn nicht auf der Whitelist | Zeigt die Wahrheit; er kann trotzdem freigeben | Interessiert es nicht |
| SSPs Relay ist kompromittiert | Versagt | Hält — Bytes werden lokal dekodiert | Hält |
| SSPs Richtlinien-Engine hat einen Fehler | Versagt | Hält | Hält |
| Der Laptop eines Signierenden ist kompromittiert | Dafür nicht ausgelegt | Teilweise — das Telefon prüft weiterhin | Hält |
| Ein Angreifer hält weniger als M Signierende | Dafür nicht ausgelegt | Hält | Hält |
| Ein Angreifer hält M oder mehr Signierende | Versagt | Versagt | Versagt |
Die letzte Zeile ist der ehrliche Boden des Modells. Multisig schützt davor, dass eine Minderheit deiner Signierenden kompromittiert wird. Es schützt nicht vor einer Mehrheit, und kein Produkt kann etwas anderes behaupten, ohne zu lügen. Deshalb zählen die Schwelle und die Unabhängigkeit deiner Signierenden mehr als jede Funktionsliste.
Was das für deinen Aufbau bedeutet
Entwirf den Vault so, dass er allein mit Schicht 3 sicher ist. Wähle Schwelle und Signierendenkreis, als gäbe es die Richtlinien-Engine nicht. Fühlt sich die Antwort unangenehm an, ist die Lösung eine andere Schwelle oder andere Signierende — nicht mehr Richtlinien.
Füge dann Richtlinien für das hinzu, worin Richtlinien gut sind. Whitelists fangen menschliche Fehler. Zeitsperren kaufen Reaktionszeit. Freigaberegeln schaffen ein zweites Augenpaar bei großen Beträgen. Das sind Prozessverbesserungen und sie senken Vorfälle wirklich; sie sind nur nicht das, was zwischen einem Angreifer und deiner Kasse steht.
Halte deine Signierenden wirklich unabhängig. Zwei Signierende auf demselben Laptop, im selben Gebäude, mit derselben Wiederherstellungsvorkehrung, sind näher an einem Signierenden als an zweien. Die Stärke von Schicht 3 kommt aus der Schwierigkeit, M getrennte Personen mit M getrennten Gerätepaaren zu kompromittieren.
Bring Signierende dazu, den Prüfbildschirm wirklich zu lesen. Schicht 2 ist die einzige Barriere, die einen legitim wirkenden, aber falschen Vorschlag abfangen kann, und sie wirkt nur, wenn ein Mensch sich mit dem befasst, was sein Gerät dekodiert hat. Ein eingeübter Hin- und Rückweg beim Anlegen des Vaults hilft, diese Gewohnheit aufzubauen, solange nichts auf dem Spiel steht.
Stelle anderen Verwahrungsanbietern dieselbe Frage. Ob du SSP nutzt oder nicht, dieser Rahmen ist übertragbar: Frage bei jeder Kontrolle auf der Funktionsseite, ob sie überlebt, wenn die eigene Software des Anbieters falsch liegt. Die Antworten sind oft aufschlussreich, und ein Anbieter, der klar antwortet, sagt dir etwas Gutes darüber, wie er denkt.
Zu den Wegen, auf denen ein Mehrschlüssel-Aufbau in der Praxis untergraben wird, geht Multisig-Ausfallmodi und wie SSP sie entschärft sie einzeln durch, und SSP Enterprise: Multisig-Vaults für Teams ist der Überblick, wie die Teile zusammenpassen.
