bsc
v1.4.15
L’objectif de BNB Smart Chain est d’apporter programmabilité et interopérabilité à BNB Beacon Chain. Afin d’embrasser la communauté populaire existante et la technologie avancée, cela apportera d’énormes avantages en restant compatible avec tous les contrats intelligents existants sur Ethereum et les outils Ethereum. Et pour y parvenir, la solution la plus simple est de développer sur la base du fork go-ethereum, car nous respectons beaucoup l’excellent travail d’Ethereum.
BNB Smart Chain commence son développement sur la base du fork go-ethereum. Ainsi, vous pouvez voir de nombreux outils, binaires et documents basés sur ceux d'Ethereum, comme le nom « geth ».
Mais à partir de cette base de compatibilité EVM, BNB Smart Chain introduit un système de 21 validateurs avec un consensus Proof of Staked Authority (PoSA) qui peut prendre en charge un temps de blocage court et des frais inférieurs. Les candidats validateurs les plus liés au jalonnement deviendront des validateurs et produiront des blocs. La détection de double signe et d'autres logiques de coupure garantissent la sécurité, la stabilité et la finalité de la chaîne.
La Smart Chain BNB sera :
Une blockchain auto-souveraine : assure la sécurité et la sûreté avec des validateurs élus.
Compatible EVM : prend en charge tous les outils Ethereum existants avec une finalité plus rapide et des frais de transaction moins chers.
Distribué avec une gouvernance en chaîne : la preuve d'autorité mise en jeu fait appel à la décentralisation et aux participants de la communauté. En tant que jeton natif, BNB servira à la fois de gaz pour l’exécution de contrats intelligents et de jetons pour le jalonnement.
Plus de détails dans le livre blanc.
Bien que la preuve de travail (PoW) ait été approuvée comme mécanisme pratique pour mettre en œuvre un réseau décentralisé, elle n'est pas respectueuse de l'environnement et nécessite également un grand nombre de participants pour maintenir la sécurité.
La preuve d'autorité (PoA) offre une certaine défense contre 51 % d'attaques, avec une efficacité et une tolérance améliorées envers certains niveaux de joueurs byzantins (malveillants ou piratés). Pendant ce temps, le protocole PoA est surtout critiqué pour n'être pas aussi décentralisé que PoW, car les validateurs, c'est-à-dire les nœuds qui se relaient pour produire des blocs, ont toutes les autorités et sont sujets à la corruption et aux attaques de sécurité.
D'autres blockchains, telles qu'EOS et Cosmos, introduisent différents types de preuves de participation adjointes (DPoS) pour permettre aux détenteurs de jetons de voter et d'élire l'ensemble des validateurs. Cela accroît la décentralisation et favorise la gouvernance communautaire.
Pour combiner DPoS et PoA en vue d'un consensus, BNB Smart Chain met en œuvre un nouveau moteur de consensus appelé Parlia qui :
Les blocs sont produits par un ensemble limité de validateurs.
Les validateurs se relaient pour produire des blocs de manière PoA, similaire au moteur de consensus Clique d'Ethereum.
L'ensemble des validateurs est élu de façon continue sur la base d'une gouvernance basée sur le jalonnement sur BNB Smart Chain.
Le moteur de consensus Parlia interagira avec un ensemble de contrats système pour réduire la vivacité, la distribution des revenus et la fonction de renouvellement de l'ensemble des validateurs.
BNB fonctionnera sur BNB Smart Chain de la même manière que ETH fonctionne sur Ethereum afin qu'il reste un native token pour BSC. Cela signifie que le BNB sera utilisé pour :
payer gas pour déployer ou invoquer un contrat intelligent sur BSC
La plupart des éléments ci-dessous sont identiques ou similaires à Go-Ethereum.
Pour connaître les conditions préalables et les instructions de construction détaillées, veuillez lire les instructions d'installation.
Construire geth nécessite à la fois un compilateur Go (version 1.21 ou ultérieure) et un compilateur C (GCC 5 ou supérieur). Vous pouvez les installer à l'aide de votre gestionnaire de packages préféré. Une fois les dépendances installées, exécutez
faire geth
ou, pour créer la suite complète d'utilitaires :
faire tout
Si vous obtenez une telle erreur lors de l'exécution du nœud avec un binaire auto-construit :
Vous avez attrapé SIGILL dans blst_cgo_init, consultez <blst>/bindinds/go/README.md.
veuillez essayer d'ajouter les variables d'environnement suivantes et de reconstruire :
export CGO_CFLAGS="-O -D__BLST_PORTABLE__" export CGO_CFLAGS_ALLOW="-O -D__BLST_PORTABLE__"
Le projet bsc est livré avec plusieurs wrappers/exécutables trouvés dans le répertoire cmd .
| Commande | Description |
|---|---|
geth | Binaire principal du client BNB Smart Chain. C'est le point d'entrée dans le réseau BSC (réseau principal, de test ou privé), capable de fonctionner comme un nœud complet (par défaut), un nœud d'archive (conservant tout l'état historique) ou un nœud léger (récupération de données en direct). Il a la même interface RPC et d'autres interfaces que go-ethereum et peut être utilisé par d'autres processus comme passerelle vers le réseau BSC via les points de terminaison JSON RPC exposés au-dessus des transports HTTP, WebSocket et/ou IPC. geth --help et la page CLI pour les options de ligne de commande. |
clef | Outil de signature autonome, qui peut être utilisé comme signataire backend pour geth . |
devp2p | Utilitaires pour interagir avec les nœuds de la couche réseau, sans exécuter une blockchain complète. |
abigen | Générateur de code source pour convertir les définitions de contrat Ethereum en packages Go faciles à utiliser et de type sécurisé au moment de la compilation. Il fonctionne sur des ABI de contrat Ethereum simples avec des fonctionnalités étendues si le bytecode du contrat est également disponible. Cependant, il accepte également les fichiers sources Solidity, ce qui simplifie grandement le développement. Veuillez consulter notre page DApps natives pour plus de détails. |
bootnode | Version allégée de notre implémentation client Ethereum qui participe uniquement au protocole de découverte de nœuds réseau, mais n'exécute aucun des protocoles d'application de niveau supérieur. Il peut être utilisé comme nœud d'amorçage léger pour faciliter la recherche de pairs dans les réseaux privés. |
evm | Version utilitaire de développement de l'EVM (Ethereum Virtual Machine) capable d'exécuter des extraits de bytecode dans un environnement et un mode d'exécution configurables. Son objectif est de permettre un débogage isolé et précis des opcodes EVM (par exemple evm --code 60ff60ff --debug run ). |
rlpdump | Outil utilitaire de développement pour convertir les dumps binaires RLP (RecursiveLength Prefix) (codage de données utilisé par le protocole Ethereum à la fois en termes de réseau et de consensus) en représentation hiérarchique plus conviviale (par exemple rlpdump --hex CE0183FFFFFFC4C304050583616263 ). |
geth Passer en revue tous les indicateurs de ligne de commande possibles est hors de portée ici (veuillez consulter notre page CLI Wiki), mais nous avons énuméré quelques combinaisons de paramètres courantes pour vous familiariser rapidement avec la façon dont vous pouvez exécuter votre propre instance geth .
Le matériel doit répondre à certaines exigences pour exécuter un nœud complet sur le réseau principal :
VPS exécutant des versions récentes de Mac OS X, Linux ou Windows.
IMPORTANT 3 To (décembre 2023) d'espace disque libre, disque SSD (SSD), gp3, 8 000 IOPS, débit de 500 Mo/s, latence de lecture < 1 ms. (si le nœud est démarré avec Snap Sync, il aura besoin d'un SSD NVMe)
16 cœurs de processeur et 64 Go de mémoire (RAM)
Suggérez le type d'instance m5zn.6xlarge ou r7iz.4xlarge sur AWS, c2-standard-16 sur Google Cloud.
Une connexion Internet haut débit avec des vitesses de téléchargement/montage de 5 Mo/s
L'exigence de testnet :
VPS exécutant des versions récentes de Mac OS X, Linux ou Windows.
500G de stockage pour testnet.
4 cœurs de CPU et 16 gigaoctets de mémoire (RAM).
# Linuxwget $(curl -s https://api.github.com/repos/bnb-chain/bsc/releases/latest |grep browser_ |grep geth_linux |cut -d" -f4)mv geth_linux geth chmod -v u+x geth# MacOSwget $(curl -s https://api.github.com/repos/bnb-chain/bsc/releases/latest |grep browser_ |grep geth_mac |cut -d" -f4)mv geth_macos geth chmod -v u+x geth
//== réseau principal wget $(curl -s https://api.github.com/repos/bnb-chain/bsc/releases/latest |grep browser_ |grep mainnet |cut -d" -f4)décompressez mainnet.zip //== testnet wget $(curl -s https://api.github.com/repos/bnb-chain/bsc/releases/latest |grep browser_ |grep testnet |cut -d" -f4)décompressez testnet.zip
Téléchargez le dernier instantané de chaindata à partir d'ici. Suivez le guide pour structurer vos fichiers.
./geth --config ./config.toml --datadir ./node --cache 8000 --rpc.allow-unprotected-txs --history.transactions 0## Il est recommandé d'exécuter fullnode avec `--tries- verify-mode none` si vous voulez des performances élevées et que vous vous souciez peu de la cohérence de l'état## Il fonctionnera avec le schéma de stockage Hash-Base par défaut./geth --config ./config.toml --datadir ./node --cache 8000 --rpc.allow-unprotected-txs --history.transactions 0 --tries-verify-mode none## Il exécute fullnode avec le schéma de stockage Path-Base. ## Cela activera l'élagage de l'état en ligne, en conservant par défaut l'état de l'historique des 90 000 derniers blocs../geth --config ./config.toml --datadir ./node --cache 8000 --rpc.allow-unprotected-txs --history.transactions 0 --tries-verify-mode aucun --state.scheme chemin
Surveillez le journal à partir de ./node/bsc.log par défaut. Lorsque le nœud a commencé la synchronisation, il devrait pouvoir voir le résultat suivant :
t=2022-09-08T13:00:27+0000 lvl=info msg="Nouveau segment de chaîne importé" blocs=1 txs=177 mgas=17,317 écoulé=31,131 ms mgasps=556,259 nombre=21 153 429 hash=0x42e6b54ba7106387f0650defc62c9ace3160b427702dab7bd1c5abb83a32d8db dirty="0.00 B"t=2022-09-08T13:00:29+0000 lvl=info msg="Nouveau segment de chaîne importé" blocs=1 txs=251 mgas=39,638 écoulé=68,827 ms mgasps=575,900 nombre=21 153 430 hash=0xa3397b273b31b013e43487689782f20c03f47525b4cd4107c1715af45a88796e dirty="0.00 B"t=2022-09-08T13:00:33+0000 lvl=info msg="Nouveau segment de chaîne importé" blocs = 1 txs = 197 mgas = 19,364 écoulés = 34,663 ms mgasps = 558,632 nombre = 21 153 431 hachage = 0x0c7872b698f28cb5c36a8a3e1e315b1d31bda6109b15467a9735a12380e2ad14 dirty = "0,00 B"
Démarrez la console JavaScript interactive intégrée de geth (via la sous-commande console de fin) à travers laquelle vous pouvez interagir à l'aide des méthodes web3 (remarque : la version web3 fournie avec geth est très ancienne et n'est pas à jour avec la documentation officielle), ainsi que les propres API de gestion de geth . Cet outil est facultatif et si vous le laissez de côté, vous pouvez toujours vous attacher à une instance geth déjà en cours d'exécution avec geth attach .
Plus de détails sur l'exécution d'un nœud et devenir validateur
Remarque : Bien que certaines mesures de protection internes empêchent les transactions de passer entre le réseau principal et le réseau de test, vous devez toujours utiliser des comptes distincts pour le jeu et l'argent réel. À moins que vous ne déplaciez manuellement les comptes, geth séparera correctement par défaut les deux réseaux et ne rendra aucun compte disponible entre eux.
Au lieu de transmettre les nombreux indicateurs au binaire geth , vous pouvez également transmettre un fichier de configuration via :
$ geth --config /chemin/vers/votre_config.toml
Pour avoir une idée de l'apparence du fichier, vous pouvez utiliser la sous-commande dumpconfig pour exporter votre configuration existante :
$ geth --your-favourite-flags dumpconfig
geth En tant que développeur, vous souhaiterez tôt ou tard commencer à interagir avec geth et le réseau BSC via vos propres programmes et non manuellement via la console. Pour faciliter cela, geth dispose d'une prise en charge intégrée des API basées sur JSON-RPC (API standard et API spécifiques geth ). Ceux-ci peuvent être exposés via HTTP, WebSockets et IPC (sockets UNIX sur les plates-formes UNIX et canaux nommés sous Windows).
L'interface IPC est activée par défaut et expose toutes les API prises en charge par geth , tandis que les interfaces HTTP et WS doivent être activées manuellement et n'exposent qu'un sous-ensemble d'API pour des raisons de sécurité. Ceux-ci peuvent être activés/désactivés et configurés comme vous le souhaitez.
Options de l'API JSON-RPC basée sur HTTP :
--http Activer le serveur HTTP-RPC
--http.addr Interface d'écoute du serveur HTTP-RPC (par défaut : localhost )
--http.port Port d'écoute du serveur HTTP-RPC (par défaut : 8545 )
--http.api proposées sur l'interface HTTP-RPC (par défaut : eth,net,web3 )
--http.corsdomain Liste de domaines séparés par des virgules à partir desquels accepter les requêtes d'origine croisée (appliqué par le navigateur)
--ws Activer le serveur WS-RPC
--ws.addr Interface d'écoute du serveur WS-RPC (par défaut : localhost )
--ws.port Port d'écoute du serveur WS-RPC (par défaut : 8546 )
--ws.api API proposées sur l'interface WS-RPC (par défaut : eth,net,web3 )
--ws.origins Origines à partir desquelles accepter les requêtes WebSocket
--ipcdisable Désactive le serveur IPC-RPC
--ipcapi API proposées sur l'interface IPC-RPC (par défaut : admin,debug,eth,miner,net,personal,txpool,web3 )
--ipcpath Nom de fichier pour le socket/pipe IPC dans le répertoire de données (les chemins explicites y échappent)
Vous devrez utiliser les capacités de vos propres environnements de programmation (bibliothèques, outils, etc.) pour vous connecter via HTTP, WS ou IPC à un nœud geth configuré avec les indicateurs ci-dessus et vous devrez parler JSON-RPC sur tous les transports. Vous pouvez réutiliser la même connexion pour plusieurs requêtes !
Remarque : Veuillez comprendre les implications en matière de sécurité de l'ouverture d'un transport basé sur HTTP/WS avant de le faire ! Les pirates sur Internet tentent activement de subvertir les nœuds BSC avec des API exposées ! De plus, tous les onglets du navigateur peuvent accéder aux serveurs Web exécutés localement, de sorte que des pages Web malveillantes pourraient tenter de subvertir les API disponibles localement !
BSC-Deploy : outil de déploiement pour la mise en place de BNB Smart Chain.
Les bootnodes sont des nœuds ultra-légers qui ne sont pas derrière un NAT et exécutent uniquement un protocole de découverte. Lorsque vous démarrez un nœud, il doit enregistrer votre enode, qui est un identifiant public que d'autres peuvent utiliser pour se connecter à votre nœud.
Tout d'abord, le bootnode nécessite une clé, qui peut être créée avec la commande suivante, qui enregistrera une clé dans boot.key :
bootnode -genkey boot.key
Cette clé peut ensuite être utilisée pour générer un bootnode comme suit :
bootnode -nodekey boot.key -addr :30311 -network bsc
Le choix du port transmis à -addr est arbitraire. La commande bootnode renvoie les journaux suivants au terminal, confirmant son exécution :
enode://3063d1c9e1b824cfbb7c7b6abafa34faec6bb4e7e06941d218d760acdd7963b274278c5c3e63914bd6d1b58504c59ec5522c56f883baceb8538674b92da48a96@127.0.0.1:0?discport=30311 Note: you're using cmd/bootnode, a developer tool. We recommend using a regular node as bootstrap node for production deployments. INFO [08-21|11:11:30.687] New local node record seq=1,692,616,290,684 id=2c9af1742f8f85ce ip=<nil> udp=0 tcp=0 INFO [08-21|12:11:30.753] New local node record seq=1,692,616,290,685 id=2c9af1742f8f85ce ip=54.217.128.118 udp=30311 tcp=0 INFO [09-01|02:46:26.234] New local node record seq=1,692,616,290,686 id=2c9af1742f8f85ce ip=34.250.32.100 udp=30311 tcp=0
Merci d'avoir envisagé d'aider avec le code source ! Nous apprécions les contributions de tous les internautes et sommes reconnaissants pour les plus petites corrections !
Si vous souhaitez contribuer à bsc, veuillez créer, corriger, valider et envoyer une pull request aux responsables pour qu'ils l'examinent et la fusionnent dans la base de code principale. Si vous souhaitez soumettre des modifications plus complexes, veuillez d'abord vérifier auprès des développeurs principaux sur notre canal Discord pour vous assurer que ces modifications sont conformes à la philosophie générale du projet et/ou obtenir des commentaires précoces qui peuvent grandement contribuer à vos efforts. plus léger ainsi que nos procédures de révision et de fusion rapides et simples.
Veuillez vous assurer que vos contributions respectent nos directives de codage :
Le code doit respecter les directives officielles de formatage Go (c'est-à-dire qu'il utilise gofmt).
Le code doit être documenté conformément aux directives officielles des commentaires de Go.
Les demandes d'extraction doivent être basées et ouvertes sur la branche master .
Les messages de validation doivent être préfixés par le(s) package(s) qu'ils modifient.
Par exemple, "eth, rpc : rendre les configurations de trace facultatives"
Veuillez consulter le Guide des développeurs pour plus de détails sur la configuration de votre environnement, la gestion des dépendances du projet et les procédures de test.
La bibliothèque bsc (c'est-à-dire tout le code en dehors du répertoire cmd ) est sous licence GNU Lesser General Public License v3.0, également incluse dans notre référentiel dans le fichier COPYING.LESSER .
Les binaires bsc (c'est-à-dire tout le code contenu dans le répertoire cmd ) sont sous licence GNU General Public License v3.0, également incluse dans notre référentiel dans le fichier COPYING .
