Compilé par : 0xxz, Golden Finance

EthCC7 s'est récemment tenu à Bruxelles et les organisateurs ont invité Vitalik, le fondateur d'Ethereum, à prononcer un discours d'ouverture.

Il convient de noter que 2024 marque le 10e anniversaire d’Ethereum ICO. Après le discours de Vitalik, les trois anciens 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.

le sujet du discours

Renforcement de 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 vérificateur de preuves pour tous 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 dApp fonctionnant 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 sur la deuxième 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 très 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 de rendre les cumuls de base viables comme principal moyen de fonctionnement de L2. Alors maintenant, si vous souhaitez que L2 ait une expérience utilisateur de premier ordre, vous devez avoir votre propre pré-confirmation, 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 améliorer 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 un graphique de la puissance de calcul de tous les pools miniers Bitcoin, et le côté droit est un graphique des jalonneurs d’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 réalité 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 intervenants indépendants. La partie bleue, Lido, 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 :

Il dispose d'un écosystème multi-clients : il existe des clients d'exécution Geth et des clients d'exécution non-Geth. 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 dans les systèmes clients de consensus ;

Communauté internationale : personnes dans de nombreux pays différents, y compris les projets, les L2, les équipes, etc. ;

Écosystème de connaissances multicentrique : il y a la Fondation Ethereum, il y a l'équipe client, et même l'équipe Reth de Paradigm a récemment accru son leadership dans l'open source ;

Des cultures qui valorisent ces attributs

Ainsi, 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 qu’il existe des mesures claires qui 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 et 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 pense que le plus gros obstacle est que vous ne pouvez pas investir votre ETH dans la DeFi protocole 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 unanimement reconnus sont : l’exigence minimale de 32 ETH et la difficulté de fonctionnement des nœuds. Il est toujours important de s'en rendre compte.

Souvent, lorsque nous commençons à réfléchir à la manière de 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 un dépôt de 32 ETH, 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 voulons le réduire à 100 000 validateurs, alors l’exigence minimale devra peut-être s’élever à 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 consisterait à 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 %, calculé 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 détruire la blockchain Ethereum. Personne, pas même le gouvernement américain, ne le souhaite.

Ces techniques d'échantillonnage sont similaires à celles d'une maison dont la porte d'entrée était protégée par quatre couches d'acier, mais 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 facilite l'exécution des nœuds.

La première étape est l'expiration de l'historique. En fait, avec EIP-4444, de nombreux progrès ont été réalisés dans ce domaine.

La deuxième étape est le client apatride. Verkle existe depuis longtemps, une autre option possible consiste à créer un arbre de hachage binaire similaire à Poséidon, une fonction de hachage compatible avec Stark. Une fois que vous l’avez, pour vérifier les blocs Ethereum, vous n’avez plus besoin de disque dur. Vous pouvez ensuite ajouter un ZKVM de type 1 qui permet à Stark de vérifier l'intégralité du bloc Ethereum, 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. ce serait un slah, si nous avons des clients apatrides, vous n'avez plus besoin de faire cela.

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, le seuil de 32 ETH et la difficulté de fonctionnement du nœud peuvent être résolus techniquement. 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 jalonnement de liquidité et les risques liés au MEV. Ce sont également des questions importantes à continuer de 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 réellement confrontés à une attaque à 51 % ?

Ethereum peut subir une attaque à 51 %, Bitcoin peut subir une attaque à 51 %, et un gouvernement peut également subir une attaque à 51 %, comme l'achat de 51 % de 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é mon jet privé, j'ai mené une attaque à 51 %, j'ai récupéré mes bitcoins et j'ai pu garder mon jet privé et voler.

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 un 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 gros risque ? Parce que l'inversion de finalité a Slash, il existe des preuves vérifiables immédiates sur la chaîne qu'au moins un tiers des nœuds ont fait quelque chose de très, très mal, et 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 écrit de logiciel pour effectuer cette vérification,

Un autre défi de la censure est que si quelqu'un veut attaquer, il peut le faire en retardant les transactions et les blocages qu'il n'aime pas pendant 30 secondes, puis en les retardant d'une minute, puis en les retardant de deux minutes, et vous ne le faites même pas. avoir un consensus sur le moment où répondre.

Donc, dis-je, en réalité, la censure représente le plus grand risque.

Il existe un argument dans la culture blockchain selon lequel s’il y a une attaque, 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 rassemble au moins une majorité de nœuds en ligne sur la base de certaines hypothèses concernant les conditions du réseau. L'argument que j'essaie de transmettre 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, encore une fois, le résultat est mathématiquement impossible : au moins, quiconque était 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 devient 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 sont 21 % des nœuds se déconnectant arrêtant la finalité.

Il y a des risques. 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 des incidents où 20 à 33 % des nœuds sont 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 de la liste 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.

Je pense que parmi les différentes idées dont j'ai parlé, environ la moitié étaient probablement spécifiquement destinées à Ethereum et axées sur L2, mais l'autre moitié était essentiellement destinée à L2 comme couche de base pour les utilisateurs d'Ethereum et L1, ou, comme, directement pour les applications des utilisateurs. utilisateur.

Utilisez des clients légers partout

À bien des égards, c'est un peu triste la façon dont nous interagissons avec l'espace, 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, si vous n'avez pas besoin de faire confiance à Infura, c'est en fait une bonne chose pour 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 également besoin d’une solution équivalente 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à. S'il s'agit d'un Rollup de base, 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, il existe 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é à des 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 en sont à la première étape du 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é. , comme 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égies de résistance quantique

Le temps nécessaire à l’informatique quantique diminue. 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.

Une alternative résistante quantique à Verkle Tree est Starked Poseidon Hash, ou si nous voulons être plus conservateurs, nous pouvons utiliser les signatures consensuelles de Blake, nous utilisons actuellement les signatures globales BLS, qui peuvent être remplacées par les signatures globales Stark. Blob utilise KZG et peut être prouvé en utilisant un codage séparé de l'arbre Merkle Stark. 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 les disposez, 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 la feuille de route agressive de la L1.

L’une des choses dont je suis le plus satisfait à propos d’Ethereum et du processus de développement de base en particulier 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’affecte donc pas réellement la capacité à améliorer l’écosystème L1 et L2. Par exemple, améliorer l'EVM L1 pour faciliter la cryptographie. Actuellement, il est trop coûteux de vérifier les hachages Poséidon dans l'EVM. 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 ils peuvent vérifier les preuves à moindre coût, 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 40 frais au lieu de 80 frais avec un accord de confidentialité ? plus de gens. Le deuxième groupe peut être utilisé sur la couche 2 et la couche 1 peut permettre de réaliser des économies significatives.

Les « Trois Grands » d’Ethereum se réunissent

2024 marque le 10e anniversaire d'Ethereum IC0. L'EthCC 2024 a invité les trois anciens fondateurs principaux d'Ethereum, Vitalik Buterin, Joseph Lubin et Gavin Wood, à assister à la réunion.

Après le discours de Vitalik, ils ont été invités à prendre une photo de groupe ensemble :

Les Trois Grands se serrent à nouveau la main