Je suis assis ici en train d'écrire ceci le dernier jour d'une interopérabilité de développeurs Ethereum au Kenya, où nous avons fait beaucoup de progrès en mettant en œuvre et en peaufinant les détails techniques des améliorations Ethereum à venir, notamment PeerDAS, le Transition de l'arbre Verkleet approches décentralisées de stockage de l'histoire dans le contexte deEIP 4444. De mon propre point de vue, on dirait que le rythme de développement d'Ethereum, et notre capacité à livrer des fonctionnalités importantes et importantes qui améliorent de manière significative l'expérience des opérateurs de nœuds et des utilisateurs (L1 et L2), est en augmentation.

Équipes de clients Ethereum travaillant ensemble pour expédier le réseau de développement Pectra.

Étant donné cette capacité technique accrue, une question importante à se poser est la suivante : construisons-nous vers les bons objectifs ? Une incitation à réfléchir à cela est une récente série de tweets mécontents du développeur principal de Geth, Peter Szilagyi, depuis longtemps.

Ce sont des préoccupations légitimes. Ce sont des préoccupations que de nombreuses personnes de la communauté Ethereum ont exprimées. Ce sont des préoccupations que j'ai moi-même personnellement eues à de nombreuses reprises. Cependant, je ne pense pas non plus que la situation soit aussi désespérée que le laissent entendre les tweets de Peter ; en réalité, bon nombre des préoccupations sont déjà prises en charge par les fonctionnalités du protocole qui sont déjà en cours, et beaucoup d'autres peuvent être résolues par des ajustements très réalistes au plan actuel.

Pour voir ce que cela signifie en pratique, passons en revue les trois exemples que Peter a fournis un par un. L'objectif n'est pas de se concentrer spécifiquement sur Peter; ce sont des préoccupations largement partagées par de nombreux membres de la communauté, et il est important d'y répondre.

MEV, et la dépendance des constructeurs

Dans le passé, les blocs d'Éther étaient créés par des mineurs, qui utilisaient un algorithme relativement simple pour créer des blocs. Les utilisateurs envoient des transactions à un réseau p2p public souvent appelé le « mempool » (ou « txpool »). Les mineurs écoutent le mempool et acceptent les transactions qui sont valides et payent des frais. Ils incluent les transactions qu'ils peuvent, et s'il n'y a pas assez d'espace, ils les priorisent en fonction des frais les plus élevés en premier.

Il s'agissait d'un système très simple et favorable à la décentralisation : en tant que mineur, vous pouvez simplement exécuter un logiciel par défaut et obtenir les mêmes niveaux de revenus de frais à partir d'un bloc que ceux que vous pourriez obtenir des fermes de minage hautement professionnelles. Cependant, vers 2020, les gens ont commencé à exploiter ce qu'on appelait la valeur extractible par les mineurs (MEV) : des revenus qui ne pouvaient être obtenus qu'en exécutant des stratégies complexes tenant compte des activités se déroulant au sein de divers protocoles DeFi.

Par exemple, prenez des échanges décentralisés comme Uniswap. Supposons qu'au moment T, le taux de change USD/Éther - sur les bourses centralisées et sur Uniswap - soit de 3000 $. Au moment T+11, le taux de change USD/Éther sur les bourses centralisées passe à 3005 $. Mais Ethereum n'a pas encore eu son prochain bloc. Au moment T+12, c'est le cas. Celui qui crée le bloc peut faire de sa première transaction une série d'achats Uniswap, achetant tout l'Éther disponible sur Uniswap à des prix allant de 3000 $ à 3004 $. Il s'agit de revenus supplémentaires, et cela s'appelle MEV. Les applications autres que les DEX ont leurs propres analogues à ce problème. Flash Boys 2.0 paperpublié en 2019 entre dans les détails à ce sujet.

Un graphique du document Flash Boys 2.0 qui montre le montant de revenu capturable en utilisant les types d'approches décrites ci-dessus.

Le problème est que cela casse l'histoire pour laquelle l'exploitation minière (ou, après 2022, la proposition de bloc) peut être «juste»: maintenant, les gros acteurs qui ont une meilleure capacité à optimiser ces types d'algorithmes d'extraction peuvent obtenir un meilleur rendement par bloc.

