Böswillige RPC-Endpoints in Rabby: Warum Node-Betreiber deine Transaktionen sehen und manipulieren können

Ein Nutzer verbindet seine Rabby Wallet mit Ethereum, um DeFi-Positionen bei Aave zu verwalten. Die Transaktionssimulation lädt, der Smart Contract wird geprüft, alles sieht legitim aus. Doch zwischen der Wallet und der Blockchain steht ein Vermittler, den der Nutzer nie explizit gewählt hat: ein öffentlicher RPC-Node, betrieben von einem Dritten. Dieser Node sieht jede unsignierte Transaktion, jeden Wallet-Abfrage und jede Interaktion mit der Chain. Er kann Transaktionen verzögern, duplizieren oder bereits vor ihrer Bestätigung analysieren, um profitable Handelsstrategien auszuführen. Die Frage ist nicht, ob dies technisch möglich ist. Die Frage ist, wie verbreitet diese Praxis bereits ist und wie ein Nutzer sie überhaupt bemerken würde.

Rabby bietet umfangreiche Sicherheitsfeatures: Transaktionssimulation vor dem Signieren, automatische Sicherheitswarnungen und Phishing-Schutz. Doch diese Kontrollen enden dort, wo der Node beginnt. Private Keys bleiben verschlüsselt auf dem Gerät, die Extension überträgt keine Zugangsdaten – aber die gesamte Kommunikation zwischen Wallet und Blockchain läuft über RPC-Endpoints, die standardmäßig von Infura, Alchemy oder anderen Diensten bereitgestellt werden. Ein böswilliger oder gehackter Node kann jede dieser Interaktionen beobachten, analysieren und ausnutzen. Selbst wenn die Transaktion signiert ist, kann ein Node-Betreiber sie aus dem Mempool herausfiltern, verzögern oder durch eigene Transaktionen unterbieten. Das ist nicht Theorie. Es ist ein dokumentiertes Risiko, das die meisten Wallet-Nutzer nicht verstehen.

Was ein öffentlicher RPC-Node über deine Transaktionen weiß

RPC-Endpoints sind das Rückgrat der Blockchain-Kommunikation. Wenn eine web3 wallet wie Rabby eine Transaktion sendet oder den aktuellen Saldo abfragt, erfolgt diese Kommunikation über RPC. Der Node empfängt die Anfrage, führt sie aus und antwortet. Für diesen Austausch muss der Node kein Geld bezahlen und sieht dabei jede Information, die die Wallet übermittelt. Das umfasst: die Wallet-Adresse, die Ziel-Adresse, den übertragenen Betrag, die Daten im Transaction Call (die Funktion, die aufgerufen wird), den Gas-Preis und die verwendete Chain-ID.

Bei einem Aave-Withdraw oder einem Token-Swap sieht der Node nicht nur, dass eine Transaktion stattfindet. Er sieht den genauen Bytecode des Smart Contract Calls, dekodiert die Funktion und versteht, dass Adresse X beispielsweise 100 USDC von Aave abheben möchte. Wenn dieser Nutzer unmittelbar danach die Position schließt oder token an einer DEX verkauft, kann ein Node-Betreiber diese Informationen nutzen, um Transaktionen auszuführen, die von dieser vorausgesehenen Bewegung profitieren – ein Phänomen, das als Maximal Extractable Value (MEV) bekannt ist. Der Node ist hier nicht einfach ein neutraler Vermittler. Er ist ein Informationsvorkoster mit direktem Anreiz, diese Informationen kommerziell auszunutzen.

Die IP-Adresse des Nutzers wird ebenfalls protokolliert. Ein Node-Betreiber kann also eine RPC-Anfrage mit einer IP-Adresse verknüpfen, dann diese IP-Adresse mit Internet-Geolokalisierungsdaten abgleichen und ein geografisches Profil erstellen. Wenn dieselbe IP-Adresse immer wieder auf die gleiche Wallet-Adresse zugreift, entsteht ein Verknüpfungspunkt zwischen virtueller Identität und physischem Standort. Für einen großen Node-Betreiber wie Infura oder Alchemy bedeutet dies, dass über Monate hinweg Profile entstehen: Welche Wallets nutzen welche Dienste? Welche interagieren mit welchen DeFi-Protokollen? Welche sind zu bestimmten Zeiten aktiv? Diese Metadaten sind wertvoll für Händler, Analytiker und Dritte, die Nutzerverhalten verstehen wollen.

