So nutzen Sie WalletConnect, um Wallets sicher zu verbinden

Kernprotokollarchitektur

1. WalletConnect arbeitet über ein Relay-basiertes Nachrichtensystem, bei dem weder die DApp noch das Wallet eine direkte Peer-to-Peer-Kommunikation herstellen.

2. Eine WebSocket-Verbindung wird zwischen dem DApp-Frontend und dem offiziellen WalletConnect-Relay-Server unter wss://relay.walletconnect.com initiiert.

3. Die DApp generiert ein eindeutiges Thema und ein temporäres Schlüsselpaar und bettet sie in einen URI ein, der gemäß der EIP-1328-Spezifikation formatiert ist.

4. Dieser URI wird als QR-Code dargestellt, der auf der DApp-Schnittstelle sichtbar ist und verschlüsselte Sitzungsmetadaten enthält, einschließlich Ablaufzeitstempel und Relay-Protokoll-ID.

5. Beim Scannen analysiert das mobile Wallet den URI, extrahiert das Thema und den SymKey und abonniert denselben Relay-Kanal mit identischen Verschlüsselungsparametern.

Anforderungen an die Wallet-Integration

1. Wallets müssen das WalletConnect V2-Client-SDK implementieren, das die EIP-155-Namespace-Aushandlung für Multi-Chain-Kompatibilität unterstützt.

2. Jede unterstützte Blockchain muss mit ihrer Ketten-ID und den angeforderten Methoden wie eth_sendTransaction oder personal_sign deklariert werden.

3. Das Wallet erzwingt eine strikte Festlegung des Berechtigungsbereichs: Es gibt niemals private Schlüssel preis, sondern signiert Nutzlasten nur mithilfe gerätelokaler kryptografischer Module.

4. Die Sitzungsgenehmigung erfordert eine explizite Benutzerbestätigung der DApp-Identität, der angeforderten Ketten und der Funktionsberechtigungen, bevor eine RPC-Bindung hergestellt wird.

5. Alle nachfolgenden Nachrichten – einschließlich Transaktionsanfragen und Signaturaufforderungen – werden durchgängig mit AES-256-GCM verschlüsselt, das aus dem gemeinsamen Diffie-Hellman-Geheimnis abgeleitet ist.

Mechanismen zur Sicherheitsdurchsetzung

1. Private Schlüssel bleiben vollständig isoliert in der sicheren Ausführungsumgebung des Wallets – werden niemals übertragen und niemals dem Speicher ausgesetzt, auf den über Webkontexte zugegriffen werden kann.

2. Der Relay-Server kann Nutzdaten nicht entschlüsseln. Es leitet nur Chiffretext zwischen Endpunkten weiter, ohne den Inhalt zu interpretieren.

3. Der Sitzungsablauf wird sowohl auf der Client- als auch auf der Relay-Seite erzwungen, wobei die Standardlimits auf 7 Tage festgelegt sind, sofern sie nicht während des Vorschlags überschrieben werden.

4. Jede Sitzung verfügt über eine unveränderliche Paarungskennung, die einen deterministischen Widerruf über von der Brieftasche initiierte Trennbefehle ermöglicht.

5. Bei App-Neustarts bleibt keine Sitzung bestehen, es sei denn, der Benutzer hat dies ausdrücklich erneut genehmigt – die automatische Wiederverbindung ist standardmäßig deaktiviert.

Handhabung von Multi-Chain-Namespaces

1. DApps deklarieren erforderliche Namespaces in ihrem Sitzungsvorschlag und geben Ketten wie eip155:1 (Ethereum Mainnet) und eip155:137 (Polygon) an.

2. Wallets antworten mit genehmigten Namespaces, die je nach Benutzerauswahl oder Einschränkungen der Wallet-Funktionalität unterschiedlich sein können.

3. Der Kettenwechsel während aktiver Sitzungen löst neue Berechtigungsaufforderungen aus – es erfolgt kein stiller Fallback oder automatische Autorisierung.

4. RPC-Anfragen werden ausschließlich an Ketten weitergeleitet, die im genehmigten Namespace enthalten sind, wodurch kettenübergreifende Lecks oder fehlgeleitete Transaktionen verhindert werden.

5. Eine einzelne WalletConnect-Sitzung kann gleichzeitig aktive Kontexte über mehrere EVM-kompatible Ketten hinweg ohne Sitzungsduplizierung aufrechterhalten.

Sitzungslebenszyklusmanagement

1. Die Verbindungsinitiierung beginnt mit der URI-Generierung und dem QR-Rendering – bis zum Abschluss des Scans findet kein Netzwerk-Handshake statt.

2. Nach der Kopplung speichert das Wallet den Sitzungsstatus lokal mithilfe eines verschlüsselten Speichers, der an Gerätebiometrie oder PIN gebunden ist.

3. Benutzer können alle aktiven Sitzungen in der Wallet-Benutzeroberfläche unter „Verbundene Apps“ anzeigen, mit Echtzeit-Statusanzeigen für jede DApp.

4. Durch das Widerrufen einer Sitzung werden alle zugehörigen Abonnements beendet, der gemeinsame Schlüssel ungültig gemacht und der zwischengespeicherte Signaturkontext sofort gelöscht.

5. Sitzungsmetadaten – einschließlich DApp-Ursprung, Kettenumfang und Zeitpunkt der letzten Interaktion – werden niemals an Analyse- oder Telemetriedienste von Drittanbietern weitergegeben.

Häufig gestellte Fragen

F: Speichert WalletConnect private Schlüssel auf seinen Relay-Servern? WalletConnect-Relay-Server verarbeiten oder speichern keine privaten Schlüssel. Sie leiten nur verschlüsselte Nutzdaten ohne Entschlüsselungsfunktion weiter.

F: Kann eine bösartige DApp nach der Verbindung nicht autorisierte Transaktionen auslösen? Nein. Jede Transaktionsanforderung erfordert eine explizite Benutzergenehmigung innerhalb der Wallet-Schnittstelle. Ohne manuelle Bestätigung wird kein Vorgang ausgeführt.

F: Ist es möglich, dasselbe Wallet gleichzeitig mit zwei verschiedenen DApps zu verbinden? Ja. WalletConnect unterstützt gleichzeitige Sitzungen. Jede DApp erhält einen isolierten Sitzungskontext mit unterschiedlichen Berechtigungen und Kettenbereichen.

F: Was passiert, wenn der Relay-Server während einer aktiven Sitzung offline geht? Aktive Sitzungen funktionieren weiterhin, da die Nachrichtenverschlüsselung und die Routing-Logik vollständig in clientseitigen Implementierungen liegen. Die Nichtverfügbarkeit des Relays betrifft nur neue Verbindungsversuche.