Vitalik Buterin veut rendre Ethereum 'aussi simple que Bitcoin' d'ici 2030

Le co-fondateur d'Ethereum, Vitalik Buterin, pense que la résilience et la scalabilité à long terme de la blockchain dépendent de sa simplification, à l'instar de Bitcoin. Dans un article de blog publié le 3 mai, il a décrit comment "Ethereum dans 5 ans pourrait devenir presque aussi simple que Bitcoin". Buterin a écrit: « L'une des choses les plus formidables à propos de Bitcoin est que le protocole est extrêmement simple. » Selon Buterin, le design minimaliste et la simplicité de Bitcoin le rendent accessible, de sorte qu'un élève de lycée peut saisir le concept et l'architecture du protocole. Buterin soutient que la simplicité apporte également d'autres avantages, tels que la réduction des coûts de création d'une nouvelle infrastructure et l'entretien de l'infrastructure existante, ainsi que la diminution du risque d'erreurs. Les mises à jour récentes telles que la preuve d'enjeu (PoS) et l'intégration de l'Argument de Connaissance Succinct Non-Interactif à Zéro Connaissance (zk-SNARK) ont rendu Ethereum plus puissant. Cependant, le fait d'ignorer la simplicité du design a accru les coûts d'Ethereum. Buterin a expliqué : "Auparavant, Ethereum ne faisait souvent pas cela ( parfois en raison de ma propre décision ) et cela a contribué à entraîner de nombreux coûts de développement excessifs, toutes sortes de risques de sécurité et une étroitesse dans la culture R&D, souvent pour poursuivre des intérêts qui se sont avérés irréalistes." Simplifier la couche de consensus d'Ethereum En novembre, le chercheur Justin Drake de la Fondation Ethereum a proposé une mise à niveau de la couche de consensus appelée 'Beam Chain'. Buterin pense que Beam Chain "a de bonnes chances de devenir beaucoup plus simple" par rapport à son prédécesseur obsolète, la beacon chain actuelle. Cela est dû au fait que la chaîne de rayons permettra de redessiner la finalité des 3 emplacements, ce qui éliminera des concepts complexes tels que des emplacements distincts, les époques et le comité de synchronisation, a noté Buterin. Il a également souligné que la mise en œuvre de la finalité fondamentale des 3 emplacements pourrait être réalisée avec environ 200 lignes de code, simplifiant ainsi beaucoup de choses. La chaîne de faisceaux réduira également le nombre de validateurs actifs à un moment donné, ce qui aidera à "utiliser des déploiements plus simples de la règle de sélection de branches plus sûres", a écrit Buterin. La chaîne de faisceau intégrera également des protocoles d'agrégation basés sur STARK, ce qui signifie que n'importe qui peut être un agrégateur. Buterin a souligné : « La complexité même des cryptomonnaies est considérable, mais au moins elle a une complexité étroitement intégrée, avec un risque systémique beaucoup plus faible pour le protocole. » Buterin a ajouté que la réduction du nombre de validateurs actifs et la combinaison de synthétiseurs basés sur STARK "pourrait permettre une architecture P2P plus simple et plus robuste". Il a poursuivi en disant qu'il y avait une occasion de repenser et de simplifier certains aspects, depuis l'entrée et la sortie des validateurs jusqu'aux fuites d'inactivité. Et cela pourrait être réalisé en réduisant le nombre de lignes de code (LoC) et en créant "des garanties plus lisibles". Buterin a souligné que la couche de consensus est "relativement distincte" des opérations d'exécution de la Machine Virtuelle Ethereum (EVM), ce qui offre "une marge relativement large" pour apporter des améliorations par rapport à la couche d'exécution. Simplifier la couche d'exécution d'Ethereum Le mois dernier, Buterin a proposé de remplacer le langage de contrat EVM par RISC-V pour augmenter l'efficacité jusqu'à 100 fois. Buterin a soutenu que l'adoption de RISC-V augmenterait également la simplicité, car "la spécification RISC-V est ridiculement simple par rapport à l'EVM". Cependant, cela signifie que la compatibilité descendante pour les applications existantes doit être maintenue. Buterin a écrit : "La première chose importante à comprendre est : il n'y a pas de manière unique de définir ce qu'est la "base de code Ethereum" ( même dans un seul client )." Selon Buterin, la zone orange ne peut pas être réduite. Buterin a déclaré que l'objectif est de minimiser la zone verte, en déplaçant le code vers la zone jaune, en indiquant que "le code est très précieux pour comprendre et interpréter la chaîne aujourd'hui ou pour construire un bloc optimal, mais il ne fait pas partie du consensus". Buterin compare ce processus à la façon dont Apple a atteint une compatibilité à long terme grâce à des couches de compilation. Il écrit : "Il est important que les zones orange et jaune soient emballées de manière complexe, quiconque souhaite comprendre le protocole peut les ignorer, le déploiement d'Ethereum peut les ignorer et toute erreur dans ces zones ne pose pas de risque pour le consensus." C'est la raison pour laquelle la complexité du code dans la zone orange et jaune a "beaucoup moins d'inconvénients" par rapport à la complexité du code dans la zone verte. Pour réduire la superficie des espaces verts, Buterin propose les étapes suivantes : Phase 1 : Les nouveaux programmes de compilation seront écrits en RISC-V. Phase 2 : Les développeurs auront la possibilité d'écrire des contrats en RISC-V. Phase 3 : Tous les précédents compilateurs seront remplacés par des implémentations RISC-V via un hard fork. Étape 4 : Déploiement de l'interpréteur EVM dans RISC-V et mise en ligne en tant que contrat intelligent. Buterin a déclaré que les étapes ci-dessus garantiront que le consensus d'Ethereum comprendra naturellement RISC-V. Norme de protocole pour simplifier Buterin a proposé de partager "une norme sur différentes parties de la pile" comme un moyen de simplifier. Par exemple, Buterin propose d'utiliser un code d'effacement unique pour échantillonner les données disponibles, diffuser en P2P et stocker l'historique de manière décentralisée. Cela minimiserait le nombre total de lignes de code, augmenterait l'efficacité et garantirait la vérifiabilité, argue-t-il. De la même manière, il propose d'avoir un format de sérialisation unique partagé sur trois couches d'Ethereum : la couche d'exécution, la couche de consensus et le contrat intelligent appelé Interface binaire d'application (ABI). Buterin propose d'utiliser SSZ, qui est facile à décoder et largement utilisé. Enfin, après que l'EVM a été remplacé par RISC-V ou un autre langage plus simple, Buterin a proposé de passer d'un arbre Merkle Patricia hexary à un arbre binaire, tant pour la couche de consensus que pour la couche d'exécution. Cette transition pourrait améliorer l'efficacité et réduire les coûts tout en garantissant que toutes les couches d'Ethereum puissent être accessibles et interprétées avec le même code, écrit Buterin. Un changement de caractère Buterin conclut en suggérant qu'Ethereum, à l'exemple de Tinygrad, applique un objectif de ligne de code maximum clairement défini. Buterin rappelle que l'objectif est de rendre le "code important pour le consensus d'Ethereum presque aussi simple que Bitcoin". Mais plus important encore, Ethereum doit adopter une norme où les options plus simples sont choisies chaque fois que cela est possible. Cela signifie donner la priorité à la complexité emballée plutôt qu'à la complexité systémique. Buterin affirme que le code qui gère les règles historiques d'Ethereum continuera d'exister avec sa dernière proposition. Cependant, un tel code doit être conservé en dehors du code essentiel du consensus ou de la zone verte.

Voir l'original
Le contenu est fourni à titre de référence uniquement, il ne s'agit pas d'une sollicitation ou d'une offre. Aucun conseil en investissement, fiscalité ou juridique n'est fourni. Consultez l'Avertissement pour plus de détails sur les risques.
  • Récompense
  • 1
  • Partager
Commentaire
0/400
GateUser-9785ab83vip
· Il y a 21h
Quel bon retour au pow, manœuvre audacieuse.
Voir l'originalRépondre0
  • Épingler
Trader les cryptos partout et à tout moment
qrCode
Scan pour télécharger Gate.io app
Communauté
Français (Afrique)
  • 简体中文
  • English
  • Tiếng Việt
  • 繁體中文
  • Español
  • Русский
  • Français (Afrique)
  • Português (Portugal)
  • Indonesia
  • 日本語
  • بالعربية
  • Українська
  • Português (Brasil)