Configurer un node Binance Smart Chain (BSC)

BNB Smart Chain — encore largement recherchée sous le nom de Binance Smart Chain, son nom jusqu’en février 2022 — est une chaîne EVM qui produit un bloc toutes les 0,45 seconde depuis le hard fork Fermi de janvier 2026, après que Maxwell avait déjà divisé par deux l’intervalle à 0,75 seconde mi-2025. Cette vitesse est agréable pour les utilisateurs et exigeante pour les opérateurs de nœuds : un full node BSC veut du matériel de niveau serveur et la bonne stratégie de synchronisation, et se tromper sur l’un des deux donne un nœud qui n’atteint jamais la tête de chaîne. Ce guide est la version copier-coller que la documentation officielle n’atteint pas : configuration basée sur un snapshot avec le fork geth de bnb-chain, une unité systemd, des notes de sécurité pour les nœuds RPC, le calcul du temps de synchronisation et des coûts, ainsi qu’un regard honnête sur le moment où vous ne devriez pas du tout en faire tourner un.

Qu’est-ce qu’un nœud BSC, et de quel type avez-vous besoin ?

Un nœud BSC exécute le client de la chaîne, valide les blocs et vous donne un endpoint JSON-RPC local avec la même interface qu’Ethereum : eth_blockNumber, eth_call, eth_sendRawTransaction et le reste. Quatre variantes comptent en pratique.

Un full node conserve l’état récent et sert le RPC — la valeur par défaut, et le sujet de ce guide. Un fast node est un full node démarré avec --tries-verify-mode none ; la documentation officielle le recommande pour les charges RPC où la vitesse d’import compte plus que la vérification stricte du trie d’état. Un archive node stocke tout l’état historique, nécessite un espace disque à deux chiffres en téraoctets et n’a de sens que pour l’indexation et l’analytique. Un validator produit des blocs, ce qui nécessite d’être élu dans le petit ensemble validé avec du BNB staké — un sujet à part, au-delà d’un guide de configuration.

Et un light node ? Le fork geth a hérité du code light-client, mais en pratique presque rien sur BSC ne sert les pairs légers, considérez donc le « nœud léger BSC » comme indisponible. Si un full node élagué représente plus que ce dont vous avez besoin, c’est précisément le cas d’usage d’une API — voir la dernière section.

Le même choix sous forme de tableau, avec les chiffres de disque de mi-2026 :

BSC et Geth : une seule base de code, deux chaînes

Le client de BSC est un fork de go-ethereum, maintenu sur github.com/bnb-chain/bsc, et le binaire s’appelle littéralement geth. Il parle le même JSON-RPC, accepte la plupart des mêmes flags, et ajoute les spécificités de BSC : le consensus proof-of-staked-authority Parlia (un seul processus constitue tout le nœud — pas de client de consensus séparé comme sur Ethereum post-fusion), plus des flags comme --tries-verify-mode. Deux conséquences pratiques en découlent. Votre tooling Ethereum fonctionne sans changement face à un nœud BSC. Et vous devez exécuter le build bnb-chain — le Geth upstream ne peut pas synchroniser BSC, ce qui est l’erreur de débutant la plus courante avec « bsc geth ».

Prérequis matériels pour un nœud BSC

La base vient du README de bnb-chain/bsc, ajustée pour la croissance des données jusqu’en 2026 :

La ligne qui met à terre la plupart des installations, ce sont les IOPS, pas la capacité. Avec des blocs de 0,45 seconde, le nœud écrit en continu, et le stockage bloc cloud aux IOPS par défaut prend du retard sur la tête de chaîne et ne s’en remet jamais. La référence du README est AWS gp3 avec 8 000 IOPS provisionnées et une latence de lecture sous la milliseconde (classe d’instance m5zn.3xlarge sur AWS, c2-standard-16 sur Google Cloud) ; un disque NVMe local dans un serveur dédié franchit cette barre avec de la marge.

Étape par étape : full node BSC à partir du snapshot officiel

