Blog Details

Ein Enterprise-Netzwerk benötigt Kontrolle über Validierung, Gebührenstruktur und Transaktionsdurchsatz – ein öffentliches Blockchain-Netzwerk bietet diese Eigenschaften nicht. Avalanche-Subnets ermöglichen es, unabhängige oder private Blockchains zu erstellen, die trotzdem mit der Avalanche-Hauptkette verbunden bleiben. Das technische Problem entsteht jedoch, wenn die Betreiber solcher Subnets ihre Anwender mit einem zuverlässigen Wallet-Interface ausstatten müssen: Die Wallet muss nicht nur Transaktionen signieren können, sondern auch Netzwerkparameter wie RPC-Endpoints, Gas-Token und Chain-IDs korrekt handhaben.

Rabby ist ein non-custodial Multi-Chain Web3 Wallet, das für EVM-kompatible Blockchains konzipiert wurde – und genau hier liegt die operative Chance. Weil Avalanche-Subnets EVM-kompatibel sind und Rabby vorkonfigurierte sowie benutzerdefinierte Netzwerke unterstützt, kann die Wallet als standardisierte Lösung in Enterprise-Szenarien eingesetzt werden. Die Transaktionssimulation vor dem Signieren, die Hardware-Wallet-Integration und die vollständige Kontrolle über Private Keys auf dem Gerät des Nutzers bieten die erforderliche Sicherheit. Die praktische Frage ist nicht, ob Rabby mit Subnets funktioniert, sondern wie eine Subnet-Betreiber die Wallet richtig konfiguriert, welche Sicherheitsvorkehrungen notwendig sind, und in welchen Use-Cases der Aufwand sich lohnt.

Avalanche-Subnets als Infrastruktur verstehen

Eine Avalanche-Subnet ist eine Untergruppe von Validierungsknoten, die einen eigenen Konsens bilden und ihre eigene Blockchain ausführen. Im Gegensatz zu einem isolierten privaten Netzwerk können Subnets mit dem Avalanche Primary Network synchronisiert bleiben, was Cross-Chain-Transaktionen oder Asset-Brücken ermöglicht. Die Betreiber entscheiden über Netzwerkparameter: Gas-Token, Gebührenstruktur, Block-Zeit und Validierungsschwelle. Das macht Subnets zu einer Lösung für Konsortien, Supply-Chain-Netzwerke und Finanzinfrastruktur-Anwendungen, bei denen die Teilnehmer eine geteilte Kontrolle über das Netzwerk haben möchten.

Für einen Nutzender stellt ein Subnet dennoch ein technisches Problem dar: Die Wallet muss die Subnet-spezifischen Parameter kennen. Das schließt eine eindeutige Chain-ID, den RPC-Endpoint des Subnet-Netzwerks, den Namen des nativen Gas-Tokens und dessen Dezimalstellen ein. Ohne korrekte Parameter zeigt die Wallet eine fehlerhafte Balance, kann Transaktionen nicht breitcasten oder bestätigt einen falschen Netzwerk-Status. Ein zentralisierter öffentlicher Explorer, der die Parameter kuratiert, existiert nicht. Die Subnet-Betreiber selbst müssen diese Informationen veröffentlichen und sicherstellen, dass sie in ein Wallet importiert werden können.

Rabby löst diesen Teil der Aufgabe durch sein benutzerdefiniertes Netzwerk-Setup. Eine EVM blockchain ist vom technischen Standpunkt eine Kette, die sich an den Ethereum Virtual Machine-Standard hält – und Rabby unterstützt als multi chain wallet nicht nur Ethereum, Arbitrum, Polygon und andere etablierte Netzwerke, sondern erlaubt es auch, beliebige EVM-kompatible Blockchains manuell hinzuzufügen. Das bedeutet, dass eine Subnet-Betreiber die Netzwerkparameter dokumentieren kann und Nutzer diese dann eintragen, ohne dass Rabby einen vorab konfigurierten Eintrag benötigt.

Ein zweiter Punkt ist die Vertrauensstruktur: Der Nutzer speichert seine Private Keys verschlüsselt auf seinem Gerät. Die Wallet selbst verwaltet die Schlüssel nicht. Das hat Konsequenzen für die Sicherheit einer Subnet-Transaktion: Wenn eine böswillige Partei einen falschen RPC-Endpoint in die Wallet-Konfiguration des Nutzers einschleust oder den Netzwerknamen ändert, kann die Transaktion auf der falschen Blockchain landen. Deswegen ist eine verifizierten Verteilung der Netzwerk-Konfiguration ein kritischer Schritt, den die Subnet-Betreiber steuern müssen.

