Wie verbinde ich ein Wallet mit einer dApp? (Web3-Grundlagen)

Grundlegendes zu den Mechanismen der Wallet-Integration

1. Eine dezentrale Anwendung ist auf eine kryptografische Identität angewiesen, um Benutzer zu authentifizieren und Transaktionen zu signieren. Diese Identität befindet sich in einer Wallet, die private Schlüssel enthält und digitale Signaturen verwaltet.

2. Wallets wie MetaMask, Phantom oder Trust Wallet stellen eine standardisierte Schnittstelle bereit, die als Ethereum Provider API (EIP-1193) bekannt ist und es dApps ermöglicht, sie zu erkennen und mit ihnen zu kommunizieren.

3. Wenn eine dApp initialisiert wird, prüft sie, ob window.ethereum oder ähnliche Anbieterobjekte vorhanden sind, die von Browsererweiterungen oder mobilen Geldbörsen eingefügt werden.

4. Das Fehlen eines solchen Objekts löst eine Fallback-Logik aus – entweder die Aufforderung zur Installation oder der Vorschlag eines Wallet-Connect-Modals für mobile Benutzer.

5. Sobald die dApp erkannt wurde, fordert sie mithilfe von ethereum.request({ method: 'eth_requestAccounts' }) um Erlaubnis zum Zugriff auf die Konten des Benutzers an und initiiert so einen sicheren, vom Benutzer genehmigten Handshake.

Umgang mit Verbindungszuständen und Ereignissen

1. Die Wallet-Verbindung ist nicht statisch – sie kann sich aufgrund eines Kontowechsels, eines Netzwerkwechsels oder einer Trennung ändern. dApps müssen auf Ereignisse wie „accountsChanged“ , „chainChanged“ und „disconnect“ warten.

2. Das Ereignis „accountsChanged“ wird ausgelöst, wenn der Benutzer ein anderes Konto auswählt oder den Zugriff entfernt. Es liefert ein Array neuer Adressen oder ein leeres Array, wenn Berechtigungen widerrufen werden.

3. Das „chainChanged“ -Ereignis signalisiert einen Wechsel zwischen Netzwerken (z. B. Ethereum Mainnet zu Sepolia). Anwendungen müssen Vertragsinstanzen entsprechend neu laden oder neu initialisieren.

4. Die Trennung kann stillschweigend erfolgen – insbesondere nach der Wallet-Sperre oder der Deaktivierung der Erweiterung – daher tragen regelmäßige Zustandsprüfungen über ethereum.isConnected() dazu bei, die Konsistenz der Benutzeroberfläche aufrechtzuerhalten.

5. Für die dauerhafte Statusverwaltung müssen die ausgewählte Ketten-ID und die Kontoadresse im Speicher oder im lokalen Speicher gespeichert werden, jedoch niemals der private Schlüssel oder die Startphrase.

Transaktionen signieren, ohne Geheimnisse preiszugeben

1. Die gesamte Transaktionssignierung erfolgt innerhalb der Wallet-Umgebung – nicht im JavaScript-Kontext der dApp. Die dApp erstellt rohe Transaktionsparameter und übergibt sie an ethereum.request({ method: 'eth_sendTransaction', params: [...] }) .

2. Das Wallet stellt eine Bestätigungs-Benutzeroberfläche dar, die Empfänger, Wert, Treibstoffschätzungen und Datennutzlast anzeigt. Benutzer genehmigen oder lehnen ab, ohne ihren privaten Schlüssel einem externen Code preiszugeben.

3. Für Off-Chain-Nachrichten – wie Anmeldeherausforderungen oder Governance-Abstimmungen – verwendet die dApp personal_sign oder eth_signTypedData_v4, um kryptografisch überprüfbare Signaturen anzufordern.

4. Typisierte Datensignierung erzwingt eine strukturierte Domänentrennung und verhindert die Wiedergabe über Ketten oder Anwendungen hinweg durch domänenspezifisches Salt und Versionierung.

5. Die Signaturüberprüfung in der Kette oder in Backend-Diensten basiert auf ecrecover oder gleichwertigen kryptografischen Primitiven, um die Adresse des Unterzeichners aus der Signatur und dem Nachrichten-Hash abzuleiten.

WalletConnect-Protokoll für mobile und Nicht-Erweiterungsszenarien

1. WalletConnect v2 richtet über Relay-Server und Pairing-URIs Ende-zu-Ende-verschlüsselte Sitzungen zwischen dApps und Wallets ein. Es vermeidet die Browser-Injektion vollständig.

2. Die dApp generiert einen Sitzungsvorschlag mit den erforderlichen Ketten, Methoden und Metadaten und zeigt dann einen QR-Code mit einem Paarungs-URI an.

3. Der Benutzer scannt den QR-Code mit einer kompatiblen Wallet-App – wie Rainbow oder Coinbase Wallet – die den Vorschlag validiert, bevor er die Sitzung genehmigt.

4. Sobald die Verbindung hergestellt ist, fließen alle JSON-RPC-Anfragen über das Relay-Netzwerk, wobei die Verschlüsselungsschlüssel beim Pairing ausgehandelt und pro Sitzung rotiert werden.

5. Die Sitzungspersistenz wird clientseitig verwaltet. Der Widerruf erfolgt, wenn eine der Parteien session.disconnect() aufruft, wodurch alle zugehörigen Schlüssel ungültig werden und gespeicherte Metadaten gelöscht werden.

Häufig gestellte Fragen

F1: Kann eine dApp meinen privaten Schlüssel während der Verbindung lesen? A1. Nein. Wallets geben private Schlüssel niemals an dApps weiter. Das Signieren erfolgt immer innerhalb der sicheren Grenzen des Wallets.

F2: Warum fragt mein Wallet jedes Mal nach einer Genehmigung, wenn ich das Netzwerk wechsle? A2. Jede EVM-kompatible Kette verfügt über einen eigenen Namespace und Kontoableitungspfad. Berechtigungen gelten pro Kette und erfordern eine ausdrückliche erneute Genehmigung.

F3: Was passiert, wenn ich meinen Browser-Cache nach dem Herstellen der Verbindung lösche? A3. Der Verbindungsstatus geht verloren, es sei denn, die dApp implementiert die Sitzungswiederherstellung über WalletConnect oder speichert nicht vertrauliche Kennungen wie Wallet-Adresse und Ketten-ID separat.

F4: Ist es sicher, eine Verbindung zu einer dApp herzustellen, die nicht bei Etherscan verifiziert ist? A4. Nein. Nicht verifizierte dApps können bösartige Skripte einschleusen oder Wallet-Eingabeaufforderungen fälschen. Überprüfen Sie stets Vertragsadressen, überprüfen Sie die Legitimität der Domain und vermeiden Sie die Eingabe von Seed-Phrasen.