Am 11. Februar 2024 wurde SSP Connect vom reinen Sicht- und Identitätsprotokoll zu einem Zahlungsprotokoll. Die Version v1.1.0 von SSP Wallet ergänzt SSP Connect um eine pay-Methode, mit der jede dApp oder Website eine echte On-Chain-Zahlung von einem SSP-Nutzer anfordern kann, ohne die Wallet-Klempnerei selbst neu zu implementieren. Die Form der Anfrage ist bewusst klein gehalten: drei Parameter, von denen einer absichtlich ein String ist.
TL;DR
- SSP Connect bietet jetzt eine
pay-Aktion neben seinen bestehenden Identitäts-Flows. - Eine Zahlungsanfrage nimmt genau drei Parameter entgegen:
chain,addressundamount. amountist mit Absicht ein String, um die Dezimalpräzision über die Leitung zu erhalten.- Der Signaturfluss läuft weiterhin Ende-zu-Ende auf den beiden Geräten des Nutzers; die dApp sieht nie Schlüssel.
- Integratoren sollten
amountvor dem Versand mitBigNumber.toFixed()(oder einem Äquivalent) formatieren.
Was SSP Connect ist
SSP Connect ist die Brücke zwischen einem SSP-Wallet-Nutzer und der Außenwelt. Es ist dasselbe leichtgewichtige Sitzungsprotokoll, das zusammen mit dem Start von SSP Wallet eingeführt wurde, bei dem die Wallet selbst ein echter 2-von-2-Multisig ist, aufgeteilt zwischen einer Browser-Erweiterung und einem auf dem Telefon liegenden SSP Key. Vor dieser Version wurde Connect vor allem für lesende Anfragen genutzt: eine Sitzung paaren, eine Adresse teilen, prüfen, dass ein bestimmter Nutzer ein bestimmtes Konto kontrolliert. Entscheidend: Geheimnisse verlassen niemals die beiden Geräte des Nutzers; Connect transportiert lediglich Absichten und Antworten zwischen ihnen und der Gegenstelle.
Was die pay-Aktion macht
Die Methode pay erweitert Connect von „sag mir, wer du bist" zu „lass mich dich um eine Zahlung bitten". Eine dApp baut eine pay-Anfrage, übergibt sie an Connect, und der Nutzer wird in seiner Wallet-Oberfläche aufgefordert, die Anfrage zu bestätigen, zu ändern oder abzulehnen. Bestätigt der Nutzer, läuft der Multisig-Signaturfluss wie immer ab — die Erweiterung bereitet vor, das Telefon ko-signiert — und die resultierende Transaktion wird übertragen. Die dApp erhält eine saubere Bestätigung oder eine saubere Ablehnung und berührt nie einen privaten Schlüssel.
Die drei Parameter
chain ist ein String, der das von SSP unterstützte Asset benennt, in dem gezahlt werden soll, zum Beispiel 'flux'. Er ist Pflicht. Der Wert entspricht den Asset-Bezeichnern, die SSP intern bereits verwendet, sodass Integratoren kein neues Namensschema lernen müssen.
address ist das Ziel der Zahlung — ein einfacher String im Adressformat, das die gewählte Chain erwartet. Auch er ist Pflicht. SSP führt auf der Empfangsseite die übliche Format- und Prüfsummenvalidierung durch, bevor die Anfrage dem Nutzer gezeigt wird.
amount ist der zu sendende Wert, ausgedrückt in der Haupteinheit dieser Chain. Zum Beispiel bedeutet '4.56' 4,56 FLUX, nicht 4,56 der kleinsten unteilbaren Einheit. Er ist Pflicht und, wichtig, ist als String statt als Zahl typisiert.
Warum „amount" ein String ist
JavaScript-Zahlen sind IEEE-754-Doubles, also genau die falsche Darstellung für Geld. 0.1 + 0.2 ist nicht 0.3, und Token-Beträge mit 18 Dezimalstellen passen schlicht nicht ohne stilles Runden in ein Double. Indem amount als String erzwungen wird, wird diese gesamte Klasse von Präzisionsfehlern an der Protokollgrenze umgangen: Was die dApp intern berechnet hat — typischerweise mit einer Big-Decimal-Bibliothek — überlebt die Reise bis zur Wallet unverändert. Die Release-Notes empfehlen, den Wert vor dem Versand mit BigNumber.toFixed() zu formatieren, dem Standardweg, einen Big-Decimal als exakte, nicht wissenschaftlich notierte Zeichenkette darzustellen.
Was als Nächstes zu tun ist
Wer eine dApp oder eine Website pflegt, die SSP Connect bereits für Identität nutzt, hat einen kurzen Aktualisierungspfad: bestehende Sitzung beibehalten und eine pay-Anfrage dort einbauen, wo zuvor der Nutzer eine Adresse kopieren musste. chain gegen die Liste der von SSP unterstützten Assets prüfen, die wirklich akzeptiert werden sollen, address clientseitig validieren, damit der Nutzer Fehler sieht, bevor sie die Wallet erreichen, und amount immer durch toFixed() (oder Äquivalent) der eigenen Big-Decimal-Bibliothek schicken, damit der gesendete String exakt dem berechneten Wert entspricht. Den Rest — Bestätigung, Signatur, Broadcast — übernimmt die Wallet, ohne jemals Schlüssel an die eigene Origin freizugeben.
Source: SSP Wallet v1.1.0 Release Notes.