Das Ziel von BNB Smart Chain besteht darin, Programmierbarkeit und Interoperabilität in die BNB Beacon Chain zu bringen. Um die bestehende beliebte Community und fortschrittliche Technologie zu nutzen, wird es enorme Vorteile bringen, da es mit allen bestehenden Smart Contracts auf Ethereum und Ethereum-Tools kompatibel bleibt. Und um dies zu erreichen, ist die Entwicklung auf Basis der Go-Ethereum-Fork die einfachste Lösung, da wir die großartige Arbeit von Ethereum sehr respektieren.
BNB Smart Chain beginnt seine Entwicklung auf Basis der Go-Ethereum-Gabel. Sie sehen also vielleicht, dass viele Tools, Binärdateien und auch Dokumente auf denen von Ethereum basieren, wie zum Beispiel der Name „geth“.
Aber ausgehend von dieser Basis der EVM-Kompatibilität führt BNB Smart Chain ein System von 21 Validatoren mit Proof of Staked Authority (PoSA)-Konsens ein, das kurze Blockzeiten und niedrigere Gebühren unterstützen kann. Die am stärksten gebundenen Validator-Kandidaten des Einsatzes werden Validatoren und produzieren Blöcke. Die Doppelzeichenerkennung und andere Slashing-Logik garantieren Sicherheit, Stabilität und Endgültigkeit der Kette.
Die BNB Smart Chain wird sein:
Weitere Details im White Paper.
Obwohl Proof-of-Work (PoW) als praktischer Mechanismus zur Implementierung eines dezentralen Netzwerks anerkannt wurde, ist es nicht umweltfreundlich und erfordert außerdem eine große Teilnehmerzahl, um die Sicherheit aufrechtzuerhalten.
Proof-of-Authority (PoA) bietet eine gewisse Verteidigung gegen 51 %-Angriffe, mit verbesserter Effizienz und Toleranz gegenüber bestimmten Ebenen byzantinischer Spieler (böswillig oder gehackt). Mittlerweile steht das PoA-Protokoll am meisten in der Kritik, weil es nicht so dezentralisiert ist wie PoW, da die Validatoren, also die Knoten, die abwechselnd Blöcke produzieren, über alle Befugnisse verfügen und anfällig für Korruption und Sicherheitsangriffe sind.
Andere Blockchains wie EOS und Cosmos führen verschiedene Arten von Deputy Proof of Stake (DPoS) ein, um den Token-Inhabern die Möglichkeit zu geben, abzustimmen und den Validatorsatz zu wählen. Es erhöht die Dezentralisierung und begünstigt die Governance der Gemeinschaft.
Um DPoS und PoA für einen Konsens zu kombinieren, implementiert BNB Smart Chain eine neuartige Konsens-Engine namens Parlia, die:
BNB wird auf der BNB Smart Chain auf die gleiche Weise laufen wie ETH auf Ethereum, sodass es als native token
für BSC bleibt. Das bedeutet, dass BNB verwendet wird, um:
gas
um Smart Contract auf BSC bereitzustellen oder aufzurufen Viele der unten genannten sind mit go-ethereum identisch oder ähnlich.
Für Voraussetzungen und detaillierte Bauanweisungen lesen Sie bitte die Installationsanweisungen.
Für die Erstellung von geth
sind sowohl ein Go (Version 1.21 oder höher) als auch ein C-Compiler (GCC 5 oder höher) erforderlich. Sie können sie mit Ihrem bevorzugten Paketmanager installieren. Sobald die Abhängigkeiten installiert sind, führen Sie sie aus
make geth
oder, um die gesamte Suite an Dienstprogrammen zu erstellen:
make all
Wenn Sie beim Ausführen des Knotens mit selbst erstellter Binärdatei eine solche Fehlermeldung erhalten:
Caught SIGILL in blst_cgo_init, consult < blst > /bindinds/go/README.md.
Bitte versuchen Sie, die folgenden Umgebungsvariablen hinzuzufügen und erneut zu erstellen:
export CGO_CFLAGS= " -O -D__BLST_PORTABLE__ "
export CGO_CFLAGS_ALLOW= " -O -D__BLST_PORTABLE__ "
Das BSC-Projekt enthält mehrere Wrapper/ausführbare Dateien im cmd
Verzeichnis.
Befehl | Beschreibung |
---|---|
geth | Haupt-BNB-Smart-Chain-Client-Binärdatei. Es ist der Einstiegspunkt in das BSC-Netzwerk (Haupt-, Test- oder privates Netz) und kann als vollständiger Knoten (Standard), Archivknoten (behält den gesamten historischen Zustand bei) oder Light-Knoten (Daten live abrufen) ausgeführt werden. Es verfügt über die gleichen und mehr RPC- und andere Schnittstellen wie go-ethereum und kann von anderen Prozessen als Gateway zum BSC-Netzwerk über JSON-RPC-Endpunkte verwendet werden, die über HTTP-, WebSocket- und/oder IPC-Transporte bereitgestellt werden. geth --help und die CLI-Seite für Befehlszeilenoptionen. |
clef | Eigenständiges Signiertool, das als Backend-Signierer für geth verwendet werden kann. |
devp2p | Dienstprogramme zur Interaktion mit Knoten auf der Netzwerkebene, ohne eine vollständige Blockchain auszuführen. |
abigen | Quellcode-Generator zum Konvertieren von Ethereum-Vertragsdefinitionen in benutzerfreundliche, typsichere Go-Pakete zur Kompilierungszeit. Es arbeitet mit einfachen Ethereum-Vertrags-ABIs mit erweiterter Funktionalität, wenn auch der Vertragsbytecode verfügbar ist. Es akzeptiert jedoch auch Solidity-Quelldateien, wodurch die Entwicklung wesentlich effizienter wird. Weitere Informationen finden Sie auf unserer Seite „Native DApps“. |
bootnode | Eine abgespeckte Version unserer Ethereum-Client-Implementierung, die nur am Netzwerkknoten-Erkennungsprotokoll teilnimmt, aber keines der übergeordneten Anwendungsprotokolle ausführt. Er kann als leichter Bootstrap-Knoten verwendet werden, um die Suche nach Peers in privaten Netzwerken zu erleichtern. |
evm | Entwickler-Utility-Version der EVM (Ethereum Virtual Machine), die in der Lage ist, Bytecode-Snippets in einer konfigurierbaren Umgebung und einem konfigurierbaren Ausführungsmodus auszuführen. Sein Zweck besteht darin, isoliertes, feinkörniges Debuggen von EVM-Opcodes zu ermöglichen (z. B. evm --code 60ff60ff --debug run ). |
rlpdump | Entwickler-Hilfsprogramm zum Konvertieren von binären RLP-Dumps (Recursive Length Prefix) (Datenkodierung, die vom Ethereum-Protokoll sowohl im Netzwerk als auch im Konsens verwendet wird) in eine benutzerfreundlichere hierarchische Darstellung (z. B. rlpdump --hex CE0183FFFFFFC4C304050583616263 ). |
geth
laufen lassen Es würde hier den Rahmen sprengen, alle möglichen Befehlszeilen-Flags durchzugehen (bitte konsultieren Sie unsere CLI-Wiki-Seite), aber wir haben ein paar gängige Parameterkombinationen aufgelistet, um Ihnen schnell einen Einblick zu geben, wie Sie Ihre eigene geth
Instanz ausführen können.
Die Hardware muss bestimmte Anforderungen erfüllen, um einen vollständigen Knoten im Mainnet auszuführen:
Die Anforderung an 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.zip
Laden Sie hier den neuesten Chaindata-Snapshot herunter. Befolgen Sie die Anleitung, um Ihre Dateien zu strukturieren.
./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 path
Überwachen Sie standardmäßig das Protokoll von ./node/bsc.log . Wenn der Knoten mit der Synchronisierung begonnen hat, sollte die folgende Ausgabe angezeigt werden:
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 "
Starten Sie die integrierte interaktive JavaScript-Konsole von geth
(über den nachfolgenden console
Unterbefehl), über die Sie mithilfe von web3
Methoden interagieren können (Hinweis: Die in geth
gebündelte web3
Version ist sehr alt und nicht auf dem neuesten Stand der offiziellen Dokumente). sowie die eigenen Verwaltungs-APIs von geth
. Dieses Tool ist optional und wenn Sie es weglassen, können Sie es jederzeit mit geth attach
an eine bereits laufende geth
-Instanz anhängen.
Weitere Details zum Ausführen eines Knotens und zum Werden eines Validators
Hinweis: Obwohl einige interne Schutzmaßnahmen verhindern, dass Transaktionen zwischen dem Hauptnetzwerk und dem Testnetzwerk übertragen werden, sollten Sie immer getrennte Konten für Spiel- und Echtgeld verwenden. Sofern Sie Konten nicht manuell verschieben, trennt geth
die beiden Netzwerke standardmäßig korrekt und stellt keine Konten zwischen ihnen zur Verfügung.
Alternativ zur Übergabe der zahlreichen Flags an die geth
Binärdatei können Sie auch eine Konfigurationsdatei über Folgendes übergeben:
$ geth --config /path/to/your_config.toml
Um eine Vorstellung davon zu bekommen, wie die Datei aussehen sollte, können Sie den Unterbefehl dumpconfig
verwenden, um Ihre vorhandene Konfiguration zu exportieren:
$ geth --your-favourite-flags dumpconfig
geth
-Knoten Als Entwickler möchten Sie eher früher als später mit geth
und dem BSC-Netzwerk über Ihre eigenen Programme und nicht manuell über die Konsole interagieren. Um dies zu unterstützen, verfügt geth
über integrierte Unterstützung für JSON-RPC-basierte APIs (Standard-APIs und geth
spezifische APIs). Diese können über HTTP, WebSockets und IPC (UNIX-Sockets auf UNIX-basierten Plattformen und Named Pipes unter Windows) verfügbar gemacht werden.
Die IPC-Schnittstelle ist standardmäßig aktiviert und stellt alle von geth
unterstützten APIs zur Verfügung, während die HTTP- und WS-Schnittstellen manuell aktiviert werden müssen und aus Sicherheitsgründen nur eine Teilmenge der APIs verfügbar machen. Diese können wie erwartet ein-/ausgeschaltet und konfiguriert werden.
HTTP-basierte JSON-RPC-API-Optionen:
--http
Aktiviert den HTTP-RPC-Server--http.addr
HTTP-RPC-Server-Abhörschnittstelle (Standard: localhost
)--http.port
HTTP-RPC-Server-Abhörport (Standard: 8545
)--http.api
-APIs, die über die HTTP-RPC-Schnittstelle angeboten werden (Standard: eth,net,web3
)--http.corsdomain
Durch Kommas getrennte Liste der Domänen, von denen ursprungsübergreifende Anfragen akzeptiert werden sollen (durch Browser erzwungen)--ws
Aktiviert den WS-RPC-Server--ws.addr
WS-RPC-Server-Abhörschnittstelle (Standard: localhost
)--ws.port
WS-RPC-Server-Abhörport (Standard: 8546
)--ws.api
APIs, die über die WS-RPC-Schnittstelle angeboten werden (Standard: eth,net,web3
)--ws.origins
Ursprünge, von denen aus WebSocket-Anfragen angenommen werden sollen--ipcdisable
Deaktiviert den IPC-RPC-Server--ipcapi
APIs, die über die IPC-RPC-Schnittstelle angeboten werden (Standard: admin,debug,eth,miner,net,personal,txpool,web3
)--ipcpath
Dateiname für IPC-Socket/-Pipe im Datenverzeichnis (explizite Pfade maskieren ihn) Sie müssen die Funktionen Ihrer eigenen Programmierumgebung (Bibliotheken, Tools usw.) nutzen, um über HTTP, WS oder IPC eine Verbindung zu einem geth
-Knoten herzustellen, der mit den oben genannten Flags konfiguriert ist, und Sie müssen JSON-RPC auf allen Transporten sprechen. Sie können dieselbe Verbindung für mehrere Anfragen wiederverwenden!
Hinweis: Bitte verstehen Sie die Sicherheitsauswirkungen, die das Öffnen eines HTTP/WS-basierten Transports mit sich bringt, bevor Sie dies tun! Hacker im Internet versuchen aktiv, BSC-Knoten mit offengelegten APIs zu unterwandern! Darüber hinaus können alle Browser-Registerkarten auf lokal laufende Webserver zugreifen, sodass bösartige Webseiten versuchen könnten, lokal verfügbare APIs zu untergraben!
Bootknoten sind superleichte Knoten, die sich nicht hinter einem NAT befinden und nur ein Erkennungsprotokoll ausführen. Wenn Sie einen Knoten starten, sollte dieser Ihren Enode protokollieren. Hierbei handelt es sich um eine öffentliche Kennung, die andere verwenden können, um eine Verbindung zu Ihrem Knoten herzustellen.
Zunächst benötigt der Bootnode einen Schlüssel, der mit dem folgenden Befehl erstellt werden kann, wodurch ein Schlüssel in boot.key gespeichert wird:
bootnode -genkey boot.key
Mit diesem Schlüssel kann dann wie folgt ein Bootnode generiert werden:
bootnode -nodekey boot.key -addr :30311 -network bsc
Die Auswahl des an -addr übergebenen Ports ist willkürlich. Der Befehl bootnode gibt die folgenden Protokolle an das Terminal zurück und bestätigt, dass es ausgeführt wird:
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
Vielen Dank, dass Sie darüber nachgedacht haben, beim Quellcode zu helfen! Wir freuen uns über Beiträge von jedem im Internet und sind selbst für die kleinste Korrektur dankbar!
Wenn Sie zu bsc beitragen möchten, forken Sie es bitte, reparieren Sie es, schreiben Sie es fest und senden Sie eine Pull-Anfrage an die Betreuer zur Überprüfung und Einbindung in die Hauptcodebasis. Wenn Sie jedoch komplexere Änderungen einreichen möchten, wenden Sie sich bitte zunächst auf unserem Discord-Kanal an die Kernentwickler, um sicherzustellen, dass diese Änderungen mit der allgemeinen Philosophie des Projekts übereinstimmen, und/oder erhalten Sie frühzeitig Feedback, das Ihre Bemühungen erheblich erleichtern kann leichter und unsere Überprüfungs- und Zusammenführungsverfahren sind schnell und einfach.
Bitte stellen Sie sicher, dass Ihre Beiträge unseren Kodierungsrichtlinien entsprechen:
master
-Zweig basieren und für diesen geöffnet werden.Weitere Informationen zum Konfigurieren Ihrer Umgebung, zum Verwalten von Projektabhängigkeiten und zu Testverfahren finden Sie im Entwicklerhandbuch.
Die bsc-Bibliothek (dh der gesamte Code außerhalb des cmd
-Verzeichnisses) ist unter der GNU Lesser General Public License v3.0 lizenziert und auch in unserem Repository in der Datei COPYING.LESSER
enthalten.
Die BSC-Binärdateien (dh der gesamte Code im cmd
-Verzeichnis) sind unter der GNU General Public License v3.0 lizenziert und auch in unserem Repository in der COPYING
Datei enthalten.