Netzwerk-Setup in Rabby durchführen

Die Browser-Extension von Rabby für Chrome, Brave und Edge bietet ein Interface zum Hinzufügen von Netzwerken. Die Prozedur ist relativ einfach, aber Genauigkeit ist unabdingbar: Der Nutzer öffnet die Wallet-Einstellungen, findet die Option für „Netzwerk hinzufügen” und gibt die erforderlichen Felder ein. Das schließt ein die Chain-ID (eine eindeutige numerische Kennung), den RPC-URL (der Endpoint für die JSON-RPC-Anfragen), den Block-Explorer-URL (falls vorhanden) und die Token-Details wie Namen, Symbol und Dezimalstellen.

Eine Subnet-Betreiber sollte diese Informationen in einem Format bereitstellen, das der Nutzer leicht überprüfen kann. Ein bewährtes Verfahren ist eine technische Dokumentation, die auch einen QR-Code oder einen Direktlink enthält, der die Netzwerk-Parameter in das Wallet importiert. Manche Wallets unterstützen standardisierte Import-Links nach dem Muster `chainId=123&rpcUrl=https://…`. Rabby nutzt eine grafische Eingabemaske, aber eine schriftliche Dokumentation bleibt notwendig, damit der Nutzer weiß, welcher Endpoint der richtige ist – insbesondere wenn mehrere Validator-Knoten unterschiedliche URLs bereitstellen.

Ein häufiger Fehler ist, einen öffentlichen RPC-Endpoint als Standard zu verwenden, ohne seine Verfügbarkeit und Zuverlässigkeit zu prüfen. Ein Endpoint kann überlastet sein, falsche Daten zurückgeben oder wegfallen. Eine professionelle Subnet-Infrastruktur sollte einen dedizierten RPC-Service betreiben oder einen bekannten RPC-Provider wie QuickNode, Alchemy oder Infura für die Subnet integrieren. Nutzer von Rabby können dann zwischen mehreren RPC-Endpoints wählen, und die Wallet wechselt automatisch auf einen anderen, falls einer ausfällt.

Ein weiterer kritischer Punkt ist die Kommunikation des nativen Gas-Tokens. Eine Subnet kann eine völlig neue Token haben oder AVAX weiterverwendet. Token-Symbol, Dezimalstellen und die Kontraktadresse (falls es sich um einen ERC-20-Token handelt) müssen exakt übereinstimmen. Wenn ein Nutzer den Token mit falschen Dezimalstellen importiert, zeigt Rabby völlig falsche Balancen an – 1000 Token können als 0.001 Token angezeigt werden. Das ist kein Sicherheitsproblem des Wallets selbst, sondern eines schlechten Onboardings.

Transaktionssimulation als Schutzschicht

Rabby bietet ein Feature, das gerade bei Subnets wertvoll ist: die Transaktionssimulation vor dem Signieren. Bevor der Nutzer eine Transaktion mit seinem Private Key bestätigt, führt Rabby eine Simulation durch, um vorherzusagen, welche Effekte die Transaktion haben wird. Das schließt ein, welche Smart Contracts ausgelöst werden, wie viel Gas benötigt wird und ob der Transaktion zu einem kritischen Fehler führen könnte.

In einer Subnet-Umgebung ist diese Simulation ein Schutz vor mehreren Risikoklassen. Erstens: Ein böser RPC-Endpoint könnte dem Nutzer einen falschen Kontostand anzeigen oder ihn davon überzeugen, dass eine bestimmte Smart-Contract-Adresse legitim ist, obwohl sie kompromittiert wurde. Die Simulation deutet auf Anomalien hin – etwa wenn eine Transaktion zu einem unerwarteten Token-Transfer führen würde. Zweitens: In einer neuen oder kleineren Subnet können Smart Contracts weniger intensiv getestet sein. Ein Fehler im Contract könnte Gelder „einfrieren” oder unerwartete Weise verhalten. Die Simulation zeigt dies vor dem Signieren an.