Ein gehackter Node oder ein Node, der von böswilligen Akteuren betrieben wird, kann einen Schritt weiter gehen. Er kann gefälschte RPC-Antworten senden, um eine Transaktion zu simulieren, obwohl sie in Realität fehlschlagen wird. Er kann Nodes-Anfragen zur Saldoabfrage manipulieren, um einem Nutzer einen falschen Kontostand anzuzeigen. Er kann Transaktionen aus dem Mempool herausfiltern und dem Nutzer eine falsche Bestätigung geben. Die Rabby-Extension überprüft Transaktionssimulationen zwar, doch diese Überprüfung ist nur so zuverlässig wie der Node, von dem die Simulation kommt.

Öffentliche RPC-Endpoints: Das unsichtbare Risiko

Rabby Wallet verbindet sich standardmäßig mit öffentlichen RPC-Endpoints für alle unterstützten EVM-Blockchains. Das ist für den Nutzer praktisch: Die Wallet muss keinen eigenen Node betreiben oder konfigurieren, Transaktionen werden unmittelbar gesendet, der Saldo wird schnell aktualisiert. Die Kosten für den Wallet-Anbieter sind minimal, weil öffentliche Endpoints kostenlos sind. Doch dieser Komfort hat einen Preis, den der Nutzer nicht sieht und der nicht in Tokens gemessen wird.

Infura und Alchemy sind die beiden größten Anbieter öffentlicher RPC-Endpoints für Ethereum und andere EVM-Blockchains. Gemeinsam verarbeiten sie einen Großteil des Transaktionsverkehrs von Retail-Nutzern. Das bedeutet, dass zwei US-Unternehmen einen Überblick über die Mehrheit der Transaktionen haben, bevor diese in der Blockchain erscheinen. Sie können sehen, welche Nutzer welche Transaktionen planen, in welcher Reihenfolge diese eintreffen, und wie schnell Nutzer auf Marktbewegungen reagieren. Dieser Datenschatz ist theoretisch durch Datenschutzrichtlinien geschützt, aber praktisch schwer zu überwachen. Keine Offenlegung erklärt, wie diese Daten intern genutzt werden, ob sie an Handelsdesk weitergegeben werden oder an externe Partner verkauft werden.

Der Gedanke mag befremdlich wirken, aber es gibt präzedenzlos für ähnliche Praktiken im traditionellen Finanzbereich. Broker, die Transaktionen im Mempool beobachten – ein Prozess namens «Front-Running» – profitieren davon, indem sie eigene Transaktionen vor denen des Nutzers einfügen. In Blockchains ist dies sogar noch leichter, weil alles transparent und pseudonym ist. Ein großer Node-Betreiber könnte theoretisch einen Pool von Wallets monitoren, vorhersagen, welche DEX-Trades diese durchführen werden, und diese Trades dann selbst ausführen, um davon zu profitieren. Der Nutzer merkt dies nicht direkt – seine Transaktion wird trotzdem bestätigt – aber der Kurs, den er erhält, ist suboptimal.

Polygon, Arbitrum, Optimism und andere EVM-Blockchains teilen dieses Risiko. Wenn Rabby über öffentliche RPC-Endpoints auf diese Chains zugreift, sind die gleichen Datensichtbarkeitsprobleme vorhanden. Hinzu kommt, dass kleinere Blockchains oft weniger dezentralisierte RPC-Infrastruktur haben, d. h., dass noch weniger Endpoints zur Verfügung stehen und die Konzentration noch größer ist.

MEV und Front-Running: Wie Node-Betreiber profitieren

Maximal Extractable Value ist nicht einfach nur eine technische Kuriositum. Es ist ein erkanntes Geschäftsmodell. Wenn ein Nutzer eine Transaktion signiert und diese in den Mempool sendet, sehen Node-Betreiber, dass beispielsweise 100 ETH gegen Stablecoins auf Uniswap getauscht werden sollen. Ein Node-Betreiber oder ein gehackter Node kann jetzt selbst eine Transaktion senden, die den gleichen Swap durchführt, bevor die Nutzer-Transaktion eintrifft. Danach folgt die ursprüngliche Nutzertransaktion und wird mit schlechteren Preisen ausgeführt. Dann sendet der Node-Betreiber eine dritte Transaktion, die die Position glattmacht und den Profit einstreicht. Dieser Prozess ist so häufig, dass Roboter diesen Prozess nun automatisieren – sogenannte MEV-Bots.

