Intervenant : Vitalik Buterin, fondateur d'Ethereum Compilé par : 0xxz, Golden Finance EthCC7 s'est récemment tenu à Bruxelles. L'organisateur a invité Vitalik, fondateur d'Ethereum, à prononcer un discours. Il convient de noter que 2024 marque le 10e anniversaire de l’IC0 d’Ethereum. Après le discours de Vitalik, les trois principaux fondateurs d’Ethereum, Vitalik Buterin, Joseph Lubin et Gavin Wood, ont de nouveau pris une photo de groupe ensemble pour commémorer l’occasion. Cet article est le discours d'ouverture prononcé récemment par Vitalik, le fondateur d'Ethereum, à EthCC7, compilé par Golden Finance 0xxz. Renforcement du sujet vocal L1 : Optimisation d'Ethereum pour devenir une couche de base de couche 2 hautement fiable, digne de confiance et sans autorisation

Spectre de vision Ethereum
Je pense qu’il existe un éventail de divisions du travail possibles concernant le rôle que la couche de base d’Ethereum pourrait jouer dans l’écosystème au cours des cinq à dix prochaines années. Vous pouvez le considérer comme un spectre de gauche à droite. Sur le côté gauche du spectre, il s’agit essentiellement d’une couche de base très minimaliste qui agit simplement comme un validateur de preuves pour toutes les L2. Peut-être également fournir la possibilité de transférer des ETH entre différents L2. Mais à part ça, c'est essentiellement ça. Sur le côté droit du spectre, il y a essentiellement un recentrage sur les dApps qui s'exécutent principalement sur L1, L2 n'étant utilisé que pour certaines transactions très spécifiques et hautes performances. Il existe des options intéressantes au milieu du spectre. J'ai mis Ethereum comme couche de base de L2 seconde en partant de la gauche. J'ai mis une version extrême à l'extrême gauche. La version extrême est que nous abandonnons complètement la partie client d'exécution d'Ethereum, ne conservons que la partie consensus et ajoutons des validateurs de preuve sans connaissance, transformant essentiellement toute la couche d'exécution en un Rollup. Je veux dire que les options les plus extrêmes sont à gauche, et à droite, cela pourrait être une couche de base, mais essayez également de donner plus de fonctionnalités à L2. Une idée dans ce sens est de réduire davantage le temps d’échange d’Ethereum, actuellement de 12 secondes, éventuellement jusqu’à 2 à 4 secondes. Le but est en fait de rendre les cumuls basés possibles comme principal moyen de fonctionnement L2. Alors maintenant, si vous souhaitez que L2 ait une expérience utilisateur de premier ordre, vous devez disposer de votre propre pré-validation, ce qui signifie soit un trieur centralisé, soit votre propre trieur décentralisé. Si leur consensus s’accélère, la L2 n’aura plus besoin de le faire. Si vous souhaitez réellement augmenter l’évolutivité de L1, le besoin de L2 sera également réduit. C'est donc un spectre. Pour le moment, je me concentre principalement sur la version deux en partant de la gauche, mais les choses que je suggère ici s'appliquent également à d'autres visions, et les conseils ici ne gênent pas réellement les autres visions. C’est quelque chose qui me semble très important. L’avantage de robustesse d’Ethereum
Un gros avantage d’Ethereum est qu’il dispose d’un écosystème de jalonnement vaste et relativement décentralisé.

Le côté gauche de l’image ci-dessus est le graphique des taux de hachage de tous les pools miniers Bitcoin, et le côté droit est le graphique des jalonneurs Ethereum. La répartition de la puissance de calcul de Bitcoin n’est actuellement pas très bonne. Deux pools de minage totalisent plus de 50 % de la puissance de calcul, et quatre pools de minage totalisent plus de 75 %. Et la situation d'Ethereum est en fait meilleure que ce que montre le graphique, car la deuxième grande partie de la partie grise n'est en réalité pas identifiée, ce qui signifie qu'il peut s'agir d'une combinaison de nombreuses personnes, et qu'il peut même y avoir de nombreux acteurs indépendants. Le Lido bleu est en réalité une étrange structure, peu coordonnée, composée de 37 validateurs différents. Ainsi, Ethereum dispose en fait d’un écosystème de jalonnement relativement décentralisé qui fonctionne plutôt bien. Nous pouvons apporter de nombreuses améliorations dans ce domaine, mais je pense qu’il est toujours utile de le reconnaître. C'est l'un des avantages uniques sur lesquels nous pouvons vraiment nous appuyer.