Depuis lors, il y a eu un débat entre deux stratégies, que je vais appeler la minimisation de l'Éther et la mise en quarantaine de l'Éther. La minimisation de l'Éther se présente sous deux formes : (i) travailler de manière agressive sur des alternatives sans Éther à Uniswap (par exemple,Échange de vaches) et (ii) développer des techniques in-protocole, comme des mempools chiffrés, qui réduisent les informations disponibles pour les producteurs de blocs, et réduisent ainsi les revenus qu'ils peuvent capturer. En particulier, les mempools chiffrés empêchent les stratégies telles que les attaques sandwich, qui placent les transactions juste avant et après les trades des utilisateurs afin de les exploiter financièrement ("front-running").

La mise en quarantaine de la MEV fonctionne en acceptant la MEV, mais en essayant de limiter son impact sur la centralisation du jalonnement en séparant le marché en deux types d'acteurs : les validateurs sont responsables de l'attestation et de la proposition de blocs, mais la tâche de choisir le contenu du bloc est sous-traitée à des constructeurs spécialisés via un protocole d'enchères. Les jalonneurs individuels n'ont plus besoin de se soucier d'optimiser l'arbitrage defi eux-mêmes ; ils rejoignent simplement le protocole d'enchères et acceptent l'offre la plus élevée. Cela s'appelle la séparation des proposants/constructeurs (PBS). Cette approche a des précédents dans d'autres industries : une des principales raisons pour lesquelles les restaurants parviennent à rester si décentralisés est qu'ils s'appuient souvent sur un ensemble assez concentré de fournisseurs pour diverses opérations qui ont de grandes économies d'échelle. Jusqu'à présent, le PBS a été raisonnablement réussi pour garantir que les petits validateurs et les gros validateurs sont sur un pied d'égalité, du moins en ce qui concerne la MEV. Cependant, cela crée un autre problème : la tâche de choisir quelles transactions sont incluses devient plus concentrée.

Mon point de vue à ce sujet a toujours été que la minimisation MEV est bonne et que nous devrions la poursuivre (j’utilise personnellement Cowswap régulièrement !) - bien que les mempools cryptés présentent de nombreux défis, mais la minimisation MEV sera probablement insuffisante ; Le MEV ne descendra pas à zéro, ni même près de zéro. Par conséquent, nous avons également besoin d’une sorte de quarantaine MEV. Cela crée une tâche intéressante : comment faire en sorte que la « boîte de quarantaine MEV » soit aussi petite que possible ? Comment donner le moins de pouvoir possible aux constructeurs, tout en les gardant capables d’absorber le rôle d’optimisation de l’arbitrage et d’autres formes de collecte des MEV ?

Si les constructeurs ont le pouvoir d'exclure complètement des transactions d'un bloc, des attaques peuvent facilement survenir. Supposons que vous ayez un position de dette garantie (CDP)dans un protocole de financement décentralisé, adossé à un actif dont le prix chute rapidement. Vous voulez soit augmenter votre garantie, soit sortir du CDP. Les constructeurs malveillants pourraient essayer de se coaliser pour refuser d'inclure votre transaction, la retardant jusqu'à ce que les prix chutent suffisamment pour qu'ils puissent liquider de force votre CDP. Si cela se produit, vous devriez payer une grosse amende et les constructeurs en obtiendraient une grande part. Alors comment empêcher les constructeurs d'exclure les transactions et de mener ce type d'attaques ?

C'est ici que les listes d'inclusion entrent en jeu.

Source: cet article ethresear.ch.

Les listes d'inclusion permettent aux proposants de blocs (c'est-à-dire, les validateurs) de choisir les transactions qui doivent être incluses dans le bloc. Les constructeurs peuvent toujours réorganiser les transactions ou insérer les leurs, mais ils doivent inclure les transactions du proposant. Finalement, les listes d'inclusion ont été modifiéespour contraindre le bloc suivant plutôt que le bloc actuel. Dans les deux cas, ils enlèvent la capacité du constructeur de pousser les transactions hors du bloc entièrement.

