nimbus eth2
Unknown
Nimbus-eth2 est une implémentation client de couche consensus (eth2) extrêmement efficace. Bien qu'il soit optimisé pour les systèmes embarqués et les appareils à ressources limitées, y compris Raspberry Pis, sa faible utilisation des ressources en fait également un excellent choix pour n'importe quel serveur ou ordinateur de bureau (où il consomme simplement moins de ressources).
Vous pouvez trouver les informations dont vous avez besoin pour exécuter un nœud balise et fonctionner en tant que validateur dans The Book.
Le Quickstart en particulier vous aidera à vous connecter rapidement au réseau principal ou au réseau de test Prater.
L'API Nimbus REST est désormais disponible à partir de :
Notez qu'à l'heure actuelle, il s'agit d'instances de test très instables. Ils peuvent parfois ne pas répondre - alors ne comptez pas sur eux pour la validation . Nous pouvons également les désactiver à tout moment.
Ce guide vous expliquera les bases de la migration vers Nimbus à partir d'un autre client. Voir ici pour les options avancées.
Vous pouvez vérifier où se situe la chaîne de balises dans l'écosystème Ethereum dans notre série Two-Point-Oh : https://our.status.im/tag/two-point-oh/
Si vous souhaitez contribuer au développement de Nimbus, notre adresse de don est 0x70E47C843E0F6ab0991A3189c28F2957eb6d3842
stable - dernière version stable - cette branche est recommandée pour la plupart des utilisateurstesting - branche préliminaire avec des fonctionnalités et des corrections de bugs prévues pour la prochaine version stable - cette branche convient à une utilisation sur les réseaux de test et aux utilisateurs aventureux qui souhaitent vivre à la périphérie.unstable - branche de développement principale avec laquelle les PR sont fusionnés - si vous souhaitez contribuer à Nimbus, commencez ici. Pour commencer à développer Nimbus lui-même, consultez le manuel du développeur.
Nous fournissons plusieurs outils pour interagir avec ETH2 et les données de la chaîne de balises :
Le simulateur de bloc peut exécuter rapidement la fonction de transition d'état de la chaîne Beacon de manière isolée. La simulation s'exécute sans mise en réseau et sans délais de créneau.
# 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 --helpLa simulation de réseau local créera un réseau peer-to-peer complet de nœuds de balise et de validateurs sur une seule machine, et exécutera la chaîne de balises en temps réel. Des paramètres tels que le nombre de fragments, le nombre de validateurs et les dossiers de données peuvent être définis en tant que variables d'environnement avant de lancer la simulation.
# 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. Par défaut, les validateurs seront divisés en deux entre les processus du nœud balise et du client validateur (50/50), communiquant via l'API de validation commune (par exemple, avec 192 validateurs et 6 nœuds, vous vous retrouverez grossièrement avec 6 nœuds balises et 6 clients validateurs. processus, où chacun d'eux gérera 16 validateurs), mais si vous ne souhaitez pas utiliser de clients de validation externes et souhaitez plutôt que tous les validateurs soient gérés par les nœuds balises, vous pouvez utiliser USE_VC=0 comme argument supplémentaire pour make local-testnet-minimal .
Vous pouvez également lancer notre instance expérimentale Vagrant avec Nim préinstallé et faites-nous part de vos commentaires sur le processus !
Les instructions génériques du dépôt Nimbus s'appliquent également ici.
Étapes spécifiques :
# 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 Le tableau de bord que vous devez importer dans Grafana est grafana/beacon_nodes_Grafana_dashboard.json .
Les réseaux de test locaux s'exécutent pendant 4 époques chacun, pour tester la finalisation. Cela se produit uniquement sur les hôtes Jenkins Linux, et leurs journaux sont disponibles en téléchargement sous forme d'artefacts, à partir de la page du travail. Ne vous attendez pas à ce que ces artefacts soient conservés plus d'un jour après la suppression de la branche correspondante.
Sous licence et distribué sous l'un des deux
ou
à votre choix. Ces fichiers ne peuvent pas être copiés, modifiés ou distribués sauf selon ces conditions.
