Aufbau von Polysend: Wie wir das Solana Wallet Management für unser Ökosystem vereinfacht haben

Bei Polysend arbeiten wir an der Mission, nahtlose Multi-Token-Zahlungen für das moderne Web zu schaffen. Unsere Browser-Erweiterung ermöglicht es Nutzern, mit nur einem Klick direkt auf Websites zu bezahlen, ohne die Seite zu verlassen, und verändert so die Art und Weise, wie Nutzer mit Content-Erstellern, digitalen Diensten und Online-Plattformen interagieren.

Als unser Entwicklungsteam begann, die Polysend-Browser-Erweiterung auf Solana zu entwickeln, stießen wir schnell auf eine Herausforderung. Alice, unsere leitende Entwicklerin, äußerte während unseres wöchentlichen Stand-ups ihre Frustration: “Das Testen der Zahlungsabläufe der Erweiterung ist unglaublich zeitaufwendig. Für jedes Testszenario benötigen wir verschiedene Wallets mit unterschiedlichen Token-Beständen, und die manuelle Verwaltung all dessen über die CLI nimmt die Hälfte unserer Entwicklungszeit in Anspruch!”

Bob, unser DevOps-Ingenieur, stimmte zu. “Die Solana CLI ist leistungsstark, aber sich all diese Befehle und Parameter zu merken, verlangsamt unseren Fortschritt bei der Erweiterung. Wir brauchen einen besseren Weg, um Test-Wallets und Tokens zu verwalten.”

Daraufhin beschlossen wir, ein grundlegendes Tool für unseren Entwicklungsworkflow zu erstellen: den Solana Wallet Manager, der jetzt in der Polysend GitHub-Organisation verfügbar ist. Dieses Bash-Script vereinfacht Wallet- und Token-Operationen und ermöglicht es uns, uns auf den Aufbau unserer Browser-Erweiterung zu konzentrieren, anstatt mit Befehlszeilen-Komplexitäten zu kämpfen. Dieser Blogpost teilt unsere Reise und das Tool, das wir entwickelt haben, das für die Entwicklung des Polysend-Ökosystems unverzichtbar geworden ist.

Die Herausforderung bei der Entwicklung einer Multi-Token-Zahlungserweiterung

Bei der Entwicklung von Polysend, unserer Browser-Erweiterung für Ein-Klick-Kryptowährungs-Zahlungen, standen wir vor mehreren technischen Herausforderungen:

Erstellen und Verwalten mehrerer Test-Wallets zur Simulation verschiedener Benutzerszenarien
Generieren verschiedener Token-Typen zum Testen der token-übergreifenden Zahlungsfunktionalität
Simulation verschiedener Kontostand-Zustände für Feature- und UI-Tests
Einrichten von Wallet-Sicherheitsstufen zum Testen unseres gestaffelten Sicherheitsmodells
Erstellen reproduzierbarer Testumgebungen für unsere CI/CD-Pipeline

Jede dieser Operationen erforderte spezifische Solana CLI-Befehle mit verschiedenen Parametern und Optionen. Obwohl die CLI umfassend ist, war sie nicht für unsere schnellen Entwicklungszyklen und Testanforderungen optimiert.

Vorstellung des Solana Wallet Managers

Unsere Lösung bestand darin, ein Script zu erstellen, das die Solana CLI-Tools in eine intuitivere Schnittstelle verpackt. Der Solana Wallet Manager übernimmt alles von der Wallet-Erstellung bis zum Token-Management mit einfachen, einprägsamen Befehlen, die auf unseren Entwicklungsworkflow abgestimmt sind.

Lassen Sie mich ein typisches Entwicklungsszenario durchgehen, um zu zeigen, wie es unsere Arbeit an der Polysend-Erweiterung rationalisiert.

Ein Tag im Leben: Entwicklung der Polysend-Erweiterung

Alice und Bob arbeiten an einer neuen Funktion für die Polysend-Browser-Erweiterung: Die Fähigkeit, automatisch geeignete Tokens für bestimmte Websites basierend auf Metadaten zu erkennen und vorzuschlagen. Lassen Sie uns ihren Workflow mit unserem Wallet Manager Tool verfolgen.

Einrichten der Entwicklungsumgebung

Zuerst starten sie ihren lokalen Solana-Validator zum Testen:

docker run -ti --name solana-test-validator -p 8899:8899 -p 8900:8900 -p 8001:8001 --rm tchambard/solana-test-validator:latest solana-test-validator