Drittens schützt die Simulation auch vor Phishing. Wenn ein Nutzer einen bösartigen Link klickt oder ihn zu einer gefälschten dApp weitergeleitet wird, könnte ein böser Vertrag versuchen, Tokens zu transferieren oder Approvals zu ändern. Rabby’s Sicherheitswarnungen flaggen verdächtige Kontraktaufrufe und zeigen dem Nutzer genau an, welche Tokens oder Approvals gefährdet sind. Das ist gerade bei einer Subnet wichtig, da der Ökosystem oft enger ist und Nutzer dApps und Smart Contracts weniger eingehend überprüft haben als bei Ethereum.

Allerdings gibt es auch eine Grenze für die Effektivität dieser Simulation: Wenn der RPC-Endpoint selbst kompromittiert ist und falsche Daten zurückgibt, kann auch die Simulation nicht alle bösen Absichten erkennen. Ein Endpoint könnte behaupten, dass eine Transaktion sicher ist, obwohl sie tatsächlich Gelder stiehlt. Deswegen bleibt die Überprüfung des RPC-Endpoints durch die Subnet-Betreiber eine notwendige Vorsichtsmaßnahme – die Wallet-Sicherheit ist nur so stark wie der Zugang zur Blockchain-Daten.

Hardware-Wallet-Integration für Subnet-Transaktionen

Für Enterprise-Anwendungen oder High-Value-Transaktionen in einer Subnet ist die Kombination von Rabby mit einer Hardware-Wallet wie Ledger oder Trezor ein bewährtes Muster. Der Nutzer speichert die Private Keys auf dem Hardware-Gerät, nicht auf dem Computer. Rabby fungiert dann als Schnittstelle: Die Wallet zeigt die Transaktion an, aber der Nutzer muss auf dem Hardware-Gerät selbst bestätigen – das Private Key verlässt das sichere Element des Geräts niemals.

Bei Avalanche-Subnets bringt das eine zusätzliche Schutzschicht: Ein böser RPC-Endpoint oder ein Phishing-Link kann den Computer des Nutzers attackieren, kann aber nicht den Private Key auf dem Hardware-Gerät stehlen. Das Hardware-Device zeigt die Transaktion unabhängig an – es könnte eine andere Adresse oder einen anderen Betrag entdecken, wenn der Computer versucht, die Daten zu manipulieren. Das ist besonders wertvoll, wenn die Subnet neue oder wenig-erprobte Smart Contracts enthält oder wenn der Nutzer einem Supply-Chain-Netzwerk mit vielen Validierungsknoten verschiedener Organisationen angehört.

Ein praktisches Szenario: Ein Logistik-Unternehmen nutzt eine Avalanche-Subnet, um Warenbewegungen zu dokumentieren. Jede Bewegung erzeugt eine Token-Transfer auf der Subnet. Der Operator des Unternehmens nutzt Rabby mit einer Ledger-Wallet, um diese Transaktionen zu signieren. Wenn ein angreifer versucht, eine falsche Warenbewegung einzutragen oder Tokens zu stehlen, muss er auch die Ledger physisch haben oder den Private Key irgendwie extrahieren – was deutlich schwärer ist als eine Software-Wallet zu hacken.

Rabby unterstützt sowohl Ledger als auch Trezor, und die Konfiguration für Subnets ist dieselbe wie für öffentliche Blockchains: Der Nutzer verbindet die Hardware-Wallet, Rabby erkennt sie, und der Nutzer wählt das Account aus. Das funktioniert, weil Hardware-Wallets ebenfalls mit EVM-Adressen und Chain-IDs arbeiten – die Subnet ist für das Hardware-Gerät einfach eine neue Chain-ID.

Use-Cases und wirtschaftliche Schwellwerte

Nicht jeder Anwendungsfall lohnt sich für eine private Subnet mit Rabby. Der Aufwand besteht aus Validierungsinfrastruktur, RPC-Service-Betrieb, Nutzer-Onboarding und Wallet-Konfiguration. Ein Unternehmen sollte eine Subnet in Betracht ziehen, wenn es eines oder mehrere der folgenden Ziele hat: vollständige Kontrolle über Netzwerk-Parameter, Datenschutz vor öffentlicher Blockchain-Transparenz, spezifische Gebührenstruktur oder technische Anforderungen, oder Zusammenarbeit mit mehreren Organisationen in einem Konsortium-Netzwerk.

