Transaktionssimulation: was eine Transaktion tut, bevor du sie signierst

Die Adresse stimmt. Der Betrag stimmt. Du hast beides geprüft. Und die Transaktion ist trotzdem nicht das, wofür du sie hältst.

Das ist kein Gedankenspiel. Es ist die gewöhnliche Form fast aller Krypto-Verluste, an denen ein sorgfältiger Mensch beteiligt ist. Niemand hat ihn überredet, Geld an einen Fremden zu schicken. Er hat etwas freigegeben, dessen sichtbare Teile alle korrekt waren und dessen Folgen ganz woanders lagen — in einer Token-Freigabe, in einem Vertragsaufruf, in einem einzigen Zeichen einer Adresse, die er schon hundertmal gesehen hatte.

Simulation ist der Versuch, diese Lücke zu schließen: dir die Wirkung einer Transaktion zu zeigen statt ihres Inhalts, bevor deine Signatur sie wahr macht.

Die Lücke zwischen dem, was du meintest, und dem, was du signierst

Eine Transaktion ist kein Satz. Sie ist Bytes.

Wenn diese Bytes eine schlichte Überweisung sind, ist die Lücke zwischen dem, was sie sagen, und dem, was sie tun, klein: eine Adresse, ein Betrag, eine Gebühr. Sind sie ein Vertragsaufruf, kann die Lücke gewaltig sein. approve sieht aus wie eine Erlaubnis. Es ist ein dauerhaftes Recht einer anderen Adresse, deine Token zu bewegen, und nach dem ERC-20-Standard verlangt nichts an diesem Aufruf eine Grenze für Höhe oder Dauer. Eine einzige, einmal signierte Freigabe kann Monate später geleert werden.

Die Oberfläche, auf die du beim Signieren schaust, muss diese Bytes in einen Satz übersetzen. Diese Übersetzung ist die Angriffsfläche. Wenn sie von demjenigen erzeugt wird, der deine Signatur will, kann sie alles Mögliche sagen.

Ein Probelauf, kein Versprechen

Simulation heißt: die Transaktion gegen den aktuellen Zustand der Chain ausführen, ohne sie zu senden, und festhalten, was sich ändert.

In SSP Enterprise geschieht das beim Anlegen eines Vorschlags, bevor jemand signiert. Die Simulation wird aus dem gebaut, was der Builder des Vorschlags erzeugt hat — Empfänger, Beträge, Token-Vertrag und Calldata, die SSP selbst zusammengesetzt hat —, niemals aus rohem, signiertem Hex, das ein Client geliefert hat. Sie läuft rein lesend. Drei Engines decken die verschiedenen Chain-Familien ab:

• EVM-Chains führen einen lesenden Aufruf gegen eine Node aus und lesen die daraus folgenden Saldoänderungen und den dekodierten Aufruf zurück.
• UTXO-Chains brauchen überhaupt keine Node. Ein- und Ausgänge sind bereits bekannt, also ist das Vorher-Nachher Arithmetik auf den ausgewählten Coins, und Empfänger werden als Wechselgeld zurück an dich oder als tatsächlich extern eingeordnet.
• Solana deserialisiert die unsignierte Transaktion, die der Builder erzeugt hat, führt das netzeigene simulateTransaction mit abgeschalteter Signaturprüfung aus und liest danach die Token-Salden des Vaults vor und nach dem Vorgang aus dem Ergebnis.

Zurück kommt eine Vorschau: wie hoch der Saldo jedes Assets vorher war, wie hoch er danach sein wird, und — auf EVM — was der Aufruf tatsächlich ist, dekodiert in eine Methode und ihre Argumente.

Zweierlei ist sie nicht. Sie ist keine Garantie: der Zustand der Chain bewegt sich, und eine Simulation zum Zeitpunkt des Vorschlags ist ein Bild der Chain, wie sie damals war. Und sie ist keine Sperre. Das ist die interessantere Hälfte des Entwurfs, und darauf kommen wir zurück.

Vierzehn Dinge, über die man Bescheid wissen sollte

Eine Vorschau, die nur Zahlen zeigt, verlangt weiterhin, dass du das Problem selbst entdeckst. Deshalb wird die Vorschau von Warnungen begleitet, und es gibt vierzehn davon, in vier Schweregraden.

