Was der SSP-Relay sehen kann und was nicht
SSP ist eine Zwei-Geräte-Wallet. Deine Browser-Erweiterung hält einen Schlüssel, dein Telefon den anderen, und keines von beiden kann allein Geld bewegen. Aber diese zwei Geräte müssen miteinander reden, und sie tun es über einen Server, den wir betreiben und Relay nennen.
Dieser Server ist der offensichtliche Ort für eine unbequeme Frage: Wenn alles über Infrastruktur läuft, die das Wallet-Unternehmen betreibt, was genau sieht dieses Unternehmen?
Das ist eine faire Frage, und sie verdient eine konkrete statt einer beruhigenden Antwort. Hier also, was tatsächlich im Code steht.
Der Relay kann nichts signieren
Fangen wir mit dem Wichtigsten an.
Der Relay erhält nie einen privaten Schlüssel. Nicht verschlüsselt, nicht aufgeteilt, in keiner Form. Dein Wallet-Schlüssel bleibt in der Browser-Erweiterung, der Schlüssel der Key-App bleibt auf dem Telefon, und das Einzige, was das Netz überquert, sind öffentliche Schlüssel, unsignierte Daten und Signaturen, die bereits auf deinen Geräten entstanden sind.
Das ist keine Richtlinienzusage, sondern eine strukturelle. Zwei-von-zwei-Multisig verlangt beide Signaturen, um Geld zu bewegen, und der Relay besitzt keinen der beiden Schlüssel. Ein völlig bösartiger Relay — unserer, kompromittiert, oder von einem Angreifer ersetzt — kann trotzdem keine gültige Transaktion erzeugen, weil das Geheimnisse erfordert, die ihm nie geschickt wurden.
Das ist die Zusage. Alles Weitere handelt davon, was der Relay tatsächlich anfasst, eine engere, aber wirklich nicht leere Menge.
Was durchläuft, und wie lange
Der Relay hält vier Arten von Datensatz. Zwei davon löschen sich selbst.
Sync-Daten, wenn du deine zwei Geräte koppelst. Sie tragen die Kette, deine Wallet-Identität, den erweiterten öffentlichen Schlüssel der Key-App, die resultierende WK-Identität, öffentliche Nonces, die erzeugte Adresse sowie den Recovery-xpub mit seiner Signatur.
Aktionsdaten, wenn du etwas signierst. Sie tragen die Kette, den Ableitungspfad, deine WK-Identität, den Aktionstyp, die Nutzlast selbst und die betreffenden UTXOs.
Beide Sammlungen haben in MongoDB einen TTL-Index von expireAfterSeconds: 900. Fünfzehn Minuten. Die Datenbank löscht den Datensatz, ganz gleich was sonst geschieht — es ist kein Aufräumjob, an den jemand denken muss, und kein Versprechen in einer Datenschutzerklärung. Es ist ein Index, durchgesetzt von der Datenbank selbst.
Push-Benachrichtigungstoken, damit dein Telefon geweckt werden kann, wenn etwas zu genehmigen ist. Diese bleiben bestehen, denn ein Token, das alle fünfzehn Minuten verfällt, wäre nutzlos.
Der Recovery-xpub, einer je Identität, ganz ohne Verfall. Das ist Absicht, und der Code sagt es: Er existiert, damit die Wallet ihn abrufen kann, wann immer sie ihn braucht, statt nur in den kurzen Momenten, in denen beide Apps zufällig wach sind.
Der Teil, bei dem wir deutlich sein sollten
Sieh dir diese Sync-Nutzlast noch einmal an. Sie enthält einen erweiterten öffentlichen Schlüssel.
Ein xpub ist kein Ausgabeschlüssel und kann keine Transaktion autorisieren. Aber er ist nicht nichts. Aus einem Konto-xpub lässt sich jede Adresse ableiten, die dieses Konto je benutzen wird — wer ihn hat, kann also den gesamten Kontostand und Transaktionsverlauf dieser Kette beobachten. Das ist Lesezugriff auf dein Finanzleben in diesem Konto — genau die Verknüpfung, deren Vermeidung On-Chain-Privatsphäre ausmacht.
Die Aktionsnutzlast ist ebenso real. Während du signierst, verarbeitet der Relay die unsignierte Transaktion: wohin das Geld geht, wie viel, und aus welchen Ausgängen.
Die ehrliche Zusammenfassung lautet also nicht „der Relay sieht nichts“. Sie lautet:
Der Relay kann dein Geld nicht ausgeben, und jeweils fünfzehn Minuten lang kann er sehen, was du damit tust.
Das Fünfzehn-Minuten-Fenster ist die Abschwächung, und es ist eine bedeutsame — es begrenzt, wie viel Verlauf sich an einer Stelle ansammeln kann. Aber in diesem Fenster sind die Daten da, und wir sagen das lieber klar, als „nicht verwahrend“ rhetorische Arbeit leisten zu lassen, die es nicht verdient hat.
Das Entwurfsprinzip, das nachahmenswert ist
Im Recovery-Dienst steht ein Kommentar, der die Architektur besser einfängt als jedes Diagramm:
die Wallet prüft diese Signatur gegen den Identitäts-Public-Key, den sie selbst ableitet, dieser Speicher wird also nicht vertraut.
Der Recovery-xpub wird zusammen mit einer abgetrennten Signatur gespeichert, die SSP Key darüber erstellt hat. Holt die Wallet ihn ab, leitet sie den Identitäts-Public-Key unabhängig ab und prüft die Signatur selbst. Gäbe der Relay einen anderen xpub zurück — durch Kompromittierung, einen Fehler oder absichtliche Vertauschung —, würde die Signatur nicht verifizieren und die Wallet würde ihn ablehnen.
Der Relay wird von der Software, die auf ihm aufsetzt, als nicht vertrauenswürdige Leitung behandelt. So baut man richtig auf selbst betriebener Infrastruktur, denn es bedeutet, dass ein Irrtum des eigenen Servers nicht zum Problem der Nutzer wird. Es ist auch das Muster, nach dem man bei jeder Wallet suchen sollte: nicht „versprechen sie, sich zu benehmen?“, sondern „was passiert, wenn ihr Server sich danebenbenimmt?“.
Was ein feindlicher Relay wirklich tun könnte
Beim echten Bedrohungsmodell lohnt Konkretheit.
Er könnte beobachten. Innerhalb des TTL-Fensters deinen xpub und deine ausstehende Transaktion. Das ist eine Preisgabe von Privatsphäre, kein Diebstahlrisiko.
Er könnte zensieren. Nachrichten zwischen deinen Geräten nicht weiterleiten, womit du auf dem üblichen Weg keine neuen Transaktionen signieren könntest. Ärgerlich und störend — und nicht dasselbe wie ein Verlust. Deine Schlüssel gehören weiter dir, deine Mittel liegen weiter on-chain, und Wiederherstellungswege existieren gerade deshalb, weil der Relay vielleicht nicht da ist.
Er könnte lügen und meistens scheitern. Einen Recovery-xpub zu vertauschen scheitert an der oben beschriebenen Signaturprüfung. Deshalb zählt diese Verifikation.
Er kann nicht signieren. Kein Schlüssel, keine Signatur, keine Transaktion.
Der realistische schlimmste Fall ist Überwachung und Störung, nicht Verlust. Das ist eine deutlich bessere Lage als bei einem verwahrenden Dienst, wo der entsprechende schlimmste Fall lautet: Das Geld ist weg. Es ist nicht dasselbe wie „niemand kann irgendetwas sehen“, und beides zu verwechseln führt dazu, dass Leute ein falsches Bild ihrer eigenen Privatsphäre haben.
Was du gegen die sichtbaren Teile tun kannst
Verstehe, was das Koppeln preisgibt. Eine Kette zu synchronisieren heißt, dass ein xpub dieser Kette den Relay passiert. Das ist der Preis dafür, dass der Zwei-Geräte-Entwurf überhaupt funktioniert.
Denk daran, dass das Fenster kurz, aber nicht null ist. Fünfzehn Minuten je Aktion sind eine Schranke, keine Abwesenheit.
Behandle den Recovery-xpub als dauerhaft. Er wird absichtlich ohne Verfall gespeichert, und er ist öffentliches Schlüsselmaterial mit prüfbarer Signatur — aber er ist beständig, und das solltest du wissen, statt es zu entdecken.
Beurteile die Architektur, nicht die Zusicherung. Die nützliche Frage zum Server einer Wallet ist nicht, ob das Unternehmen Diskretion verspricht. Sie lautet, ob die Software merken würde, dass der Server gelogen hat. Unsere prüft Signaturen, statt Antworten zu glauben, und du kannst das im Code nachlesen, statt uns zu glauben.
Am liebsten wäre uns, die Form des Tauschs würde verstanden. Eine Zwei-Geräte-Wallet braucht einen Koordinationskanal, und ein Koordinationskanal ist ein Ort, an dem sich Metadaten sammeln. Wir haben das mit datenbankseitig erzwungenem Verfall begrenzt und die Clients so gebaut, dass sie dem Server misstrauen — aber ehrlich bleibt: Der Relay sieht echte Dinge, kurz, und keine noch so sorgfältige Architektur macht diese Zahl zu null.