Ein realistisches Beispiel: Ein Konsortium von Banken betreibt eine Subnet für schnelle Abwicklung von Interbank-Zahlungen. Der Durchsatz muss hoch sein, die Gebühren müssen niedrig sein, und die Daten dürfen nicht öffentlich sein. Jede Bank betreibt einen oder mehrere Validierungsknoten. Die Kunden der Banken nutzen Rabby, um Transaktionen zu signieren. Das ist wirtschaftlich sinnvoll, weil der Betrieb der Infrastruktur auf die Konsortium-Partner verteilt ist und die Gebühren unter den Partnern aufgeteilt werden. Die Wallet wird zum Standardtool, auf das jeder Partner setzt.

Ein weniger geeignetes Beispiel: Ein Startup mit einer Idee für eine neue DeFi-Primitive startet eine Avalanche-Subnet als Testumgebung. Nur wenige Nutzer nutzen sie. Die Infrastrukturkosten sind dennoch gleich, die Netzwerk-Effekte sind minimal, und es ist nicht klar, ob Nutzer das Netzwerk verstehen. In diesem Fall ist es effizienter, auf dem Avalanche-Hauptnetz oder einer bestehenden Layer-2 wie Arbitrum oder Polygon zu starten – diese haben bereits Ökosystem-Liquidität und Nutzer-Vertrautheit. Rabby unterstützt alle diese Blockchains, so dass der Umstieg vom Hauptnetz zur Subnet später immer noch möglich ist.

Ein wichtiger wirtschaftlicher Punkt: Die Betreiber einer Subnet müssen Nutzern helfen, Rabby zu konfigurieren. Das erfordert klare Dokumentation, Schritt-für-Schritt-Guides und eventuell Support-Kanäle. Wenn Nutzer die Netzwerk-Parameter falsch eingeben oder keinen zuverlässigen RPC-Endpoint finden, werden sie frustriert und kehren zu bekannteren Blockchains zurück. Das Wallet-Interface von Rabby ist benutzerfreundlich, aber es ersetzt nicht gute Dokumentation durch die Subnet-Betreiber.

Sicherheits- und Betriebsvorkehrungen

Eine Subnet, die für Production eingesetzt wird, erfordert mehrere Sicherheitsmaßnahmen. Erstens: Die Netzwerk-Parameter müssen durch einen vertrauenswürdigen Kanal verteilt werden. Das kann ein offizieller Dokumentations-Link sein, der von einem Unternehmens-Server gehostet wird und ein zertifikat besitzt. Ein öffentlicher Forum-Post, eine Slack-Nachricht oder ein Twitter-Tweet ist unzureichend – ein Angreifer könnte diese unterlaufen oder ein Fake-Post verbreiten. Wenn Rabby oder die Browser-Extension selbst eines Tages Netzwerk-Lists unterstützen sollte, wäre das ideal, aber derzeit ist manuelle Eingabe unvermeidbar.

Zweitens: Der RPC-Endpoint muss überwacht und hochverfügbar sein. Ein Single-Point-of-Failure RPC-Service macht die gesamte Subnet unerreichbar. Eine professionelle Subnet sollte mehrere RPC-Knoten betreiben oder einen verwalteten RPC-Provider unter Vertrag nehmen, der Failover garantiert. Rabby kann in seinen Einstellungen mehrere RPC-Endpoints für ein Netzwerk speichern und automatisch einen neuen versuchen, wenn einer ausfällt – das ist ein wichtiges Fallback-Muster.

Drittens: Die Betreiber sollten Sicherheitswarnungen und Exploits aktiv überwachen. Wenn in einem Smart Contract der Subnet ein kritischer Bug entdeckt wird, müssen die Nutzer schnell informiert werden. Rabby’s Transaktionssimulation kann helfen, bestimmte böse Contracts zu erkennen, aber sie ist kein Ersatz für regelmäßige Audits und Incident-Response-Planung. Ein Konsortium-Netzwerk sollte einen Incident-Response-Plan haben, falls eine Wallet kompromittiert wurde oder ein Contract gehackt wird.

Viertens: Private Keys sollten immer unter der Kontrolle des Nutzers bleiben – nicht der Subnet-Betreiber. Deswegen ist Rabby als non-custodial Wallet die richtige Wahl. Ein Betreiber, der Nutzer dazu drängt, Keys auf einem zentralen Service zu deponieren, schafft ein neues Sicherheitsrisiko. Die dezentrale Natur einer Blockchain-Subnet ist nur dann sinnvoll, wenn die Wallets ebenfalls dezentral sind.

Migrationen und Langzeitstabilität