Dann stellen sie das Script ein, um ihren lokalen Cluster zu verwenden:

./solana-wallet-manager.sh set-cluster local

Bob überprüft die Verbindung:

./solana-wallet-manager.sh check-cluster

Und sieht:

Checking availability of cluster: http://localhost:8899
Cluster is available!
Cluster version: 1.18.22

“Perfekt,” sagt Bob. “Der Validator läuft. Jetzt erstellen wir einige Test-Wallets, die der Multi-Wallet-Architektur unserer Erweiterung entsprechen.”

Erstellen von Test-Wallets für verschiedene Sicherheitsstufen

Zum Testen ihrer Erweiterung müssen Alice und Bob verschiedene Benutzer-Wallets mit unterschiedlichen Sicherheitsstufen simulieren:

./solana-wallet-manager.sh create-wallet everyday-wallet
./solana-wallet-manager.sh create-wallet savings-wallet
./solana-wallet-manager.sh create-wallet subscription-wallet

Sie überprüfen die erstellten Wallets:

./solana-wallet-manager.sh list-wallets

Available wallets:
  everyday-wallet - CRKL2q4S9FfBhjbhUCRjXNx4EPUFZDRcWjQG4K3UHyV3
  savings-wallet - Eo87sYSuDaQ18FwZWpUhAu84jPW5Ziae2HoCGM6qa6Tr
  subscription-wallet - FQRq5VwZqAyUidyryr1KwDf369Q4bgnAwHC8776n9YNo

“Schaut, wie einfach das war,” bemerkt Alice. “Jedes Wallet hat sein eigenes Verzeichnis unter ~/solana-wallets/ mit sicher gespeichertem Keypair. Wir können diese Wallets jetzt in unsere Erweiterung importieren, um die Wallet-Wechsel-Funktionalität zu testen.”

Finanzierung der Wallets

Nun benötigen sie etwas SOL für die Arbeit:

./solana-wallet-manager.sh use-wallet everyday-wallet
./solana-wallet-manager.sh airdrop 2

“Im Mainnet würden wir hier echtes SOL übertragen,” erklärt Bob dem neuen Praktikanten, der über seine Schulter schaut. “Aber auf Devnet und Localnet können wir SOL für Tests airdroppen, um die Kontostandsanzeige und Transaktionsgebührenabwicklung der Erweiterung zu testen.”

Sie finanzieren auch die anderen Wallets:

./solana-wallet-manager.sh airdrop 1 savings-wallet
./solana-wallet-manager.sh airdrop 5 subscription-wallet

Erstellen benutzerdefinierter Tokens für Zahlungstests

Jetzt kommt der wichtige Teil. Um die Multi-Token-Zahlungsfähigkeiten von Polysend zu testen, müssen sie einige benutzerdefinierte Tokens erstellen:

./solana-wallet-manager.sh use-wallet everyday-wallet
./solana-wallet-manager.sh create-token "Content Creator Token" CONTENT 6

“Ich erstelle CONTENT mit 6 Dezimalstellen, wie die meisten Standard-Tokens,” erklärt Alice. “Es ist für unseren Testfall, bei dem Websites bevorzugte Tokens für Creator-Zahlungen angeben können.”

Die Ausgabe zeigt, was hinter den Kulissen passiert:

Creating new token: Content Creator Token (CONTENT) with 6 decimals
Generating token keypair...
...
Token created successfully!
Token address: ELui9ZRhrP7qWgcPyPkjkbxa9PzSTSy2fpmvKVmQZr5o
Token information saved to /home/alice/solana-wallets/everyday-wallet/tokens/CONTENT.json
Creating token account...
Token account created successfully!

“Das ist fantastisch,” sagt Bob. “Das Script hat gerade ein neues Keypair speziell für diesen Token generiert, den Token on-chain erstellt, ein Token-Konto in unserem Wallet angelegt und alle Informationen für später gespeichert. Das wären mindestens vier separate CLI-Befehle gewesen.”

Sie erstellen einige weitere Tokens zum Testen verschiedener Erweiterungsszenarien:

./solana-wallet-manager.sh create-token "Subscription Payment Token" SUBSCRIBE 2
./solana-wallet-manager.sh create-token "Microtip Token" MICROTIP 9

“SUBSCRIBE hat nur 2 Dezimalstellen, da es für ganze Abonnement-Einheiten gedacht ist,” bemerkt Alice. “Und MICROTIP hat 9, weil wir extrem kleine Trinkgeldbeträge in der UI der Erweiterung testen müssen.”

