Einen Binance Smart Chain (BSC) Node einrichten

BNB Smart Chain — weiterhin vielfach als Binance Smart Chain gesucht, ihr Name bis Februar 2022 — ist eine EVM-Chain, die seit dem Fermi-Hardfork im Januar 2026 alle 0,45 Sekunden einen Block produziert, nachdem Maxwell das Intervall Mitte 2025 bereits auf 0,75 Sekunden halbiert hatte. Diese Geschwindigkeit ist angenehm für Nutzer und anspruchsvoll für Node-Betreiber: Ein BSC-Full-Node braucht Hardware im Server-Format und die richtige Sync-Strategie, und wird eines von beidem falsch gemacht, erreicht der Node nie den Chain-Head. Dieser Guide ist die Copy-paste-Version, bei der die offiziellen Docs aufhören: snapshot-basiertes Setup mit dem bnb-chain-geth-Fork, eine systemd-Unit, Sicherheitshinweise für RPC-Nodes, Sync-Zeit- und Kostenrechnung, sowie ein ehrlicher Blick darauf, wann Sie gar keinen betreiben sollten.

Was ist ein BSC-Node, und welchen Typ brauchen Sie?

Ein BSC-Node betreibt den Chain-Client, validiert Blocks und gibt Ihnen einen lokalen JSON-RPC-Endpoint mit derselben Schnittstelle wie Ethereum: eth_blockNumber, eth_call, eth_sendRawTransaction und den Rest. In der Praxis zählen vier Varianten.

Ein Full Node hält den aktuellen State und bedient RPC — der Standard, und das Thema dieses Guides. Ein Fast Node ist ein Full Node, der mit --tries-verify-mode none gestartet wird; die offiziellen Docs empfehlen ihn für RPC-Workloads, bei denen Import-Geschwindigkeit mehr zählt als strikte State-Trie-Verifikation. Ein Archive Node speichert jeden historischen State, braucht Speicherplatz im zweistelligen Terabyte-Bereich und ergibt nur für Indexierung und Analytics Sinn. Ein Validator produziert Blocks, was voraussetzt, in die kleine gewählte Menge mit gestaktem BNB gewählt zu werden — ein eigenes Thema jenseits eines Setup-Guides.

Und ein Light Node? Der geth-Fork hat den Light-Client-Code geerbt, aber in der Praxis bedient auf BSC fast nichts Light Peers, betrachten Sie „BSC Light Node” also als nicht verfügbar. Ist ein gepruneter Full Node mehr, als Sie brauchen, ist genau das der Fall für eine API — siehe den letzten Abschnitt.

Dieselbe Wahl als Tabelle, mit Speicherzahlen Stand Mitte 2026:

BSC und Geth: eine Codebasis, zwei Chains

BSCs Client ist ein Fork von go-ethereum, gepflegt unter github.com/bnb-chain/bsc, und die Binary heißt buchstäblich geth. Sie spricht dasselbe JSON-RPC, akzeptiert die meisten derselben Flags und fügt BSC-Spezifika hinzu: den Parlia-Proof-of-Staked-Authority-Consensus (ein Prozess ist der gesamte Node — kein separater Consensus-Client wie beim Post-Merge-Ethereum), plus Flags wie --tries-verify-mode. Zwei praktische Konsequenzen folgen daraus. Ihr Ethereum-Tooling funktioniert unverändert gegen einen BSC-Node. Und Sie müssen den bnb-chain-Build verwenden — Upstream-Geth kann BSC nicht synchronisieren, was der häufigste Anfängerfehler mit „bsc geth” ist.

Hardware-Anforderungen für BSC-Nodes

Die Basiswerte stammen aus dem bnb-chain/bsc-README, angepasst an das Datenwachstum bis 2026:

Die Zeile, die die meisten Setups killt, sind die IOPS, nicht die Kapazität. Bei 0,45-Sekunden-Blocks schreibt der Node ununterbrochen, und Cloud-Block-Storage mit Standard-IOPS fällt hinter den Chain-Head zurück und holt das nie wieder auf. Die Referenz des README ist AWS gp3 mit 8.000 provisionierten IOPS und Sub-Millisekunden-Lesezugriff (Instanzklasse m5zn.3xlarge auf AWS, c2-standard-16 auf Google Cloud); eine lokale NVMe-Platte in einem dedizierten Server übertrifft diese Marke mit Reserve.