Ein Szenario, das nicht unterschätzt werden sollte, ist der Übergang zwischen Netzwerk-Versionen. Eine Subnet kann seine Chain-ID ändern, Validatoren hinzufügen oder entfernen oder sogar zu einer anderen Layer wechseln. Wenn Nutzer bereits Transaktionen in einer Subnet gemacht haben, benötigen sie eine klare Migrationsstrategie.

Rabby ermöglicht es, mehrere Netzwerke parallel zu konfigurieren. Ein Nutzer könnte also sowohl die alte Subnet als auch die neue speichern, bis klar ist, dass alle Assets migriert wurden. Das erfordert jedoch erneut, dass die Betreiber eine explizite Migrationsstrategie dokumentieren – etwa einen Smart Contract, der Assets von einer Subnet in die andere brückt, oder einen manuellen Withdrawn-Prozess. Die Wallet selbst kann Assets nicht automatisch zwischen Subnets verschieben, wenn die Subnets unterschiedliche Blockchains sind.

Für Subnets, die lange Zeit stabil sein sollen, ist eine offene Kommunikation über Pläne, Ausfallzeiten und Upgrades notwendig. Ein Nutzer, der seine Keys in Rabby speichert, verliert nie die Kontrolle über seine Assets – aber er könnte die Subnet nicht erreichen, falls RPC-Endpoints wegfallen oder das Netzwerk abgeschaltet wird. Deswegen sollten Betreiber mindestens mehrere Monate im Voraus ankündigen, wenn eine Subnet heruntergefahren wird, damit Nutzer Assets abheben und migrieren können.

Ein zusätzlicher Punkt für Nutzer: Backups und Recovery. Rabby speichert Private Keys verschlüsselt auf dem Gerät. Ein Nutzer kann den Seed Phrase (oder die Papier-Backups) regelmäßig überprüfen und sicherstellen, dass er den Private Key durch den Seed wiederherstellen kann. Das ist Standard für jede web3 wallet, aber es ist gerade bei Subnets wichtig: Wenn der Nutzer Rabby neu installiert oder sein Gerät wechselt, muss der Seed funktionieren, unabhängig davon, ob die Subnet noch erreichbar ist.

Rabby im Vergleich zu anderen Lösungen

Es gibt andere Wallets, die EVM-kompatible Blockchains unterstützen. MetaMask ist vermutlich das bekannteste Beispiel und unterstützt ebenfalls benutzerdefinierte Netzwerke. Der Hauptunterschied zu Rabby liegt in der Benutzererfahrung: Rabby wurde speziell für Multi-Chain-Szenarien entwickelt. Es zeigt in einem Dashboard mehrere Blockchains gleichzeitig, ermöglicht schnelle Netzwerk-Wechsel und hat eine stärker integrierte Transaktionssimulation. Für einen Nutzer, der häufig zwischen einer Subnet und dem Avalanche-Hauptnetz oder anderen EVM blockchains hin- und herwechselt, ist Rabby ergonomischer.

Ein weiterer Punkt ist die Desktop- und Mobile-Verfügbarkeit. Rabby ist derzeit als Browser-Extension verfügbar, und eine Desktop-App für Windows und macOS ist in Entwicklung. Eine Mobile-App für iOS und Android ist ebenfalls geplant – Nutzer können rabby wallet mobile für ios und android in den App Stores aktualisieren, sobald diese verfügbar sind. Das ist wichtig für Subnets, die auf mobilen Geräten genutzt werden, etwa für Supply-Chain-Tracking auf Smartphones von Logistik-Mitarbeitern.

Ein dritter Unterschied ist die Sicherheits-Architektur. Rabby hat eine starke Transaktionssimulation, die böse Contracts und Phishing-Versuche erkennt. Das ist nicht einzigartig, aber die Implementierung ist durchdacht. Für Subnet-Betreiber, die ihren Nutzern ein sicheres Onboarding geben möchten, ist eine Wallet, die viele böse Contracts automatisch erkennt, ein großer Vorteil – es reduziert Support-Last und Nutzer-Fehler.

MetaMask hat eine größere Marktpräsenz und ein etablierteres Ecosystem, aber das ist für eine Subnet möglicherweise irrelevant. Das wichtigere Kriterium ist, ob die Wallet zuverlässig funktioniert, die Transaktionssimulation robust ist und die Betreiber ein klares Interface zur Konfiguration haben. Auf all diese Punkte erfüllt Rabby die Anforderung.