Token-Metadaten für die Erweiterung verstehen

“Lasst mich erklären, was mit den Token-Metadaten passiert,” sagt Alice zum Team. “Wenn wir einen Token erstellen, werden mehrere wichtige Informationen gespeichert:

Der Token-Name (“Content Creator Token”) - dieser wird im Token-Selektor der Erweiterung angezeigt
Das Token-Symbol (“CONTENT”) - dies wird in der UI für Kurzreferenzen verwendet
Der Dezimalwert (6) - dieser beeinflusst, wie wir Kontostände in der Erweiterung anzeigen
Die Token-Adresse - diese wird für die On-Chain-Identifikation und Transaktionen verwendet
Die Keypair-Datei - diese gibt uns die Berechtigung, weitere Tokens für Tests zu prägen”

“Das Script speichert all dies in einer JSON-Datei, was es einfach macht, später darauf zuzugreifen. Ohne dies müssten wir manuell all diese Werte selbst verfolgen, was fehleranfällig wäre, wenn wir die Token-Anzeige und Konvertierungsfunktionen der Erweiterung testen.”

Tokens prägen, um Benutzer-Kontostände zu simulieren

Jetzt prägen sie einige Tokens, um verschiedene Benutzer-Kontostandsszenarien in der Erweiterung zu simulieren:

./solana-wallet-manager.sh mint-token CONTENT 1000000

“Das sind eine Million CONTENT-Tokens mit 6 Dezimalstellen, also tatsächlich 1.000.000,000000 Tokens,” erklärt Alice. “Lass uns auch einige unserer anderen Tokens prägen.”

./solana-wallet-manager.sh mint-token SUBSCRIBE 50000
./solana-wallet-manager.sh mint-token MICROTIP 9999999999

“Für MICROTIP prägen wir fast 10 Milliarden Tokens, weil wir testen müssen, wie die Erweiterung mit sehr kleinen Stückelungen und großen Zahlen in der UI umgeht,” erklärt Bob.

Tokens verteilen, um Multi-Wallet-Funktionalität zu testen

Jetzt müssen sie Tokens auf die verschiedenen Test-Wallets verteilen, um einen Benutzer mit mehreren Wallets in der Polysend-Erweiterung zu simulieren:

./solana-wallet-manager.sh transfer-token CONTENT 100000 savings-wallet

Die Ausgabe zeigt:

Using wallet as recipient: savings-wallet - CRKL2q4S9FfBhjbhUCRjXNx4EPUFZDRcWjQG4K3UHyV3
Transferring 100000 CONTENT tokens from everyday-wallet to CRKL2q4S9FfBhjbhUCRjXNx4EPUFZDRcWjQG4K3UHyV3
...
Attempting transfer with automatic recipient account funding...
Token transfer successful

“Hier bemerke ich etwas wirklich Wichtiges,” weist Alice hin. “Das Script hat automatisch das Token-Konto für savings-wallet erstellt. Normalerweise wäre das ein separater Schritt, an den wir denken müssten, aber das Script hat es mit dem --fund-recipient Flag für uns erledigt. Das ist genau die Art von Logik, die wir im Token-Transfer-Flow der Erweiterung implementieren.”

Sie senden weitere Tokens an verschiedene Wallets:

./solana-wallet-manager.sh transfer-token SUBSCRIBE 1000 subscription-wallet
./solana-wallet-manager.sh transfer-token MICROTIP 500000000 everyday-wallet

Testen der Kontostandsanzeige der Erweiterung

Bob wechselt zum everyday-wallet, um Kontostände zu überprüfen:

./solana-wallet-manager.sh use-wallet everyday-wallet
./solana-wallet-manager.sh list-tokens

Tokens owned by wallet: everyday-wallet
...
Token                                         Balance
-----------------------------------------------------
ELui9ZRhrP7qWgcPyPkjkbxa9PzSTSy2fpmvKVmQZr5o  900000   (CONTENT)
HNgcDc2cogpS12iW9pZWnimPiMSCd4hL3dVD2RhZeW9z  500000000 (MICROTIP)

“Perfekt!” sagt Alice. “Jetzt kann ich überprüfen, ob der Kontostandsformatierer unserer Erweiterung sowohl große Mengen von Standard-Tokens als auch astronomische Mengen von Microtip-Tokens korrekt handhabt.”

Zahlungsabläufe simulieren