Schritt für Schritt: BSC-Full-Node aus dem offiziellen Snapshot

Von Genesis zu synchronisieren ist möglich und eine schlechte Idee. Die Docs selbst raten davon ab — sie schlagen für den Versuch Hardware mit 40k+ IOPS vor, und es dauert trotzdem Wochen. Der unterstützte Weg: den Chain-Data-Snapshot herunterladen, den Node darauf starten, aufholen lassen. Die Befehle gehen von Ubuntu 24.04 aus.

1. Server vorbereiten

sudo apt update && sudo apt install -y aria2 lz4 unzip jq
sudo useradd --no-create-home --shell /usr/sbin/nologin bsc
sudo mkdir -p /var/lib/bsc
sudo chown bsc:bsc /var/lib/bsc
sudo ufw allow 30311 comment 'bsc p2p'

Port 30311 ist BSCs Peer-to-Peer-Port und der einzige Blockchain-Port, der offen sein sollte. Der RPC-Port bleibt auf localhost.

2. Die bnb-chain-geth-Binary herunterladen

cd /tmp
curl -s https://api.github.com/repos/bnb-chain/bsc/releases/latest \
  | jq -r '.assets[] | select(.name=="geth_linux") | .browser_download_url' \
  | xargs wget -O geth_linux
chmod +x geth_linux
sudo mv geth_linux /usr/local/bin/geth-bsc
geth-bsc version

Die Binary in geth-bsc umzubenennen verhindert den klassischen Unfall, ein per Distro installiertes Upstream-Geth gegen BSC-Daten zu starten.

3. config.toml und genesis.json holen

cd /tmp
curl -s https://api.github.com/repos/bnb-chain/bsc/releases/latest \
  | jq -r '.assets[] | select(.name=="mainnet.zip") | .browser_download_url' \
  | xargs wget -O mainnet.zip
unzip -o mainnet.zip
sudo mv config.toml genesis.json /var/lib/bsc/
sudo chown bsc:bsc /var/lib/bsc/config.toml /var/lib/bsc/genesis.json

Hinweis: geth-bsc init genesis.json wird nur beim Sync ab Genesis benötigt. Auf dem Snapshot-Weg überspringen Sie init — der Snapshot bringt seine eigene Datenbank mit.

4. Den Snapshot herunterladen und entpacken

Snapshots liegen bei github.com/bnb-chain/bsc-snapshots, dem offiziellen Repository. Es veröffentlicht Stand Mitte 2026 drei Datensätze: den gepruneten Snapshot mit rund 1,6 TB komprimiert (nur aktuelle Blocks — der richtige für diesen Guide), den vollständigen Snapshot mit rund 6 TB, und inkrementelle Snapshots, die nur die Änderungen seit einem vorherigen abrufen, eine Ergänzung aus der Fermi-Ära (BEP-593). Die aktuelle Generation braucht Client v1.7.2 oder neuer, was der Download in Schritt 2 bereits erfüllt. Das Repo liefert außerdem ein fetch-snapshot.sh-Skript, das in einem Befehl herunterlädt, die MD5-Prüfsumme kontrolliert (Flag -c) und entpackt; der manuelle Weg unten zeigt, was dahinter passiert. Zwei Wege, das Archiv auf die Platte zu bekommen:

cd /var/lib/bsc
# Option A: resumable download, needs space for archive + extracted data
sudo -u bsc aria2c -x8 -s8 -c '<PASTE_SNAPSHOT_URL>'
sudo -u bsc bash -c "lz4 -cd geth.tar.lz4 | tar -x"

# Option B: stream-extract, needs space only once, but no resume
sudo -u bsc bash -c "wget -qO- '<PASTE_SNAPSHOT_URL>' | lz4 -d | tar -x"

aria2c lädt über acht Verbindungen herunter und setzt nach Unterbrechungen fort (-c) — mit reinem wget beginnt ein abgebrochener Multi-Terabyte-Download von vorn. Nach der Extraktion muss die Chain-Datenbank unter /var/lib/bsc/geth/chaindata liegen; das Archiv-Layout hat sich zwischen Snapshot-Generationen geändert, verschieben Sie also bei Bedarf den inneren geth-Ordner dorthin. Prüfen Sie vor dem Entpacken: vergleichen Sie die MD5 von der Snapshot-Seite, oder lassen Sie fetch-snapshot.sh -c das übernehmen — ein bitgekipptes Terabyte-Archiv kostet Sie einen Tag. Option A braucht Platz für Archiv und extrahierte Daten gleichzeitig, beim gepruneten Set rund 2 TB Puffer, und das ist der eigentliche Grund für die Empfehlung einer 4-TB-Platte.