Synchroniser depuis la genèse est possible et une mauvaise idée. La documentation elle-même le déconseille — elle suggère du matériel à 40k+ IOPS pour la tentative, et cela prend quand même des semaines. La voie prise en charge : télécharger le snapshot de données de la chaîne, démarrer le nœud dessus, le laisser rattraper son retard. Les commandes supposent Ubuntu 24.04.

1. Préparer le serveur

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'

Le port 30311 est le port pair-à-pair de BSC et le seul port blockchain à ouvrir. Le port RPC reste en localhost.

2. Télécharger le binaire geth de bnb-chain

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

Renommer le binaire en geth-bsc évite l’accident classique de démarrer un geth upstream installé via la distro contre des données BSC.

3. Récupérer config.toml et genesis.json

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

Remarque : geth-bsc init genesis.json n’est nécessaire que pour une synchronisation depuis la genèse. Avec la méthode par snapshot, vous sautez l’init — le snapshot apporte sa propre base de données.

4. Télécharger et décompresser le snapshot

Les snapshots se trouvent sur github.com/bnb-chain/bsc-snapshots, le dépôt officiel. Il publie mi-2026 trois jeux de données : le snapshot élagué à environ 1,6 To compressé (blocs récents uniquement — le bon choix pour ce guide), le snapshot complet à environ 6 To, et des snapshots incrémentaux qui ne récupèrent que les changements depuis un snapshot précédent, un ajout de l’ère Fermi (BEP-593). La génération actuelle nécessite le client v1.7.2 ou plus récent, ce que le téléchargement de l’étape 2 satisfait déjà. Le dépôt fournit aussi un script fetch-snapshot.sh qui télécharge, vérifie la somme de contrôle MD5 (flag -c) et décompresse en une seule commande ; la méthode manuelle ci-dessous montre ce qui se passe en coulisses. Deux façons de mettre l’archive sur le disque :

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 télécharge sur huit connexions et reprend après une interruption (-c) — avec un simple wget, un téléchargement multi-téraoctet interrompu recommence de zéro. Après extraction, la base de données de la chaîne doit se trouver dans /var/lib/bsc/geth/chaindata ; la disposition de l’archive a changé entre les générations de snapshots, déplacez donc si besoin le dossier geth interne à cet emplacement. Vérifiez avant de décompresser : comparez le MD5 de la page du snapshot, ou laissez fetch-snapshot.sh -c s’en charger — une archive d’un téraoctet corrompue vous coûte une journée. L’option A nécessite de l’espace pour l’archive et les données extraites en même temps, soit environ 2 To de marge pour le jeu élagué, et c’est la vraie raison derrière la recommandation d’un disque de 4 To.

5. Unité systemd

Créez /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 est l’interrupteur « fast node » de la documentation officielle, recommandé pour servir du RPC quand vous acceptez le compromis de cohérence d’état. --history.transactions 0 maintient l’index des transactions complet ; les guides plus anciens utilisent le --txlookuplimit 0, désormais déprécié, pour le même usage. TimeoutStopSec=600 donne au nœud dix minutes pour vider ses tampons à l’arrêt — des arrêts brutaux finissent tôt ou tard par corrompre la base de données.

6. Démarrer et vérifier

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

Une sortie saine est un flux constant de lignes « Imported new chain segment ». Comparez votre hauteur avec un explorateur public :

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

Convertissez le résultat hexadécimal et vérifiez-le sur bscscan.com. Quand eth_syncing renvoie false et que la hauteur correspond, le nœud est en ligne.

Sécuriser un nœud RPC BSC

L’unité ci-dessus lie le RPC à 127.0.0.1, ce qui convient pour un nœud utilisé uniquement par un logiciel local. Si d’autres machines ont besoin d’y accéder, n’ouvrez pas le port 8545 brut vers internet. Placez nginx ou Caddy devant, avec TLS, un jeton d’authentification ou une allowlist d’IP, et de la limitation de débit. Gardez --http.api sur eth,net,web3 — n’exposez jamais admin, debug ou txpool sur un nœud accessible. Les endpoints BSC publics non authentifiés sont découverts et matraqués en quelques jours, et des appels eth_getLogs sans restriction peuvent mettre à genoux même du matériel puissant. Le port P2P 30311 reste le seul port blockchain ouvert. Une différence avec Ethereum mérite d’être mentionnée : il n’y a ici ni engine API ni secret JWT, car Parlia n’a besoin d’aucun client de consensus séparé — le pare-feu et la liaison localhost constituent tout le périmètre, donc ils doivent être corrects.