Jetzt können sie die Kernzahlungsfunktionalität der Polysend-Erweiterung testen:

./solana-wallet-manager.sh use-wallet everyday-wallet
./solana-wallet-manager.sh transfer-token CONTENT 50 subscription-wallet

“Dies simuliert eine Content-Zahlung vom Alltags-Wallet des Benutzers,” erklärt Alice. “In der Erweiterung würde dies ausgelöst werden, wenn der Benutzer auf die Zahlungsschaltfläche auf einer Webseite mit den entsprechenden Zahlungs-Meta-Tags klickt.”

Sie testen auch eine Abonnementzahlung:

./solana-wallet-manager.sh use-wallet subscription-wallet
./solana-wallet-manager.sh transfer-token SUBSCRIBE 10 savings-wallet

“Mit dem Wallet Manager Script können wir schnell all diese Testszenarien einrichten und ausführen, ohne uns direkt mit der Komplexität der Solana CLI auseinandersetzen zu müssen,” bemerkt Bob.

Die Magie hinter den Kulissen

Was dieses Script so wertvoll für die Polysend-Entwicklung macht, ist das, was hinter den Kulissen passiert. Lassen Sie mich einige wichtige technische Aspekte erklären:

Token-Erstellungsprozess erklärt

Als Alice den CONTENT-Token erstellte, passierte Folgendes:

Ein einzigartiges Keypair wurde generiert: Dies wird zur “Mint Authority” - der einzigen Identität, die neue Tokens erstellen darf. Das Script erstellte eine Datei unter ~/solana-wallets/everyday-wallet/tokens/CONTENT_keypair.json, die diese Autorität enthält.
Der Token wurde on-chain erstellt: Das Script verwendete den spl-token create-token Befehl der Solana CLI und konfigurierte ihn mit dem Keypair und der Dezimalpräzision.
Ein Token-Konto wurde erstellt: Anders als bei Ethereum benötigt Solana separate Konten für jeden Token-Typ. Das Script erstellte automatisch dieses Konto im everyday-wallet.
Metadaten wurden lokal gespeichert: Alle Token-Informationen wurden in CONTENT.json gespeichert, was es einfach macht, später bei der Entwicklung der Token-Verarbeitungslogik der Erweiterung darauf zuzugreifen.

“Ohne das Script müssten wir all diese Dateien und Adressen manuell verfolgen,” sagt Bob. “Ich hatte früher Tabellen mit diesen Informationen, was fehleranfällig war und unsere Erweiterungsentwicklung verlangsamte.”

Konfigurationsmanagement

“Ein weiteres subtiles, aber entscheidendes Feature,” weist Alice hin, “ist, wie das Script mit der Solana-Konfiguration umgeht.”

Für jede Operation:

Speichert das Script die aktuelle Solana-Konfiguration
Setzt das richtige Wallet als Standard-Signer
Führt die Operation durch
Stellt die ursprüngliche Konfiguration wieder her

“Das bedeutet, dass wir das Script neben regulären Solana CLI-Befehlen verwenden können, ohne unsere Einrichtung zu stören,” erklärt Alice. “Das ist eine enorme Verbesserung der Lebensqualität, wenn wir am Transaktionssignierungscode der Erweiterung arbeiten.”

Reale Auswirkungen: Wie dieses Tool unseren Entwicklungsprozess verändert hat

Bevor wir dieses Script erstellten, dauerte das Einrichten einer Testumgebung für unsere Browser-Erweiterung für Alice und Bob fast einen ganzen Tag. Mit mehreren Wallets, Tokens und komplexen Konfigurationen gab es häufige Fehler und verlorene Zeit.

“Erinnerst du dich, als wir alle unsere Test-Wallets neu machen mussten, weil wir vergessen hatten, eines der Keypairs zu speichern?” erinnert Bob Alice.

Alice nickt. “Oder als wir Tokens an eine Adresse schickten, die noch kein Token-Konto eingerichtet hatte, und die Transaktion fehlschlug. Das verzögerte unsere OAuth-Integration um einen Tag.”

Jetzt dauert das Einrichten einer kompletten Testumgebung für die Polysend-Erweiterung weniger als 15 Minuten. Das Script übernimmt die gesamte mühsame Arbeit, verhindert häufige Fehler und sorgt für Konsistenz im gesamten Entwicklungsteam.

Über einfache Tests hinaus: Fortgeschrittene Nutzungsszenarien

