bsc
v1.4.15
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:
Eine selbstsouveräne Blockchain : Bietet Sicherheit durch gewählte Validatoren.
EVM-kompatibel : Unterstützt alle vorhandenen Ethereum-Tools sowie schnellere Endgültigkeit und günstigere Transaktionsgebühren.
Verteilt mit On-Chain-Governance : Proof of Staked Authority bringt Dezentralisierung und Community-Teilnehmer. Als nativer Token wird BNB sowohl als Gas für die Ausführung intelligenter Verträge als auch als Token für das Abstecken dienen.
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:
Blöcke werden von einer begrenzten Anzahl von Validatoren erstellt.
Validatoren wechseln sich ab, um Blöcke auf PoA-Art zu produzieren, ähnlich der Clique-Konsens-Engine von Ethereum.
Der Validatorsatz wird auf der Grundlage einer auf Stakes basierenden Governance auf der BNB Smart Chain ausgewählt.
Die Parlia-Konsens-Engine wird mit einer Reihe von Systemverträgen interagieren, um eine Reduzierung der Lebendigkeit, eine Umsatzverteilung und eine Erneuerungsfunktion für den Validatorsatz zu erreichen.
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:
Zahlen Sie 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
mach Geth
oder, um die gesamte Suite an Dienstprogrammen zu erstellen:
alles machen
Wenn Sie beim Ausführen des Knotens mit selbst erstellter Binärdatei eine solche Fehlermeldung erhalten:
SIGILL in blst_cgo_init gefangen, siehe <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 Status bei) oder als 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 funktioniert auf 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 rationalisiert 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 Das Durchgehen aller möglichen Befehlszeilen-Flags würde hier den Rahmen sprengen (bitte konsultieren Sie unsere CLI-Wiki-Seite), aber wir haben ein paar gängige Parameterkombinationen aufgelistet, um Ihnen schnell einen Überblick darüber zu verschaffen, 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:
VPS mit aktuellen Versionen von Mac OS X, Linux oder Windows.
WICHTIG 3 TB (Dezember 2023) freier Festplattenspeicher, Solid-State-Laufwerk (SSD), GP3, 8.000 IOPS, 500 MB/S Durchsatz, Leselatenz <1 ms. (Wenn der Knoten mit Snap-Sync gestartet wird, benötigt er eine NVMe-SSD)
16 CPU-Kerne und 64 GB Arbeitsspeicher (RAM)
Schlagen Sie den Instanztyp m5zn.6xlarge oder r7iz.4xlarge in AWS und c2-standard-16 in der Google Cloud vor.
Eine Breitband-Internetverbindung mit Upload-/Download-Geschwindigkeiten von 5 MB/s
Die Anforderung an Testnet:
VPS mit aktuellen Versionen von Mac OS X, Linux oder Windows.
500 G Speicher für Testnetz.
4 CPU-Kerne und 16 Gigabyte Arbeitsspeicher (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
//== Hauptnetz 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## Es wird empfohlen, fullnode mit „--tries-“ auszuführen. „Verify-Mode None“, wenn Sie eine hohe Leistung wünschen und sich wenig um die Zustandskonsistenz kümmern.## Es wird standardmäßig mit dem Hash-Base-Speicherschema ausgeführt./geth --config ./config.toml --datadir ./node --cache 8000 --rpc.allow-unprotected-txs --history.transactions 0 --tries-verify-mode none## Es führt Fullnode mit Path-Base Storage Scheme aus. ## Es aktiviert die Inline-Statusbereinigung und behält standardmäßig den Verlaufsstatus der letzten 90.000 Blöcke bei../geth --config ./config.toml --datadir ./node --cache 8000 --rpc.allow-unprotected-txs --history.transactions 0 --tries-verify-mode keine --state.scheme Pfad
Ü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="Neues Kettensegment importiert" Blocks=1 txs=177 mgas=17.317 elapsed=31.131ms mgasps=556.259 Zahl=21.153.429 hash=0x42e6b54ba7106387f0650defc62c9ace3160b427702dab7bd1c5abb83a32d8db dirty="0.00 B"t=2022-09-08T13:00:29+0000 lvl=info msg="Neues Kettensegment importiert" Blocks=1 txs=251 mgas=39,638 verstrichen=68,827 ms mgasps=575,900 Zahl=21.153.430 hash=0xa3397b273b31b013e43487689782f20c03f47525b4cd4107c1715af45a88796e dirty="0.00 B"t=2022-09-08T13:00:33+0000 lvl=info msg="Neues Kettensegment importiert" Blöcke = 1 Txs = 197 Mgas = 19,364 verstrichen = 34,663 ms Mgasps = 558,632 Anzahl = 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 Cross-Origin-Anfragen angenommen 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!
BSC-Deploy: Bereitstellungstool zum Einrichten der BNB Smart Chain.
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=<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
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:
Der Code muss den offiziellen Go-Formatierungsrichtlinien entsprechen (d. h. gofmt verwenden).
Der Code muss unter Einhaltung der offiziellen Go-Kommentarrichtlinien dokumentiert werden.
Pull-Anfragen müssen auf dem master -Zweig basieren und für diesen geöffnet werden.
Commit-Nachrichten sollten die Pakete vorangestellt werden, die sie ändern.
ZB „eth, rpc: Trace-Konfigurationen optional machen“
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.