5. systemd-Unit

Erstellen Sie /etc/systemd/system/bsc.service:

[Unit]
Description=BSC full node (bnb-chain geth fork)
After=network-online.target
Wants=network-online.target

[Service]
User=bsc
Group=bsc
Type=simple
Restart=always
RestartSec=5
TimeoutStopSec=600
LimitNOFILE=65536
ExecStart=/usr/local/bin/geth-bsc \
  --config /var/lib/bsc/config.toml \
  --datadir /var/lib/bsc \
  --cache 8000 \
  --tries-verify-mode none \
  --history.transactions 0 \
  --rpc.allow-unprotected-txs \
  --http --http.addr 127.0.0.1 --http.port 8545 \
  --http.api eth,net,web3

[Install]
WantedBy=multi-user.target

--tries-verify-mode none ist der „Fast Node”-Schalter aus den offiziellen Docs, empfohlen für RPC-Serving, wenn Sie den State-Konsistenz-Trade-off akzeptieren. --history.transactions 0 hält den Transaktionsindex vollständig; ältere Guides nutzen für denselben Zweck das veraltete --txlookuplimit 0. TimeoutStopSec=600 gibt dem Node zehn Minuten zum Flushen beim Herunterfahren — harte Kills korrumpieren früher oder später die Datenbank.

6. Starten und verifizieren

sudo systemctl daemon-reload
sudo systemctl enable --now bsc
journalctl -fu bsc

Gesunde Ausgabe ist ein stetiger Strom von „Imported new chain segment”-Zeilen. Vergleichen Sie Ihre Höhe mit einem öffentlichen Explorer:

curl -s -X POST -H 'Content-Type: application/json' \
  -d '{"jsonrpc":"2.0","method":"eth_blockNumber","params":[],"id":1}' \
  http://127.0.0.1:8545

Konvertieren Sie das Hex-Ergebnis und prüfen Sie es gegen bscscan.com. Wenn eth_syncing false zurückgibt und die Höhe übereinstimmt, ist der Node live.

Einen BSC-RPC-Node absichern

Die Unit oben bindet RPC an 127.0.0.1, was für einen Node richtig ist, den nur lokale Software nutzt. Brauchen andere Maschinen Zugriff, öffnen Sie Port 8545 nicht roh ins Internet. Setzen Sie nginx oder Caddy davor, mit TLS, einem Auth-Token oder IP-Allowlist und Rate-Limiting. Halten Sie --http.api bei eth,net,web3 — exponieren Sie niemals admin, debug oder txpool auf einem erreichbaren Node. Unauthentifizierte öffentliche BSC-Endpoints werden binnen Tagen entdeckt und bombardiert, und uneingeschränkte eth_getLogs-Aufrufe können selbst starke Hardware ins Straucheln bringen. Der P2P-Port 30311 bleibt der einzige offene Blockchain-Port. Ein Unterschied zu Ethereum ist es wert, genannt zu werden: Es gibt hier keine Engine-API und kein JWT-Secret, weil Parlia keinen separaten Consensus-Client braucht — die Firewall und die Localhost-Bindung sind der gesamte Perimeter, weshalb sie stimmen müssen.

Monitoring und Health-Checks

Ein BSC-Node versagt auf eine typische Art: Der Prozess läuft weiter, während der Node hinter den Head zurückfällt. Uptime-Checks auf Prozessebene übersehen das vollständig, prüfen Sie stattdessen Sync-Status und Höhe.

# false = at the head; a sync object = still catching up
curl -s -X POST -H 'Content-Type: application/json' \
  -d '{"jsonrpc":"2.0","method":"eth_syncing","params":[],"id":1}' \
  http://127.0.0.1:8545

# peer count as hex
curl -s -X POST -H 'Content-Type: application/json' \
  -d '{"jsonrpc":"2.0","method":"net_peerCount","params":[],"id":1}' \
  http://127.0.0.1:8545