Les avantages de robustesse d'Ethereum incluent également : ● Disposer d'un écosystème multi-clients : il existe des clients d'exécution Geth et des clients d'exécution non-Geth, et la proportion de clients d'exécution non-Geth dépasse même celle des clients d'exécution Geth. Une situation similaire se produit également dans le système client consensuel ; ● Communauté internationale : les gens sont dans de nombreux pays différents, y compris les projets, L2, équipes, etc. ● Écosystème de connaissances multicentrique : il y a la Fondation Ethereum et il y a les équipes clients ; même des équipes comme l'équipe Reth de Paradigm ont récemment accru leur leadership dans l'open source ; une culture qui valorise ces attributs. Par conséquent, l'écosystème Ethereum en tant que couche de base présente déjà ces avantages très puissants. Je pense que c'est quelque chose de très précieux et qu'il ne faut pas l'abandonner facilement. J’irais jusqu’à dire que des mesures claires peuvent être prises pour renforcer ces atouts et même remédier à nos faiblesses. Où Ethereum L1 ne répond-il pas à des normes élevées ? Comment peut-il être amélioré ?
Voici un sondage que j'ai réalisé sur Farcaster il y a environ six mois : si vous n'effectuez pas de jalonnement en Solo, qu'est-ce qui vous empêche de jalonner en Solo ? Je peux répéter la question dans cette salle, qui fait le staking Solo ? Sans Staking Solo, lequel d'entre vous estime que le seuil de 32 ETH est le plus gros obstacle, qui estime que gérer un nœud est trop difficile est le plus gros obstacle, et qui estime que le plus gros obstacle est de ne pas pouvoir investir son ETH dans un Protocole DeFi en même temps ? Qui pense que le plus gros obstacle est la peur de devoir placer des clés privées sur un nœud en cours d’exécution où elles peuvent être plus facilement volées ? On peut voir que les deux principaux obstacles convenus sont : l’exigence minimale de 32 ETH et la difficulté de fonctionnement du nœud. Il est toujours important de s'en rendre compte. Souvent, lorsque nous commençons à chercher comment maximiser la capacité des gens à double usage de leurs garanties dans les protocoles DeFi, nous constatons qu'un grand nombre de personnes n'utilisent même pas du tout les protocoles DeFi. Concentrons-nous donc sur les principaux problèmes et sur ce que nous pouvons faire pour tenter de les résoudre. Commencez par exécuter un nœud de validation, ou en d’autres termes, à partir du seuil de 32 ETH. En fait, ces deux questions sont liées car elles sont toutes deux fonction du nombre de validateurs dans la preuve d’enjeu d’Ethereum. Aujourd'hui, nous avons environ 1 million d'entités de validation, chacune avec 32 ETH en dépôt, donc si l'exigence minimale était modifiée à 4 ETH, nous aurions alors 8 millions ou peut-être plus de 8 millions, peut-être 9 millions ou 10 millions de validateurs. Si nous voulions descendre à 100 000 validateurs, l’exigence minimale s’élèverait probablement à environ 300 ETH. C'est donc un compromis. Ethereum a toujours essayé de se situer au milieu du compromis. Cependant, si nous pouvons trouver des moyens de l'améliorer, nous aurons alors des points de statistiques supplémentaires que nous pourrons éventuellement utiliser pour réduire les exigences minimales ou pour faciliter l'exécution d'un nœud. En fait, je pense maintenant que l'agrégation des signatures n'est même pas la principale difficulté du fonctionnement d'un nœud. Au début, nous pourrions nous concentrer davantage sur la réduction des exigences minimales, mais à terme, cela impliquera les deux. Il existe donc deux techniques qui peuvent améliorer ces deux aspects. Une technique consiste à autoriser le jalonnement ou à permettre la finalité sans exiger que chaque validateur signe.Fondamentalement, vous avez besoin d’une sorte d’échantillonnage aléatoire d’un nombre suffisant de nœuds pour obtenir une sécurité économique significative. À l’heure actuelle, je pense que nous disposons d’une sécurité économique plus que suffisante. Le coût d’une attaque à 51 %, en termes de quantité d’ETH réduite, est d’un tiers de 32 millions d’ETH, soit environ 11 millions d’ETH. Qui dépenserait 11 millions d’ETH pour casser la blockchain Ethereum. Personne, pas même le gouvernement américain, ne le souhaite. Ces techniques d'échantillonnage sont similaires à ce qui se passerait si vous aviez une maison et que la porte d'entrée était protégée par quatre couches d'acier, mais que la fenêtre n'était qu'un morceau de verre de mauvaise qualité que quelqu'un pourrait facilement briser avec une batte de baseball. Je pense qu'Ethereum est comme ça dans une certaine mesure, si vous voulez faire une attaque à 51%, vous devez perdre 11 millions d'ETH. Mais en réalité, il existe de nombreuses autres façons d’attaquer le protocole, et nous devrions vraiment renforcer davantage ces défenses. Ainsi, si vous disposez d’un sous-ensemble de validateurs effectuant la finalité, le protocole est toujours suffisamment sécurisé et vous pouvez réellement augmenter le niveau de décentralisation. La deuxième technique est une meilleure agrégation des signatures. Vous pourriez faire quelque chose d'avancé comme Starks, et au lieu de prendre en charge 30 000 signatures par emplacement, nous pourrions éventuellement prendre en charge davantage de signatures. C'est la première partie. La deuxième partie consiste à faciliter l'exécution des nœuds. La première étape est l'expiration de l'historique. En fait, avec l'EIP-4444, de nombreux progrès ont été réalisés à cet égard. La deuxième étape est le client apatride. Verkle existe depuis longtemps, une autre option possible consiste à créer un arbre de hachage binaire comme Poséidon, une fonction de hachage conviviale pour Stark. Une fois que vous l’avez, pour vérifier les blocs Ethereum, vous n’avez plus besoin de disque dur. Vous pouvez également ajouter ultérieurement un ZKVM de type 1 qui permet à Stark de vérifier des blocs Ethereum entiers, de sorte que vous puissiez vérifier des blocs Ethereum arbitrairement grands en téléchargeant des données, ou même des données d'échantillonnage de disponibilité des données, et vous n'avez alors qu'à vérifier une seule preuve. Si vous faites cela, l’exécution du nœud deviendra plus facile. L'une des choses les plus ennuyeuses actuellement avec les clients sans état est que si vous souhaitez modifier les paramètres matériels ou logiciels, vous devez généralement soit repartir de zéro et perdre une journée, soit faire quelque chose de très dangereux et mettre les clés en deux. sera Slashed quelque part, et si nous avons un client apatride, vous n'avez plus besoin de le faire. Vous pouvez simplement démarrer un nouveau client autonome, fermer l'ancien, déplacer les clés et démarrer le nouveau. Vous ne perdez qu’une époque. Une fois que vous disposez de ZKVM, la configuration matérielle requise tombe pratiquement à zéro. Par conséquent, les deux problèmes, le seuil de 32 ETH et la difficulté d’exécution des nœuds, peuvent être techniquement résolus. Je pense qu'il y a beaucoup d'autres avantages à faire cela, cela améliorera vraiment notre capacité à augmenter le staking individuel des gens, cela nous donnera un meilleur écosystème de staking individuel et évitera les risques de centralisation du staking. La preuve de participation présente d'autres défis, tels que les risques liés au staking liquide et les risques liés au MEV. Ce sont également des questions importantes qu’il convient de continuer à considérer. Nos chercheurs y réfléchissent. Récupérez après 51 % d'attaque
J’ai vraiment commencé à réfléchir sérieusement et rigoureusement. Il est surprenant de voir combien de personnes ne pensent pas du tout à ce sujet et le traitent simplement comme une boîte noire. Que se passera-t-il si nous sommes effectivement confrontés à une attaque à 51 % ? Ethereum peut faire face à une attaque à 51 %, Bitcoin peut faire face à une attaque à 51 %, et un gouvernement peut également faire face à une attaque à 51 %, par exemple en achetant 51 % des politiciens. Un problème est que vous ne voulez pas vous fier uniquement à la prévention, vous voulez également avoir un plan de rétablissement. Une idée fausse très répandue est que les gens pensent que 51 % des attaques visent à renverser la finalité. Les gens y prêtent attention car c’est ce que Satoshi Nakamoto a souligné dans le livre blanc. Vous pouvez doubler vos dépenses, après avoir acheté un jet privé, j'ai mené une attaque à 51 %, j'ai récupéré mes bitcoins, j'ai également gardé mon jet privé et j'ai volé. Une attaque plus réaliste pourrait impliquer d’effectuer des dépôts sur des bourses et des choses comme compromettre les protocoles DeFi. Mais le renversement n’est pas vraiment la pire des choses. Le plus grand risque dont nous devrions nous inquiéter est en réalité la censure. 51 % des nœuds ont cessé d'accepter les blocs des 49 % restants ou de tout nœud essayant de contenir un certain type de transaction. Pourquoi est-ce le plus grand risque ? Parce que l'inversion de finalité a Slash, il existe une preuve vérifiable immédiate sur la chaîne qu'au moins un tiers des nœuds ont fait quelque chose de très, très mal et qu'ils ont été punis. Et dans une attaque de censure, ce n'est pas attribuable à la procédure, il n'y a aucune preuve procédurale immédiate permettant de dire qui a fait quelque chose de mal. Maintenant, si vous êtes un nœud en ligne, si vous voulez voir qu'une certaine transaction n'a pas été incluse dans 100 blocs, mais que nous n'avons même pas de logiciel écrit pour effectuer cette vérification, un autre défi avec l'examen est de savoir si quelqu'un veut aux attaques, ils peuvent le faire, ils commencent par retarder les transactions et les blocages qu'ils n'aiment pas pendant 30 secondes, puis les retardent d'une minute, puis les retardent de deux minutes, et vous n'avez même pas de consensus sur le moment où répondre . Donc, dis-je, la censure représente en réalité le plus grand risque. Il existe un argument dans la culture blockchain selon lequel si une attaque se produit, la communauté s'unira et fera évidemment quelques soft forks et éliminera les attaquants. Cela est peut-être vrai aujourd’hui, mais cela repose sur de nombreuses hypothèses concernant la coordination, l’idéologie et toutes sortes d’autres choses, et on ne sait pas exactement dans quelle mesure une telle chose sera vraie dans 10 ans. Donc, ce que beaucoup d’autres communautés blockchain commencent à faire, disent-elles, c’est que nous avons des choses comme la censure, nous avons ces erreurs qui sont de nature plus non imputable. Nous devons donc nous appuyer sur le consensus social. Alors comptons uniquement sur le consensus social et soyons fiers d’admettre que nous l’utiliserons pour résoudre nos problèmes. En fait, je préconise d’aller dans la direction opposée. Nous savons qu’il est mathématiquement impossible de coordonner entièrement les réponses automatisées et de cibler automatiquement la majorité des attaquants examinés. Mais nous pouvons nous en rapprocher le plus possible. Vous pouvez créer un fork qui met réellement en ligne au moins une majorité de nœuds sur la base de certaines hypothèses concernant les conditions du réseau. L'argument que j'essaie de faire valoir ici est que ce que nous voulons en réalité, c'est essayer de rendre la réponse à une attaque à 51 % aussi automatisée que possible. Si vous êtes un validateur, votre nœud doit exécuter un logiciel qui, s'il détecte des transactions censurées ou certains validateurs censurés, décensurera automatiquement la majorité de la chaîne et tous les nœuds honnêtes le feront automatiquement en raison de leur Le code en cours d'exécution est coordonné sur les mêmes quelques fourchettes souples. Bien sûr, là encore, il y a un résultat mathématiquement impossible : au moins, quiconque hors ligne à ce moment-là ne serait pas en mesure de dire qui avait raison et qui avait tort. Il existe de nombreuses limites, mais plus on se rapproche de cet objectif, moins le consensus social a besoin de travail. Si vous imaginez ce qui se produit réellement, une attaque à 51 %. Ce ne sera pas comme si, ci-dessous, tout d'un coup, à un moment donné, Lido, Coinbase et Kraken allaient publier un article de blog à 17 h 46 disant essentiellement, hé les gars, nous faisons une revue maintenant. Ce qui pourrait réellement arriver, c’est que vous assisterez en même temps à une guerre sur les réseaux sociaux et à toutes sortes d’autres attaques en même temps. Si effectivement une attaque à 51 % se produit, en passant, je veux dire, nous ne devrions pas supposer que Lido, Coinbase et Kraken seront au pouvoir dans 10 ans. L’écosystème Ethereum deviendra de plus en plus courant et devra être hautement adaptable à cela.Nous voulons que la charge sur la couche sociale soit aussi légère que possible, ce qui signifie que nous avons besoin que la couche technique présente au moins un candidat clairement gagnant, et s'ils veulent sortir d'une chaîne en cours d'examen, ils devraient se rallier. autour d'une poignée de fourchettes souples supérieures. Je préconise que nous fassions davantage de recherches et que nous fassions une recommandation très précise. Proposition : Augmenter le seuil de quorum à 75 % ou 80 %
Je pense que le seuil de quorum (Remarque : le mécanisme de quorum est un algorithme de vote couramment utilisé dans les systèmes distribués pour garantir la redondance des données et leur cohérence éventuelle) peut être augmenté des deux tiers aujourd'hui à 75 % ou 80 % environ. L’argument de base est que si une chaîne malveillante telle qu’une chaîne de censure attaque, la récupération deviendra très, très difficile. Mais en revanche, si vous augmentez la proportion de Quorum, quels sont les risques ? Si le quorum est de 80 %, alors au lieu de 34 % des nœuds se déconnectant et arrêtant la finalité, ce serait 21 % des nœuds se déconnectant arrêtant la finalité. C'est risqué. Voyons à quoi cela ressemble en pratique ? D'après ce que j'ai compris, je pense que la finalité n'a été bloquée qu'une seule fois pendant environ une heure car plus d'un tiers des nœuds étaient hors ligne. Et puis, y a-t-il eu des incidents où 20 à 33 % des nœuds étaient hors ligne ? Je pense une fois au plus et zéro fois au moins. Étant donné qu'en pratique, très peu de validateurs se déconnectent, je pense en fait que le risque de le faire est assez faible. Les avantages sont essentiellement que la barre qu'un attaquant doit atteindre est considérablement augmentée, et que la gamme de scénarios dans lesquels la chaîne passe en mode sans échec en cas de vulnérabilité côté client est considérablement augmentée, de sorte que les gens peuvent réellement collaborer pour déterminer ce qui se passe. s'est mal passé. Si le seuil de quorum augmente de 67 % à 80 %, alors en supposant que la proportion qu'un client doit atteindre augmente de 67 % à 80 %, alors la valeur d'un petit nombre de clients, ou la valeur qu'un petit nombre de les clients peuvent fournir, commence vraiment à augmenter. Autres problèmes de censure D'autres problèmes de censure concernent soit les listes d'inclusion, soit une alternative aux listes d'inclusion. Ainsi, toute cette histoire de propositions multi-parallèles, si elle fonctionne, pourrait même remplacer les listes d'inclusion. Vous avez besoin, soit d'une abstraction de compte, soit d'une abstraction de compte dans une sorte de protocole. La raison pour laquelle vous en avez besoin est qu’à l’heure actuelle, les portefeuilles de contrats intelligents ne bénéficient pas vraiment des listes d’inclusion. Les portefeuilles de contrats intelligents ne bénéficient pas vraiment d’une quelconque garantie de résistance à la censure au niveau de la couche protocolaire. Ils bénéficieraient d’une abstraction des comptes dans le protocole. Donc, il y a beaucoup de choses, en fait beaucoup de ces choses sont précieuses dans la vision du centre L2 et dans la vision du centre L1. Parmi les différentes idées dont j'ai discuté, environ la moitié concernent probablement spécifiquement les solutions L2 pour Ethereum, mais l'autre moitié est essentiellement applicable aux utilisateurs d'Ethereum avec L2 comme couche de base et L1, ou des applications directes à l'utilisateur. Utilisez des clients légers n’importe où À bien des égards, c'est un peu triste la façon dont nous interagissons avec l'industrie, nous sommes décentralisés, nous ne faisons pas confiance, qui dans cette salle exécute un client léger sur son ordinateur qui valide le consensus ? rare. Qui utilise Ethereum en faisant confiance au portefeuille du navigateur d’Infura ? Dans cinq ans, j’aimerais voir le nombre de mains levées s’inverser. J'aimerais voir des portefeuilles qui ne font confiance à Infura pour rien. Nous devons intégrer des clients légers. Infura peut continuer à fournir des données. Je veux dire, c'est en fait bien pour Infura si vous n'avez pas besoin de faire confiance à Infura, car cela leur permet de créer et de déployer plus facilement une infrastructure, mais nous disposons d'outils pour supprimer l'exigence de confiance. Ce que nous pouvons faire, c'est avoir un système dans lequel l'utilisateur final exécute quelque chose comme un client léger Helios. Il devrait en fait s’exécuter directement dans le navigateur, validant directement le consensus Ethereum. S'il veut vérifier quelque chose sur la chaîne, comme interagir avec la chaîne, alors il vous suffit de vérifier directement la preuve Merkle. Si vous faites cela, vous gagnerez en fait un certain degré de manque de confiance dans vos interactions avec Ethereum. C'est pour la L1. De plus, nous avons besoin d’un schéma équivalent pour L2. Sur la chaîne L1, il y a des en-têtes de bloc, des états, des comités de synchronisation et un consensus. Si vous vérifiez le consensus, si vous savez quel est l'en-tête du bloc, vous pouvez parcourir la branche Merkle et voir quel est l'état. Alors, comment pouvons-nous fournir des garanties légères de sécurité aux clients pour les L2 ? La racine d'état de L2 est là. Si elle est basée sur Rollup, il existe un contrat intelligent, et ce contrat intelligent stocke l'en-tête de bloc de L2. Ou, si vous avez une pré-confirmation, vous disposez d'un contrat intelligent qui stocke l'identité de la pré-confirmation, vous déterminez donc qui est la pré-confirmation, puis écoutez un sous-ensemble des deux tiers de leurs signatures. Ainsi, une fois que vous avez l’en-tête du bloc Ethereum, vous disposez d’une chaîne de confiance assez simple, le hachage, la branche Merkle et la signature, que vous pouvez vérifier, et vous pouvez obtenir une vérification légère du client. Il en va de même pour n’importe quelle L2. J’en ai parlé aux gens dans le passé, et souvent la réponse est : Oh mon Dieu, c’est intéressant, mais à quoi ça sert ?Une grande partie de L2 est multi-signature. Pourquoi ne faisons-nous pas confiance aux multi-signatures pour vérifier les multi-signatures ? Heureusement, depuis l’année dernière, ce n’est plus le cas. Optimism et Arbitrum sont dans la première phase de Rollup, ce qui signifie qu'ils disposent en fait de systèmes de preuve fonctionnant sur la chaîne et d'un comité de sécurité qui peut les couvrir en cas de vulnérabilité, mais le comité de sécurité doit franchir un seuil de vote très élevé. , disons 75% de 8 personnes, la taille de l'Arbitrum passera à 15 personnes. Ainsi, dans le cas d'Optimism et d'Arbitrum, ils ne sont pas seulement multisigs, ils ont de véritables systèmes de preuve, et ces systèmes de preuve ont en fait un rôle, au moins en termes d'avoir la majorité du pouvoir pour décider quelle chaîne est correcte ou fausse. . EVM va encore plus loin, je crois qu'il n'a même pas de comité de sécurité, donc c'est complètement dénué de confiance. Nous commençons vraiment à avancer dans ce domaine, et je sais que beaucoup d’autres L2 progressent également. L2 est donc plus qu'un simple multisig, donc le concept de clients légers pour L2 commence à prendre tout son sens. Aujourd'hui, nous pouvons déjà vérifier la branche Merkle, il suffit d'écrire le code. Demain, nous pourrons également valider ZKVM, afin que vous puissiez valider entièrement Ethereum et L2 dans le portefeuille de votre navigateur. Qui veut être un utilisateur Ethereum sans confiance dans un portefeuille de navigateur ? merveilleux. Qui préférerait être un utilisateur d’Ethereum sans confiance sur son téléphone mobile ? Qu'en est-il d'un Raspberry Pi ? Qu'en est-il d'une montre intelligente ? De la station spatiale ? Nous allons résoudre ce problème également. Nous avons donc besoin de l'équivalent d'une configuration RPC qui contient non seulement les serveurs avec lesquels vous parlez, mais également les instructions d'authentification du client léger. C’est quelque chose sur lequel nous pouvons travailler. Stratégie anti-quantique
Le temps nécessaire à l’informatique quantique se raccourcit. Metaculous pense que les ordinateurs quantiques arriveront au début des années 2030, et certains pensent plus tôt. Nous avons donc besoin d’une stratégie de résistance quantique. Nous avons une stratégie de résistance quantique. Il existe quatre parties d’Ethereum qui sont vulnérables à l’informatique quantique, et chacune propose des alternatives naturelles. L'alternative résistante quantique à Verkle Tree est Starked Poseidon Hash, ou si nous voulons être plus conservateurs, nous pouvons utiliser la signature consensuelle de Blake, nous utilisons actuellement la signature globale BLS, qui peut être remplacée par la signature globale Stark. Blob utilise KZG, qui peut être prouvé à l'aide d'arbres Merkle Stark codés par séparation. Les comptes d'utilisateurs utilisent actuellement ECDSA SECP256K1, qui peut être remplacé par des signatures basées sur le hachage, ainsi que par l'abstraction et l'agrégation de comptes, des portefeuilles de contrats intelligents ERC 4337, etc. Une fois que vous disposez de cela, l'utilisateur peut configurer son propre algorithme de signature, en utilisant essentiellement une signature basée sur le hachage. Je pense que nous devons vraiment commencer à réfléchir à la création de signatures basées sur le hachage afin que les portefeuilles des utilisateurs puissent facilement passer aux signatures basées sur le hachage. Simplification du protocole Si vous souhaitez une couche de base robuste, le protocole doit être simple. Il ne devrait pas avoir 73 hooks aléatoires et une certaine compatibilité ascendante qui existe à cause d'une idée stupide et aléatoire qu'un type aléatoire nommé Vitalik a eue en 2014. Il est donc utile d’essayer de vraiment simplifier et de commencer à réellement éliminer la dette technique. Les journaux sont actuellement basés sur des filtres Bloom, qui ne fonctionnent pas bien et ne sont pas assez rapides. Des améliorations des journaux sont donc nécessaires pour ajouter une immuabilité plus forte, ce que nous faisons déjà du côté sans état, limitant essentiellement l'état de chaque bloc de vues. Ethereum est une collection incroyable en ce moment, il y a RLP, il y a SSZ, il y a API, et idéalement nous devrions simplement utiliser SSZ, mais au moins nous débarrasser de RLP, de l'état et de l'arbre binaire Merkle, une fois que vous avez l'arbre binaire Merkle, alors tout Ethereum est sur un arbre Merkle binaire. Fast Finality, Single Slot Finality (SSF), nettoie les précompilateurs inutilisés, comme le précompilateur ModX, qui provoque souvent des erreurs de consensus, ce serait bien si nous pouvions le supprimer et le remplacer par du code de solidité haute performance. Résumer En tant que couche de base robuste, Ethereum présente des avantages tout à fait uniques, y compris certains que Bitcoin ne possède pas, tels que la décentralisation consensuelle et des recherches approfondies sur la récupération après attaque de 51 %. Je pense qu’il est nécessaire de vraiment renforcer ces atouts. Reconnaissez et corrigez également nos lacunes pour garantir que nous répondons à des normes très élevées. Ces idées sont entièrement compatibles avec une feuille de route L1 agressive. L’une des choses dont je suis le plus satisfait à propos d’Ethereum, en particulier du processus de développement de base, est que notre capacité à travailler en parallèle s’est considérablement améliorée. C'est un point fort, on peut effectivement travailler sur beaucoup de choses en parallèle. Se soucier de ces sujets n’a donc pas réellement d’impact sur la capacité à améliorer l’écosystème L1 et L2. Par exemple, améliorer l'EVM L1 pour faciliter la cryptographie. La validation des hachages Poséidon dans l'EVM est actuellement trop coûteuse. La cryptographie 384 bits est également trop coûteuse. Il y a donc quelques idées en plus d'EOF, telles que les opcodes SIMD, EVM max, etc. Il existe une possibilité de connecter ce coprocesseur hautes performances à l'EVM. C'est mieux pour la couche 2 car la vérification des preuves peut être moins coûteuse, et mieux pour les applications de couche 1 car les protocoles de confidentialité comme les zk SNARK sont moins chers. Qui a utilisé l'accord de confidentialité ? Qui veut payer des frais de 40 $ au lieu de 80 $ ? De plus en plus de gens choisiront le premier. Un deuxième groupe d'utilisateurs peut effectuer des transactions sur la couche 2, tandis que la couche 1 peut réduire considérablement les coûts. ​