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. Vous pouvez donc 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 :
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 :
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 :
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
make gethou, pour créer la suite complète d'utilitaires :
make allSi vous obtenez une telle erreur lors de l'exécution du nœud avec un binaire auto-construit :
Caught SIGILL in blst_cgo_init, consult < 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. Il s'agit du 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érant des 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 :
L'exigence de testnet :
# Linux
wget $( 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
# MacOS
wget $( 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//== mainnet
wget $( curl -s https://api.github.com/repos/bnb-chain/bsc/releases/latest | grep browser_ | grep mainnet | cut -d " -f4 )
unzip mainnet.zip
//== testnet
wget $( curl -s https://api.github.com/repos/bnb-chain/bsc/releases/latest | grep browser_ | grep testnet | cut -d " -f4 )
unzip testnet.zipTé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
# # It is recommend to run fullnode with `--tries-verify-mode none` if you want high performance and care little about state consistency
# # It will run with Hash-Base Storage Scheme by default
./geth --config ./config.toml --datadir ./node --cache 8000 --rpc.allow-unprotected-txs --history.transactions 0 --tries-verify-mode none
# # It runs fullnode with Path-Base Storage Scheme.
# # It will enable inline state prune, keeping the latest 90000 blocks' history state by default.
./geth --config ./config.toml --datadir ./node --cache 8000 --rpc.allow-unprotected-txs --history.transactions 0 --tries-verify-mode none --state.scheme pathSurveillez 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= " Imported new chain segment " blocks=1 txs=177 mgas=17.317 elapsed=31.131ms mgasps=556.259 number=21,153,429 hash=0x42e6b54ba7106387f0650defc62c9ace3160b427702dab7bd1c5abb83a32d8db dirty= " 0.00 B "
t=2022-09-08T13:00:29+0000 lvl=info msg= " Imported new chain segment " blocks=1 txs=251 mgas=39.638 elapsed=68.827ms mgasps=575.900 number=21,153,430 hash=0xa3397b273b31b013e43487689782f20c03f47525b4cd4107c1715af45a88796e dirty= " 0.00 B "
t=2022-09-08T13:00:33+0000 lvl=info msg= " Imported new chain segment " blocks=1 txs=197 mgas=19.364 elapsed=34.663ms mgasps=558.632 number=21,153,431 hash=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 /path/to/your_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 dumpconfiggeth 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 !
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= 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 rendre vos efforts beaucoup plus importants. 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 :
master .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 .
