Nimbus Eth2 (Beacon-Kette)

Github-Aktionen CI

Nimbus-eth2 ist eine äußerst effiziente Client-Implementierung auf Konsensebene (eth2). Obwohl es für eingebettete Systeme und ressourcenbeschränkte Geräte – einschließlich Raspberry Pis – optimiert ist, ist es aufgrund seines geringen Ressourcenverbrauchs auch eine ausgezeichnete Wahl für jeden Server oder Desktop (wo es einfach weniger Ressourcen beansprucht).

Dokumentation
Verwandte Projekte
Spenden
Branchenführer
Entwicklerressourcen
Werkzeuge und Hilfsmittel
Für Forscher
- Blocksimulation
- Lokale Netzwerksimulation
- Visualisierung von Simulationsmetriken
- CI-Setup
Lizenz

Dokumentation

Die Informationen, die Sie benötigen, um einen Beacon-Knoten zu betreiben und als Validator zu fungieren, finden Sie im Buch.

Insbesondere der Quickstart hilft Ihnen dabei, sich schnell entweder mit dem Mainnet oder dem Prater-Testnetz zu verbinden.

Testen Sie Ihre Werkzeuge schnell mit Nimbus

Die Nimbus REST-API ist jetzt verfügbar unter:

http://unstable.mainnet.beacon-api.nimbus.team/
http://testing.mainnet.beacon-api.nimbus.team/
http://unstable.sepolia.beacon-api.nimbus.team/
http://testing.holesky.beacon-api.nimbus.team/
http://unstable.holesky.beacon-api.nimbus.team/

Beachten Sie, dass es sich derzeit um sehr instabile Testinstanzen handelt. Es kann vorkommen, dass sie nicht reagieren. Verlassen Sie sich also bei der Validierung bitte nicht auf sie . Wir können sie auch jederzeit deaktivieren.

Von einem anderen Client migrieren

Dieser Leitfaden führt Sie durch die Grundlagen der Migration von einem anderen Client zu Nimbus. Weitere Optionen finden Sie hier.

Spenden

Wenn Sie zur Nimbus-Entwicklung beitragen möchten, lautet unsere Spendenadresse 0x70E47C843E0F6ab0991A3189c28F2957eb6d3842

Branchenführer

stable – neueste stabile Version – dieser Zweig wird für die meisten Benutzer empfohlen
testing – Vorabversionszweig mit Funktionen und Bugfixes, die für die nächste stabile Version geplant sind – dieser Zweig eignet sich für die Verwendung in Testnetzen und für abenteuerlustige Benutzer, die am Rande leben möchten.
unstable – Hauptentwicklungszweig, gegen den PRs zusammengeführt werden – wenn Sie zu Nimbus beitragen möchten, beginnen Sie hier.

Entwicklerressourcen

Informationen zum Einstieg in die Entwicklung von Nimbus selbst finden Sie im Entwicklerhandbuch.

Werkzeuge und Hilfsmittel

Wir bieten verschiedene Tools für die Interaktion mit ETH2 und den Daten in der Beacon-Kette:

ncli – Befehlszeilentool mit hübschen Druckern, SSZ-Decodern und Zustandsübergangshelfern zur Interaktion mit Eth2-Datenstrukturen und -Funktionen
ncli_db – Befehlszeilentool zum Durchführen von Operationen an der Nimbus-SQLite-Datenbank
multinet – eine Reihe von Skripten zum lokalen Erstellen und Ausführen mehrerer Eth2-Clients

Für Forscher

Blocksimulation

Der Blocksimulator kann die Zustandsübergangsfunktion der Beacon-Kette schnell und isoliert ausführen. Die Simulation läuft ohne Vernetzung und ohne Slot-Zeitverzögerungen.

 # build and run the block simulator, then display its help ("-d:release" speeds it
# up substantially, allowing the simulation of longer runs in reasonable time)
make NIMFLAGS= " -d:release " block_sim
build/block_sim --help

Lokale Netzwerksimulation

Durch die lokale Netzwerksimulation wird ein vollständiges Peer-to-Peer-Netzwerk aus Beacon-Knoten und Validatoren auf einem einzigen Computer erstellt und die Beacon-Kette in Echtzeit ausgeführt. Parameter wie Shard, Validator-Anzahl und Datenordner können vor dem Start der Simulation als Umgebungsvariablen festgelegt werden.

 # Clear data files from your last run and start the simulation with a new genesis block:
make VALIDATORS=192 NUM_NODES=6 USER_NODES=1 local-testnet-minimal

# In another terminal, get a shell with the right environment variables set:
./env.sh bash

# In the above example, the network is prepared for 7 beacon nodes but one of
# them is not started by default (`USER_NODES`) - this is useful to test
# catching up to the consensus. The following command will start the missing node.
./tests/simulation/run_node.sh 0 # (or the index (0-based) of the missing node)

# Running a separate node allows you to test sync as well as see what the action
# looks like from a single nodes' perspective.

Standardmäßig werden Validatoren zur Hälfte zwischen Beacon-Knoten- und Validator-Client-Prozessen (50/50) aufgeteilt und kommunizieren über die gemeinsame Validator-API (bei 192 Validatoren und 6 Knoten erhalten Sie beispielsweise ungefähr 6 Beacon-Knoten und 6 Validator-Clients). Prozesse, wobei jeder von ihnen 16 Validatoren handhaben wird), aber wenn Sie keine externen Validator-Clients verwenden möchten und stattdessen alle Validatoren von den Beacon-Knoten gehandhabt werden sollen, können Sie USE_VC=0 als zusätzliches Argument verwenden, um make local-testnet-minimal .

Alternativ starten Sie unsere experimentelle Vagrant-Instanz mit vorinstalliertem Nim und geben Sie uns Ihr Feedback zum Prozess!

Visualisierung von Simulationsmetriken

Auch hier gelten die allgemeinen Anweisungen aus dem Nimbus-Repo.

Spezifische Schritte:

 # This will generate the Prometheus config on the fly, based on the number of nodes:
make REMOTE_VALIDATORS_COUNT=192 NUM_NODES=6 USER_NODES=0 local-testnet-minimal

# In another terminal tab, after the sim started:
cd tests/simulation/prometheus
prometheus

Das Dashboard, das Sie in Grafana importieren müssen, ist grafana/beacon_nodes_Grafana_dashboard.json .

Überwachungs-Dashboard

CI-Setup

Lokale Testnetze laufen jeweils 4 Epochen lang, um die Finalisierung zu testen. Dies geschieht nur auf Jenkins-Linux-Hosts, deren Protokolle als Artefakte auf der Seite des Jobs heruntergeladen werden können. Erwarten Sie nicht, dass diese Artefakte länger als einen Tag nach dem Löschen des entsprechenden Zweigs erhalten bleiben.

Jenkins-Artefakte