Für einen normalen Nutzer mit einer einfachen Transaktion können die Auswirkungen moderat sein – etwa 1 bis 5 Prozent schlechter Preis. Aber bei größeren Transaktionen, insbesondere bei Liquidationen oder großen DeFi-Positionen, kann MEV-Extraktion Hunderte oder Tausende von Dollar kosten. Der Nutzer weiß dies nicht, weil die Transaktion trotzdem erfolgreich ist und der Saldo sinkt. Er sieht nur den erhaltenen Betrag, nicht den hypothetischen besseren Preis, den er hätte erhalten können, wenn der Mempool transparenter gewesen wäre.

Rabby selbst hat keinen direkten Anreiz, MEV zu extrahieren – die Wallet-Extension verdient kein Geld pro Transaktion. Aber die RPC-Endpoints, die Rabby nutzt, gehören Diensten, die genau diesen Anreiz haben. Infura und Alchemy konkurrieren in einem Markt, in dem profitables MEV-Sharing ein Wettbewerbsvorteil sein kann. Der Endnutzer hat hiervon keine Kenntnis, weil die Abstraktion zwischen Wallet und Endpoint diese Realität unsichtbar macht.

Sandwich-Attacken sind eine spezifische MEV-Ausprägung, bei der ein Node-Betreiber oder Miner eine Nutzertransaktion gezielt isoliert und von oben und unten mit eigenen Transaktionen umgibt. Der Nutzer sendet beispielsweise eine Swap-Transaktion mit hohem Preisimpact. Der Node-Betreiber sendet zuerst eine Transaktion, die den Preis bewegt, dann folgt die Nutzer-Transaktion mit noch schlechteren Bedingungen, und schließlich wird die erste Transaktion rückgängig gemacht. Der gesamte Profit wird aus der Nutzertransaktion extrahiert. Rabby-Nutzer sind nicht immun gegen diese Attacken, weil die Sicherheit der Transaktionssimulation nicht gegen böswillige Nodes schützt.

Private RPC-Endpoints: Die Lösung und ihre Grenzen

Die Lösung für dieses Datensichtbarkeitsproblem heißt «Private RPC-Endpoints». Statt Transaktionen an einen öffentlichen Node zu senden, der Hunderte oder Tausende andere Clients verarbeitet, sendet der Nutzer Transaktionen an einen dedizierten Endpoint, der nur ihm gehört oder von einem Dienst betrieben wird, der sich vertraglich verpflichtet hat, keine Daten zu extrahieren oder zu teilen. Dienste wie Flashbots Protect, MEV-Blocker oder Wallets von Exchanges nutzen diese privaten Endpoints.

Mit einem privaten Endpoint wird die Transaktion sofort gebündelt und an validatoren gesendet, ohne durch den öffentlichen Mempool zu gehen. Ein Node-Betreiber oder MEV-Bot kann die Transaktion also nicht sehen, bevor sie in einen Block inkludiert wird. Damit entfällt das Front-Running-Fenster. Der Nutzer erhält bessere Preise, weil sein Trade nicht von Sandwich-Attacken betroffen ist. Die RPC-Anfragen werden nicht mit der IP-Adresse protokolliert oder mit öffentlichen Endpoints verknüpft.

Rabby Wallet bietet aktuell begrenzte Unterstützung für private RPC-Endpoints. Nutzer können manuell Custom RPC-Endpoints konfigurieren, aber die Wallet schlägt standardmäßig nicht vor, dies zu tun. Für sicherheitsbewusste Nutzer ist dies ein wichtiger Konfigurationsschritt, den sie selbst durchführen müssen. Um die rabby wallet extension herunterladen und konfigurieren zu können, müssen Nutzer zuerst verstehen, was private Endpoints sind und warum sie notwendig sind – ein Wissensvorsprung, den nicht alle haben.

Private Endpoints sind jedoch keine perfekte Lösung. Sie verschieben das Vertrauensproblem nur. Wenn ein Nutzer einen privaten Endpoint verwendet, muss er dem Betreiber dieses Endpoints vertrauen, dass dieser nicht doch Daten extrahiert oder speichert. Wenn der Endpoint gehackt wird oder sein Betreiber kompromittiert ist, sind die Transaktionen wieder sichtbar. Außerdem können private Endpoints unter hoher Last oder bei Netzwerkfehlern ausfallen, was den Wallet-Betrieb unterbricht. Ein Nutzer muss also einen Fallback zu öffentlichen Endpoints haben, was bedeutet, dass nicht alle Transaktionen geschützt sind.