Surveillance et contrôles de santé

Un nœud BSC échoue d’une manière typique : le processus continue de tourner pendant que le nœud prend du retard sur la tête de chaîne. Les vérifications d’uptime au niveau du processus passent complètement à côté, vérifiez donc plutôt l’état de synchronisation et la hauteur.

# 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

Le contrôle le plus strict compare votre eth_blockNumber avec une seconde source — un endpoint public ou un explorateur — toutes les quelques minutes, et alerte si l’écart grandit. Calibrez le seuil sur le rythme de BSC : 400 blocs semble beaucoup et représente trois minutes de temps de chaîne à 0,45 seconde par bloc. Des seuils copiés depuis les outils Ethereum sont bien trop laxistes ici.

Le fork hérite de la pile de métriques de Geth. Démarrez avec --metrics (endpoint Prometheus sur le port 6060, gardez-le en localhost), et les tableaux de bord Grafana standards de Geth fonctionnent en grande partie sans modification. Avant tout tableau de bord, fixez deux alertes : utilisation disque au-dessus de 85 %, et hauteur de bloc locale figée pendant cinq minutes. Un journalctl -u bsc --since -24h | grep -ci error quotidien dans un mail cron complète le dispositif — des taux d’erreur en hausse précèdent la plupart des pannes de plusieurs jours.

Temps de synchronisation, et pourquoi les snapshots restent utiles

De l’arithmétique plutôt que des promesses : le snapshot élagué de 1,6 To, à 100 Mo/s soutenus, prend environ 4,5 heures à télécharger, à 50 Mo/s environ 9. L’extraction est limitée par le disque et ajoute quelques heures sur du NVMe. Le snapshot a un jour ou deux de retard sur la tête de chaîne ; un nœud sain importe plusieurs fois plus vite que le temps réel, donc le rattrapage coûte des heures, pas des jours. Au total, prévoyez une journée de travail. La synchronisation depuis la genèse, en comparaison, tourne pendant des semaines sur du matériel extrême — d’où la recommandation officielle du snapshot, point final.

Croissance de l’état et élagage

La base de données continue de croître après le premier jour — l’état avec chaque nouveau contrat et compte, les données de bloc au rythme dicté par les blocs de 0,45 seconde. La croissance exacte dépend de l’activité du réseau ; plutôt que de faire confiance à un chiffre fixe, exécutez du -sh /var/lib/bsc/geth/chaindata chaque semaine et construisez votre propre courbe de tendance. Le schéma à attendre : des centaines de Go par trimestre, pas par an.

Trois outils permettent de maîtriser la taille. geth-bsc snapshot prune-state est l’élagage hors ligne intégré : il élimine les nœuds d’état auxquels plus rien ne fait référence, prend de nombreuses heures sur une base de données multi-téraoctets, et le nœud ne sert rien pendant ce temps. Le wipe-and-restore est l’alternative que beaucoup d’opérateurs préfèrent : tous les quelques mois, supprimer le datadir et restaurer le dernier snapshot élagué. Le temps d’arrêt total est souvent inférieur à celui de l’élagage, et vous obtenez en prime une base de données fraîchement compactée.

Le troisième outil est arrivé avec Fermi : les snapshots incrémentaux (BEP-593). Plutôt que de retélécharger 1,6 To à chaque rafraîchissement, vous ne récupérez que ce qui a changé depuis la génération de snapshot que vous avez déjà, ce qui transforme le rafraîchissement périodique d’un job de nuit en une affaire de quelques heures. Le README de bsc-snapshots documente ce flux de travail à côté des archives classiques.

Erigon sur BSC — et son successeur