Freigaben — die Kategorie, die die meisten Wallets leert. Eine unbegrenzte oder unbeschränkte Freigabe ist kritisch. Jede Ausgabefreigabe über null an eine Adresse, die nicht auf deiner Zulassungsliste steht, ist hoch. Und eine extern gehaltene Adresse statt eines Vertrags freizugeben ist hoch, denn dafür gibt es praktisch keinen legitimen Grund: Verträge geben Freigaben aus, Menschen nicht.

Empfänger — ein Empfänger, der weder in den Kontakten deiner Organisation noch auf der Whitelist des Vaults steht, wird markiert. Ebenso einer, an den dein Vault noch nie gesendet hat. Für sich genommen ist beides nicht falsch. Beides ist einen zweiten Blick wert.

Vertragsrisiko — ein Zielvertrag, dessen Quellcode nicht verifiziert ist, einer, der in den letzten sieben Tagen deployt wurde, nativer Wert, der überhaupt an einen Vertrag geht, und jede Adresse, die ein Anbieter als schlicht bösartig meldet.

Ausführung — die Transaktion revertiert in der Simulation, was heißt, sie wird on-chain scheitern und die Gebühr verbrennen. Oder der simulierte Abfluss passt nicht zu den Beträgen, die der Vorschlag angibt: der Vault verliert mehr oder weniger, als auf dem Bildschirm steht.

Degradierung — und, klar benannt, der Fall, dass die Simulation gar nicht laufen konnte. Eine unerreichbare Node erzeugt „nicht verfügbar", nicht Schweigen und keinen erfundenen Freibrief.

Der Unterschied zwischen diesen Schweregraden zählt mehr als die Anzahl. Kritisch und hoch handeln von einer Transaktion, die wahrscheinlich nicht ist, was sie zu sein scheint. Mittel und Info handeln von einer ungewöhnlichen Transaktion, und das sind legitime Transaktionen gelegentlich.

Address Poisoning: der Angriff, der sorgfältige Menschen schlägt

Eine Warnung verdient einen eigenen Abschnitt, denn sie zielt genau auf die Gewohnheit, die fast jeder Sicherheitsratschlag empfiehlt.

Address Poisoning funktioniert so. Ein Angreifer schickt deinem Vault eine winzige oder wertlose Transaktion von einer Adresse, die eigens so gebaut ist, dass sie die ersten sechs und die letzten vier Zeichen einer Adresse teilt, mit der du ohnehin zu tun hast. Es wird nichts gestohlen. Es wird eigentlich nicht einmal etwas getan. Die Transaktion existiert, damit die ähnlich aussehende Adresse in deinem Verlauf auftaucht.

Später — Tage später, wenn du dieselbe Gegenpartei erneut bezahlst — kopierst du die Adresse aus deinem eigenen Transaktionsverlauf, wie sorgfältige Menschen es tun, statt sie abzutippen. Du prüfst sie, wie sorgfältige Menschen prüfen: die ersten paar Zeichen, die letzten paar Zeichen. Beide stimmen. Die Mitte nicht, und in der Mitte landet das Geld.

SSP prüft jeden Empfänger eines Vorschlags gegen die Adressen, die dein Vault bereits kennt, mit genau dem Präfix-und-Suffix-Vergleich, den das menschliche Auge anstellt, und gibt eine kritische Warnung aus, die die nachgeahmte Adresse benennt. Dieselbe Prüfung läuft in die Gegenrichtung über eingehende Historie, sodass eine vergiftete Adresse schon bei ihrer Ankunft markiert wird und nicht erst, wenn du sie benutzen willst.

Warum man diesen Angriff kennen sollte, selbst wenn man SSP nie benutzt: Die Prüfgewohnheit, die jeden anderen Adressangriff stoppt, ist genau die, die dieser Angriff aushebeln soll. Vergleiche ganze Adressen — oder vergleiche gar nichts.

Warum die Warnungen auf dem Server berechnet werden — und trotzdem nichts blockieren

Der Warnungssatz wird serverseitig bestimmt, mit den Kontakten deiner Organisation und der Whitelist des Vaults als Quelle der Wahrheit. Das ist Absicht: Könnte ein Client entscheiden, was als zugelassen gilt, könnte ein kompromittierter Client stillschweigend entscheiden, dass alles zugelassen ist.