Netzwerkwechsel und Multi-Chain-Risiken

Rabby bietet einen automatischen Netzwerkwechsel und ein Multi-Chain-Dashboard, das Ethereum, Arbitrum, Polygon, BNB Chain, Avalanche und Optimism unterstützt. Dieses Feature ist praktisch, aber es multipliziert auch die RPC-Sichtbarkeitsprobleme. Jede Chain hat ihre eigene Infrastruktur. Wenn Rabby standardmäßig öffentliche Endpoints für alle Chains nutzt, wird die Datensichtbarkeit über alle Chains hinweg vergrößert. Ein Node-Betreiber oder ein korrelierender Dritte könnte einen Nutzer über mehrere Chains hinweg verfolgen, indem er RPC-Anfragen korreliert.

Polygon-Transaktionen werden beispielsweise über Infura’s Polygon RPC verarbeitet. BNB Chain-Transaktionen folgen einem anderen Endpoint. Wenn ein Nutzer auf beiden Chains tätig ist und seine Wallet-Adresse auf einer öffentlichen Blockchain identifiziert wurde, können die beiden Datenströme leicht verknüpft werden. Ein Datenbroker oder ein verknüpftes Netzwerk von Nodes könnte ein komplettes Bild des Nutzers zusammensetzen: Welche Positionen auf welchen Chains? Welche Strategien? Welche Risiken? Diese Korrelation ist ein Mehrwert-Datensicherheitsrisiko, das nicht in der Dokumentation von Rabby erwähnt wird.

Hardware Wallet Support mit Ledger und Trezor bietet zwar Schutz für Private Keys, aber nicht für RPC-Kommunikation. Die signierte Transaktion wird auf dem Hardware-Gerät erstellt, aber ihr Weg zum Node ist immer noch über die Rabby-Extension. Falls die Extension gehackt wird, können Netzwerk-Traffic und RPC-Anfragen weiterhin abgefangen werden, auch wenn die Private Keys physisch geschützt sind. Der Hardware-Wallet schützt nur eine Ebene der Sicherheit, nicht die gesamte Kommunikation.

Transaktionssimulation als false sense of security

Rabby simuliert Transaktionen vor dem Signieren, um Phishing und bösartige Smart Contracts zu erkennen. Dies ist ein wertvolles Feature, das Nutzer vor offensichtlichen Betrügereien bewahrt. Ein Nutzer sieht vor dem Signieren, was passieren würde – Saldo-Änderungen, Token-Auszahlungen, Smart-Contract-Interaktionen. Rabby warnt, wenn eine Transaktion verdächtig ist.

Doch diese Simulation hängt von der RPC-Daten ab, die der Node zurücksendet. Ein gehackter oder böswilliger Node kann die Simulationsergebnisse verfälschen. Er kann dem Nutzer vorgaukeln, dass eine Transaktion sicher ist, obwohl sie in Realität ausfallen würde oder schlecht für ihn ist. Die Transaktionssimulation-Warnung kann also täuschen, wenn der Node nicht vertrauenswürdig ist. Rabby prüft nicht, ob der Node selbst vertrauenswürdig ist – es prüft nur, ob die Daten, die der Node sendet, mit bestimmten Mustern übereinstimmen.

Ein Beispiel: Ein Nutzer versucht, Stablecoins von Aave zu leihen. Der Node gibt zurück, dass ausreichend Liquidität verfügbar ist und die Transaktion sicher ist. Der Nutzer signiert. Aber ein böswilliger Node könnte wissentlich gemeldet haben, dass Liquidität verfügbar ist, wenn dies nicht wahr ist. Die Transaktion wird versendet, aber sie scheitert auf der Chain, weil keine Liquidität verfügbar war. Die Transaktion-Gas wird trotzdem verbraucht. Für den Nutzer war dies eine ineffiziente Entdeckung eines Fehlers, den die Wallet-Sicherheit nicht verhindert hat.

Ein noch fataleres Szenario: Ein Node manipuliert die Simulationsergebnisse für eine Kreditliquidation. Der Nutzer sieht in der Simulation, dass genug Sicherheiten vorhanden sind. Der Node meldet: alles in Ordnung. Der Nutzer signiert die Transaktion. Aber der Node hat gelogen – die Sicherheiten sind nicht ausreichend. Die Transaktion wird akzeptiert, aber die Position wird liquidiert, weil der Node falsche Daten simuliert hat. Dieses Szenario ist theoretisch, aber die technischen Mittel sind verfügbar.