Pendant des années, la réponse aux besoins d’archive de BSC a été bsc-erigon, le portage d’Erigon par NodeReal : une synchronisation d’archive complète depuis zéro en environ trois jours, stockée sur environ 4,3 To là où le fork geth en nécessite des dizaines. Ce chapitre est clos. La maintenance s’est arrêtée fin 2025, et le dépôt node-real/bsc-erigon a été archivé en avril 2026 — lecture seule, aucun correctif, aucun support pour les futurs forks. NodeReal oriente les opérateurs vers Reth-BSC, le successeur basé sur Rust, comme client d’archive recommandé pour l’avenir.

Ce que cela signifie en pratique mi-2026 : pour le nœud RPC élagué de ce guide, le fork geth officiel reste la référence et le choix le plus sûr. Pour les charges d’archive, évaluez d’abord Reth-BSC, et considérez les machines bsc-erigon existantes comme des migrations en attente — un client non maintenu manque le prochain hard fork au moment prévu.

Ce que coûte un nœud BSC

Considérez ceci comme une méthode de calcul, pas une grille tarifaire. La classe 16 cœurs / 64 Go / 4 To NVMe relève du territoire des serveurs dédiés — aucune offre VPS honnête ne couvre cela. Chez les hébergeurs européens, des machines avec ces spécifications se situent, en ordre de grandeur, dans la fourchette basse à moyenne des centaines d’euros par mois. Les mêmes spécifications construites à partir d’instances cloud avec 8k IOPS provisionnées (la référence AWS du README) atterrissent généralement plus haut, souvent d’un facteur deux ou plus, car les IOPS provisionnées sont facturées séparément.

Ajoutez ensuite vos heures : configuration initiale d’une journée de travail avec ce guide, plus les mises à niveau lors des hard forks et les rafraîchissements de snapshots à raison de quelques heures par mois. Multipliez par votre taux horaire. Pour la plupart des équipes, la ligne main-d’œuvre finit par dépasser la ligne hébergement — bon à savoir avant de vous engager.

Maintenance : hard forks et mises à niveau

BSC effectue des hard forks à un rythme qui surprend les opérateurs Ethereum. La seule année 2025 a apporté Lorentz et Maxwell, chacun divisant par deux l’intervalle des blocs ; Fermi a suivi le 14 janvier 2026 et a fait passer les blocs de 0,75 à 0,45 seconde tout en ajoutant les snapshots incrémentaux et en renforçant la finalité rapide. Chaque fork a une version client minimale — v1.6.4 pour Fermi — et un nœud en dessous se bloque au bloc du fork avec des erreurs de consensus. Mi-2026, la lignée de versions en est à v1.7.x, et les snapshots actuels supposent au moins la v1.7.2.

Abonnez-vous donc au flux de releases bnb-chain/bsc sur GitHub et traitez les mises à niveau comme une routine plutôt que comme des événements. La procédure est courte : télécharger le nouveau geth_linux, le vérifier, arrêter le service, remplacer /usr/local/bin/geth-bsc, redémarrer — la base de données est conservée. Les notes de version signalent les changements de configuration, et BSC renomme les flags plus souvent que Geth upstream, parcourez-les donc avant le redémarrage, pas après. Prévoyez un quart d’heure par release, et attendez-vous à un fork tous les quelques mois.

Pour les configurations de développement, un réseau privé local est disponible via le toolkit BSC-Deploy plutôt qu’en faisant tourner des nœuds mainnet.

Dépannage

Le nœud importe des blocs mais continue de prendre du retard sur la tête de chaîne

Presque toujours les IOPS du disque. Benchmarkez avec fio et comparez à la référence de 8k IOPS ; le stockage en réseau avec des IOPS par défaut est le coupable habituel. Confirmez que --tries-verify-mode none est bien défini. Si le matériel est en dessous du tableau des prérequis, aucun flag ne comblera l’écart.

Erreurs « missing trie node », ou le nœud recommence à synchroniser depuis le bloc 0 après une restauration de snapshot

La disposition du datadir est incorrecte. La base de données de la chaîne doit se trouver à <datadir>/geth/chaindata — si le log affiche « Writing custom genesis block », geth a trouvé un datadir vide et a redémarré de zéro. Arrêtez le service, déplacez le dossier geth extrait au bon endroit, redémarrez.

Le nombre de pairs reste proche de zéro