Ce qui précède était un véritable labyrinthe de contexte compliqué. Mais le MEV est un problème complexe ; même la description ci-dessus passe à côté de nombreuses nuances importantes. Comme le dit le vieil adage, “Vous ne cherchez peut-être pas le MEV, mais le MEV vous cherche”. Les chercheurs d'Ethereum sont déjà assez alignés sur l'objectif de “minimiser la boîte de quarantaine”, réduisant ainsi autant que possible les préjudices que les développeurs peuvent causer (par exemple, en excluant ou en retardant les transactions comme moyen d'attaquer des applications spécifiques).

Cela dit, je pense que nous pouvons aller encore plus loin. Historiquement, les listes d'inclusion ont souvent été conçues comme une fonctionnalité “à part, en cas de besoin”: normalement, on n'y pense pas, mais juste au cas où des développeurs malveillants commencent à faire des choses folles, elles vous offrent un “deuxième chemin”. Cette attitude se reflète dans les décisions de conception actuelles: dans le EIP actuel, la limite de gaz d'une liste d'inclusion est d'environ 2,1 million. Mais nous pouvons opérer un changement philosophique dans la façon dont nous pensons aux listes d'inclusion : considérons la liste d'inclusion comme étant le bloc, et considérons le rôle du constructeur comme étant une fonction annexe d'ajout de quelques transactions pour collecter MEV. Et si ce sont les constructeurs qui ont la limite de gaz de 2,1 million ?

Je pense que les idées dans cette direction - vraiment pousser la boîte de quarantaine à être aussi petite que possible - sont vraiment intéressantes, et je suis en faveur d’aller dans cette direction. Il s’agit d’un changement par rapport à la « philosophie de l’ère 2021 » : dans la philosophie de l’ère 2021, nous étions plus enthousiastes à l’idée que, puisque nous avons maintenant des constructeurs, nous pouvons « surcharger » leurs fonctionnalités et les faire servir les utilisateurs de manière plus compliquée, par exemple. en soutenant Marchés de frais ERC-4337. Dans cette nouvelle philosophie, les parties de validation des transactions de l'ERC-4337 devraient être consacrées dans le protocole. Heureusement, l'équipe ERC-4337 est déjà @yoavincreasingly warm about this direction.

Résumé : La réflexion sur la MEV a déjà commencé à renforcer le rôle des producteurs de blocs, notamment en donnant aux producteurs de blocs le pouvoir de garantir directement l'inclusion des transactions des utilisateurs. Les propositions d'abstraction de compte vont déjà dans le sens de la suppression de la dépendance aux relais centralisés, voire aux regroupeurs. Cependant, on peut soutenir valablement que nous n'allons pas assez loin, et je pense que la pression exercée sur le processus de développement pour aller plus loin dans cette direction est très bienvenue.

Staking liquide

Aujourd'hui, les validateurs solo représentent un pourcentage relativement faible de l'ensemble du jalonnement d'Ethereum, et la plupart du jalonnement est effectué par divers fournisseurs - certains opérateurs centralisés, et d'autres DAO, comme Lido et RocketPool.

J'ai fait mes propres recherches - divers sondages [1][2], des sondages, des conversations en personne, posant la question «pourquoi êtes-vous - spécifiquement vous - aujourd'hui pas en solo-staking?» Pour moi, un écosystème de solo-staking robuste est de loin mon résultat préféré pour la mise en jeu d'Éthereum, et l'une des meilleures choses à propos d'Éthereum est que nous essayons réellement de soutenir un écosystème de solo-staking robuste au lieu de simplement nous rendre à la délégation. Cependant, nous sommes loin de cet objectif. Dans mes sondages et enquêtes, quelques tendances cohérentes se dégagent :

1. La grande majorité des personnes qui ne font pas du solo-staking citent comme raison principale le minimum de 32 ETH.
2. Parmi ceux qui citent d'autres raisons, la plus haute est le défi technique de l'exécution et de la maintenance d'un nœud validateur.
3. La perte de disponibilité instantanée d'ETH, les risques de sécurité liés aux clés privées "chaudes" et la perte de capacité à participer simultanément aux protocoles de financement décentralisé, sont des préoccupations importantes mais moins importantes.

Les principales raisons pour lesquelles les gens ne participent pas seuls au jalonnement, selon les sondages de Farcaster.

Il y a deux questions clés pour la recherche sur le jalonnement à résoudre :

1. Comment résolvons-nous ces préoccupations?
2. Si, malgré des solutions efficaces à la plupart de ces préoccupations, la plupart des gens ne veulent toujours pas miser en solo, comment maintenir le protocole stable et robuste contre les attaques malgré ce fait ?

De nombreux éléments de recherche et développement en cours visent précisément à résoudre ces problèmes :

1. Verkle arbresplusEIP-4444permettre aux nœuds de mise en jeu de fonctionner avec des exigences de disque dur très faibles. De plus, ils permettent aux nœuds de mise en jeu de se synchroniser presque instantanément, simplifiant grandement le processus de configuration ainsi que les opérations telles que le passage d'une implémentation à une autre. Ils rendent également les clients légers Ethereum beaucoup plus viables, en réduisant la bande passante nécessaire pour fournir des preuves pour chaque accès à l'état.
2. Recherche(par exemple ces propositions)dans des moyens de permettre un ensemble de valdiateurs beaucoup plus grand (permettant des minimums de mise beaucoup plus petits) tout en réduisant en même temps les frais généraux des nœuds de consensus. Ces idées peuvent être mises en œuvre dans le cadre definalité d'un seul emplacement. Faire cela rendrait également les clients légers plus sûrs, car ils pourraient vérifier l'ensemble complet des signatures au lieu de compter sur comités de synchronisation).
3. Les optimisations continues du client Ethereum continuent de réduire le coût et la difficulté de l'exécution d'un nœud validateur, malgré l'augmentation de l'historique.
4. Recherche surplafonnement des pénalitéspourrait potentiellement atténuer les préoccupations concernant le risque de clé privée, et permettre aux validateurs de miser simultanément leur ETH dans les protocoles de defi s'ils le souhaitent.
5. 0x01 Identifiants de retraitpermettre aux stakers de définir une adresse ETH comme adresse de retrait. Cela rend les pools de mise décentralisés plus viables, leur donnant un avantage par rapport aux pools de mise centralisées.