Die strengere Prüfung vergleicht Ihre eth_blockNumber alle paar Minuten mit einer zweiten Quelle — einem öffentlichen Endpoint oder einem Explorer — und alarmiert, wenn die Lücke wächst. Kalibrieren Sie die Schwelle auf BSCs Takt: 400 Blocks klingt nach viel und sind bei 0,45-Sekunden-Blocks drei Minuten Chain-Zeit. Aus Ethereum-Tooling kopierte Schwellen sind hier deutlich zu lax.

Der Fork erbt Geths Metrics-Stack. Starten Sie mit --metrics (Prometheus-Endpoint auf Port 6060, halten Sie ihn auf localhost), und die Standard-Geth-Grafana-Dashboards funktionieren größtenteils unverändert. Setzen Sie vor jedem Dashboard zwei Alerts: Speichernutzung über 85 Prozent, und lokale Block-Höhe fünf Minuten flach. Ein tägliches journalctl -u bsc --since -24h | grep -ci error in einer Cron-Mail rundet es ab — steigende Fehlerzahlen kündigen die meisten Ausfälle Tage im Voraus an.

Sync-Zeit, und warum Snapshots nützlich bleiben

Rechnung statt Versprechen: Der 1,6-TB-geprunte Snapshot braucht bei konstanten 100 MB/s rund 4,5 Stunden zum Download, bei 50 MB/s rund 9. Die Extraktion ist Disk-gebunden und fügt auf NVMe ein paar Stunden hinzu. Der Snapshot liegt ein bis zwei Tage hinter dem Chain-Head; ein gesunder Node importiert mehrfach schneller als Echtzeit, sodass das Aufholen Stunden kostet, keine Tage. Insgesamt planen Sie einen Arbeitstag ein. Genesis-Sync läuft dagegen Wochen auf extremer Hardware — weshalb die offizielle Empfehlung der Snapshot ist, Punkt.

State-Wachstum und Pruning

Die Datenbank wächst nach Tag eins weiter — State mit jedem neuen Contract und Account, Block-Daten im Takt, den 0,45-Sekunden-Blocks vorgeben. Das genaue Wachstum hängt von der Netzwerkaktivität ab; statt einer fixen Zahl zu vertrauen, führen Sie wöchentlich du -sh /var/lib/bsc/geth/chaindata aus und bauen Sie Ihre eigene Trendlinie. Das zu erwartende Muster: Hunderte GB pro Quartal, nicht pro Jahr.

Drei Werkzeuge halten die Größe im Zaum. geth-bsc snapshot prune-state ist das eingebaute Offline-Pruning: Es verwirft State-Nodes, auf die nichts mehr verweist, dauert bei einer Multi-Terabyte-Datenbank viele Stunden, und der Node bedient währenddessen nichts. Wipe-and-Restore ist die Alternative, die viele Betreiber bevorzugen: Alle paar Monate das Datadir löschen und den neuesten gepruneten Snapshot wiederherstellen. Die Gesamtausfallzeit ist oft geringer als beim Pruning, und Sie bekommen als Bonus eine frisch kompaktierte Datenbank.

Das dritte Werkzeug kam mit Fermi: inkrementelle Snapshots (BEP-593). Statt für jedes Refresh erneut 1,6 TB herunterzuladen, holen Sie nur, was sich seit der Snapshot-Generation, die Sie bereits haben, geändert hat, was das periodische Refresh von einem Über-Nacht-Job zu einer Sache von Stunden macht. Das bsc-snapshots-README dokumentiert diesen Workflow neben den klassischen Archiven.

Erigon auf BSC — und sein Nachfolger

Jahrelang war die Antwort auf BSC-Archive-Bedarf bsc-erigon, NodeReals Port von Erigon: ein vollständiger Archive-Sync von Grund auf in rund drei Tagen, gespeichert auf rund 4,3 TB, wo der geth-Fork zig Terabyte braucht. Dieses Kapitel ist geschlossen. Die Wartung endete mit 2025, und das Repository node-real/bsc-erigon wurde im April 2026 archiviert — nur lesbar, keine Fixes, kein Support für künftige Forks. NodeReal verweist Betreiber auf Reth-BSC, den Rust-basierten Nachfolger, als empfohlenen Archive-Client für die Zukunft.

