Vers le milieu de cette année, Ethereum, la deuxième plus grande blockchain en termes de valeur monétaire, et avec des centaines de milliards de dollars d'actifs en fonction de son fonctionnement, passera de l'algorithme de consensus Proof-of-Work sécurisant le système aujourd'hui , au système Proof-of-Stake de demain - une procédure décrite par beaucoup comme changer le moteur d'un avion en le pilotant. Ethereum ne peut en aucun cas cesser de produire des blocs valides.
Contrairement à la plupart des blockchains, par exemple, Bitcoin, la communauté de développeurs d'Ethereum, encouragée par la Fondation Ethereum (EF) et de nombreuses personnalités de la communauté, s'est mis d'accord pour développer plusieurs versions des logiciels clients implémentant le protocole de la Preuve de pieu blockchain de consensus, souvent appelée Ethereum 2.0. Les différentes versions du logiciel client sont séparées par langage de programmation et par les équipes individuelles qui les développent.
Après la fusion, il y aura deux types de nœuds
La transition sera une fusion, souvent simplement appelée The Merge, entre le Ethereum les nœuds de réseau d'aujourd'hui, parmi lesquels un sous-ensemble fonctionne comme des mineurs, et les nœuds exécutant la chaîne dite de balise qui est déjà opérationnelle depuis décembre 2020. Dans le même temps, il y aura une séparation des tâches des nœuds. Aujourd'hui, les nœuds effectuent à la fois l'exécution des transactions et la validation de ces mêmes transactions.
Après la fusion, il y aura deux types de nœuds : un type présentera la machine virtuelle Ethereum, le EVM, aux utilisateurs et aux contrats intelligents, exécutez les transactions et envoyez-les aux nœuds de validation pour les valider. Les nœuds d'exécution sur la chaîne d'exécution effectueront essentiellement les mêmes tâches qu'actuellement, sauf que la validation sera prise en charge par les nœuds de validation sur la chaîne de consensus.
Les deux types de clients partagent du code, étant donné qu'ils sont développés dans le même langage de programmation, et les clients d'exécution ont été légèrement mis à jour pour s'adapter à la fusion. La plupart des parties du client d'exécution, telles que l'EVM, peuvent être réutilisées avec de légères modifications. Finalement, les clients d'exécution peuvent supprimer complètement les parties du code qui effectue la validation sur le présent Preuve de travail chaîne.
La fusion n'est donc pas réellement une fusion au sens commun où deux chaînes deviendront une seule, mais plutôt qu'à un certain moment, à une certaine hauteur de bloc pour être correct, les nœuds d'aujourd'hui cesseront de valider les transactions, un devoir qui seront plutôt effectués par des validateurs. Il s'agit d'une amélioration classique de la robustesse par la séparation des tâches en différentes couches logiques.
66 % sur un client pourrait signifier la fin de la partie
Le raisonnement derrière avoir plusieurs logiciels clients est qu'un défaut, un bogue ou une vulnérabilité dans l'un des clients n'affectera pas les autres clients, car ils ne partagent pas le même code ou même les langages de programmation.
Il est juste de se demander pourquoi ce n'est pas le cas avec, disons, Bitcoin. La raison en est que le protocole Bitcoin et sa mise en œuvre sont très simples par rapport au protocole Ethereum. Ethereum est une machine beaucoup plus complexe, d'un ordre de grandeur que Bitcoin, et une complexité accrue, par nature, signifie un risque plus élevé de vulnérabilités et plus de surfaces d'attaque.
Tout va bien tant que la répartition des différents clients est égale, ou proche de l'égalité, et notamment de manière à ce qu'aucun client ne soit utilisé à plus de 33% de la puissance de staking dans le réseau. Si ce n'est pas le cas, et certainement si un client est utilisé par plus de 66 % de la puissance de mise, ce qui est le cas aujourd'hui, alors toute l'idée d'avoir différentes bases de code pour différents clients est pratiquement inutile.
Sans trop entrer dans les détails de la façon dont différentes distributions peuvent avoir des effets différents sur le fonctionnement du réseau, il suffit de dire que si un bogue grave frappe un client avec moins de ⅓ de la puissance de jalonnement, alors aucun mal n'est fait. Le réseau continuera à fonctionner sans aucun problème. Le bug sera corrigé et tout redeviendra normal.
Si la même chose arrive à un client avec entre ⅓ et ½ de la puissance de jalonnement, alors c'est un peu plus grave mais les utilisateurs ne s'en apercevront pas. Des mécanismes automatiques de toutes sortes s'en chargeront. Si un bogue grave frappe un client avec plus de la moitié de la puissance de jalonnement, une multitude de mécanismes seront automatiquement exécutés qui finiront par réparer la situation, mais il y aura des complications et des perturbations sur le réseau, et les utilisateurs seront affectés.
Si, cependant, un bogue frappe un client qui est utilisé par plus des ⅔ de la puissance de jalonnement, c'est fondamentalement la fin de la partie. Les clients de buggy ont une super-majorité et tout le pouvoir qui va avec, et la chaîne de buggy se finalisera. Essentiellement, tout ce que les clients non bogués peuvent faire est soit de diviser définitivement la chaîne, auquel cas nous aurons deux Ethereums, soit de rejoindre la chaîne de buggy et de vivre avec ce que le bogue a causé.
Les lecteurs intéressés à lire les détails sont fortement recommandés de lire jmcook. eth article sur Miroir.
Supermajorité sur Prysm, pas une situation idéale
À ce jour, environ ⅔ de la puissance de jalonnement du réseau exécute l'implémentation du client Prysm, développée par Prysmatic Labs. Ce n'est, pour dire le moins, pas une situation idéale au cas où le client Prysm s'avérerait contenir un bogue, et le bogue pourrait être exploité d'une manière qui provoque un échec de consensus sur le réseau. Pour être juste, ce scénario est peu probable, mais néanmoins non nul.
Les autres clients sur le marché sont Lighthouse, Teku, Nimbus, Grandine et Loadstar. Parmi ceux-ci, Grandine et Loadstar ont de très petites parts de marché, toutes deux bien inférieures à 1 %. Grandine est le seul publié sous une licence de source fermée.
La répartition des clients consensuels au moment de la publication est présentée dans l'illustration ci-dessous. Comme le lecteur peut le constater, la domination de Prysm est bien au-delà de la satisfaction, mais juste en dessous du niveau critique des ⅔. Pour obtenir des informations et des ressources à jour, visitez clientdiversity.org.
Une question juste à se poser est de savoir pourquoi le client Prysm est si dominant ; il doit y avoir une raison pour laquelle les personnes et les organisations qui exécutent des nœuds de validation ont choisi Prysm ? Pour répondre à la question, CryptoSlate a contacté Marius van der Wijden, développeur principal d'Ethereum travaillant sur le client Geth (Golang Ethereum) Proof-of-Work.
Règles de Prysm en raison de l'avantage du premier arrivé
"Je pense que les principales raisons du succès de Prysms sont l'avantage du premier arrivé, l'outillage et le golang. Prysm a été le premier prototype d'implémentation d'un client balise. Ainsi, ils ont pu commencer à optimiser leur client très tôt et ils ont eu plus de temps pour créer des outils supplémentaires (par exemple, l'interface utilisateur Web) et une bonne documentation. »
"Un autre grand avantage est le langage de programmation utilisé par prysm - golang - qui est raisonnablement performant et très facile à lire et à développer. Go-ethereum est également écrit en golang, ainsi les développeurs familiers avec Geth pourraient également facilement comprendre et auditer prysm", dit van der Wijden.
Ce dernier est important car le manque de répartition uniforme entre les clients d'exécution de la preuve de travail est encore pire qu'avec les clients de consensus. Au moment d'écrire ces lignes, la « part de marché » de Geth est supérieure à 85 %. Cependant, dans un monde post-fusion, ce n'est pas vraiment un problème puisque les nœuds d'exécution exécutent simplement des transactions, mais ils n'offrent pas la sécurité comme le font les clients de consensus.
« Go-ethereum a actuellement une supermajorité de 85 % sur la couche d'exécution. Ce sera un peu mieux après la fusion puisque les jalonneurs peuvent exécuter plusieurs clients de couche d'exécution, avec un client balise, afin de toujours se retrouver sur la bonne chaîne », déclare van der Wijden.
Les grands échanges sont les grands contributeurs de Prysm
Maintenant, tous les opérateurs de nœud ne sont pas égaux. Au contraire, certains opérateurs de nœuds ont jalonné beaucoup plus d'éther que d'autres, et ils exercent donc plus de pouvoir de jalonnement que leurs pairs moins importants. Les plus gros parieurs sont les soi-disant services et/ou pools de jalonnement, offrant la possibilité de parier de l'éther sur la chaîne de balises sans avoir besoin de cracher 32 ETH, et si ce n'était pas pour tous les principaux services de jalonnement exécutant le client Prysm , la question de la diversité des clients ne serait pas un problème.
Ces services de jalonnement ont des noms familiers : Coinbase, Kraken et Binance. Oui, pareil.
Avec 278,407 48,864 nœuds de validation sur la chaîne de balises aujourd'hui, Coinbase seul, avec ses 17.5 92.4 validateurs (XNUMX %) et XNUMX % de ces validateurs exécutant Prysm, contribue 24.3 % à la question de la diversité.
Lorsque CryptoSlate a contacté Coinbase pour lui demander comment il percevait le problème de la diversité des clients, la contribution de l'entreprise à celui-ci et ce que Coinbase ferait, le cas échéant, pour dégonfler le problème, les communications de Coinbase, Jaclyn Sales, ont souligné un fil de tweet de Coinbase Cloud du 22 février.
Dans le fil, Coinbase indique principalement que la sécurité est la motivation derrière le choix d'utiliser Prysm.
«Coinbase utilise plusieurs fournisseurs de jalonnement eth2 pour maximiser la sécurité et la distribution des clients. Lors du lancement du jalonnement eth2, Coinbase a évalué les clients et les fournisseurs existants pour maximiser ces caractéristiques, ce qui signifiait commencer par Prysm car c'était le seul client viable prenant en charge les signataires à distance.
"Les signataires à distance permettent aux validateurs de générer et de stocker des clés dans des environnements isolés au lieu de les conserver sur le validateur lui-même, ce qui augmente considérablement la sécurité des validateurs eth2 sur Coinbase."
Coinbase : Prysm avait de meilleures fonctionnalités de sécurité
Selon le tweet, les signataires à distance permettent également à Coinbase Cloud d'offrir une protection contre la double signature grâce à un logiciel de marque d'eau élevée qui aide à protéger les validateurs de tout problème avec les modules de signature dans les clients.
"Dans l'équipe Coinbase Cloud, nous desservons Coinbase Retail, mais aussi de nombreux autres clients. Nous soutenons Lighthouse depuis près d'un an et avons travaillé avec @sigp_io pour ajouter la prise en charge des signataires à distance à Lighthouse à la fin de l'année dernière », poursuit le tweet.
Quant à Kraken, avec un nombre de validateurs de 30,847 11 (94.9 %), une utilisation de Prysm de 15.7 % et une contribution globale de Prysm de XNUMX %, Brian Hoffman, chef de produit senior chez Kraken, répond dans un e-mail que,
"Lorsque nous avons construit notre modèle de jalonnement ETH2 pour la première fois, nous avons trouvé que Prysm était la solution la plus appropriée en raison de sa maturité et de sa stabilité."
"Suite à des discussions avec la Fondation Ethereum, Kraken et Staké ont également commencé à déployer de nouveaux validateurs basés sur Teku, ainsi qu'à migrer certains validateurs existants. De cette façon, nous pouvons accroître la diversité de notre logiciel client validateur et offrir aux clients un service de jalonnement en chaîne encore plus résilient.
Binance avec 24,410 8.7 validateurs (76.6%), une utilisation de Prysm de 10% et une contribution globale de Prysm de XNUMX% n'a pas répondu à la demande de commentaire de CryptoSlate.
Le troisième plus grand service de jalonnement, Lido, avec 50,274 18 validateurs (42.8%) a deux fois plus de validateurs que Binance, mais l'utilisation de Prysm est d'au moins "seulement" 11.5%, et donc Lido contribue à hauteur de XNUMX% à la domination de Prysm.
Décentralisé, Rocket Pool ouvre la voie
Il y a bien sûr des exceptions mais celles-ci sont très petites. Le pool de jalonnement décentralisé Rocket Pool, pour sa part, a un nombre de validateurs de 2,100 0.75 (10.6%) avec seulement 0.12% des validateurs exécutant Prysm, où Rocket Pool ne contribue que pour XNUMX% à la domination de Prysm.
Dans l'ensemble, les quatre principaux services et pools de jalonnement ont à leur portée de résoudre la situation, et du bon côté des choses, il y a des discussions en cours entre les services de jalonnement, et entre les services de jalonnement et la Fondation Ethereum. Selon Marius van der Wijden, développeur principal d'Ethereum, la progression de ces discussions est "bonne".
«Oui, il y a des discussions à ce sujet, à la fois en interne et en externe. Je pense que les grands pools de jalonnement travaillent à transférer des parties de leur infrastructure vers d'autres clients. Ils doivent mettre à jour leurs métriques et leur infrastructure de surveillance pour les nouveaux clients, de sorte qu'il leur faudra peut-être plus de temps pour changer que les validateurs à domicile », déclare van der Wijden.
Selon van der Wijden, il n'est ni risqué ni difficile pour un opérateur de nœud de changer de logiciel client.
« Toutes les implémentations majeures sont assez bien testées et maintenues. Si un utilisateur est déjà en train de jalonner, il doit fermer et conserver sa base de données de slashing, s'il n'a pas de base de données de slashing, il doit attendre quelques minutes (> 7 minutes) entre l'arrêt de l'ancien client et le démarrage du nouveau client. Les seules difficultés pourraient survenir pour les plus gros parieurs, car certains clients fournissent des API différentes des autres », déclare van der Wijdens.
La fusion est-elle sûre à poursuivre?
Avec la fusion dans quelques mois seulement, la communauté Ethereum devra probablement accepter une distribution client moins qu'idéale ; la probabilité que la domination de Prysm tombe en dessous de 33 % doit être considérée comme très faible. Cela ne décourage cependant pas Marius van der Wijden ni les autres développeurs principaux d'Ethereum de poursuivre la fusion.
« Je pense qu'il est prudent de poursuivre. Les chances qu'un échec du consensus se produise sont très faibles à mon avis. Nous avons une excellente infrastructure de test et de fuzzing qui fonctionne en permanence pour trouver les différences entre les clients. Même si un échec de consensus se produit, nous serons en mesure de publier de nouvelles versions et de résoudre les fourches rapidement et facilement.
"Nous avons également un fort consensus sur le fait que nous ne renflouerons pas les jalonneurs qui dirigent un client majoritaire si leurs clients se conduisent mal", a déclaré van der Wijden.
Le poste Diversité des clients d'Ethereum : avec 66 % d'entre eux exécutant Prysm, la fusion est-elle sûre à poursuivre ? apparaît en premier sur CryptoSlate.
- "
- 100
- 11
- 2020
- 7
- Qui sommes-nous
- Selon
- Supplémentaire
- Avantage
- algorithme
- Tous
- déjà
- parmi
- Apis
- autour
- Outils
- audit
- caution
- En gros
- chaîne de balises
- devenez
- Le plus grand
- milliards
- binance
- Bit
- Bitcoin
- Block
- blockchain
- Punaise
- les soins
- causé
- chances
- classiques
- fonds à capital fermé
- le cloud
- code
- coinbase
- Commun
- Communications
- Communautés
- De l'entreprise
- par rapport
- complexe
- Consensus
- continuer
- continue
- contrats
- Core
- pourriez
- Couples
- Clients
- Base de données
- Décentralisé
- développer
- développé
- Développeur
- mobiles
- développement
- Devs
- DID
- différent
- distribution
- Diversité
- dollars
- double
- down
- Goutte
- "Early Bird"
- même
- les effets
- essence
- ETH
- Éther
- Ethereum
- Ethereum 2.0
- Fondation ethereum
- peut
- exemple
- Sauf
- Échanges
- exécution
- Échec
- juste
- fin
- Prénom
- Abonnement
- trouvé
- Fondation
- jeu
- générer
- aller
- Bien
- l'
- ayant
- la taille
- aide
- Haute
- très
- Accueil
- Comment
- HTTPS
- Des centaines
- idée
- image
- important
- Améliore
- individuel
- Infrastructure
- aide
- vous aider à faire face aux problèmes qui vous perturbent
- IT
- rejoindre
- en gardant
- clés
- Kraken
- langue
- Langues
- lancement
- Niveau
- Licence
- logo
- Location
- recherchez-
- click
- majeur
- Majorité
- manager
- Marché
- Métrique
- mineurs
- miroir
- modèle
- Stack monitoring
- mois
- (en fait, presque toutes)
- noms
- Nature
- réseau et
- nœuds
- code
- Opinion
- Opportunités
- de commander
- organisations
- Autre
- Personnes
- pool
- Piscines
- power
- représentent
- Press
- assez
- Problème
- Produit
- Programmation
- langages de programmation
- important
- Preuve de pieu
- Preuve de travail
- protéger
- protection
- protocole
- fournir
- question
- vite.
- Reader
- en cours
- Les raisons
- de Presse
- Ressources
- détail
- Analyse
- Risqué
- solidité
- Roulent
- Courir
- pour le running
- des
- vente
- sécurité
- sens
- service
- Services
- Partager
- Partages
- étapes
- petit
- smart
- Contrats intelligents
- So
- Logiciels
- RÉSOUDRE
- scission
- Stabilité
- pieu
- Staking
- Commencer
- j'ai commencé
- Boutique
- STRONG
- succès
- Support
- Appareils
- Interrupteur
- combustion propre
- Talks
- équipe
- Essais
- Avec
- fiable
- aujourd'hui
- aujourd'hui
- Transactions
- Tweet
- ui
- comprendre
- Mises à jour
- utilisateurs
- Plus-value
- Voir
- Salle de conférence virtuelle
- machine virtuelle
- vulnérabilités
- vulnérabilité
- attendez
- web
- Quoi
- Wikipédia
- dans les
- sans
- travaillé
- de travail
- world
- vaut
- écriture
- an