Cependant, une fois de plus, il y a plus que nous pourrions faire. Il est théoriquement possible de permettre aux validateurs de retirer beaucoup plus rapidement : Casper FFG continue d'être sûr même si l'ensemble des validateurs change de quelques pour cent à chaque fois qu'il finalise (c'est-à-dire une fois par époque). Par conséquent, nous pourrions réduire beaucoup plus la période de retrait si nous y mettions du sien. Si nous voulions réduire considérablement la taille du dépôt minimum, nous pourrions prendre une décision difficile de faire des compromis dans d'autres directions, par exemple, si nous augmentons le temps de finalité de 4x, cela permettrait un @VitalikButerin/paramétriser-casper-le-compromis-décentralisation-temps-de-finalité-surcoût-3f2011672735">Diminution de la taille minimale du dépôt de 4x. La finalité d'un seul slot nettoierait plus tard cela en dépassant entièrement le modèle "chaque staker participe à chaque époque".

Une autre partie importante de toute cette question concerne l'économie du jalonnement. Une question clé est : voulons-nous que le jalonnement soit une activité relativement de niche, ou voulons-nous que tout le monde ou presque tout le monde mette en jeu tout leur ETH ? Si tout le monde participe au jalonnement, quelle est la responsabilité que nous voulons que tout le monde assume ? Si les gens finissent simplement par déléguer cette responsabilité parce qu'ils sont paresseux, cela pourrait conduire à la centralisation. Il y a ici des questions philosophiques importantes et profondes. Des réponses incorrectes pourraient entraîner Ethereum sur un chemin de centralisation et de « recréation du système financier traditionnel avec des étapes supplémentaires » ; des réponses correctes pourraient créer un exemple brillant d'un écosystème réussi avec un large éventail de jalonneurs solo et de pools de jalonnement hautement décentralisés. Ce sont des questions qui touchent aux économies et aux valeurs fondamentales d'Ethereum, nous avons donc besoin d'une participation plus diversifiée ici.

Exigences matérielles des nœuds

Beaucoup des questions clés de la décentralisation d'Ethereum finissent par se résumer à une question qui a défini la politique de la blockchainpendant une décennie: à quel point voulons-nous rendre l'exécution d'un nœud accessible, et comment ?

Aujourd'hui, exécuter un nœud est difficile. La plupart des gens ne le font pas. Sur l'ordinateur portable que j'utilise pour écrire ce message, j'ai un Éthernoeud, et il occupe 2,1 téraoctets - déjà le résultat d'un génie en génie logiciel et en optimisation. J'ai dû acheter un disque dur supplémentaire de 4 To à mettre dans mon ordinateur portable pour stocker ce nœud. Nous voulons tous que l'exécution d'un nœud soit plus facile. Dans mon monde idéal, les gens pourraient exécuter des nœuds sur leurs téléphones.