Was das in der Praxis Mitte 2026 bedeutet: Für den gepruneten RPC-Node in diesem Guide bleibt der offizielle geth-Fork die Referenz und die sicherste Wahl. Für Archive-Workloads evaluieren Sie zuerst Reth-BSC, und betrachten Sie bestehende bsc-erigon-Maschinen als Migration, die noch aussteht — ein ungepflegter Client verpasst den nächsten Hardfork planmäßig.

Was ein BSC-Node kostet

Betrachten Sie das als Rechenweg, nicht als Preisliste. Die Klasse 16-Core / 64 GB / 4 TB NVMe ist Dedicated-Server-Territorium — keine ehrliche VPS-Stufe deckt das ab. Bei europäischen Hostern liegen Maschinen mit diesen Specs als Größenordnung im niedrigen bis mittleren dreistelligen Euro-Bereich pro Monat. Dieselben Specs aus Cloud-Instanzen mit 8k provisionierten IOPS (die AWS-Referenz aus dem README) landen typischerweise höher, oft um den Faktor zwei oder mehr, weil provisionierte IOPS separat abgerechnet werden.

Dann addieren Sie Ihre Stunden: initiales Setup ein Arbeitstag mit diesem Guide, plus Hardfork-Upgrades und Snapshot-Refreshes mit ein paar Stunden pro Monat. Multiplizieren Sie mit Ihrem Stundensatz. Für die meisten Teams landet die Arbeitszeile größer als die Hosting-Zeile — gut zu wissen, bevor Sie sich festlegen.

Wartung: Hardforks und Upgrades

BSC forkt in einem Tempo, das Ethereum-Betreiber überrascht. Allein 2025 brachte Lorentz und Maxwell, die jeweils das Block-Intervall halbierten; Fermi folgte am 14. Januar 2026 und brachte Blocks von 0,75 auf 0,45 Sekunden, während inkrementelle Snapshots hinzukamen und Fast Finality verschärft wurde. Jeder Fork hat eine Mindest-Client-Version — v1.6.4 für Fermi — und ein Node darunter bleibt am Fork-Block mit Consensus-Fehlern stehen. Stand Mitte 2026 liegt die Release-Linie bei v1.7.x, und die aktuellen Snapshots setzen mindestens v1.7.2 voraus.

Abonnieren Sie also den bnb-chain/bsc-Release-Feed auf GitHub und behandeln Sie Upgrades als Routine statt als Ereignis. Die Prozedur ist kurz: das neue geth_linux herunterladen, verifizieren, den Dienst stoppen, /usr/local/bin/geth-bsc ersetzen, neu starten — die Datenbank bleibt erhalten. Release Notes nennen Config-Änderungen, und BSC benennt Flags häufiger um als Upstream-Geth, überfliegen Sie sie also vor dem Neustart, nicht danach. Planen Sie eine Viertelstunde pro Release ein, und rechnen Sie mit einem Fork alle paar Monate.

Für Entwicklungs-Setups steht über das BSC-Deploy-Toolkit ein lokales privates Netzwerk zur Verfügung, statt Mainnet-Nodes zu betreiben.

Troubleshooting

Der Node importiert Blocks, fällt aber immer weiter hinter den Head zurück

Fast immer Disk-IOPS. Benchmarken Sie mit fio und vergleichen Sie gegen die 8k-IOPS-Referenz; Network-Attached-Storage mit Standard-IOPS ist der übliche Übeltäter. Bestätigen Sie, dass --tries-verify-mode none gesetzt ist. Liegt die Hardware unter der Anforderungstabelle, schließt kein Flag die Lücke.

„missing trie node”-Fehler, oder der Node startet nach einer Snapshot-Wiederherstellung bei Block 0 neu

Das Datadir-Layout stimmt nicht. Die Chain-Datenbank muss unter <datadir>/geth/chaindata liegen — zeigt das Log „Writing custom genesis block”, hat geth ein leeres Datadir gefunden und neu begonnen. Dienst stoppen, den extrahierten geth-Ordner an den richtigen Ort verschieben, neu starten.

Die Peer-Anzahl bleibt nahe null

Prüfen Sie, ob Port 30311 offen und weitergeleitet ist. Eine veraltete config.toml ist der zweite Verdächtige: Bootstrap- und Static-Node-Listen ändern sich über die Zeit, laden Sie also mainnet.zip erneut aus dem neuesten Release herunter. Bei Heimanschlüssen prüfen Sie zusätzlich NAT.