Wie Nutzer ihr RPC-Risiko reduzieren können

Das erste und wirksamste Mittel ist der Wechsel zu einem privaten oder vertrauenswürdigen RPC-Endpoint. Rabby erlaubt das manuelle Hinzufügen von Custom RPCs. Ein Nutzer kann Flashbots Protect, MEV-Blocker oder einen selbst betriebenen Node verwenden. Diese Schritte erfordern technische Kenntnisse, aber sie beseitigen die Datensichtbarkeit über öffentliche Endpoints. Für Nutzer, die nur gelegentlich Transaktionen durchführen, ist der Aufwand möglicherweise nicht lohnend. Für aktive DeFi-Nutzer, die täglich handeln, kann die Gebührenersparnis durch MEV-Schutz den Konfigurationsaufwand rechtfertigen.

Das zweite Mittel ist die Diversifizierung von RPC-Endpoints für verschiedene Zwecke. Lesezugriffe (Saldoabfragen, Smart-Contract-Reads) können über einen Endpoint erfolgen, Transaktionsübermittlungen über einen anderen. Dies verringert die Profilierung, die durch Korrelation entsteht, auch wenn es nicht alle Risiken beseitigt. Rabby könnte dies automatisieren, tut es aber derzeit nicht.

Das dritte Mittel ist die Minimierung des RPC-Verkehrs selbst. Ein Nutzer kann die Walletaktualisierungen seltener durchführen, Token-Positionen lokal tracken statt ständig abzufragen, und große Transaktionen zu Zeiten durchführen, wenn weniger korrelierbare Aktivität stattfindet. Dies ist ein Verhaltensmittel, das keine technische Konfiguration erfordert, aber konsequent durchgeführt sein muss.

Das vierte Mittel ist die Nutzung von Privacy Coins oder Layer-2-Lösungen mit zusätzlicher Privatheit, die RPC-Level-Sichtbarkeit nicht vollständig beseitigen, aber verschleieren. Allerdings ist der EVM-Ökosystem nicht auf Privacy-First-Design ausgelegt, daher sind diese Optionen begrenzt.

Das fünfte Mittel ist Awareness. Nutzer sollten verstehen, dass die Verbindung zwischen Wallet und Blockchain nicht Ende-zu-Ende-verschlüsselt ist und dass RPC-Endpoints ein Datensichtbarkeitsproblem darstellen. Dies ist nicht dasselbe wie die Kenntnis, dass Private Keys lokal gespeichert sind. Ein Nutzer kann sicher fühlen, weil Rabby Sicherheitswarnungen anzeigt und Hardware-Wallet-Support anbietet, aber gleichzeitig durch einen böswilligen Node ausspioniert werden. Rabby könnte diese Realität deutlicher kommunizieren.

Die Zukunft von Wallet-Infrastruktur

Die langfristige Lösung könnte in vertrauensfreien RPC-Infrastrukturen liegen. Projekte wie Blaze oder The Graph versuchen, dezentralisierte Query-Layer zu bauen, bei denen kein einzelner Node Macht über die Daten hat. Wenn Rabby oder andere Wallets solche Infrastrukturen nutzen könnten, würde das Datensichtbarkeitsproblem an der Quelle gelöst. Allerdings sind diese Lösungen noch nicht ausgereift oder weit verbreitet genug für tägliche Nutzung.

Eine andere Richtung ist die Zukunft von Blockchains selbst. Wenn mehr Validator und Staking-Systeme MEV-Burning oder Encrypted Mempools implementieren, wird das Profitierungspotenzial für Node-Betreiber verringert. Ethereum-Upgrades wie Proposer-Builder Separation versprechen, Front-Running schwächer zu machen, aber nicht zu eliminieren. Für Desktop- und Mobile-Apps von Rabby wird es wahrscheinlich länger dauern, bis bessere Lösungen implementiert werden, weil die Komplexität wächst.

Zwischenzeitlich ist der Status quo: Rabby ist eine sichere, benutzerfreundliche Wallet mit soliden Sicherheitsfeatures auf der Transaktionssignierungsebene. Aber die Kommunikation zwischen Wallet und Blockchain bleibt eine Schwachstelle, die durch öffentliche RPC-Endpoints entsteht. Nutzer, die sich dieses Risikos bewusst sind und bereit sind, private Endpoints zu konfigurieren, können ihre Sicherheit erheblich verbessern. Nutzer, die dies nicht tun, akzeptieren ein stilles Risiko, das sie durch die Extension nicht sehen.