Comme je l'ai écrit ci-dessus, EIP-4444 et les arbres Verkle sont deux technologies clés qui nous rapprochent de cet idéal. Si les deux sont mis en œuvre, les exigences matérielles d'un nœud pourraient plausiblement diminuer à moins de cent gigaoctets, voire à près de zéro si nous éliminons entièrement la responsabilité de stockage de l'historique (peut-être uniquement pour les nœuds non-stakers).Type 1 ZK-EVMssupprimerait le besoin d'exécuter soi-même le calcul de l'EVM, car vous pourriez simplement vérifier une preuve que l'exécution était correcte. Dans mon monde idéal, nous empilerions toutes ces technologies ensemble, et même les portefeuilles d'extension de navigateur Ethereum (par exemple Metamask, Rabby) auraient un nœud intégré qui vérifie ces preuves, effectue un échantillonnage de disponibilité des données, et est satisfait que la chaîne est correcte.

La vision décrite ci-dessus est souvent appelée « The Verge ».

Tout cela est connu et compris, même par les personnes soulevant des préoccupations concernant la taille des nœuds Ethereum. Cependant, il y a une préoccupation importante : si nous déléguons la responsabilité de maintenir l'état et de fournir des preuves, n'est-ce pas un vecteur de centralisation ? Même s'ils ne peuvent pas tricher en fournissant des données invalides, cela ne va-t-il pas à l'encontre des principes d'Ethereum de devenir trop dépendant d'eux ?

Une version très proche à court terme de cette préoccupation est le malaise de nombreuses personnes à l'égard de l'EIP-4444 : si les nœuds Ethereum classiques n'ont plus besoin de stocker l'ancienne histoire, qui le fait ? Une réponse courante est : il y a certainement suffisamment de grands acteurs (par exemple, les explorateurs de blocs, les échanges, les couches 2) qui ont l'incitation à détenir ces données, et par rapport à les 100 pétaoctets stockés par la machine Wayback, la chaîne Ethereum est minuscule. Il est donc ridicule de penser que toute l'histoire sera réellement perdue.

Cependant, cet argument repose sur la dépendance à l'égard d'un petit nombre de grands acteurs. Dans mon taxonomie des modèles de confiance, c'est une hypothèse de 1-sur-N, mais le N est assez petit. Cela comporte ses risques résiduels. Une chose que nous pourrions faire à la place est de stocker l'ancien historique dans un réseau pair à pair, où chaque nœud ne stocke qu'un petit pourcentage des données. Ce type de réseau effectuerait quand même suffisamment de copies pour garantir la robustesse : il y aurait des milliers de copies de chaque donnée, et à l'avenir nous pourrions utiliser un codage par effacement (de manière réaliste, en mettant l'historique dans EIP-4844blobs de type (qui ont déjà un codage d'effacement intégré) pour augmenter encore la robustesse.

Les blobs ont un codage d'effacement à l'intérieur des blobs et entre les blobs. Le moyen le plus simple de créer un stockage ultra-robuste pour toute l'histoire de l'Éthereum pourrait bien être de simplement mettre des blocs de balise et d'exécution dans des blobs.Source de l'image : codex.storage

Depuis longtemps, ce travail a été relégué au second plan; Réseau de portailexiste, mais réaliste n'a pas obtenu le niveau d'attention proportionné à son importance dans l'avenir d'Ethereum. Heureusement, il y a maintenant un fort intérêt pour la dynamique visant à mettre beaucoup plus de ressources dans une version minimisée de Portal qui se concentre sur le stockage distribué, et l'accessibilité, de l'histoire. Cette dynamique devrait être développée, et nous devrions déployer des efforts concertés pour mettre en œuvre l'EIP-4444 bientôt, associée à un réseau pair-à-pair décentralisé robuste pour stocker et récupérer l'ancienne histoire.

Pour les états et les ZK-EVM, ce type d'approche distribuée est plus difficile. Pour construire un bloc efficace, il suffit d'avoir l'état complet. Dans ce cas, je préfère personnellement une approche pragmatique : nous définissons et nous en tenons à un certain niveau d'exigences matérielles nécessaires pour avoir un “nœud qui fait tout”, qui est supérieur au coût (idéalement décroissant) de simplement valider la chaîne, mais encore assez bas pour être abordable pour les amateurs. Nous nous appuyons sur une hypothèse de 1-sur-N, où nous nous assurons que le N est assez grand. Par exemple, il pourrait s'agir d'un ordinateur portable haut de gamme pour les consommateurs.