lz4 meldet „Decoding error” beim Entpacken

Das Archiv ist unvollständig. Setzen Sie den Download mit aria2c -c fort und vergleichen Sie die Dateigröße mit der auf der Snapshot-Seite, bevor Sie erneut entpacken. Denken Sie daran, dass Option A Platz für Archiv und extrahierte Daten gleichzeitig braucht.

Der OOM-Killer beendet den Node

journalctl -k | grep -i oom klärt die Frage. Die Unit setzt --cache 8000, und der tatsächliche Speicherverbrauch übersteigt beim Aufholen die Cache-Zahl deutlich — auf den empfohlenen 64 GB kein Problem, auf abgespeckter Hardware schon. Senken Sie --cache, bevor Sie irgendetwas anderes senken, halten Sie Swap als Absturzpuffer aktiv, und denken Sie daran, dass ein per OOM gekillter Node nichts flusht: der nächste Start kann Sie mit dem oben genannten „missing trie node”-Fall begrüßen.

Die Platte läuft voll

Zuerst df -h, dann du -h --max-depth=2 /var/lib/bsc, um das Wachstum zu finden. Vergessene Snapshot-Archive sind der häufigste Befund — allein das geprunte .tar.lz4 liegt bei rund 1,6 TB, und Option A lässt es zurück, wenn Sie den Cleanup überspringen. Ist chaindata selbst das Problem, aktualisieren Sie vom neuesten gepruneten Snapshot oder führen Sie Offline-Pruning aus (siehe den Abschnitt zum State-Wachstum). Auf BSCs Wachstumskurve ist eine volle Platte ein Planungsfehler, kein Pech; der 85-Prozent-Alert aus dem Monitoring-Abschnitt existiert, um Ihnen die Woche zu verschaffen, die Sie brauchen.

Eigenen Node betreiben — oder eine API nutzen?

Ein ehrlicher Vergleich, da Chaingateway die Alternative verkauft.

Betreiben Sie den Node, wenn Sie rohes JSON-RPC in schwerem, anhaltendem Volumen konsumieren — Indexierung, Backtesting, Log-Scanning über Millionen Blocks — oder wenn keine dritte Partei zwischen Ihnen und der Chain sitzen darf. Ein dedizierter Server ist ein Fixkostenposten mit unbegrenzten Requests, und ab einem gewissen Aufrufvolumen schlägt er jeden abgerechneten Plan. Der Break-even kommt auf BSC schneller als auf den meisten Chains, gerade weil die Hardware-Hürde hoch, aber flach ist.

Nutzen Sie eine API, wenn der Node nur Verrohrung für Zahlungen wäre. Ein synchronisierter BSC-Full-Node liefert Ihnen eth_sendRawTransaction und Logs; alles, was ein Payment-System tatsächlich braucht — Deposit-Adressen pro Kunde, Erkennung eingehender BEP-20-Transfers, signierte Webhooks, Key-Storage, Retries — ist Software, die Sie obendrauf bauen und am Laufen halten müssten. Diese Engineering-Stunden, zu den Sätzen aus dem Kostenabschnitt, übersteigen die Server-Rechnung bei Weitem.

Chaingateways BNB-Smart-Chain-API deckt diese Ebene als REST ab: Adressen importieren (POST /api/v2/bsc/addresses/import), BEP-20-Token versenden (POST /api/v2/bsc/transactions/bep20), und HMAC-signierte Deposit-Webhooks empfangen — GET /api/v2/bsc/webhooks/notifications/failed listet fehlgeschlagene Zustellungen, und jede kann über den Retry-Endpoint erneut gesendet werden. Der Break-even in einem Satz: dedizierter Server plus Ihre Bau- und Betriebsstunden gegen einen Plan auf /de/pricing/. Für Payment-Flows bleibt die API bis weit über Small-Business-Skalierung hinaus günstiger; für rohe RPC-Feuerkraft gewinnt der Node früh. Der Quickstart und der Webhook-Guide bringen Sie in Minuten zum ersten Test, und der 7-tägige Test kommt ohne KYC aus (registrieren).

Betreiben Sie auch andere Chains? Siehe die Setup-Guides für Ethereum und TRON.