Der Solana Wallet Manager ist nicht nur für grundlegende Tests gedacht. Hier sind einige fortgeschrittene Wege, wie unser Team es für die Polysend-Entwicklung nutzt:

Testen von Sicherheitsstufen

Die Polysend-Erweiterung implementiert verschiedene Sicherheitsstufen für Wallets. Mit dem Wallet Manager können wir:

Wallets erstellen, die verschiedene Sicherheitsstufen repräsentieren
Spezifische Beträge übertragen, um Sicherheitsschwellentests zu simulieren
Die Schutzmechanismen der Erweiterung für hochwertige Überweisungen validieren

“Das Script machte es einfach, exakte Kontostandszenarien für das Testen unserer Sicherheitsbestätigungen zu reproduzieren,” erklärt Alice.

Integrationstests

Für das Testen der Integration der Browser-Erweiterung mit Websites mussten wir verschiedene Token-Besitzmuster simulieren:

“Wir haben ein Script erstellt, das den Wallet Manager verwendet, um standardisierte Testumgebungen mit vorhersagbaren Wallets und Token-Beständen einzurichten,” erklärt Bob. “So können wir validieren, wie die Erweiterung mit verschiedenen Website-Zahlungsmetadaten interagiert.”

CI/CD-Pipeline

Bob integrierte das Script in unsere CI/CD-Pipeline:

“Für jeden Pull Request starten wir eine saubere Testumgebung mit frisch erstellten Wallets und Tokens,” erklärt er. “Die automatisierten Tests überprüfen das Verhalten der Erweiterung mit verschiedenen Token-Typen und Kontostandskonfigurationen und bauen die Umgebung anschließend wieder ab.”

Dieser Ansatz stellt sicher, dass unsere Tests sich nicht gegenseitig beeinflussen und immer in einem konsistenten Zustand laufen.

Entwickler-Onboarding

“Wenn neue Entwickler zum Polysend-Projekt stoßen, lassen wir sie ein Tutorial mit dem Script durcharbeiten,” sagt Alice. “Es hilft ihnen, Solanas Kontomodell und Token-System zu verstehen, ohne sich in CLI-Komplexität zu verlieren.”

Neue Teammitglieder können vom ersten Tag an produktiv sein und sich auf Erweiterungsfunktionen konzentrieren, anstatt auf Infrastrukturdetails.

Sicherheitsüberlegungen und Best Practices

Obwohl der Solana Wallet Manager die Entwicklungserfahrung erheblich verbessert, ist es wichtig, seine Grenzen zu verstehen:

“Dieses Script ist für Entwicklung und Tests konzipiert,” betont Bob. “Es speichert Keypairs als einfache JSON-Dateien, was für den Produktionseinsatz nicht sicher genug ist, aber perfekt für unsere Entwicklungsbedürfnisse.”

Für die eigentliche Polysend-Erweiterung implementieren wir eine viel robustere Sicherheit:

Lokale Verschlüsselung mit PBKDF2 und AES-GCM
Gestaffelte Sicherheitsstufen für verschiedene Wallet-Typen
Transaktionssignierungsbestätigungs-UI
Ausgabenlimits und automatische Sperren

Fazit: Entwicklerfreundliche Tools für bessere Produkte

Unsere Reise bei der Erstellung des Solana Wallet Managers hat uns eine wichtige Lektion gelehrt: Die Investition in Entwicklertools zahlt sich enorm aus, wenn man komplexe Produkte wie die Polysend-Erweiterung entwickelt.

“Die Stunden, die wir in die Erstellung dieses Scripts investiert haben, haben uns Wochen an Entwicklungszeit erspart,” reflektiert Alice. “Und was noch wichtiger ist, es hat Frustration reduziert und die Entwicklung angenehmer gemacht, so dass wir uns auf die Benutzererfahrung unserer Erweiterung konzentrieren können.”

Indem wir dieses Tool mit der Community teilen, hoffen wir, die Solana-Entwicklung für alle zugänglicher zu machen, von erfahrenen Blockchain-Ingenieuren bis hin zu Entwicklern, die gerade erst mit Web3 beginnen.

Das vollständige Script und die Dokumentation sind auf unserem GitHub verfügbar. Wir freuen uns über Beiträge und Vorschläge aus der Community!

Hinweis: Die Token-Beispiele in diesem Blogpost (CONTENT, SUBSCRIBE und MICROTIP) sind fiktiv und wurden nur zu Demonstrationszwecken erstellt. Jede Ähnlichkeit mit tatsächlichen Tokens ist zufällig.