Vérifiez que le port 30311 est ouvert et redirigé. Un config.toml obsolète est le second suspect : les listes de bootstrap et de nœuds statiques changent avec le temps, retéléchargez donc mainnet.zip depuis la dernière release. Sur les connexions domestiques, vérifiez également le NAT.

lz4 signale une « Decoding error » pendant l’extraction

L’archive est incomplète. Reprenez le téléchargement avec aria2c -c et comparez la taille du fichier à celle indiquée sur la page du snapshot avant de décompresser à nouveau. Rappelez-vous que l’option A nécessite de l’espace libre pour l’archive et les données extraites en même temps.

L’OOM killer termine le nœud

journalctl -k | grep -i oom tranche la question. L’unité définit --cache 8000, et l’utilisation réelle de la mémoire dépasse largement le chiffre du cache pendant le rattrapage — sans problème avec les 64 Go recommandés, problématique sur du matériel allégé. Réduisez --cache avant de réduire quoi que ce soit d’autre, gardez le swap activé comme tampon anti-crash, et souvenez-vous qu’un nœud tué par l’OOM ne vide rien : le prochain démarrage peut vous accueillir avec le cas « missing trie node » ci-dessus.

Le disque se remplit complètement

df -h d’abord, puis du -h --max-depth=2 /var/lib/bsc pour trouver la croissance. Les archives de snapshot oubliées sont la découverte la plus fréquente — le seul .tar.lz4 élagué pèse environ 1,6 To, et l’option A le laisse derrière elle si vous sautez le nettoyage. Si chaindata lui-même est le problème, rafraîchissez depuis le dernier snapshot élagué ou effectuez un élagage hors ligne (voir la section sur la croissance de l’état). Sur la courbe de croissance de BSC, un disque plein est un échec de planification, pas de la malchance ; l’alerte à 85 % de la section surveillance existe pour vous offrir la semaine dont vous avez besoin.

Faire tourner son propre nœud — ou utiliser une API ?

Une comparaison honnête, puisque Chaingateway vend l’alternative.

Faites tourner le nœud lorsque vous consommez du JSON-RPC brut à un volume important et soutenu — indexation, backtesting, scan de logs sur des millions de blocs — ou lorsqu’aucun tiers ne doit se trouver entre vous et la chaîne. Un serveur dédié est un coût fixe avec des requêtes illimitées, et au-delà d’un certain volume d’appels, il bat n’importe quel plan facturé à l’usage. Le seuil de rentabilité arrive plus vite sur BSC que sur la plupart des chaînes, précisément parce que la barre matérielle est élevée mais stable.

Utilisez une API lorsque le nœud ne servirait que de tuyauterie pour des paiements. Un full node BSC synchronisé vous donne eth_sendRawTransaction et des logs ; tout ce dont un système de paiement a réellement besoin — adresses de dépôt par client, détection des transferts BEP-20 entrants, webhooks signés, stockage de clés, réessais — est un logiciel que vous devriez construire par-dessus et maintenir en fonctionnement. Ces heures d’ingénierie, aux tarifs de la section sur les coûts, dépassent largement la facture du serveur.

L’API BNB Smart Chain de Chaingateway couvre cette couche en REST : importer des adresses (POST /api/v2/bsc/addresses/import), envoyer des tokens BEP-20 (POST /api/v2/bsc/transactions/bep20), et recevoir des webhooks de dépôt signés HMAC — GET /api/v2/bsc/webhooks/notifications/failed liste les livraisons échouées, et chacune peut être renvoyée via l’endpoint de réessai. Le seuil de rentabilité en une phrase : serveur dédié plus vos heures de construction et d’exploitation, contre un plan sur /fr/pricing/. Pour les flux de paiement, l’API reste moins chère bien au-delà de l’échelle des petites entreprises ; pour la puissance RPC brute, le nœud gagne tôt. Le quickstart et le guide des webhooks vous amènent à un premier test en quelques minutes, et l’essai de 7 jours ne nécessite aucun KYC (inscription).

Vous faites aussi tourner d’autres chaînes ? Consultez les guides de configuration pour Ethereum et TRON.