Und dennoch kann nichts davon eine Transaktion aufhalten. Die Simulation entscheidet nie über Signieren oder Senden. Ein Anbieter, der Fehler wirft, in ein Timeout läuft oder keine Node erreicht, liefert „nicht verfügbar", und der Vorschlag bleibt vollständig signierbar. Das gesamte Subsystem ist fehlerisoliert, damit ein Absturz in der Vorschau niemals einen Vorschlag stranden lassen kann.

Das klingt nach einer merkwürdigen Entscheidung, deshalb sei die Begründung deutlich gesagt. Eine Vorschau, die blockieren kann, ist eine Vorschau, die zum Blockieren gebracht werden kann — indem man eine Node lahmlegt, indem man ein falsches Kritisch erzeugt, auf jede der tausend Arten, wie Software schiefgeht. Mittel, die sich nicht bewegen lassen, weil ein beratender Dienst kränkelt, sind Mittel, die du teilweise verloren hast. Die Schwelle in der Multisig schützt das Geld; die Simulation ist da, um die Menschen mit den Schlüsseln zu informieren. Was eine Transaktion wirklich aufhält ist die lange Fassung dieses Arguments.

Wenn Server und Gerät sich widersprechen

Alles Bisherige ist die Lesart des Servers. Dein Gerät hat seine eigene.

Wenn SSP Wallet dir einen Vorschlag zum Signieren zeigt, dekodiert es die Bytes selbst und zeigt, was es gefunden hat — nicht die Zusammenfassung des Servers. Dann vergleicht es beides. Impliziert der dekodierte Aufruf des Servers andere Empfänger als die, die das Gerät hergeleitet hat, erhebt das Gerät eine eigene kritische Widerspruchswarnung und stuft die Vorschau des Servers sichtbar herab.

Die Dekodierung des Geräts ist die maßgebliche. Die Prüfung ist bewusst konservativ: eine fehlende oder ausstehende Server-Simulation ist eine Degradierung, kein Widerspruch, und wird nicht als solcher gemeldet. Außerdem gilt sie nur für EVM-Chains, wo der Server überhaupt einen dekodierten Aufruf erzeugt; auf UTXO-Chains gibt es nichts zu vergleichen, und die eigene Dekodierung des Geräts steht schlicht für sich.

Das ist die Eigenschaft, die man mitnehmen sollte, egal welche Wallet man nutzt. Eine zweite Meinung ist nur dann etwas wert, wenn sie von einer Stelle kommt, die nicht durch denselben Vorgang kompromittiert sein könnte wie die erste. Zwei Zusammenfassungen vom selben Server sind eine Zusammenfassung.

Eine Risikoleiste lesen, ohne sie zu übersehen

Warnungen wirken nur, solange sie nicht zur Tapete werden. Ein paar Gewohnheiten halten sie nützlich.

Lies zuerst den Schweregrad, dann das Detail. Kritisch und hoch sind es wert, innezuhalten. Eine mittlere oder informative Warnung bei einer ersten Zahlung an einen neuen Lieferanten ist das System, das korrekt arbeitet, kein Grund zur Sorge.

Behandle jede Freigabewarnung als vollen Halt. Überweisungen bewegen, was sie zu bewegen sagen. Freigaben gewähren ein Recht, das die Transaktion überdauert. Wolltest du keine dauerhafte Erlaubnis erteilen, lautet die Antwort nein.

Glaube dem Gerät mehr als dem Bildschirm. Widersprechen sich beide, dann ist das Telefon in deiner Hand dasjenige, das auf Hardware läuft, die ein Angreifer separat hätte kompromittieren müssen.

Nimm „nicht verfügbar" nicht als „alles gut". Es heißt, dass niemand geprüft hat. Das ist ein Grund, selbst genauer hinzusehen, gerade bei einer großen oder ungewöhnlichen Zahlung.

Alles hier dreht sich um den Moment vor einer Signatur. Für das, was danach kommt — wer signieren darf, wie viele nötig sind und welche Vorgänge erneut beide Geräte verlangen — beginne mit dem Einrichten deines ersten Enterprise-Vaults und kritischen Aktionen und dem erneuten Signieren. Und für die Angriffsmuster, um die herum diese Warnungen geformt sind, deckt Phishing-Angriffe auf Krypto-Nutzer die menschliche Hälfte des Problems ab.