La preuve ZK-EVM est susceptible d'être la pièce la plus délicate, et les prouveurs ZK-EVM en temps réel sont susceptibles de nécessiter un matériel considérablement plus puissant qu'un nœud d'archive, même avec avancées comme Binius, et pire cas-limitant avecgaz multidimensionnel. Nous pourrions travailler dur sur un réseau de preuve distribué, où chaque nœud prend la responsabilité de prouver par exemple un pour cent de l'exécution d'un bloc, et ensuite le producteur de bloc n'a besoin d'agréger que les cent preuves à la fin. Les arbres d'agrégation de preuves pourraient aider davantage. Mais si cela ne fonctionne pas bien, alors un autre compromis serait d'autoriser les exigences matérielles de la preuve à augmenter, mais de s'assurer qu'un « nœud qui fait tout » peut vérifier les blocs Ethereum directement (sans preuve), assez rapidement pour participer efficacement au réseau.

Conclusions

Je pense que c'est en fait vrai que la pensée Ethereum de l'ère 2021 est devenue trop confortable avec le fait de décharger des responsabilités sur un petit nombre d'acteurs à grande échelle, tant qu'un certain type de mécanisme de marché ou de système de preuve de connaissance nulle existait pour forcer les acteurs centralisés à se comporter honnêtement. De tels systèmes fonctionnent souvent bien dans le cas moyen, mais échouent de manière catastrophique dans le pire des cas.

Nous ne faisons pas ça.

En même temps, je pense qu'il est important de souligner que les propositions actuelles de protocole Ethereum se sont déjà éloignées de ce genre de modèle de manière significative, et prennent beaucoup plus au sérieux le besoin d'un réseau vraiment décentralisé. Les idées autour des nœuds sans état, des atténuations de MEV, de la finalité d'un seul slot, et des concepts similaires, vont déjà beaucoup plus dans cette direction. Il y a un an, l'idée de réaliser un échantillonnage de la disponibilité des données en se greffant sur des relais en tant que nœuds semi-centralisés était sérieusement envisagée. Cette année, nous avons dépassé le besoin de faire de telles choses, avec des progrès étonnamment robustes surPeerDAS.

Mais il y a beaucoup que nous pourrions faire pour aller plus loin dans cette direction, sur les trois axes dont j'ai parlé ci-dessus, ainsi que sur de nombreux autres axes importants.Heliosa fait de grands progrès dans la fourniture à Ethereum d'un "client léger réel". Maintenant, nous devons le faire inclure par défaut dans les portefeuilles Ethereum, et faire en sorte que les fournisseurs RPC fournissent des preuves avec leurs résultats afin qu'ils puissent être validés, et étendre la technologie du client léger aux protocoles de couche 2. Si Ethereum évolue via une feuille de route centrée sur le rollup, les couches 2 doivent bénéficier des mêmes garanties de sécurité et de décentralisation que la couche 1. Dans un monde centré sur le rollup, il y a beaucoup d'autres choses auxquelles nous devrions accorder plus d'attention; les ponts décentralisés et efficaces entre les couches 2 sont un exemple parmi d'autres. De nombreux dapps obtiennent leurs journaux via des protocoles centralisés, car le balayage de journaux natif d'Ethereum est devenu trop lent. Nous pourrions améliorer cela avec un sous-protocole décentralisé dédié;@vbuterin/parallel_post_state_roots">voici une proposition de la mienne sur la façon dont cela pourrait être fait.

Il y a un nombre quasi illimité de projets blockchain visant la niche du "nous pouvons être ultra-rapides, nous réfléchirons à la décentralisation plus tard". Je ne pense pas qu'Ethereum devrait être l'un de ces projets. Ethereum L1 peut et doit certainement être une base solide pour les projets de couche 2 qui adoptent une approche hyper-évolutive, en utilisant Ethereum comme un socle pour la décentralisation et la sécurité. Même une approche centrée sur la couche 2 nécessite que la couche 1 elle-même ait une scalabilité suffisante pour gérer un nombre significatif d'opérations. Mais nous devrions avoir un profond respect pour les caractéristiques qui rendent Ethereum unique, et continuer à travailler pour maintenir et améliorer ces caractéristiques alors qu'Ethereum se développe.

Avertissement：

1. Cet article est repris de [[Vitalik Buterin]], Tous les droits d'auteur appartiennent à l'auteur original [Vitalik Buterin]. If there are objections to this reprint, please contact the Porte Apprendreéquipe, et ils s'en occuperont rapidement.
2. Clause de non-responsabilité : Les points de vue et opinions exprimés dans cet article sont uniquement ceux de l'auteur et ne constituent aucun conseil en investissement.
3. Les traductions de l'article dans d'autres langues sont effectuées par l'équipe Gate Learn. Sauf mention contraire, il est interdit de copier, distribuer ou plagier les articles traduits.