Ethereum Beast Mode - Scaling L1 to 10k and Beyond | Justin Drake

Ryan :
[0:02] Justin, qu'est-ce que le lean Ethereum au plus haut niveau ?

Justin ou David :
[0:07] Bien sûr. Le lean Ethereum, c'est la conviction que nous pouvons utiliser cette technologie très puissante appelée SNARKs, cette cryptographie magique pour amener Ethereum au niveau suivant, à la fois en termes de performance et d'échelle, mais aussi en termes de sécurité et de décentralisation. J'appelle le premier mode bête et le second mode fort.

Ryan :
[0:29] Attendez, d'accord. Le mode bête et le mode fort. Qu'est-ce que c'est que le mode bête et qu'est-ce que c'est que le mode fort ?

David :
[0:34] Oui. Le mode bête, c'est en partie cette vision qui consiste à faire passer la L1 à un giga gaz par seconde. J'appelle cela la frontière du giga gaz ou l'ère du giga gaz, ainsi que l'augmentation considérable de la disponibilité des données afin que nous puissions obtenir un téra gaz par seconde sur la L2. C'est donc 10 000 TPS sur le L1, 10 millions TPS sur le L2. Et si vous deviez résumer cela en une phrase, il s'agirait en fait d'avoir suffisamment de débit pour toutes les finances.

Ryan :
[1:07] Et donc le mode bête est sur la couche d'exécution, je suppose, ce qui sera défini un peu plus en détail. Mais c'est là que l'espace de bloc et les transactions de gaz et toute cette activité et les contrats intelligents, toute cette activité se passe sur la couche d'exécution. C'est DeFi. DeFi, les paiements, oui.

David :
[1:27] Exactement. Elle comprend également la couche de disponibilité des données pour les L2. Et cela nous donne, grosso modo, un amplificateur 1000 fois supérieur à ce que nous pouvons faire avec la L1.

Ryan :
[1:37] D'accord. Et même la couche de disponibilité des données pour les L2, que font les L2 ? L'exécution. C'est donc une question d'exécution en mode bestial. D'accord. Mode fort. Qu'est-ce que le mode fort ?

David :
[1:47] Le quatrième mode consiste à avoir une sécurité sans compromis. Le meilleur temps de fonctionnement de sa catégorie, la meilleure décentralisation de sa catégorie, la sécurité post-quantique, s'assurer que le pipeline MEV est proprement découplé des validateurs, et aussi avoir la meilleure finalité de sa catégorie en quelques secondes par rapport à ce que nous avons actuellement, qui est une question de 10 minutes, 10 à 20 minutes. C'est ce que les gens ont dit.

Ryan :
[2:13] C'est la couche de consensus, c'est ça ? Donc la couche consensus est le mode fort, le mode bête est la couche exécution. Exactement.

David :
[2:20] Il y a un petit lien dans le sens où la technologie que nous allons utiliser pour résoudre le mode bête nous permet aussi de résoudre le mode fort.

David :
[2:29] Et la raison en est que les snarks permettent aux validateurs de vérifier de très, très petites preuves. Et cela aide vraiment à la décentralisation parce que la barrière à l'entrée pour devenir un validateur d'un point de vue matériel est extrêmement faible.

Justin ou David :
[2:44] Et le mode bête et le mode fort, j'ai l'impression que ce sont des modes offensifs et défensifs. Comme l'exécution, le mode bête est, Ethereum est agressif. Nous allons de l'avant. Nous allons de l'avant en mode bête. Et puis le mode fort, c'est un peu ce qu'Ethereum a toujours fait. Et nous continuons à le faire, ce qui est en quelque sorte ce que nous appelons la résistance à la troisième guerre mondiale, c'est-à-dire que tout va mal dans le monde. Mais Ethereum continuera à produire des blocs parce qu'il est très résistant. C'est la monnaie bunker. Nous avons donc une offensive défensive, c'est peut-être une façon de dépeindre cela.

David :
[3:18] Exactement. Et avec Snarks, nous avons la permission de faire de plus grands rêves sur la mise à l'échelle agressive et la performance.

Justin ou David :
[3:27] Il faut souligner, Justin, qu'Ethereum n'a jamais vraiment fait de mode bête auparavant. Nous ne sommes jamais vraiment passés à l'offensive. C'est en quelque sorte la première fois que nous pouvons dire de manière crédible qu'Ethereum n'évolue pas de manière marginale, mais de manière agressive. Est-ce exact ?

David :
[3:50] Je veux dire, je dirais que la disponibilité des données sur laquelle nous travaillons depuis de nombreuses années fait partie du mode bestial pour débloquer les L2. Mais la L1 est restée stagnante.

Justin ou David :
[4:02] Au niveau de la L1, le mode bête au niveau de la L1. C'est exact.

David :
[4:04] Donc pendant quatre ans, il y a quatre ans, la limite de gaz était de 30 millions de gaz, et aujourd'hui elle est de 45 millions de gaz. En quatre ans, nous n'avons donc augmenté la limite de gaz que de 50 %, ce qui est inférieur à la loi de Moore et aux améliorations matérielles.

Justin ou David :
[4:20] Oui, ce n'est pas très spectaculaire.

David :
[4:23] Mais maintenant, nous avons la permission d'être extrêmement ambitieux car la technologie arrive à maturité.

Ryan :
[4:29] D'accord. Ces quatre dernières années, nous sommes passés de 30 millions à 45 millions sur la première couche d'Ethereum. Si j'ai bien compris, au début, peut-être en 2016, la limite de gaz était de 6 millions. Nous sommes donc passés d'une limite inférieure à 30 millions. Et la façon dont nous y sommes parvenus relève de l'ingénierie brute. Mais appeler cette mise à l'échelle sur la L1, de toute façon, le mode bête, ce n'est pas tout à fait juste. Je veux dire, qu'avons-nous fait ? Il s'agit d'une échelle de trois à cinq X, quelque chose comme ça. Et cela a pris 10 ans d'histoire d'Ethereum. Mais quand nous parlons de gaz et de limites de gaz et de ce genre de choses, ce dont nous parlons, c'est de transactions par seconde, n'est-ce pas ? Ou du moins, il s'agit d'une approximation des transactions par seconde. Tout au long de cet épisode, nous ferons souvent référence à la taille des blocs. Pouvez-vous donc définir ce qu'est la taille des blocs et comment elle est liée aux transactions par seconde et à la mise à l'échelle générale ?

David :
[5:32] Absolument. La transaction la plus simple possible s'appelle un transfert et consomme 21 000 gaz. Vous n'avez pas besoin de vous souvenir de ce chiffre, mais en moyenne, nous effectuons des transactions plus complexes.

David :
[5:44] Par exemple, nous avons des swaps DEX, qui consomment 100 000 gaz. Donc si vous avez un giga gaz par seconde, c'est-à-dire 1 milliard de gaz par seconde, et que vous divisez ce chiffre par votre transaction moyenne de 100 000 gaz, vous obtenez le TPS de 10K. Pour continuer sur le thème des puissances de 10, il y a environ 100 000 secondes dans une journée, et il y a environ 10 milliards de personnes sur Terre. Si l'on calcule par personne, on obtient 0,1 transaction par personne et par jour, ce qui, à mon avis, est un bon début, mais ce n'est pas suffisant pour toutes les finances, n'est-ce pas ? En tant qu'humains, nous effectuons plus d'une transaction financière tous les 10 jours.

Ryan :
[6:28] Et il y a aussi les robots qui arrivent sur la chaîne.

David :
[6:31] Absolument. C'est un grand amplificateur. J'espère que nous pourrons atteindre une échelle de 10 millions de transactions par seconde à long terme. C'est l'ère TerraGas. Et cela débloque une centaine de transactions par jour et par personne.

Ryan :
[6:46] D'accord, mais le giga gaz, c'est l'espoir d'y arriver et le plan dans le lean Ethereum est d'y arriver sur la couche 1 d'Ethereum. Ai-je raison ? Et puis les teragas sont dans l'écosystème de la couche 2 d'Ethereum en engageant, vous savez, une donnée dans la couche de disponibilité des données à grande échelle d'Ethereum. C'est exact.

David :
[7:08] TerraGas est donc l'agrégat de tous les roll-ups combinés. Et vous pouvez l'imaginer, grosso modo, comme un millier de copies de L1, chacune faisant un giga gaz.

Ryan :
[7:19] D'accord. Où en sommes-nous maintenant ? Si nous essayons d'atteindre le giga gaz sur la L1 et le TerraGas sur la L2, tu as mentionné quelques chiffres sur la situation d'Ethereum. S'agissait-il d'une limite de 60 millions de gaz ? Quelle est la limite de gaz actuelle et à quelle distance en sommes-nous ?

David :
[7:36] Oui, la limite de gaz est très confuse parce que nous avons des créneaux de 12 secondes. Il faut tout redénommer à la seconde près. Mais à L1, nous sommes à environ 500x de cet objectif. Donc entre deux et trois ordres de grandeur. Et dans une très large mesure, le principal goulot d'étranglement que nous avons aujourd'hui est le validateur. Nous nous sommes donc fixé comme contrainte, comme objectif, une décentralisation maximale. Et nous ne permettons pas aux validateurs, ou du moins nous ne supposons pas que les validateurs disposent d'un matériel puissant. Ils fonctionnent sur des ordinateurs portables. Et en éliminant ce goulot d'étranglement, nous pouvons facilement, à mon avis, multiplier par 10 ou par 100. Et avec suffisamment de travail, nous pouvons obtenir ce 500x qui nous permet d'atteindre un giga gaz par seconde.

Ryan :
[8:28] D'accord. Et combien de giga gaz par seconde représente Ethereum aujourd'hui ? Tu as dit que c'est parce que nous traduisons plusieurs choses. Tu as dit... C'est deux mégas par seconde. C'est combien ?

David :
[8:39] Deux mégagas par seconde.

Ryan : [8:42] D'accord :
[8:42] Ok. Donc c'est deux mégagas par seconde en ce moment.

Justin ou David :
[8:45] Et nous voulons 1 000 mégagas par seconde.

Ryan :
[8:48] D'accord, c'est pour ça qu'on est à 500x. Une autre façon de traduire cela est que nous avons 20, environ 20 transactions par seconde, peut-être, pour ces transactions simples sur Ethereum. Et nous voulons être à 10 000. Encore une fois, c'est 500 fois moins que ce que nous avons aujourd'hui. C'est ce que dit le mode bête. Nous allons faire 500x sur la couche 1 d'Ethereum, n'est-ce pas ?

David :
[9:08] C'est ce que j'espère. C'est la vision que j'essaie de mettre en avant. Et lentement, chaque semaine, avec de plus en plus de développements sur les ZKVM, les gens commencent à croire que c'est possible.

Ryan :
[9:20] D'accord, c'est intéressant. Nous allons donc parler de vision et d'exécution tout au long de cet épisode, à de nombreux endroits. Mais avant cela, puisque nous sommes encore en train de définir le contexte, je pense que certaines personnes vont se gratter la tête et se demander pourquoi Justin parle de la mise à l'échelle de la L1, et pourquoi Ethereum en général parle de la mise à l'échelle de la L1 ? Je pensais que le plan était la feuille de route centrée sur le roll-up où la couche 1 d'Ethereum reste assez lente. Oui, peut-être qu'elle augmente un peu au fur et à mesure que la loi de Moore s'améliore et que l'ingénierie s'améliore un peu, mais elle ne va pas passer en mode bête parce que le plan en mode bête, je pensais qu'il était déjà défini comme la feuille de route centrée sur le roll-up. Et toute l'échelle d'Ethereum se produit sur les L2. Eh bien, vous dites, non, nous allons continuer à faire évoluer la L2, mais nous faisons aussi évoluer la L1. Certaines personnes vont se gratter la tête et demander : pourquoi ? S'agit-il d'un changement ? Est-ce un pivot ?

Ryan :
[10:22] Pourquoi essayons-nous de développer la L1 en premier lieu ?

David :
[10:25] Je dirais que oui, c'est un changement. C'est un pivot parce que nous disposons maintenant d'une technologie qui nous permet de passer à l'échelle tout en préservant la décentralisation. Ce qui est venu en premier, c'est l'exigence de décentralisation. Ensuite, nous avons essayé de faire au mieux avec cette exigence. Et c'est le statu quo que nous avons. Mais maintenant que nous disposons d'une nouvelle technologie, nous pouvons commencer à repenser le type d'échelle que nous pouvons avoir à L1. La première réponse est donc simplement parce que nous le pouvons. La deuxième réponse est que si nous voulons qu'Ethereum L1 soit un hub, c'est-à-dire l'endroit où les actifs sont frappés, où le bridging se produit, où les retraits forcés se produisent, où une grande partie de la liquidité de grande valeur se produit, alors nous avons besoin que L1 ait une quantité minimale d'échelle que, Et 0,1 transactions par humain, vous devriez penser que c'est la plus haute densité de transactions économiques qui peut y arriver. Tous les autres seront potentiellement exclus. On peut donc considérer qu'il s'agit de transactions de règlement, de transactions de frappe de monnaie, de transactions où l'on met en place une trappe d'évacuation, où l'on a 100 000 $ bloqués sur une L2, où le séquenceur est hors ligne ou quelque chose comme ça, eh bien, on peut juste forcer le retrait et on sera prêt à payer les 10 cents ou quoi que ce soit sur L1 afin de libérer ses fonds.

Ryan :
[11:51] Ce sont donc les deux raisons. Pour revenir à la première, parce que nous pouvons, cela implique que nous ne pouvions pas le faire avant et nous aurons toute une conversation sur les snarks et cette cryptographie magique qui a émergé, disons, et s'est durcie au cours de la dernière décennie. Mais l'idée que nous mettons à l'échelle la L1 maintenant parce que nous le pouvons signifie que nous ne pouvions pas le faire auparavant. Cela signifie presque que la mise à l'échelle de la L1 aurait été la première option si nous l'avions pu. Par exemple, est-il préférable de mettre à l'échelle la L1 plutôt que la L2 ? Et si nous avions pu, disons en 2018, ce qui signifie que Snarks a été libéré à ce moment-là, cela aurait été le chemin par défaut plutôt que les L2 ?

David :
[12:39] Je pense que oui. Je pense que si nous avions pu évoluer, disons, il y a cinq ans avec les ZKVM, c'est probablement ce que nous aurions fait, mais cela n'aurait pas été suffisant. Nous aurions encore dû emprunter la voie de la disponibilité des données pour débloquer les millions de transactions par seconde dont nous avons besoin pour accueillir toute la finance. Ainsi, dans un certain sens, il y aurait eu un ordre différent, mais je pense que nous aurions quand même emprunté le chemin difficile de la collaboration avec SNARK pour l'exécution et de la collaboration avec l'échantillonnage de la disponibilité des données pour la bande passante. Vous pouvez considérer ces deux outils, SNOX et la disponibilité des données, comme les deux faces d'une même pièce de monnaie. Il s'agit essentiellement de la bande passante et du calcul, qui sont les deux ressources primitives consommées par une blockchain.

Ryan :
[13:31] Certaines personnes seront encore déconcertées par cette réponse, Justin, parce qu'elles diront, attendez, attendez une seconde, pourquoi n'avez-vous pas pu mettre à l'échelle Ethereum en 2018 ? Et ils citeront d'autres chaînes de couche 1 aujourd'hui qui sont effectivement en train de passer à l'échelle. Je veux dire, vous avez des L1 qui disent qu'elles peuvent passer à 10 000 transactions par seconde et plus. D'autres sont capables d'effectuer des millions de transactions. Je pense que Solana réalise des milliers de transactions par seconde en pointe, au moins, et ils promettent bien plus. S'agissait-il donc d'un problème de compétences ? Pourquoi Ethereum n'a-t-il pas pu évoluer ?

David :
[14:09] Oui, c'est une bonne question. Beaucoup de L1 à haute performance ont une décentralisation relativement faible. Monad, par exemple, grosso modo, Ballpark, ils ont 100 validateurs, Say, 100 validateurs, BNB chain, encore moins de validateurs.

David :
[14:32] Et non seulement ils ont un petit nombre de validateurs, mais aussi la barrière à l'entrée pour devenir validateur est d'avoir un serveur dans le centre de données, parce que vous devez stocker beaucoup d'états, vous devez avoir une connexion internet très fiable et à haut débit, vous devez avoir beaucoup de RAM, vous devez avoir des CPU rapides. C'est le genre de choses qu'il est plus difficile d'obtenir chez soi. C'est également la stratégie adoptée par Solana. Solana réalise en moyenne un millier de transactions d'utilisateurs par seconde, avec moins d'un millier de validateurs. Si vous regardez la carte de l'emplacement de ces validateurs, vous constaterez qu'ils se trouvent presque tous dans des centres de données. Et la grande majorité d'entre eux, plus de 50 %, se trouvent, je crois, dans deux centres de données situés à quelques dizaines de kilomètres l'un de l'autre. En Europe. C'est donc très, très concentré. Et ce n'est pas quelque chose que nous avons toléré sur Ethereum.

Ryan :
[15:40] Peux-tu nommer la contrainte alors ? Il semble donc qu'Ethereum ne tolère pas quelque chose, qu'il ne tolère pas les validateurs fonctionnant dans les centres de données. Il y a donc une contrainte auto-imposée sur la conception. Nommez-la. Quelle est cette contrainte par rapport à " pourquoi ne pouvons-nous pas capituler et commencer à faire fonctionner les choses dans les centres de données comme certaines autres chaînes ont commencé à le faire ?

David :
[16:05] Nous nous intéressons aux connexions Internet à domicile et au matériel de base, comme un ordinateur portable. Et une partie de la raison a à voir avec la vivacité. Récemment, nous avons eu une panne d'AWS, plusieurs chaînes ont été mises hors ligne. Ce n'est pas ce que nous voulons avec Ethereum. Mais nous sommes très paranoïaques, au point que nous voulons un modèle de sécurité où même si tous les opérateurs de centres de données du monde décident d'attaquer Ethereum en même temps, il y a toujours un temps de fonctionnement. Et il y a environ, disons 100 opérateurs de centres de données dans le monde. Ce n'est donc pas totalement farfelu. Et je suppose qu'une autre différence est que, vous savez, nous essayons d'avoir le meilleur temps de fonctionnement de sa catégorie, n'est-ce pas ? Nous avons un temps de fonctionnement de 100 % depuis Genesis. Et une partie de cela consiste à ne pas prendre de raccourcis. Et je pense que ce que certaines de ces autres chaînes ont fait, c'est qu'elles ont accepté de rogner sur les coûts pour obtenir de meilleures performances.

Justin ou David :
[17:08] Lorsque nous parlons de passer d'un débit de gaz de deux mégagas par seconde à mille mégagas par seconde, un 500X n'est pas seulement quelque chose que l'on peut concevoir. La raison pour laquelle nous faisons cela aujourd'hui, c'est parce qu'Ethereum est en train de passer à travers

Justin ou David :
[17:28] quelque chose de plus proche d'une évolution que d'une mise à niveau technique. Et certaines des chaînes dont nous venons de parler ont toujours été comme de l'ingénierie d'abord. Et c'est de là que viennent certains des avantages en termes de performances. Solana, par exemple, s'est beaucoup appuyé sur l'ingénierie et a produit des nœuds et des clients d'exécution bien conçus. Et puis, où sont ces logiciels, où s'expriment-ils le mieux sous leur forme la plus aboutie ? Eh bien, dans un centre de données, dans un centre de données pour les choses lourdement conçues. Et c'est là qu'une grande partie des chaînes modernes de mise à l'échelle de 2020 à 2025 ont obtenu une partie de leur débit.

Justin ou David :
[18:04] Ethereum a été patient, mais pour obtenir ce 500x, ce n'est pas vraiment une question d'ingénierie. C'est plutôt une évolution. Une nouvelle voie s'est ouverte avec certaines des choses dont vous avez parlé, Justin, avec tout le processus ZK. Era, où ce n'est pas nécessairement une question d'ingénierie, mais c'est en fait la cryptographie qui ouvre une voie pour faire quelque chose comme un 500x. Et donc c'est en quelque sorte, et ça a toujours été dans la poche arrière d'Ethereum depuis le premier jour. Cela a toujours été la stratégie théorique de mise à l'échelle. Et ces dernières années, je pense que vous et les gens de la Fondation Ethereum vous êtes dit, ok, ce chemin est maintenant clair pour nous, et nous sommes prêts à l'emprunter. C'est en quelque sorte mon diagnostic de ces dernières années. Est-ce exact ?

David :
[18:48] Oui, c'est vrai. En fait, la clé de voûte est la cryptographie. Et les exigences que nous avons pour la cryptographie sont extrêmement élevées. L'une des choses auxquelles nous tenons, par exemple, c'est la diversité. Il s'agit d'une cryptographie compliquée, et nous voulons avoir le même type de diversité que celle dont nous bénéficions aujourd'hui à la couche de consensus et à la couche d'exécution, avec les équipes de consensus et l'équipe d'exécution. J'espère donc que nous pourrons avoir cinq VM ZKE différentes avec des défaillances non corrélées. Une autre exigence forte pour la cryptographie est la preuve en temps réel. L'idée est que lorsqu'un bloc est produit, la preuve du bloc correspondant doit arriver avant le bloc suivant. Le temps de latence doit donc être inférieur à un slot Ethereum, soit moins de 12 secondes. Et puis...

David :
[19:43] Une autre exigence que nous avons au-delà de la sécurité et de la latence est la consommation d'énergie. Pour en revenir à ce commentaire sur les centres de données, nous ne voulons pas que les prouveurs soient eux-mêmes dans des centres de données, car vous avez introduit un nouveau point d'étranglement. Ce que nous espérons donc, c'est une démonstration sur site. Et par "sur place", nous entendons sur place, à la maison, dans un garage, dans un bureau. Et le chiffre spécifique que nous avons en tête est de 10 kilowatts.

David :
[20:20] Pour vous donner un ordre de grandeur, un grille-pain consomme un kilowatt. C'est donc l'équivalent de 10 grille-pains. Et c'est aussi l'équivalent d'un chargeur domestique Tesla qui consomme environ 10 kilowatts. Donc, si nous pouvons avoir des millions de chargeurs domestiques dans le monde, il est raisonnable d'avoir cette exigence pour les prouveurs. Il convient de souligner que, contrairement au consensus, qui exige que la moitié des participants se comportent honnêtement, il suffit d'un seul prouveur honnête pour que tout fonctionne. C'est pourquoi les exigences matérielles imposées aux participants au consensus sont très différentes. Ici, nous voulons que la barrière à l'entrée soit la plus basse possible, par exemple un Raspberry Pi ou un ordinateur portable, parce que l'hypothèse d'honnêteté est de 50 %. Mais pour les prouveurs, c'est une hypothèse de un sur n, et il n'y a pas de mal à l'augmenter.

Ryan :
[21:18] D'accord, on commence à décortiquer la couche du mode bête, la couche d'exécution avec certains de ces composants. Personnellement, je ne suis pas encore prêt à y arriver. J'ai donc encore quelques questions. Ce que tu viens de décrire est une pile qui nous permet de continuer à faire de la blockchain.

Ryan :
[21:36] validation ou la vérification en dehors d'un centre de données à partir d'une connexion Internet domestique. Et j'aimerais savoir pourquoi ou quels cas d'utilisation sont importants pour cela. Vous avez dit qu'il s'agissait en partie de la vivacité et du temps de fonctionnement. Et en effet, Ethereum a eu 10 ans de temps de fonctionnement ininterrompu. C'est fantastique. Mais il y a d'autres propriétés que la décentralisation et le temps de fonctionnement confèrent en quelque sorte. L'une d'entre elles, assez célèbre, avec Bitcoin et Ethereum, comme vous l'avez expliqué sur Bankless, est la propriété de votre crypto-monnaie d'être une réserve de valeur. Ainsi, le bitcoin en est encore à la cryptographie 1.0. Il ne fait rien de particulier. Ce n'est pas vraiment dans la feuille de route. Mais il a maintenu un débit très faible, un TPS très faible, mais aussi des exigences très faibles en matière de nœuds. Vous pouvez donc faire fonctionner un nœud Bitcoin depuis votre maison. Ce n'est pas une chaîne de centres de données.

Ryan :
[22:40] Similaire à Ethereum. Mais j'aimerais savoir pourquoi. Parce que pour Bitcoin, ils sont très clairs sur la raison. C'est parce que Bitcoin est une réserve de valeur. C'est parce que c'est de l'or numérique et que tout le monde a besoin d'y accéder. Nous avons soutenu sur Bankless qu'à 10 transactions par seconde, une partie de cet accès prendra probablement la forme de micro-stratégies et d'ETF. Et vous ne serez pas en mesure de faire des choses dans DeFi que vous pouvez faire si vous mettez à l'échelle votre couche de base. Je ne veux pas revenir sur ce point. Mais je veux poser la question du pourquoi ? Quels sont les cas d'utilisation de l'Ethereum L1 qui sont importants ? Vitalik a écrit un billet de blog sur la lenteur du DeFi. Est-ce l'un d'entre eux ? Le cas d'utilisation de la réserve de valeur en fait-il partie ? J'ajouterai juste une autre dimension. Des personnes sont venues sur le podcast pour dire que la feuille de route d'Ethereum est défectueuse parce qu'elle est obsédée par la décentralisation. Ils sont obsédés par le fait que les nœuds peuvent fonctionner chez quelqu'un. Si vous supprimez cette obsession, vous pourrez évoluer beaucoup plus rapidement et ils ne comprennent pas la raison de cette obsession. Donc, quels sont les cas d'utilisation comme Ethereum sur le provisionnement lui-même. Quels sont les cas d'utilisation les plus propices à cette décentralisation, que j'appellerai obsession, contrainte qu'Ethereum s'est auto-imposée ? S'agit-il de DeFi ? Est-ce la réserve de valeur ? Qu'est-ce que c'est ?

David :
[24:00] C'est la réserve de valeur. C'est l'argent. Et vous pouvez l'observer de manière empirique. Vous avez la monnaie numéro un, le bitcoin, qui est l'exact opposé du mode bête, n'est-ce pas ? C'est un tas de merde, n'est-ce pas ? C'est comme si tu avais un...

Ryan :
[24:18] Attends, c'est quoi une merde ?

David :
[24:20] Bitcoin, l'actif ? Blockchain, la chaîne, désolé. La blockchain elle-même.

Justin ou David :
[24:25] Même les bitcoiners diront que la blockchain Bitcoin est une charge sur le BTC, l'actif. C'est en fait aligné sur le Bitcoin ou la philosophie.

David :
[24:33] Et pourtant, c'est un actif de 2 000 milliards de dollars. Et puis vous avez quelque chose entre Ethereum, qui essaie d'obtenir une certaine performance, une certaine robustesse et une neutralité crédible. Et nous sommes un actif de 500 milliards de dollars. Et puis il y a quelque chose qui s'appuie entièrement sur le mode bête, comme Solana, et qui représente un actif de 100 milliards de dollars. Et les nouvelles chaînes qui s'appuient encore plus sur le mode bestial ont des valorisations plus faibles. Je pense donc que l'argent exige cette prime mimétique. Et le marché nous a dit empiriquement que la robustesse, le mode de pensée, le temps de fonctionnement, la neutralité crédible, la lenteur, les garanties à long terme sont des choses extrêmement importantes.

Ryan :
[25:27] Il me semble logique que la réserve de valeur soit le premier cas d'utilisation de quelque chose comme le Bitcoin ou l'Ethereum, parce que si vous y réfléchissez du point de vue de l'utilisateur, vous voulez mettre votre valeur à un endroit. Vous pouvez aller dans une grotte, vous savez, pendant 10 ans et en ressortir et elle est toujours là. C'est ce qu'on appelle la réserve de valeur. Vous stockez de la valeur à travers le temps.

Ryan :
[25:50] Et le Bitcoin a en quelque sorte compris cela. Mais je pense que quand on parle de réserve de valeur, il s'agit aussi d'instruments au porteur, tu sais, par exemple, je ne sais pas si je me soucie de l'USDC sur Ethereum comme réserve de valeur et si je le mets sur Ethereum et que je vais dans une grotte pendant 10 ans et que j'en ressors. Je ne sais pas ce qui pourrait arriver à l'USDC. Il pourrait, vous savez, Jeremy Allaire, je suis sûr qu'il est entre des mains grises, quelles que soient les lois qui pourraient changer. Vous savez, il pourrait se désapprouver, quelque chose de mauvais pourrait arriver à l'USDC. Le cas d'utilisation de la réserve de valeur est donc vraiment centré sur les actifs cryptographiques natifs sur Ethereum, principalement ETH. L'Ether est l'actif qui sert principalement de réserve de valeur sur Ethereum. Donc, quand je pense aux cas d'utilisation tangibles, et vous dites une sorte de réserve de valeur, les choses qui nécessitent une décentralisation maximale, c'est probablement l'Ether l'actif. Et puis peut-être une poignée de primitives DeFi. C'est ce que je pense. Et ce n'est pas tant les actifs du monde réel, sauf s'ils agissent comme une paire d'échange pour quelque chose comme l'Ether. C'est ainsi que je vois les choses. Mais c'est pourquoi je suis curieux de savoir comment vous voyez les choses,

Ryan :
[27:05] Justin, et comment les gens de la Fondation Ethereum le voient. Quelles sont les applications qui seront les plus importantes sur la première couche ?

David :
[27:14] Je veux dire, les gens ont des opinions différentes au sein de la Fondation Ethereum. Mais je suis d'accord avec vous pour dire que l'application la plus importante d'Ethereum est l'argent. Et c'est de là que dérivent toutes les applications. Si vous voulez avoir des prêts, des échanges, si vous voulez avoir des marchés de prédiction, tout est dans une large mesure prédictif.

David :
[27:35] Prédéterminé par l'existence de cet argent fort. Et c'est particulièrement vrai avec ces distributions de loi de puissance et les situations où le gagnant prend le plus. J'ai essayé de faire valoir qu'une chaîne unique comme Ethereum peut gérer toute la finance. Dans une large mesure, la raison pour laquelle nous avons tant de fragmentation à L1 est qu'Ethereum n'a pas grandi assez vite pour absorber toute l'innovation. Mais nous disposons désormais d'une feuille de route crédible pour en absorber la totalité. En ce qui concerne la prime monétaire, c'est le gagnant qui prend le plus. Vous devez d'une manière ou d'une autre convaincre la société que votre actif est le plus légitime. Et si vous regardez les concurrents, par exemple, vous regardez les actifs vendus.

David :
[28:30] Cela vient d'être disqualifié pour être de l'argent, à mon avis. N'est-ce pas ? Le fait qu'il y ait eu 10 pannes sur une poignée d'années le disqualifie immédiatement. Le plus important est donc de rester suffisamment longtemps dans le jeu pour ne pas être disqualifié. Et maintenant, nous avons ces deux actifs qui sont en concurrence, le bitcoin et l'éther. Et je pense que dans quelques années, le bitcoin sera également disqualifié à cause de sa blockchain. Non pas parce qu'il a échoué en mode "bête", mais parce qu'il a échoué en mode "fort". Il ne sera pas en mesure de se protéger contre la diminution de l'émission.

Ryan :
[29:11] La diminution de l'émission est une sorte de scénario catastrophe pour le bitcoin ?

David :
[29:15] Oui. Si vous regardez les frais de transaction actuellement, ils représentent environ un demi pour cent de tous les revenus des mineurs. Donc 99,5 % proviennent de l'émission. Et nous savons que cette fraction va tomber à zéro, nous l'avons tous les quatre ans. À l'heure actuelle, le bitcoin est garanti par des frais de trois bitcoins par jour. Trois bitcoins par jour, ce n'est tout simplement pas suffisant pour sécuriser le bitcoin.

Justin ou David :
[29:39] Nous avons parlé de la dichotomie entre le mode bête et le mode fort. Et maintenant, je voudrais peut-être nommer nos préjugés parce que moi, Ryan, Justin, nous sommes tous venus à la crypto, à Ethereum en 2017 et avant. Et c'est vraiment à ce moment-là que la décentralisation en mode fort était le jeu. Et c'est un peu comme notre génération de crypto. Les nouvelles générations de crypto valorisent vraiment le mode bête bien plus que le mode fort. Je pense que tous ceux qui sont entrés dans la cryptographie en 2021 ou plus tard ont probablement une part disproportionnée de leur portefeuille en bitcoins par rapport à ceux qui sont arrivés avant 2021. Et quelque chose que j'aimerais souligner, c'est que même si nous parlions de l'idée de l'argent, c'est une question d'argent. Le mode fort est votre ticket d'entrée dans la compétition de l'argent. Néanmoins, les préférences des utilisateurs après 2021 ont vraiment préféré le mode bête et les transactions, le volume des transactions, les frais de transaction ont lentement, le pendule s'est déplacé vers les chaînes qui vont vite, les chaînes qui font du mode bête.

Ryan :
[30:45] Et donc, même si - j'ajouterais, David, quelles que soient les contraintes, n'est-ce pas ?

Justin ou David :
[30:49] Quelles que soient les contraintes.

Ryan :
[30:50] Aucune contrainte de type validateur domestique.

Justin ou David :
[30:52] Oui. Et donc je ne veux pas que nous parlions trop du mode bête parce qu'en fait c'est ce qu'Ethereum essaie de faire en 2025 et au-delà : nous avons l'impression d'avoir couvert le mode fort et maintenant nous pouvons débloquer le mode bête. Et le mode bête a beaucoup de valeur. C'est là que vous obtenez une finance composable globale sur une seule chaîne. C'est là que vous intégrez toute l'humanité, toute la finance, sur une seule chaîne. C'est là que vous obtenez l'adoption par les utilisateurs et toutes les bonnes choses qui viennent avec une chaîne de contrats intelligents. Et donc... Je suis dans ce camp, nous sommes tous dans ce camp où le mode fort est la chose cool que les blockchains apportent de manière unique au monde. Néanmoins, les préférences des utilisateurs se sont éloignées du mode fort pour passer à

Justin ou David :
[31:37] le mode bête au fur et à mesure que les blockchains sont adoptées par le grand public. Et maintenant, la stratégie d'Ethereum est de pénétrer agressivement ce marché avec certaines des technologies et des stratégies dont nous allons parler dans la suite.

David :
[31:49] de cet épisode. Oui. Je suis donc d'accord sur le fait qu'Ethereum essaie de se créer un nouveau territoire avec le mode bête. Mais il y a une chose que je voudrais souligner : si vous avez un mode bête sans mode fort, c'est une activité très superficielle. L'une des façons de le mesurer est de regarder les mèmes coins sur Solana. C'est là qu'une grande partie de l'activité s'est produite. Et vous savez, nous avons plus de 10 millions de mèmes pièces sur Solana et la capitalisation boursière globale de toutes les mèmes pièces sur Solana est inférieure à 10 milliards de dollars, ce qui est une goutte d'eau dans l'océan. Donc, oui, il y en a eu beaucoup.

Justin ou David :
[32:24] Est-ce que 10 milliards de dollars sont une goutte d'eau dans l'océan ?

David :
[32:26] Donc, vous savez, par rapport aux pièces stables, par exemple, comme une seule pièce stable sur Ethereum L1 Tether, c'est plus de 100 milliards de dollars. Ce n'est qu'un cas d'utilisation, dix fois plus important. Vous pourriez regarder les prêts sur Avid, qui représentent également des dizaines de milliards de dollars. Mais vous pouvez aussi regarder, vous savez, la capitalisation boursière d'Ethereum, qui est 50 fois plus grande. Il y a un actif 50 fois plus important que 10 millions d'actifs combinés. Nous en reparlerons peut-être.

Ryan :
[32:53] Plus de détails sur les stablecoins plus tard dans l'épisode quand, tu sais, parce que j'ai cette question en suspens : dans quelle mesure les stablecoins ont-ils besoin des garanties de sécurité en mode bête avec décentralisation d'Ethereum L1 ? Mais réservons cette question pour plus tard.

Ryan :
[33:08] Et prenons cela dans les sections que vous avez présentées. Revenons à ce que tu disais plus tôt dans l'épisode, quand j'ai posé la question : qu'est-ce qu'un Ethereum allégé ? Vous avez dit que c'était Snarks. C'est la cryptographie magique que nous avons débloquée. C'est le mode bête, qui consiste à mettre à l'échelle Ethereum sur la L1 et la L2 du point de vue des transactions par seconde. Et c'est le mode fort, qui défend la décentralisation, la barrière à l'entrée la plus basse possible pour quelqu'un qui veut gérer un nœud. Prenons donc le reste de l'épisode pour aborder chacune de ces sections.

Ryan :
[33:43] Snarks. Ok, c'est de la cryptographie magique. Justin, on t'a eu dans un épisode. Je pense que c'est peut-être le premier épisode que tu as fait avec Bankless. C'était il y a environ quatre ans. Et vous aviez ce principe qui m'est resté en tête depuis, à savoir que la vraie façon de faire évoluer la blockchain, c'est la cryptographie. C'est le premier choix. C'est ainsi que Bitcoin a pu faire ce qu'il fait. Puis, lorsque la cryptographie échoue, on passe à l'économie et à la cryptoéconomie. Mais l'étalon-or, c'est que si l'on peut faire évoluer la cryptographie dans n'importe quel type de conception de protocole ou de mécanisme, alors on fait évoluer la cryptographie. Le Bitcoin et l'Ethereum sont tous deux basés sur une cryptographie qui est populaire depuis un certain temps. Je ne sais pas, je l'appellerai la cryptographie qui a eu Lindy dans les années 2010, n'est-ce pas ? C'est ce sur quoi Ethereum s'est basé jusqu'à présent. Et maintenant, les SNARKs. Faites-nous un historique de la cryptographie sur laquelle Ethereum est basé aujourd'hui et de cette mise à jour basée sur SNARKs. Et quelle est cette nouvelle cryptographie ?

David :
[34:51] Oui, depuis Bitcoin, la cryptographie que nous utilisons est extrêmement primitive. Il s'agit de deux éléments de cryptographie différents. La première est appelée fonction de hachage. C'est ce qui permet de construire des blocs et des chaînes. C'est ce que vous utilisez pour Merkleiser l'état. En fait, il s'agit d'un grand nombre d'arbres de Merkle. L'autre élément de la cryptographie s'appelle la signature numérique, ou simplement la signature. Elle permet d'authentifier la propriété et de signer les transactions.

David :
[35:25] Et aujourd'hui, en 2025, c'est la cryptographie de l'âge de pierre par rapport à ce que nous avons aujourd'hui. Et ces nouveaux snarks primitifs libèrent vraiment un tout nouvel espace de conception pour les blockchains. Elles nous permettent notamment de résoudre ce dilemme, que certains appellent le trilemme, entre l'échelle et la décentralisation. Nous pouvons vraiment résoudre cet éternel compromis en faisant en sorte que les validateurs vérifient ces preuves courtes et que ces preuves aient autant d'exécution que les constructeurs de blocs et la chaîne peuvent en absorber. Si l'on considère les deux ressources de base dont nous disposons pour passer à l'échelle supérieure, la première est l'exécution. Nous avons des stocks pour cela. Et l'autre, ce sont les données. Et ici, nous avons l'échantillonnage de la valeur des données.

David :
[36:31] Maintenant, en plus de vouloir ces deux déverrouillages du point de vue de la mise à l'échelle, nous voulons également nous assurer que la cryptographie que nous avons est durable à long terme. Dans notre contexte, cela signifie une sécurité post-quantique. Aujourd'hui, pour les données de l'échantillonnage précoce, nous avons pris un petit raccourci. Mais nous avons déployé une cryptographie appelée KZG, qui n'est pas sécurisée au niveau post-quantique. Nous devons donc disposer d'un plan de mise à niveau. Et c'est là que les SNARKs sont utiles au-delà de l'échelle. Ils contribuent également à la sécurité post-quantique au niveau de la couche de données.

Ryan :
[37:19] Il y a quatre ans, vous parliez des SNARKs et le terme que vous avez utilisé, en fait, je crois que nous avons titré l'épisode " moon math ", n'est-ce pas ? Il s'agissait d'une sorte de mathématique lunaire émergente. Et ça fait un moment que ça existe, juste pour les gens qui ne sont pas cryptographes, d'accord ? Je veux dire que nous n'avons pas besoin d'entrer dans les détails de ce que sont les SNARKs et de ce qu'ils peuvent faire. Je pense que pour beaucoup de gens qui nous écoutent, il suffit de comprendre qu'il s'agit de mathématiques lunaires, qu'elles sont utilisées dans la pratique depuis un certain temps et qu'elles sont raisonnablement sûres. Lorsque nous parlons de SNARKs et de ZK, parce que vous avez utilisé le terme ZK EVMs tout à l'heure, est-ce que ZK et SNARKs sont une seule et même chose ? Ou alors, comment se fait-il que nous utilisions parfois ZK et que vous utilisiez aujourd'hui SNARKs ? Comme si les gens ne comprenaient pas les différences entre ces termes.

David :
[38:06] Bien sûr, le terme technique est SNARK. Le S signifie succinct. On peut dire que c'est petit. Et puis la partie NARC, argument non interactif de la connaissance. Il s'agit d'un jargon sophistiqué pour désigner une preuve. Snark n'est donc rien d'autre qu'une petite preuve. Il s'avère que cette technologie, les Snarks, nous donne aussi gratuitement une autre propriété appelée connaissance zéro, qui est importante dans le monde de la vie privée. Mais nous n'utilisons pas cette propriété pour la mise à l'échelle.

Ryan :
[38:40] Alors comment peut-on les appeler ZKEVM ?

David :
[38:42] C'est tellement confus.

Ryan :
[38:43] Ils ne sont pas privés.

Justin ou David :
[38:44] On ne fait pas un très bon travail pour les nommer dans cette industrie.

Ryan :
[38:46] Est-ce qu'on devrait les appeler les EVM Snark ? Vraiment ?

David :
[38:49] On devrait les appeler Snark EVM, oui.

Ryan :
[38:51] Ok. Nous ne gagnerons pas ce combat aujourd'hui. Nous ne sommes pas là pour jouer à ce jeu.

David :
[38:55] C'est un combat perdu d'avance.

Ryan :
[38:56] Depuis combien de temps les snarks existent-ils ? Toutes les chaînes de première génération aujourd'hui, toutes les chaînes que nous avons en production, Bitcoin, Ethereum, utilisent toutes une cryptographie plus primitive, comme tu l'as dit, des fonctions de hachage, des signatures numériques. Il y a eu cette expérience appelée Zcash. Et le Z, je pense, est l'abréviation de zero knowledge ou snarks, n'est-ce pas ? Ils utilisent une partie de cette technologie. Et cela existe depuis, je ne sais pas, 2014, quelque chose comme ça. Zcashers, corrigez-moi sur les dates. Quelle est la robustesse de cette technologie ? Quelle est son utilité ? À quel point est-elle utilisée ? Sommes-nous sûrs d'être prêts pour les snarks en prime time sur une chaîne qui sécurise près d'un trillion de dollars en valeur ?

David :
[39:36] D'accord. Zcash a été lancé, je crois, en 2016, il y a neuf ans. Et quand vous regardez en arrière, ils étaient des pionniers absolus, mais ils étaient aussi des DGens, comme des DGens cryptographiques. Ils ont détruit la cryptographie, qui était, vous savez, c'était comme construire des fusées, n'est-ce pas ? Ça pouvait leur exploser à la figure. Et en fait, il y a eu un moment où ça a explosé, n'est-ce pas ? Je ne sais pas si vous vous en souvenez, mais il y a quelques années, Zcash a eu ce bug critique qui permettait à n'importe qui de frapper une grande quantité arbitraire de jetons ZEC.

Ryan :
[40:09] C'est vrai, et comme c'est privé, nous ne savons pas si c'est arrivé ou non, si le bug a été exploité ou non, n'est-ce pas ? Nous n'en sommes pas sûrs.

David :
[40:17] Exactement. Et donc...

David :
[40:19] Et l'une des grandes choses que nous devons faire est de résoudre le problème de la sécurité. Et il y a globalement deux solutions satisfaisantes pour Ethereum. La première consiste à avoir une diversité de SNARKs. Vous avez donc cinq fournisseurs de SNARK différents et vous acceptez qu'un bloc soit valide. Par exemple, si trois de ces SNARKs retournent un bloc valide, vous pouvez continuer d'une manière très similaire à la diversité des couches d'exécution et de consensus. L'autre solution est ce que nous appelons la vérification formelle, qui consiste à choisir un seul système de preuve et à l'auditer jusqu'à ce que nous ayons la garantie qu'il n'y a littéralement pas de bogues. C'est un peu comme si vous écriviez une preuve mathématique de l'exactitude de l'ensemble de votre implémentation SNARK. Malheureusement, il est encore un peu tôt pour effectuer cette vérification formelle de bout en bout, mais nous avons commencé à travailler dans ce sens. L'année dernière, nous avons annoncé un programme de vérification formelle de 20 millions de dollars.

David :
[41:26] Dirigé par Alex Hicks. Et de nombreux progrès ont été réalisés. Et je m'attends à ce que cette décennie, peut-être en 2029, 2030, nous ayons un snark vérifié formellement de bout en bout, qui n'ait aucun bug. L'autre chose que je voudrais mentionner, c'est que Zcash avait un cas d'utilisation extrêmement simple, qui se résume à des transferts.

David :
[41:50] Et ce qu'ils ont fait, c'est qu'ils ont écrit ce qu'on appelle des circuits personnalisés. Ils se salissaient donc les mains avec ces snarks. Mais l'approche moderne.

David :
[42:04] C'est ce qu'on appelle les ZKVM, qui sont en fait un moyen d'utiliser la puissance des SNARK sans être un expert en SNARK. Un développeur typique, comme un développeur Rust, par exemple, peut écrire des programmes typiques et les compiler dans la ZKVM. C'est d'ailleurs l'une des conditions pour que la technologie SNARK soit suffisamment mature pour la L1. La raison en est que nous voulons prendre les implémentations EVM existantes et les compiler sur le ZKVM. Ainsi, par exemple, notre EVM, qui est l'implémentation EVM au sein de ref, qui est l'un des clients de la couche d'exécution, nous le prenons et nous le compilons pour les ZKVM. Nous pouvons prendre EVM1, qui est une autre implémentation, la compiler, EFREX, il y a ZKsync OS, et il y a aussi des implémentations qui sont écrites en Go, par exemple, Geth a une implémentation EVM. Nevermind a une implémentation en C-sharp. Et nous voulons prendre autant de ces implémentations que possible et les compiler dans les KVM. C'est une tendance très récente. C'est quelque chose qui n'existe vraiment que depuis un ou deux ans.

Ryan :
[43:19] Mais nous nous sentons bien, je pense, en nous appuyant sur les SNARC comme technologie de base pour Ethereum au niveau de la couche L1. Je veux dire qu'ils ne sont pas aussi matures que les fonctions de hachage, qui existent depuis quoi ? Je ne sais pas, depuis des décennies, n'est-ce pas ? Les années 1970, 1980, quelque chose comme ça ? Les signatures numériques également ? Je veux dire que ce sont des primitives cryptographiques très renforcées. Les snarks ont quoi, 15 ans ?

David :
[43:49] Donc théoriquement, ils ont quelque chose comme 30 ans. Mais en pratique, Zcash a été l'un des premiers projets à les mettre en production. Et il a environ 10 ans.

Ryan :
[44:00] D'accord, mais on se sent bien avec Snarks en tant que pile technologique aujourd'hui. Et en général, est-ce que les Snarks sont communément acceptés dans les cercles de cryptographie profonde comme, ouais, ça marche. Les calculs sont fiables. On ne peut pas les casser.

David :
[44:14] Oui. Mais il y a des Snarks et des Snarks. Nous avons donc toutes les exigences. Nous avons la preuve en temps réel, c'est une exigence. Nous avons la diversité. Nous avons l'aspect ZKVM. Et nous avons aussi l'exigence de la preuve en temps réel. Et nous avons l'exigence de 10 kilowatts pour la vivacité.

Justin ou David :
[44:35] Il y a une citation d'Elon Musk que j'aime bien et qui me semble pertinente : l'erreur la plus fréquente d'un ingénieur intelligent est d'optimiser une chose qui devrait plutôt être éliminée. Je veux que vous preniez cette métaphore pour vous demander pourquoi nous faisons cela. Nous parlons donc des snarks, des mathématiques qui les sous-tendent et de leur fonctionnement. Faisons un zoom arrière et parlons du pourquoi, parce qu'il s'agit en fait de faire ce qui rendrait Elon Musk heureux. Elle élimine un composant entier, que d'autres chaînes ont choisi d'optimiser. Pouvez-vous nous en parler un peu ?

David :
[45:06] Absolument. Aujourd'hui, lorsque vous exécutez un validateur, vous exécutez deux clients distincts. Vous exécutez un client de la couche de consensus. Chez moi, j'en utilise un appelé Lighthouse, et vous exécutez également un client de couche d'exécution. Celui que j'utilise chez moi s'appelle GEF. Ce que nous voulons vraiment, c'est éliminer le goulot d'étranglement de l'évolutivité. Et dans ce cas, c'est GEF. Sur mon ordinateur, GEF ne peut pas traiter un gigahertz par seconde, en partie parce que le matériel n'est pas adéquat, mais aussi parce que le logiciel ne l'est pas non plus. Et ce que j'espère faire à DevConnect dans environ 25 jours, c'est arrêter mon nœud GIF et supprimer complètement ce goulot d'étranglement. Et au lieu de compter sur GIF pour me dire que les blocs sont valides, je téléchargerai les preuves de ZKEVM. Et peu importe la taille des blocs. De mon point de vue, la preuve a toujours la même taille. C'est le S. Il est distinct. Et oui, cela résonne beaucoup avec les citations d'Elon, qui dit que nous ne devrions pas optimiser le GIF. Nous devrions simplement le supprimer complètement.

Ryan :
[46:18] Ce qui nous amène, je pense, à cette sorte de commerce de l'exécution allégée. Et pour en parler plus en détail. Nous avons donc cette nouvelle cryptographie magique SNARKs qui nous permet de faire évoluer Ethereum en général. En particulier, nous allons parler de la mise à l'échelle de la L1 ici et nous permet de le faire de la manière contrainte dont Ethereum a toujours fonctionné. Justin, vous parlez de remplacer Geth, qui est votre client d'exécution. C'est le mode bête. Avec un client ZKEVM. Donc plutôt que d'utiliser l'ancienne façon de faire un validateur, la nouvelle façon, je pense, déplace le rôle d'un validateur de l'exécution de chaque bloc, n'est-ce pas ? Comme chaque transaction et chaque bloc, au lieu d'exécuter,

Ryan :
[47:17] Vérifier qu'un bloc a été, je suppose, exécuté correctement. Peux-tu décrire cela plus en détail ? Parce que c'est la partie où nous parlons du mode bête, nous parlons de la mise à l'échelle de la L1 ici, nous parlons de l'exécution allégée pour Ethereum, et une technologie centrale ici est le ZKEVM qui change ce que les validateurs font. Ils passent de l'exécution à la vérification. Je ne sais pas si j'ai une intuition sur la façon dont cela fonctionne, pourquoi c'est possible

Ryan :
[47:51] et comment on peut le faire tout en préservant la décentralisation. Peux-tu me la donner ?

David :
[47:55] Absolument. Le processus de vérification d'un bloc est extrêmement intensif. La première chose à faire est de télécharger le bloc, ce qui constitue déjà un goulot d'étranglement, n'est-ce pas ? Si les blocs sont trop gros, vous ne pouvez littéralement pas les télécharger. Si vous disposez d'une connexion Internet domestique. Mais une fois que vous avez le bloc, vous devez charger la version la plus récente de l'état Ethereum. Et cela représente une centaine de gigaoctets. Mais bien sûr, si nous augmentons considérablement la limite de gaz, cela pourrait être des téraoctets, des dizaines de téraoctets. C'est donc un problème. Une fois l'état chargé, il faut exécuter les transactions. Et pour cela, vous avez besoin de deux ressources. Vous avez besoin d'un processeur avec de nombreux cœurs et vous avez besoin de beaucoup de mémoire vive. Et en plus de tout cela, vous devez maintenir un mempool et de nombreuses connexions peer-to-peer.

David :
[48:51] Et vous devez également stocker l'historique, qui peut également représenter des centaines de gigaoctets. Donc toute cette machinerie folle, nous la supprimons complètement et nous la vérifions comme étant à l'épreuve des coups. C'est sans état. Il n'est pas nécessaire de conserver une copie de l'état. C'est sans histoire. Il n'est pas nécessaire de conserver une copie de l'historique FM. Il est sans mémoire vive dans le sens où vous n'avez pas besoin de gigaoctets de mémoire vive. Vous pouvez avoir besoin de 100 kilo-octets de RAM. Vous n'avez pas besoin de beaucoup de cœurs, vous n'avez besoin que d'un seul cœur, et il pourrait s'agir d'un dispositif très faible. En fait, le nouveau mème que j'espère introduire est celui du Raspberry Pi Pico. Le suffixe Pico fait donc référence à ce matériel à 8 dollars par rapport au Raspberry Pi normal, qui coûte environ 100 dollars. Je pense qu'au moins, à titre d'expérience amusante, nous pourrions faire fonctionner un validateur sur un Raspberry Pi Pico.

Ryan :
[49:54] Et si c'est le cas, bien sûr, tu sais, plus de gens seront plus familiers avec, disons, un smartphone. Tu pourrais l'utiliser sur ton smartphone. Il pourrait fonctionner sur votre smartwatch, par exemple, n'est-ce pas ? Un Raspberry Pi Pico est même beaucoup plus limité que ces environnements. Donc, bien sûr, il pourrait fonctionner sur ces choses. Ce n'est plus un ordinateur portable.

David :
[50:11] Exactement. Et cela m'amène à un autre aspect du quatrième mode, qui est le point de vue des utilisateurs. Aujourd'hui, en tant qu'utilisateur, chaque fois que je consomme de l'état Ethereum, je dois le faire par le biais d'un intermédiaire qui exécute un nœud complet en mon nom. Il peut s'agir d'Infura, de Metamask, de Rabbi Wallet, etc. Cela pourrait être Etherscan. En fait, je fais confiance à ces entités pour me dire quel est l'état d'Ethereum. Et si, au lieu de cela, je pouvais vérifier directement l'exactitude de l'état d'Ethereum dans mon onglet de navigateur, comme sur mon téléphone, comme dans l'application, et que cela ne coûtait rien, que c'était instantané. Et bien, maintenant je ne suis pas soumis à toutes les défaillances de ces intermédiaires. Si, par exemple, Infura tombe en panne, je peux toujours effectuer des transactions. Si Infura ou Metamask veut censurer certains types d'applications, par exemple les transactions de l'OFAC, ils ne sont plus en mesure de le faire parce qu'ils ne sont plus autant intermédiaires. Peut-être qu'Etherscan a été piraté et que quelqu'un a mis en place une interface malveillante pour tenter de drainer un grand nombre de personnes. C'est le genre de chose qui devrait être plus difficile à faire une fois que les utilisateurs auront plus de souveraineté sur l'état valide de la chaîne.

Ryan :
[51:35] D'accord, c'est pourquoi SNARX, qui est le ZK des ZKEVM comme nous l'avons établi, atteint à la fois le mode bête parce qu'il débloque un goulot d'étranglement qui était l'exécution et nous amène au potentiel de quelque chose comme une couche 1 d'Ethereum avec 10 000 transactions par seconde. Simultanément, il atteint le mode fort, c'est-à-dire le mode de défense. C'est la défense. C'est plus de gens qui peuvent faire fonctionner des nœuds de n'importe où sur le matériel de consommation le plus basique. La raison pour laquelle Snarks est si puissant est qu'il s'agit d'une épée à double tranchant qui nous permet d'atteindre l'échelle tout en maintenant la décentralisation actuelle de l'exécution d'un nœud Ethereum, mais en l'améliorant encore, en faisant en sorte que vous puissiez exécuter un nœud Ethereum sur un smartphone ou une montre.

Ryan :
[52:27] D'accord, mais ce que nous avons fait dans cette sorte de configuration ZKEVM et dans le nouveau client d'exécution dont tu parles, et certains de ces éléments ne sont pas en développement, nous parlerons de ce que cela signifie aujourd'hui. Mais nous avons fait quelque chose d'important. Nous avons fait passer ces validateurs de l'exécution de chaque transaction à leur vérification. Mais quelqu'un fait l'exécution, n'est-ce pas ? Qui fait l'exécution maintenant dans ce monde ? Et pourquoi est-ce que c'est bien d'avoir juste...

Ryan :
[52:55] Les validateurs se contentent de vérifier plutôt que d'exécuter et de vérifier comme ils le faisaient jusqu'à présent ? Les exécuteurs sont-ils maintenant un vecteur de centralisation dans toute la chaîne d'approvisionnement de la blockchain Ethereum ?

David :
[53:07] Oui, excellente question. Nous avons donc un nouvel acteur, qui s'appelle le prouveur. Le prouveur est responsable de la génération des preuves. Il y a deux régimes que nous allons déployer en production. Le premier est le régime des preuves optionnelles, dans lequel nous nous appuyons sur l'altruisme. Nous comptons sur différents acteurs pour générer les preuves gratuitement pour le réseau. Nous comptons ensuite sur les validateurs individuels pour qu'ils acceptent de vérifier ces preuves. Il s'agit là d'une excellente preuve de concept, mais ce que nous voulons, à terme, ce sont des preuves obligatoires. Qu'est-ce que cela signifie ? Cela signifie qu'en tant que producteur de blocs, c'est-à-dire en tant qu'entité qui construit le bloc et le propose, je suis responsable de la production de toutes les preuves correspondantes. Si les preuves manquent, le bloc n'est pas valide. Il ne sera pas inclus dans la chaîne canonique. Nous devons à présent nous pencher sur les incitations. Nous ne comptons plus sur l'altruisme. Nous nous appuyons en fait sur la rationalité. La raison en est que le producteur de blocs reçoit des honoraires, le MEV, et s'il manque un bloc, il sera également pénalisé pour ce manque.

Ryan :
[54:26] Et quand tu dis producteur de blocs, producteur de blocs et prouveur sont synonymes dans ce monde ?

David :
[54:32] Ils ne le sont pas, mais pas nécessairement, devrais-je dire. Ils pourraient donc être regroupés en une seule entité et intégrés verticalement. Mais ce que je prévois, c'est que nous allons assister à une séparation des préoccupations. Aujourd'hui encore, il existe une séparation entre le proposant et le constructeur. Et ce que je prévois, c'est que le constructeur sous-traite la preuve à des prouveurs spécialisés.

Ryan :
[54:59] Je suis un peu rouillé là-dessus, d'accord ? Prover, builder, pardon, proposer, builder, prover, validator. Ok, repassez-nous en revue toute la chaîne d'approvisionnement, comment un bloc entre dans la chaîne d'Ethereum aujourd'hui, et quel sera l'état futur.

David :
[55:17] à quoi va ressembler cet état futur. Aujourd'hui, à chaque slot, il y a un validateur échantillonné de façon aléatoire, appelé le proposant, qui décidera quel bloc ira sur la chaîne.

Ryan :
[55:30] C'est le problème. Si tu gères un validateur, tu le fais chez toi.

David :
[55:33] Oui. Mais il y a une mise en garde importante, à savoir que les proposants sont supposés ne pas être assez sophistiqués pour construire les blocs les plus rentables possible. Ils vont donc déléguer à des constructeurs plus sophistiqués le soin de le faire en leur nom. C'est ce que l'on appelle la PBS (Proposer-Builder Separation). Nous disposons d'un outil appelé MevBoost qui nous aide à effectuer cette séparation. Ce qui devrait se passer à l'avenir, c'est que nous ajouterons encore un autre rôle, celui de prouveur, et que les constructeurs confieront les tâches de preuve à ces prouveurs sophistiqués. Il s'avère que le paysage des constructeurs est assez centralisé. Il est donc raisonnable de s'attendre à ce que ces deux rôles soient regroupés dans la pratique pour au moins un grand nombre de blocs.

Ryan :
[56:33] Pourquoi est-ce que c'est bien ? Pourquoi est-ce que c'est bien que les constructeurs et potentiellement les prouveurs dans le futur soient centralisés, mais qu'on se donne tout ce mal pour s'assurer que les validateurs peuvent fonctionner sur une smartwatch ?

David :
[56:46] Il y a donc plusieurs réponses. La première est liée à l'hypothèse d'honnêteté. Pour que le consensus fonctionne correctement, il faut que 50 % des participants au consensus se comportent honnêtement. Il s'agit là d'une barre extrêmement haute. Elle est très, très difficile à atteindre. Aujourd'hui, nous avons 10 000 participants au consensus, 10 000 opérateurs de validation, et 5 000 d'entre eux doivent se comporter honnêtement, ce qui n'est pas une mince affaire, mais nous y sommes parvenus.

Ryan :
[57:22] Au fait, 10 000 opérateurs de validateurs, ce sont des opérateurs de validateurs indépendants, parce que certaines personnes voient des chiffres comme des millions de validateurs, mais vous dites 10 000 et ils ne comprennent pas pourquoi vous dites 10 000 alors qu'ils voient des chiffres comme un million de validateurs sur Ethereum.

David :
[57:39] Oui, laissez-moi vous expliquer ça. Pendant de nombreuses années, il y a eu cette contrainte qu'un validateur logique individuel représentait 32 ETH, et nous avons en effet un million de ces entités de 32 ETH, mais ce qui se passe souvent, c'est qu'il y a un seul opérateur qui contrôle plusieurs de ces validateurs. Récemment, nous avons procédé à une mise à niveau appelée MaxEB, qui a permis d'augmenter le solde effectif maximum à 2000 ETH. Nous commençons donc à assister à une consolidation des validateurs. Si un opérateur unique contrôle plusieurs validateurs, il peut maintenant les regrouper pour en faire des validateurs plus grands et plus gros. En fait, si vous êtes un opérateur et que vous écoutez ce podcast, je vous encourage à consolider parce que c'est bon pour vous et c'est aussi bon pour le réseau. Mais si vous regardez les opérateurs individuels, il n'y en a pas un million, il y en a plutôt 10 000.

Ryan :
[58:35] J'ai vu des estimations de 10 000, certains disent jusqu'à 15 000. C'est du même ordre que le réseau le plus décentralisé de la crypto-monnaie, le Bitcoin. J'ai vu des estimations pour Bitcoin autour de 15 000 à 25 000 nœuds, quelque chose comme ça. Et c'est la chose que nous gardons décentralisée. Quoi qu'il en soit, je voulais juste clarifier ce chiffre, mais continuer avec le flux, si vous voulez, où vous étiez, où, vous savez, je suppose que la question était, pourquoi est-il acceptable que les constructeurs de blocs et les prouveurs à l'avenir soient très peu nombreux, sont ces entités centralisées ?

David :
[59:08] L'une des raisons est qu'il s'agit d'une minorité honnête du côté des prouveurs. Il suffit qu'un seul prouveur soit disponible pour les constructeurs pour que la chaîne continue à fonctionner. Et nous avons pris ce chiffre de N très au sérieux. N est donc au moins 100 parce qu'il y a au moins 100 opérateurs de centres de données parmi lesquels vous pouvez choisir. Mais même cela ne nous satisfait pas. Nous voulons que N soit plus grand de plusieurs ordres de grandeur. C'est la raison pour laquelle nous avons opté pour une démonstration sur site où, vous le savez, des fous comme moi pourraient faire fonctionner un prouveur depuis leur domicile. Et c'est quelque chose que j'ai l'intention de faire.

Ryan :
[59:47] Donc tout ce dont on a besoin, c'est de Justin ou d'un fou comme Justin et tout va bien. Rien n'est corrompu dans la chaîne. Aucun bloc invalide ne passe de l'autre côté.

David :
[1:00:01] C'est une solution de repli pour la vivacité. Dans le pire des cas, si nous devions nous appuyer sur les centres de données, nous fonctionnerions à un giga gaz par seconde. Puis, d'un jour à l'autre, les gouvernements diraient : "Hé, les centres de données, arrêtez le processus de démonstration". Nous retomberions alors à un niveau beaucoup plus bas, disons 100 mégas. Et la raison pour laquelle nous retomberions à 100 mégagas est que c'est le maximum qui pourrait être fait en dehors du nuage. Et ce serait très mauvais en termes de garanties pour le monde, car nous voulons avoir ce débit garanti. Nous ne voulons pas dégrader la vivacité de la chaîne. Nous voulons donc être dans une position où ce que nous déployons en production est quelque chose que nous pouvons garantir même dans une situation de type Troisième Guerre mondiale, ce qui n'est pas une mince affaire. Mais c'est quelque chose que la technologie est capable de fournir grâce aux récentes innovations.

Ryan :
[1:01:03] Bien sûr, cette garantie de pérennité est très importante pour le cas d'utilisation de la réserve de valeur, n'est-ce pas ? même si le débit des transactions chute dans ces scénarios extrêmes. La valeur stockée est toujours vivante parce que vous pouvez accéder à votre valeur sur la chaîne et en faire quelque chose. Parlons un peu plus des prouveurs. Vous avez dit que vous pourriez avoir la possibilité d'exécuter des épreuves à la maison.

David :
[1:01:27] C'est bien.

Ryan :
[1:01:28] Mais vous vous attendez aussi à ce que la fonctionnalité du prouveur soit plus centralisée dans, je suppose, la majorité des cas. Si je comprends bien, les prouveurs, c'est un profil matériel beaucoup plus large, non ? Et il s'agit d'un matériel spécialisé parce qu'il calcule des nombres ou qu'il fait des mathématiques lunaires. Bref, vous dites oui, mais non. Oui. Où est-ce que je me trompe ? À quoi cela ressemble-t-il vraiment d'être un prouveur ?

David :
[1:01:54] Oui. Il s'agit donc d'un matériel inhabituel dans le sens où la plupart des gens ne l'auront pas, mais il est fabriqué à partir de matériel de base, en particulier des GPU de jeu. Donc 16 GPU de jeu, par exemple le 5090 qui est sorti récemment, c'est suffisant pour prouver tout Ethereum en temps réel. J'ai l'intention de construire une petite plateforme GPU à la maison. Et un grand nombre de passionnés d'IA le font parce que c'est le même matériel dont vous avez besoin pour l'IA. En plus du caractère vivant, qui est l'une des questions que je pose souvent au sujet de la décentralisation des prouveurs, l'autre considération très importante est la résistance à la censure.

David :
[1:02:37] Surtout quand nous allons augmenter la limite de gaz. Parce que la façon dont nous appliquons la résistance à la censure aujourd'hui, en supposant que tous les constructeurs et l'ensemble du pipeline MEV censurent, est en s'appuyant sur une petite minorité altruiste de validateurs qui sont prêts à forcer l'inclusion de transactions du mempool sans passer par les constructeurs. Et nous avons cette proposition appelée Fossil, qui augmente d'environ 100 fois le débit total de cette inclusion forcée. Aujourd'hui, nous avons environ 10% des validateurs qui font cela de manière altruiste. Mais avec Fossil, nous aurons 16 validateurs à chaque emplacement. Il s'agit donc de tous les créneaux, et non plus de 10 % des créneaux. Et à l'intérieur d'un créneau, il y aura 16 inclusions au lieu d'une seule. D'une certaine manière, il y a donc 160 fois plus de possibilités d'inclusion forcée.

David :
[1:03:41] Et c'est quelque chose qu'il est important de faire comme condition préalable avant de passer à des limites de gaz très élevées.

Ryan :
[1:03:50] Cela signifie que les constructeurs, les prouveurs, aucun de ces composants plus centralisés, que nous appellerons centralisés entre guillemets, vous savez, comme des entités, ne peut réellement...

Ryan :
[1:03:59] censurer quoi que ce soit sur la chaîne. Donc on préserve, et on renforce en fait après Fossil, les garanties de résistance à la censure d'Ethereum. Je crois que fossil est peut-être prévu pour l'année prochaine. Je sais que c'est un peu flou, mais le fossile arrivera probablement plus tôt que d'autres choses dont nous parlerons aujourd'hui. D'accord, donc les EVM ZK, vous prenez quelque chose comme le client d'exécution, quelque chose comme Geth, et il y a beaucoup de clients d'exécution différents. Vous avez dit que vous exécutiez Geth aujourd'hui et que vous obteniez une version ZK EVM d'un client d'exécution Ethereum. Peut-être que la meilleure façon d'assembler ces pièces, où le client d'exécution se transforme en vérificateur en exécutant chaque bloc, est de parler de votre configuration à domicile et de ce que vous prévoyez pour DevConnect, d'accord ? Si j'ai bien compris, il existe de nombreux clients ZKEVM différents qui sont en cours de développement. Je suppose que vous allez peut-être en choisir un. Et puis il semble que vous allez aussi franchir une étape supplémentaire, celle d'exécuter vos propres tests à la maison. Dites-nous donc quelle est l'expérience de Justin Drake qui sera réalisée par DevConnect et nous pourrons peut-être l'intégrer dans la feuille de route plus générale. Mais que faites-vous ?

David :
[1:05:19] D'accord. Le prouveur va donc devoir attendre Noël. Je pense à un cadeau de Noël, un cluster de 16 GPU. Mais à plus court terme, en novembre pour DevConnect, j'espère faire fonctionner mon validateur en téléchargeant, comme tu l'as dit, ZKEVM Proves. Mais il n'y en aura pas qu'un seul. Ce serait en fait autant que je peux mettre la main dessus. Et le nombre que j'ai en tête est cinq.

Ryan :
[1:05:46] Cinq clients ZKEVM ?

David :
[1:05:49] Des preuves, oui. Il y a donc cinq systèmes de preuve différents. Et à chaque slot, il y aurait cinq preuves correspondantes pour chaque, enfin, une preuve par client. Il y en a donc cinq au total. Ces preuves sont très courtes et très rapides à vérifier. Il faut, par exemple, 10 millisecondes pour les vérifier. Donc, si vous en avez cinq, cela ne prend que 50 millisecondes. Ce n'est pas grand-chose. Je les téléchargerais donc tous. Et si trois d'entre eux sont d'accord, alors c'est ma source de vérité. Et la raison pour laquelle j'en télécharge plus d'un est que certains d'entre eux peuvent être bogués dans le sens où il est possible de créer une preuve pour un bloc invalide. C'est pourquoi nous voulons que plusieurs d'entre eux soient d'accord. Et certains d'entre eux peuvent présenter ce que j'appelle des bogues de complétude ou des défauts de collision.

David :
[1:06:43] Dans certaines circonstances, le système de preuve ne peut tout simplement pas générer de preuve parce qu'il y a une sorte de bug dans le système. C'est pourquoi je n'exigerais pas que les cinq preuves soient toutes d'accord. Ce n'est pas grave si deux d'entre elles n'apparaissent jamais, je pourrai quand même continuer. Il s'agit donc d'une nouvelle façon d'envisager la diversité des clients, car aujourd'hui, la diversité des clients s'applique à l'ensemble des validateurs. On regarde donc l'ensemble des validateurs et on se dit que 20 % d'entre eux utilisent le client A, 20 % le client B, etc. Alors qu'ici, la diversité est interne à un seul validateur. Et cela est possible précisément parce que nous avons les SNARK, parce qu'il est très bon marché d'utiliser plusieurs VM ZKE. Et c'est l'une des raisons pour lesquelles je pense que les ZKVM vont devenir de plus en plus populaires.

David :
[1:07:38] nous donneront une sécurité supérieure à celle que nous avons aujourd'hui. La première raison est que nous avons une diversité de clients internes par opposition à une diversité de validateurs externes. Deuxièmement, la barrière à l'entrée pour devenir un validateur sera plus basse, donc nous aurons plus de décentralisation, plus de sécurité.

David :
[1:07:57] Un autre point est que nous allons supprimer des dizaines de milliers de lignes de code. Aujourd'hui, j'exécute ce client de couche d'exécution, et tout ce dont j'ai vraiment besoin, c'est le cœur du client, c'est-à-dire l'implémentation EVM. C'est la logique, tout ce qui l'entoure, la gestion du mempool, de l'historique, de l'état et du réseau peer-to-peer, une grande partie de ce code peut être supprimée de mon point de vue d'opérateur de validateur. Il y a aussi ce qu'on appelle l'API du moteur, qui est un peu technique, mais c'est essentiellement le bus de communication entre la couche de consensus et la couche d'exécution. Historiquement, il y a eu un tas de bogues dans cette interface. Et cela va complètement disparaître parce que, encore une fois, je n'exécuterais pas un client de la couche d'exécution. Nous en arrivons donc à ce point de minimalisme. Et en fait, cela alimente un peu le mème Ethereum lean où nous essayons d'être aussi minimes que possible et de couper toute la graisse pour rester maigres.

Ryan :
[1:09:00] Ok, juste pour que je comprenne ce que tu es en train de faire ici et comment cela s'inscrit dans d'autres choses que j'ai vues au sein d'Ethereum. Tu as dit que tu prévoyais d'utiliser trois systèmes de preuve différents, des systèmes de preuve ZKEVM. Pour l'instant, je comprends que la couche d'exécution, encore une fois, la chose que nous voulons obtenir en mode bête, est un client comme Geth. Disons que c'est ce que vous utilisez aujourd'hui. Et puis la version ZKEVM de ceci est comme Reth, qui est un autre client Ethereum, plus l'un de ces trois systèmes de preuve, les systèmes de preuve ZKEVM que je montre à l'écran. Et pour ceux qui ne regardent pas cela, il s'agit d'un site web appelé ethproofs.org. Et sur ethproofs.org, vous pouvez voir la progression de différents systèmes de test ZKEVM. Est-ce que vous utilisez rath plus un de ces trois systèmes de test ou est-ce que ces systèmes de test remplacent en quelque sorte rath, et de quoi parlons-nous exactement ?

David :
[1:10:03] Oui, excellente question. Ce que nous voulons faire, c'est préserver la diversité des implémentations EVM, également connues sous le nom de clients de la couche d'exécution. Nous voulons donc avoir ref, mais aussi d'autres implémentations EVM. En ce qui concerne les clients les plus prêts, nous en avons un appelé EFREX, qui est un client Rust plus récent de la classe Lambda. Nous en avons un appelé EVM1, et nous en avons un appelé zkSyncOS, qui a été implémenté par Matterlabs. Chacun de ces quatre systèmes peut être combiné avec un système de preuve. Je peux donc, par exemple, utiliser Zysk avec EVM1. Je peux faire fonctionner Pico avec Ref. Je peux utiliser OpenVM avec EFREX. Ce que je veux essayer de faire, c'est d'avoir autant de diversité que possible, à la fois pour les implémentations AVM de la couche d'exécution et pour les ZKVM.

Ryan :
[1:11:06] J'ai compris. D'accord, juste une question secondaire. La raison pour laquelle nous avons tous ces clients d'exécution différents, dont certains dont je n'avais même pas entendu parler auparavant, tu sais, geth est peut-être un client dont beaucoup de gens ont entendu parler. Reth est une sorte d'implémentation Rust de Paradigm. Donc ils ont, vous savez, durci, ils ont conçu tout ça. Est-ce que la raison pour laquelle nous avons toutes ces différentes implémentations de clients est qu'Ethereum a une spécification renforcée ? La plupart des autres réseaux n'ont pas plus d'une implémentation client. Je me demande comment Ethereum peut en avoir des dizaines.

Justin ou David :
[1:11:39] Ethereum est la seule chaîne qui a une spécification, la seule chaîne qui a un niveau d'adoption significatif et qui a aussi une spécification.

David :
[1:11:46] Oui, donc ce que la plupart des chaînes font, c'est qu'elles ont une implémentation de référence sans préciser les spécifications. Et donc si vous voulez recréer un deuxième client, vous devez regarder l'implémentation et essayer de la copier bogue pour bogue, si vous voulez. C'est un processus extrêmement difficile. Et vous savez, c'est en partie la raison pour laquelle FireDancer dans l'écosystème Solana n'a pas encore été livré, bien que cela fasse trois ou quatre ans qu'ils y travaillent. Solana n'a tout simplement pas de spécifications. Et c'est une situation similaire avec Bitcoin.

David :
[1:12:20] Donc, mais, vous savez, avoir une spécification c'est bien, mais ce n'est pas suffisant. Nous devons également avoir une culture qui encourage la diversité et qui reconnaît la valeur qui en découle. Et la valeur, dans une très large mesure, c'est le temps de fonctionnement. Historiquement, nous avons eu de nombreux clients individuels qui sont tombés en panne et qui ont été remplacés en l'espace de quelques heures ou de quelques jours. Et pendant qu'ils sont remplacés, les autres clients servent effectivement de solution de repli. Une autre raison pour laquelle la diversité est importante, c'est qu'elle apporte de la diversité au niveau de la gouvernance. Ainsi, les développeurs d'Oracle jouent un rôle important dans les mises à niveau d'Ethereum. Et le fait qu'aucune équipe de clients n'ait un poids excessif est très sain. Enfin, la dernière raison pour laquelle la diversité, à mon avis, est extrêmement importante, c'est qu'elle nous permet d'avoir de nombreux développeurs différents, des centaines de développeurs, qui comprennent tous en même temps les rouages d'Ethereum. Je pense que Bankless est très célèbre pour sa citation selon laquelle, vous savez, la chose la plus positive pour Ethereum est d'être compris. Et je pense que lorsque vous dites cela, vous savez, du point de vue de l'utilisateur, de l'investisseur, du développeur d'applications. Mais je pense que c'est encore très vrai du point de vue des développeurs clients.

Ryan :
[1:13:40] Oui, et ça propulse Ethereum sur cette voie : n'importe qui peut construire un client dans le monde parce qu'il peut lire les spécifications, il peut construire le client, il a les compétences en développement. Tous ces clients sont donc en concurrence les uns avec les autres en termes d'innovation et d'ajout de nouvelles fonctionnalités. Et c'est une très bonne chose. D'accord, nous avons donc ces clients, peut-être ces clients mis à jour prêts pour ZK EVM, les clients d'exécution, les Geths du monde et autres, même si Geth n'est peut-être pas prêt pour cela, vous en nommez d'autres. Et puis il y a ceci : que se passe-t-il avec les preuves d'ETH ? Parce que c'est quelque chose de séparé, je pense, n'est-ce pas ? Ou est-ce que c'est séparé ? Nous avons toute une compétition ici pour faire descendre la preuve en temps réel en dessous de 12 secondes, je crois.

Ryan :
[1:14:22] Qu'est-ce qui se passe avec les preuves ETH ? Pourquoi est-ce important ? Et comment cela s'intègre-t-il dans votre installation domestique ?

David :
[1:14:30] Oui. En ce qui concerne les preuves d'ETH, l'accent est mis sur les ZKVM. Nous leur permettons de choisir leur implémentation EVM préférée. Et la grande majorité de ces ZKVM utilisent ref, ou EVM, parce que c'est l'implémentation la plus appropriée. À une exception près, Airbender de ZK Sync, qui utilise ZK Sync OS, leur propre implémentation de l'EVM. Pour la démo, je vais télécharger des preuves depuis EveProofs, et je ne vais pas être trop pointilleux sur l'implémentation de l'EVM. Il s'agit surtout d'une preuve de concept du côté de ZKVM. Mais finalement, lorsque nous aurons les preuves obligatoires, nous aurons besoin que la communauté FM parvienne à un consensus sur une liste canonique de ZKVM et sur les paires correspondantes avec les implémentations EVM. L'une des choses que vous avez dites, Ryan, c'est que lorsque nous avons de la diversité, nous avons la possibilité de faire jouer la concurrence. Et je pense qu'il s'agit là d'un aspect très sain : il est plus probable qu'improbable que nous choisissions les cinq implémentations EVM les plus rapides et les plus respectueuses des sarcasmes, de sorte que nous puissions toujours disposer de cette propriété appelée " preuve en temps réel ".

David :
[1:15:45] Et GEF a toujours été le leader. Ils étaient littéralement en situation de monopole. Ils avaient Genesis. C'était la seule option disponible. Et ils ont régné pendant les dix dernières années. Je pense que le fait qu'il y ait cette concurrence est une bouffée d'air frais et devrait conduire à de nombreuses innovations.

Ryan :
[1:16:03] Cette concurrence en particulier, peut-être que les gens, nos auditeurs ont vu les gros titres. Si vous êtes dans la cryptographie profonde, vous savez, dans Ethereum, vous avez probablement vu certaines de ces équipes atteindre une sorte de jalon. Je crois qu'ils appellent cela prouver l'EVM en moins de 12 secondes. Et cela semble devenir de plus en plus rapide. Je pense que Sysynct était l'une des principales équipes à le faire au début. Ils ont dit qu'ils avaient réussi à passer sous la barre des 12 secondes. Et maintenant, il y a d'autres équipes. Il y a quelques semaines, j'ai vu une équipe appelée Brevis. Ils ont franchi de nouvelles étapes. Qu'est-ce que cette course pour prouver que l'EVM fonctionne à une certaine vitesse ? Et pourquoi est-ce important ? Et est-ce qu'on y est déjà ?

David :
[1:16:47] Oui. La raison pour laquelle c'est important, c'est que cela ouvre la voie à l'espoir de la frontière du giga gaz. Il s'agit donc littéralement d'une création de valeur de plusieurs billions de dollars pour le monde entier, parce que nous allons débloquer la limite du gaz. Du point de vue des équipes ZKVM, c'est un moyen de prouver cette technologie et d'avoir une chance de faire partie de cette liste canonique de, par exemple, cinq ZKVM qui seraient intégrées à chaque validateur et à chaque testeur sur Ethereum. Et en fait, chaque nœud de vérification complète aurait ces cinq ZKVM intégrés. À l'heure actuelle, je maintiens ce suivi et cette liste de ZKBM. Il y en a environ 35 qui essaient de répondre à différents cas d'utilisation. Mais sur ces 35, la concurrence est rude. Nous avons réduit le nombre à environ 10 candidats à la sélection d'un site canonique pour la L1.

Ryan :
[1:17:58] Et pourquoi est-ce important, une vitesse inférieure à 12 secondes ? Et comment cela s'améliore-t-il si rapidement ?

David :
[1:18:02] Le fonctionnement d'Ethereum est le suivant : un bloc est produit et, dans le reste de l'emplacement, les attestateurs qui votent pour l'extrémité de la chaîne doivent savoir que le bloc est valide. Ainsi, pour conserver cette propriété selon laquelle les validateurs votent pour le sommet de la chaîne, ils doivent recevoir la preuve de la validité avant l'arrivée du bloc suivant. Et le bloc suivant arrive dans un créneau, c'est-à-dire dans les 10 secondes. Dans la pratique, ils doivent en fait fournir la preuve plus rapidement que 12 secondes. Il s'agit de 12 secondes moins un petit delta, car il y a tout le temps de propagation de la preuve. Le chiffre que nous avons à l'esprit est donc en réalité de 10 secondes. C'est donc notre objectif. Et nous voulons que tous les blocs économiquement pertinents puissent être prouvés en moins de 10 secondes. Il y a donc cette notion de "prover killer", qui est un bloc artificiellement construit qui prend beaucoup de temps à prouver, plus de 10 secondes. Mais ce qui se passera avec les preuves obligatoires, c'est qu'il ne sera pas rationnel pour les constructeurs de blocs de générer ces prover killers, car ils se tireraient une balle dans le pied. Ils se tireraient dans les pattes parce qu'ils ne seraient pas en mesure de générer la preuve qui conduirait à un lot manqué. Ils perdraient les frais et le MEV et seraient également pénalisés.

Justin ou David :
[1:19:28] Je vois. C'est donc un mécanisme de défense. Pouvons-nous parler de la façon dont nous allons du point A au point B ? Le point A est la situation actuelle d'Ethereum, où aucun bloc n'est vérifié, et la situation que nous souhaitons pour Ethereum, où il s'agit d'un équilibre dominant où presque tous les blocs sont vérifiés. Et nous avons initialisé avec succès l'Ethereum avec cette technologie ZK proving. Historiquement, lorsque Ethereum a fait des hard forks, c'est à ce moment-là que nous avons fait les grandes mises à jour d'Ethereum. Nous avons fait un hard fork sur la preuve d'enjeu. Nous avons fait un hard fork sur le 4844. Toutes les grandes améliorations de l'Ethereum ont été réalisées dans le cadre de cette fonction très progressive. Comme nous venons de le faire, nous avons fait un hard fork de la mise à jour.

Justin ou David :
[1:20:10] Si j'ai bien compris, ce n'est pas comme ça que ça va se passer. Ce sera différent. Peut-être pourriez-vous nous expliquer comment nous allons du point A au point B, c'est-à-dire l'intégration de toute la magie ZK dont nous avons parlé dans la chaîne. Comment cela se passe-t-il en réalité ?

David :
[1:20:23] Absolument. La feuille de route approximative que j'ai est une feuille de route en quatre étapes. La phase zéro implique qu'un très petit sous-ensemble de validateurs, environ 1 %, choisisse de vérifier des preuves générées de manière altruiste. Par exemple, générées dans le contexte des preuves ETH, qui sont, dans une large mesure, juste un budget marketing de beaucoup de ces preuves ZKVM. L'un des inconvénients de la phase zéro est qu'en tant que validateur, je perdrai les récompenses liées à la rapidité d'exécution. Il existe une récompense spéciale dans Ethereum, appelée "timeliness rewards", qui est accordée à ceux qui attestent immédiatement d'un bloc. Et je perdrai cette récompense parce que j'attesterai avec quelques secondes de retard. Cela nous amène donc à la première phase, où nous avons la preuve retardée ou l'attestation retardée, ou encore l'exécution retardée, où, en gros, au lieu d'avoir à attester immédiatement lorsque le bloc arrive, vous avez plus de temps. Pensez à un créneau entier pour attester. Ainsi, même si vous mettez quelques secondes à attester, tout va bien. Vous obtiendrez cette récompense pour votre rapidité. À ce moment-là, je m'attends à ce que le nombre de validateurs qui choisissent de participer passe d'environ 1 % à quelque chose de plus proche de 10 %. Pourquoi 10 % ?

Justin ou David :
[1:21:44] Parce que c'est à ce moment-là que l'on commence à être incité.

David :
[1:21:47] C'est compatible avec les incitations, exactement. Oui. Et c'est en fait, vous savez, vous êtes incité à le faire parce que maintenant vous n'avez pas besoin de lancer un nouveau, d'acheter un nouveau disque dur, vous savez, quand l'état devient trop grand et vous n'avez pas besoin de mettre à jour votre ordinateur s'il meurt. Ou, vous savez, je pourrais simplement vendre mon MacBook que j'utilise pour valider et acheter un Raspberry Pi à la place, par exemple. Quoi qu'il en soit, je m'attends à ce que les validateurs les plus faibles, ceux qui travaillent à domicile, optent pour ce mécanisme. Et les validateurs beaucoup plus sophistiqués, comme ceux de Coinbase, de Binance ou de Lido, continueront à fonctionner comme d'habitude.

Ryan :
[1:22:29] Et ils opteraient pour ce mécanisme parce que l'empreinte matérielle est plus faible.

David :
[1:22:32] Oui, exactement. Et à partir de là, on peut commencer à augmenter la limite de gaz, n'est-ce pas ? Car nous avons maintenant deux types de nœuds. Nous avons ceux qui vérifient les preuves. Nous pouvons augmenter la limite de gaz pour eux, sans problème. Ensuite, nous avons les opérateurs sophistiqués qui utilisent du matériel plus puissant qu'un simple ordinateur portable. Pour eux, il n'y a qu'un tas de tampons pour augmenter la limite de gaz. Ainsi, dès la première phase, il est possible d'être plus agressif avec la limite de gaz. La phase 2 est celle où la magie opère vraiment, c'est-à-dire les preuves obligatoires, où nous demandons au producteur de blocs de générer les preuves et où tout le monde est censé fonctionner sur des ZKEVM.

Ryan :
[1:23:17] C'est un hard fork ?

David :
[1:23:20] Oui, mais c'est un hard fork qui ne change que la règle de choix du fork. Il s'agit donc d'un hard fork très minimal qui dit que lorsque vous attestez, vous ne devez le faire qu'après avoir vérifié que les preuves existent et sont valides. Ce n'est donc pas une fourche difficile. C'est en fait assez simple. Et puis il y a la phase trois, qui est la phase finale. Il s'agit de ce que nous appelons des preuves enchâssées, où au lieu d'avoir une diversité de cinq ZKVM, nous n'en choisissons qu'une et nous la vérifions formellement d'un bout à l'autre. Nous sommes donc intimement convaincus qu'il n'y a littéralement aucun bogue dans ce vérificateur enchâssé. Et cela débloque toutes sortes de choses, cela simplifie la conception avant tout, mais cela débloque aussi des choses comme les validiums natifs, ce qui est, je suppose, peut-être un sujet pour un autre jour.

Justin ou David :
[1:24:16] D'accord, donc cinq ans, et c'est après cinq ans de tests de la technologie, parce que je pense que nous nous attendons plus ou moins à des bugs au cours de ces phases.

Justin ou David :
[1:24:28] Et nous devons jouer au chat et à la souris pendant un certain temps, cinq ans, avant de penser que c'est suffisamment testé pour en faire une partie formelle de la couche 1 d'Ethereum afin de vraiment débloquer toute la magie que les snarks nous offrent.

David :
[1:24:44] Exactement. Nous supposons que l'EKVM de chaque individu est cassé, mais que dans l'ensemble, en tant que groupe, il est sécurisé. Et cette phase deux, où nous avons des preuves obligatoires, on peut la considérer comme étant semi-enregistrée, où nous avons, dans un certain sens, une liste d'EKVM multiples, mais il n'y a pas celle dans laquelle nous mettons tous nos œufs dans le panier.

Justin ou David :
[1:25:07] La théorie veut que les nœuds les plus faibles, les nœuds les plus lents, les individus qui vérifient Ethereum via Starlink dans leur camping-car dans un parc, un parc national, quelque part en dehors du réseau. Ces personnes, les nœuds les plus lents de tout le groupe, sont celles qui se mettent à niveau en premier et passent du plus lent au plus rapide. Ils sautent en quelque sorte tout le monde. Et au fur et à mesure que la technologie devient plus robuste, plus prête, plus renforcée, plus efficace, elle commence à remonter la chaîne du nœud le plus lent suivant, du nœud le plus lent suivant, jusqu'à ce que nous soyons dans une sorte de nœud médian. Et ce qui commence à rester des anciens clients d'exécution, les nœuds Ethereum, ce sont les nœuds des centres de données, les nœuds Coinbase, les nœuds Kraken, les nœuds Binance, les gens avec une infrastructure lourde, lourde avec une très grande empreinte qui sont juste comme la distribution des nœuds d'Ethereum sont ceux qui se trouvent dans le centre de données. Et ils sont en quelque sorte les derniers à disparaître parce qu'ils ont le plus de mémoire tampon, le plus de bande passante. Et puis à un moment donné, ils vont basculer aussi parce que nous venons de le forker dans le protocole Ethereum. C'est en quelque sorte le plan.

David :
[1:26:20] Exactement.

Ryan :
[1:26:21] Pouvons-nous parler de cela et de la façon dont cela s'articule avec l'idée ? Donkrad a publié un billet de blog il n'y a pas très longtemps, dans lequel il évoque l'idée d'une augmentation de 3 fois pour Ethereum en termes de limite de gaz chaque année. J'aimerais vous montrer une diapositive. Je ne sais pas d'où elle vient. En fait, cela ressemble à un travail de Justin Drake. Je parie qu'elle provient de l'une de vos présentations, qui traite de ce sujet. Et donc, en ce moment, après, je crois que nous avons fait deux augmentations de la limite de gaz pour Ethereum cette année, ou était-ce juste une ?

David :
[1:26:58] Nous en avons fait deux. Nous sommes passés de 30 à 36 et de 36 à 45.

Ryan :
[1:27:02] C'est exact. D'accord. De 36 à 45. D'accord. Et l'idée derrière le post de Donkrat, je crois, était une sorte d'engagement social, de feuille de route empilant les mains pour la communauté Ethereum afin d'essayer d'augmenter Ethereum de 3x en termes de transactions par seconde et de limite de gaz chaque année. D'accord. Et donc si nous étions sur la bonne voie pour 2025, à la fin de cette année, nous serions à 100 mégagas. Il semble que nous serons peut-être à 45, ou peut-être à 60, ou quelque chose comme ça.

David :
[1:27:39] Oui, donc avec Fusaka, qui arrive en décembre, nous pourrons augmenter la limite de gaz. On me dit que 60 est sûr et que nous pourrons peut-être obtenir un peu plus, 80, peut-être 100, je ne sais pas, mais oui, quand j'ai fait ces diapositives, c'était il y a quelques mois.

David :
[1:27:57] Tomas essayait de fixer au sein de la Fondation FIM l'objectif d'atteindre une limite de méga gaz d'ici la fin de l'année et d'essayer de maintenir ce rythme de 3x que Bankrat a suggéré à l'origine dans son EIP 7938.

David :
[1:28:13] Maintenant, 3x par an, je pense que c'est une sorte de point idéal entre faisable et ambitieux. C'est donc nettement plus rapide que la loi de Moore, mais ce n'est pas complètement impossible. La proposition de Dankrat était d'atteindre cette vitesse de 3 fois par an sur une période de quatre ans. Et surtout, c'est quelque chose qui se ferait automatiquement. Aujourd'hui, la façon dont nous procédons aux augmentations des limites de gaz est extrêmement laborieuse. Ce dont nous avons besoin, c'est que les opérateurs individuels et les clients de la couche de consensus définissent de nouvelles valeurs par défaut ou que les opérateurs modifient la configuration par défaut pour que la limite de gaz augmente. Il s'agit donc d'une couche sociale, extrêmement coûteuse et nécessitant beaucoup de coordination. Ce que Dankrat a suggéré à la place, c'est qu'à chaque bloc, la limite de gaz augmente un tout petit peu, juste un ou deux gaz. Ainsi, une fois que la coordination sociale a été effectuée une fois, cela se fait automatiquement. Et ma suggestion spécifique est de passer de quatre ans à six ans, parce qu'après six ans de composition à trois fois par an, on obtient les 500 fois dont nous avons besoin pour atteindre un gigahertz par seconde.

Ryan :
[1:29:39] D'accord, et parlons-en un peu plus et combinons cela avec l'idée d'Ethereum. La raison pour laquelle nous avons été réticents à appuyer sur l'accélérateur sur la limite de gaz et le débit est que cela commencerait à augmenter les exigences pour les validateurs et à expulser nos validateurs domestiques du réseau et à pousser Ethereum davantage vers les centres de données. Et ce n'est pas ce que nous voulons. Maintenant, je suppose que le sauvetage ou la plate-forme d'atterrissage d'un Ethereum allégé est, au fur et à mesure que nous augmentons la limite de gaz, peut-être 3 fois par an, les nœuds de validation à domicile, les nœuds qui ne sont pas des centres de données dans Ethereum, ils peuvent alors migrer vers un ZK EVM et l'exécuter sur un Raspberry Pi ou un smartphone ou du matériel très bon marché. Ainsi, avant d'avoir une solution MVE ZK, ces validateurs auraient disparu pour toujours, en gros. Nous serions devenus plus centralisés, avec moins de validateurs et plus de centres de données. Mais parce qu'ils ont un ZKEVM, ils peuvent être parmi les premiers à passer à la frontière du ZKEVM lorsque la marée monte. Cela a donc ouvert le terrain de jeu pour permettre à Ethereum d'envisager d'augmenter la limite de gaz sur une base plus régulière et peut-être jusqu'à 3 fois par an. Est-ce que c'est à peu près ce qui se passe ?

David :
[1:31:08] Oui, c'est ça. D'accord.

Ryan :
[1:31:10] J'ai une autre question à poser, il y a la limite de gaz et le débit dans les deux cas. Ce que nous augmentons, c'est la limite de gaz. Est-ce exact ? Et notre limite de gaz actuelle est différente du méga gaz que nous produisons actuellement. Vous avez dit que nous étions à deux méga gaz par seconde, je crois, plus tôt dans l'épisode, mais nous avons une limite de gaz de quoi, 45 ?

David :
[1:31:32] Oui. Laissez-moi vous expliquer les maths. Il y a deux complications. La première, c'est que nous avons 12 emplacements de secondes. C'est donc 45 millions divisés par 12. Et puis il y a une autre complication, c'est qu'avec EAP-1559, nous avons un objectif et une limite où l'objectif est deux fois plus bas. Il faut donc diviser par deux. Si vous prenez 45, que vous le divisez par 12 et que vous le divisez ensuite par 2, c'est ainsi que vous obtenez 2 mégagas par seconde. C'est un peu dommage parce que, vous savez, dans un certain sens, la limite de gaz est artificielle parce qu'elle dépend de la durée du créneau. Et nous avons l'intention de réduire la durée des créneaux, par exemple, de 12 à 6 secondes. Mon modèle mental préféré est donc de penser en termes de gaz par seconde, ce qui est assez proche du concept de TPS.

Ryan :
[1:32:27] Ces phases, zéro, un, deux, la phase finale, trois. Vous avez dit qu'arriver à trois pourrait prendre cinq ans. As-tu une idée de calendrier ? Je suppose que la phase zéro démarre techniquement, vous savez, vous serez peut-être parmi les premiers à utiliser ce matériel. Dans un mois environ, le mois prochain. Quel est le calendrier pour le reste ?

David :
[1:32:49] Oui. Donc 2025 pour la phase zéro et ensuite un an pour chaque autre phase. Donc phase un, 2026, phase deux, 2027, phase trois, 2028, par exemple. Je pense que c'est un calendrier raisonnable.

Ryan :
[1:33:01] D'accord. Les ZKEVM nous permettent d'augmenter la taille des blocs et le débit. La preuve en temps réel est quelque chose dont nous avons parlé. Nous sommes en dessous de 12 secondes. Le temps de bloc sur Ethereum est de 12 secondes à l'heure actuelle. Est-ce que cela fait partie du mode bête de faire descendre ce temps à six et moins de six et jusqu'où pouvons-nous pousser cela et comment cela s'intègre-t-il dans les ZKEVM ? Devons-nous attendre que les prouveurs de ZKEVM soient suffisamment rapides pour nous faire passer en toute sécurité sous la barre des six secondes et ensuite nous pouvons faire baisser le temps réel comme la production de l'espace de bloc à quelque chose comme six, quelles sont les contraintes à respecter ?

David :
[1:33:42] Oui. Il s'avère donc que la proposition de réduire la durée des créneaux est quelque peu en concurrence avec les ZKVM parce que nous aurons globalement moins de temps de latence pour faire la preuve et que cela rendra les choses plus difficiles. Mais je pense que même si nous réduisions la durée du créneau à six secondes, nous pourrions y arriver sans problème. Cela ne ferait que retarder les choses de quelques mois, peut-être six. C'est donc une décision que la communauté doit prendre. Voulons-nous réduire la durée des créneaux au prix d'un retard de six mois pour les ZKBN ? Je suppose qu'il n'est pas de mon ressort de prendre une telle décision. Mais si vous êtes prêts à vous projeter plusieurs années dans l'avenir, par exemple en 2029, j'espère que nous pourrons aller au-delà des six secondes. Lors de l'exposé sur la chaîne de faisceaux, il y a moins d'un an, j'ai essayé d'annoncer quatre secondes. Récemment, nous avons organisé un atelier à Cambridge avec un groupe de chercheurs, et nous sommes arrivés à une nouvelle idée qui pourrait débloquer des créneaux rapides, encore plus rapides, potentiellement des créneaux de deux secondes. Je ne veux donc pas promettre trop de choses, mais je pense que nous serons en mesure d'aller

David :
[1:35:02] moins de six secondes dans le contexte du consensus lean, qui est un rebranding de la chaîne des faisceaux.

Ryan :
[Je suppose donc que dans les deux cas, que nous augmentions les limites de gaz et que nous rendions les blocs plus gros, qu'ils hébergent plus de transactions, ou que nous réduisions les temps de fente, tout cela va dans le même sens, celui d'atteindre le giga-gaz, n'est-ce pas ? Ces deux types de chiffres augmentent notre giga. Est-ce que c'est faux ?

David :
[1:35:28] Non, non, non. La réduction de la durée des créneaux ne modifie pas le débit. Donc si nous devions réduire... Cela ne change pas le débit. Si nous devions, par exemple, passer de 12 secondes à des créneaux de six secondes, nous réduirions en conséquence la limite de gaz de 2 fois.

Ryan :
[1:35:42] Oui, d'accord. C'est l'inverse. Oui, bien sûr.

David :
[1:35:46] D'accord.

Ryan :
[1:35:46] Oui. C'est pourquoi ces deux choses sont en désaccord.

David :
[1:35:50] Je veux dire, sur le papier, la réduction de la durée du créneau est en fait neutre parce qu'au moment de la bifurcation, la durée du créneau est réduite d'un facteur deux, la limite de gaz est réduite d'un facteur deux, et tout cela s'annule. Mais en termes d'ingénierie pour obtenir des preuves en temps réel, oui, ils sont un peu en désaccord parce que chaque seconde de temps du prouveur dont nous disposons est en fait très précieuse. Et cela signifie simplement que les équipes de ZKVM devront travailler encore plus dur pour réduire les choses. En attendant.

Justin ou David :
[1:36:22] Quand cette technologie sera complètement mature, n'aurons-nous pas éliminé la contrainte de temps de toute façon ? Oui. Donc, disons, dans plus de cinq ans, comme en ce moment, nous parlons vraiment de la façon dont nous pouvons intégrer cette technologie le plus tôt possible. Et c'est à ce moment-là qu'une seconde compte vraiment en termes de temps de blocage. Mais à l'avenir, une seconde n'aura plus aucune importance, n'est-ce pas ? Pouvez-vous nous en parler ? Oui.

David :
[1:36:43] Et à la fin, ce que j'envisage, c'est que nous ayons des CPU SNOC qui génèrent la preuve au fur et à mesure qu'ils effectuent le calcul. Vous avez donc une unité centrale typique qui fonctionne, disons, à trois gigahertz. Non seulement elle effectue le calcul à trois gigahertz, mais elle produit une preuve en même temps qu'elle effectue le calcul. On peut considérer qu'un cœur d'unité centrale, par exemple un cœur RISC-V, représente un millimètre carré de silicium sur la puce. Il ne prend donc pas beaucoup de place. Aujourd'hui, nous sommes capables de construire facilement des puces avec, disons, une centaine de millimètres carrés de surface de matrice. Vous pouvez donc imaginer qu'à l'avenir, lorsque vous achèterez votre processeur, il s'agira d'une puce assez grande, de 100 millimètres carrés. 1 % de cette surface est utilisée pour effectuer le calcul brut et 99 % pour faire la preuve en temps réel. Mais ici, nous ne voulons pas dire en temps réel avec le temps Ethereum, qui est d'un slot. Nous parlons en termes de temps CPU, qui est de l'ordre de la nanoseconde. D'accord.

Justin ou David :
[1:37:49] Oui, c'est intéressant.

Ryan :
[1:37:50] Le seul élément de votre installation à domicile, je veux juste le comprendre. Au début, tu vas utiliser une configuration de type ZKEVM, comme nous l'avons dit. Faire tourner des provers à la maison, d'accord, c'est votre cadeau de Noël, vous avez ces GPU, vous savez, le Père Noël a été bon pour vous, vous avez été un bon garçon, je suppose, peu importe ce que c'est. Mais il faut de la puissance, de l'énergie pour faire fonctionner les prouveurs à domicile. Et d'après ce que j'ai compris, certaines équipes travaillent à rendre cela plus efficace. Pouvez-vous nous parler de l'énergie nécessaire si vous voulez faire fonctionner votre propre prouveur à la maison ? Il s'agit essentiellement de l'électricité nécessaire à votre domicile aujourd'hui. Et qu'est-ce qu'il faut faire pour s'assurer que nous avons au moins un certain niveau de décentralisation dans ce réseau d'épreuvage ?

David :
[1:38:44] Oui, absolument. Les 10 kilowatts que j'ai mentionnés représentent environ 10 grille-pains. C'est aussi un chargeur de voiture électrique. C'est aussi un four électrique très puissant ou un chauffe-eau puissant pour votre douche. C'est donc quelque chose qui a été installé et vous n'avez pas besoin d'acheter une nouvelle maison, je suppose, pour tirer 10 kilowatts. Les GPU dont nous parlons, les GPU de jeu, consomment des centaines de watts chacun, la puissance nominale maximale étant d'environ 500 watts, soit un demi-kilowatt. Je pense donc que la taille de la grappe est de 16 GPU. Donc 16 fois 500 watts, cela fait 8 kilowatts. Il faut ensuite prévoir un tampon pour les machines hôtes et le refroidissement, car il faut des ventilateurs pour faire circuler l'air, ce qui consomme également de l'électricité. Ce que j'ai l'intention de faire pour Noël, c'est d'acheter un cluster de 16 GPU, de les connecter à mon domicile et à ma connexion Internet domestique, et de produire un bloc, une preuve pour chaque bloc Ethereum en temps réel.

David :
[1:39:57] Si vous m'aviez demandé il y a deux mois, quand est-ce que je pourrais faire cette démonstration ? Je vous aurais répondu peut-être six mois plus tard. Mais le rythme de Snarks est tellement incroyable qu'aujourd'hui, 16 GPU suffisent.

David :
[1:40:13] Nous avons donc déjà atteint l'objectif que nous nous étions fixé de 10 kilowatts. Et nous avons plusieurs équipes qui y sont parvenues. Vous avez mentionné Pico. Hier encore, une autre équipe, l'équipe Zysk, y est parvenue. Je veux dire que techniquement, ils ont utilisé 24 GPU, mais ils se sont rapprochés des 16. Nous avons également d'autres équipes. Par exemple, l'équipe AirBender, et je m'attends à ce que l'équipe Succinct atteigne également les 16 GPU. Le 22 novembre, lors de DevConnect, nous verrons donc combien d'équipes ont atteint les 16 GPU. Je m'attends à ce qu'il y en ait au moins deux, trois, voire quatre. Et si vous voulez participer à cette démo en temps réel, vous pouvez vous inscrire à EveProofsDay. C'est donc EveProofs.Day. Malheureusement, la salle dont nous disposons est limitée à quelques centaines de personnes. Et notre liste d'attente compte près de 300 personnes à l'heure actuelle. Mais inscrivez-vous quand même, car nous allons mettre en vente de nouveaux billets.

Ryan :
[1:41:23] Est-ce que ces 10 kilowatts vont être, en gros, est-ce que ça va baisser ? Donc une fois que tu auras reçu ton cadeau de Noël, tu vas faire tourner ces provers, tes factures d'électricité vont grimper en flèche, n'est-ce pas ? C'est comme faire fonctionner un chargeur Tesla 24 heures sur 24, 7 jours sur 7, en gros. Vous allez donc payer un peu plus cher. S'agit-il uniquement du coût d'exploitation d'un prouveur ou peut-on passer de 10 grille-pains à un seul grille-pain ?

David :
[1:41:47] Oui, c'est une excellente question. Il y a deux aspects. Le premier est qu'à mesure que les ZKVM s'améliorent et que vous avez besoin de moins en moins de GPU, cela va être l'occasion d'augmenter la limite de gaz. Ce que nous voulons faire, c'est continuer à augmenter la limite de gaz pour être toujours à 10 kilowatts. Nous restons donc à 10 kilowatts. C'est ainsi que nous atteindrons un giga gaz par seconde. L'autre chose que je voudrais mentionner est que, vous savez, cette phase altruiste n'est pas vraiment représentative de ce qui se passera finalement, c'est-à-dire que nous n'avons pas vraiment besoin que les solutions de repli prouvent chaque bloc tout le temps. Nous avons seulement besoin qu'ils s'activent en cas de problème. Ainsi, si tous les fournisseurs de nuages se déconnectent soudainement, les constructeurs de blocs peuvent m'utiliser comme prouveur, mais je ne m'activerai que dans un bloc sur 10 000 lorsque cela sera nécessaire. La plupart du temps, je ne consommerai pas d'électricité, si ce n'est l'électricité nécessaire pour me connecter à Internet. On peut donc considérer cela comme une sorte d'armée de réserve qui n'est activée qu'en cas de besoin.

Ryan :
[1:43:03] J'aime bien cette analogie. J'aime beaucoup. Avant d'activer vos propres prouveurs, qui va faire les preuves ? D'ailleurs, dans cette configuration, les prouveurs sont-ils motivés ? Obtiennent-ils une part des récompenses des blocs dans le cadre de ce projet ? Qu'est-ce qu'ils y gagnent ?

David :
[1:43:20] Oui. En fin de compte, les prouveurs sont motivés par les frais et le MEV, et ils seront payés par les constructeurs de blocs. Il y a une chose qui vaut la peine d'être abordée avec les yeux grands ouverts, c'est que les frais seront en fin de compte payés par les utilisateurs. Ces derniers devront donc payer davantage pour leurs transactions. Et plus précisément, vous allez devoir payer des frais de transaction,

David :
[1:43:45] qui couvrira le coût de la preuve. Mais la bonne nouvelle, c'est que le coût de la preuve pour une transaction typique est d'un centième de centime. Ainsi, pour la plupart des applications, vous ne vous rendrez même pas compte qu'il y a des frais de preuve supplémentaires qui sont ajoutés. Ce que je prévois, c'est que le MEV sera beaucoup plus élevé et que les frais de disponibilité des données seront également plus importants. Et bien sûr, à mesure que les ZKVM s'améliorent, nous allons passer d'un centième de centime par transaction à un millième de centime. Et donc, oui, c'est en fin de compte la façon dont les incitations fonctionnent.

Ryan :
[1:44:26] Seulement les frais de transaction et le MEV, pas de récompenses de consensus, pas de récompenses d'émission.

David :
[1:44:31] Donc une chose que nous pouvons faire en tant que concepteurs de mécanismes, c'est qu'au lieu de miser sur les récompenses, qui sont à mon avis totalement inutiles parce que nous avons les frais et le MEV, nous pouvons miser sur les pénalités. Nous pouvons donc mettre en place une configuration où si, pour une raison quelconque, vous ne générez pas les preuves et que vous agissez de manière malveillante, vous serez pénalisé. Et le chiffre que j'ai à l'esprit est un ETH. Si vous manquez un créneau Ethereum, vous êtes pénalisé d'un ETH parce que cela ne devrait jamais se produire, surtout dans un contexte où nous avons cette mise à niveau appelée APS, séparation attesté-proposant, où nous supprimons le proposant de l'équation et où nous n'avons que des entités sophistiquées, les constructeurs et les prouveurs. Ceux-ci devraient avoir un temps de fonctionnement extrêmement élevé. Et vous savez, il y a une externalité négative aux blocs manquants d'Ethereum, n'est-ce pas ? Cela signifie que, dans un certain sens, Ethereum saute un battement de cœur et ce n'est pas bon. Je pense donc qu'il est sain de fixer un prix pour les blocs manquants. Et c'est quelque chose que nous pourrons faire une fois que nous aurons mis à jour l'APS. Parce qu'aujourd'hui, nous supposons qu'un grand nombre de validateurs fonctionnent sur des connexions Internet domestiques, et de temps en temps, mon fournisseur d'accès à Internet se dérègle et je n'ai pas d'Internet, et nous ne voulons pas avoir cette pénalité d'un ETH juste parce que vous êtes hors ligne et que vous n'avez pas eu de chance. Mais pour les constructeurs et les prouveurs, oui, nous pouvons leur infliger une pénalité d'un ETH, sans problème.

Ryan :
[1:45:59] Wow. C'est donc le mode bête pour la mise à l'échelle d'Ethereum, la première couche. Je dois avouer, Justin, que je ne l'avais pas compris avant la conversation que nous venons d'avoir. Maintenant, je le comprends beaucoup mieux. Il y a tant d'autres choses que nous n'avons pas abordées et nous en sommes déjà à presque deux heures. Nous ne pouvons donc pas tout couvrir ici. Mais très rapidement, lorsque vous avez présenté le mode bête, vous avez également dit que ce n'était pas seulement dans cinq ans, n'est-ce pas ? Cela pourrait se produire dans cinq ans, par exemple, et il y aura une montée en puissance. Il ne s'agit pas seulement d'un Big Bang après cinq ans. Nous en sommes à 10 000 transactions par seconde. Mais ce plan pourrait nous permettre d'atteindre un gigabit de gaz, soit 10 000 transactions par seconde sur la couche 1 d'Ethereum d'ici 2030. D'accord. Nous augmentons aussi simultanément la disponibilité des données grâce à la configuration dank sharding que nous avons actuellement, de sorte que les L2 peuvent atteindre des téragas par seconde. Cela a-t-il un rapport avec les CKEVM et tout ce dont nous avons parlé ? Ou cela se passe-t-il simplement en parallèle ? Et chaque fois que nous en avons l'occasion, nous élargissons la voie rapide, la disponibilité de l'état et l'espace des blobs pour les L2.

David :
[1:47:08] Cela se passe en parallèle. Mais je tiens à souligner une chose qui fait le lien entre ces deux mondes, à savoir les rollups natifs. Un rollup natif est un rollup qui a la même exécution que L1, mais en L2. L'un des avantages majeurs des rollups natifs est que vous n'avez pas à vous soucier des bogues dans votre prouveur de snark ou votre jeu de preuve de fautes. Vous n'avez pas à vous soucier de maintenir l'équivalence avec la L1, qui elle-même évolue avec chaque hard fork et chaque EIP. Et peut-être que la chose la plus importante est que vous n'avez pas besoin d'avoir un conseil de sécurité pour gérer ces bugs et cette maintenance.

David :
[1:47:53] Et ce qui est étonnant avec cette technologie, les ZKVM, c'est que pour les L2, nous pouvons effectivement supprimer entièrement la limite de gaz. Le goulot d'étranglement n'est que la disponibilité des données. La raison en est que les L2 peuvent générer des preuves pour leurs transactions hors chaîne à l'aide de prouveurs très puissants. Ils n'ont pas besoin d'une puissance de 10 kilowatts. Ils peuvent avoir des prouveurs beaucoup plus puissants s'ils le souhaitent. La seule chose qu'ils apportent sur la chaîne est cette preuve minuscule que les validateurs peuvent vérifier. C'est la prochaine génération de roll-ups. Nous avons beaucoup de chance d'avoir Luca Dono de L2Beat, qui croit beaucoup en cette idée et qui se fait le champion du processus EIP et de tout le travail technique nécessaire pour déployer ce système sur le réseau principal.

Ryan :
[1:48:53] Quand cela se produira-t-il dans ce calendrier où nous avons parlé de, tu sais, les phases zéro à trois de la mise en place des EVM ZK ?

David :
[1:49:00] L'une des réalités d'Ethereum est que nous avons ce processus de gouvernance appelé ACD et que nous avons un nombre très limité d'opportunités de faire des hard forks. Historiquement, nous avons eu un hard fork par an. Nous essayons de doubler ce chiffre en passant à un hard fork tous les six mois. Mais même au sein d'un hard fork, il y a des limites à ce que l'on peut faire. Et il s'avère que beaucoup de développeurs différents veulent beaucoup de choses différentes. Il y a donc 10, 20, voire 30 propositions concurrentes différentes. Et dans n'importe quel hard fork, on ne peut vider la file d'attente que trois, quatre, peut-être cinq, cinq à la fois. Cela entraîne toutes sortes d'externalités, dont l'une est qu'il est très difficile de prédire ce qui passera par le processus de mort d'Oracle. Et une autre externalité est qu'il en résulte beaucoup de frustration. Vous pouvez considérer l'ACD comme une sorte de broyeur de viande ou de broyeur d'âme où vous avez des développeurs enthousiastes aux yeux brillants qui arrivent et qui ressortent frustrés et blasés parce que leur EIP n'a pas été sélectionné depuis très longtemps.

David :
[1:50:14] Un exemple ici pourrait être Fossil, n'est-ce pas ? Fossil est un projet pour lequel nous avons le PIE, toutes les recherches ont été faites. Toutes les recherches ont été effectuées, une grande partie du travail a été faite, et pourtant il n'est toujours pas inclus. Il a été question de l'inclure à Fusaka. Il a été question de l'inclure à Glamsterdam, et maintenant il est poussé, poussé et poussé. Il est donc difficile de prévoir certaines de ces choses. C'est en partie la raison pour laquelle je suis si enthousiaste à propos de Lean Consensus, parce que Lean Consensus est une optimisation de la gouvernance par lots où, pendant une période prolongée, nous nous contentons de faire de la R&D pure. Nous pouvons donc avoir cette...

David :
[1:51:00] R&D passionnante et rapide. Ensuite, ce que nous proposons à l'ACD est quelque chose de nettement meilleur que ce que nous avons actuellement, disons 10 fois meilleur. Et il faudra beaucoup de temps pour qu'il passe par l'ACD, mais lorsqu'il y passera,

David :
[1:51:17] nous regrouperons, disons 100 EIP qui auraient été dégroupés auparavant. Ainsi, au lieu que l'avenir à long terme, le jeu final d'Ethereum, si vous voulez, soit étalé sur des décennies de petites mises à niveau incrémentielles, nous avons la possibilité de mettre en lot quelque chose, des mises à niveau plus importantes sur une période de quatre ans environ.

Ryan :
[1:51:41] Nous avons surtout parlé de la couche d'exécution allégée, parce que c'est la grande partie que je ne comprenais pas. Et c'est la partie la plus importante, passer en mode " bête " et mettre à l'échelle la première couche. Nous avons parlé un peu du consensus lean, je pense, et du mode fort du point de vue de tout ce qui peut être exécuté à partir d'un smartphone ou d'une smartwatch. Mais y a-t-il d'autres éléments dans le consensus allégé ? Parce que c'est une autre couche de la pile Ethereum que vous voulez vous assurer que les gens comprennent aujourd'hui. Quand on parle d'Ethereum allégé, on parle de la couche d'exécution allégée et de la mise à l'échelle de ce mode bestial. Et vous parlez aussi de consensus allégé. Le consensus allégé est peut-être moins sexy, mais il est peut-être plus important d'une certaine manière. Et vous venez de faire allusion à l'une des raisons pour lesquelles la plupart d'entre nous, les utilisateurs, ne voient pas pourquoi c'est important. Qu'y a-t-il d'autre dans le consensus allégé que nous n'ayons pas abordé ? Et pourquoi est-ce important ?

David :
[1:52:39] L'Ethereum allégé est en fait constitué de trois initiatives différentes. Au sein de L1, vous avez trois couches, la couche de consensus, la couche de données et la couche d'exécution. Et c'est...

David :
[1:52:52] Nous n'avons même pas abordé la couche de données, si ce n'est pour dire qu'elle doit être sécurisée post-quantique. Mais oui, il se passe effectivement beaucoup de choses dans la couche de consensus. Les têtes d'affiche sont, d'une part, le remplacement des signatures agrégées BLS par un équivalent post-quantique et, d'autre part, une finalité beaucoup plus rapide. Deuxièmement, la finalité est beaucoup plus rapide. Ainsi, au lieu de prendre deux époques, ce qui représente 64 slots, cela peut prendre seulement deux ou trois slots. Une autre amélioration importante est la réduction significative de la durée des créneaux. Et la dernière amélioration est que, tout comme les VM ZKE, nous pouvons snarkifier l'intégralité de la couche de consensus de sorte que les appareils vraiment faibles, les onglets de navigateur, les téléphones peuvent vérifier entièrement non seulement la partie exécution d'Ethereum, mais aussi la couche de consensus. Ainsi, lorsque nous construisons des ponts, par exemple, entre les L1, c'est le même type de technologie qui serait utilisé. Ensuite, vous avez fait allusion à la possibilité de faire les choses différemment en termes de gouvernance. Nous avons donc procédé à de petites mises à niveau progressives. Nous avons accumulé 10 ans de dette technique. C'est l'occasion de rafraîchir et...

David :
[1:54:16] Une partie de la raison pour laquelle je suis excité par Ethereum n'est pas parce que nous avons eu 10 ans de temps de fonctionnement, mais parce que nous allons avoir encore 100 ans de temps de fonctionnement. Et au cours des 100 prochaines années, nous allons augmenter notre valeur totale sécurisée à des centaines de billions par rapport à ce que nous avons aujourd'hui, qui est juste un billion de dollars de valeur totale sécurisée. Et je pense que le processus de développement d'Oracle tel qu'il est structuré aujourd'hui est un peu la queue qui remue le chien, n'est-ce pas ? L'histoire de 10 ans, c'est la queue. Vous savez, nous avons accumulé beaucoup de dettes techniques et le chien, ce sont les 100 prochaines années. Et je pense que le Lean Consensus consiste à rééquilibrer un peu les choses pour que les 100 prochaines années où, vous savez, toute la finance sera construite au-dessus d'Ethereum, que la vision ait une chance de se matérialiser. Et cela va nécessiter de grands changements au sein de L1. Donc, dans un certain sens, Lean Ethereum est une invitation à être audacieux, à être ambitieux, et à penser aux 100 prochaines années plus qu'aux 10 dernières années.

Ryan :
[1:55:20] Justin, pour conclure, c'est peut-être l'occasion de poser une autre question. Quand je pense au contexte de cette discussion, je me dis que l'objectif d'Ethereum est de faire évoluer le réseau Ethereum vers Snarks. Ethereum, comme Bitcoin, est basé à l'origine sur la cryptographie 1.0, la cryptographie blockchain 1.0. Snarks est la cryptographie 2.0. Et donc maintenant nous appliquons Snarks et faisons, je pense que vous avez utilisé les termes, que je n'ai pas entièrement compris à l'époque, snarkifier l'ensemble de la pile. Voilà ce que c'est. C'est ce qu'est l'Ethereum allégé. Il s'agit d'une mise à niveau de l'ensemble de la pile vers la cryptographie 2.0, la génération snarks de la cryptographie. Certains réseaux pourraient suivre ces traces, d'autres non. Difficile de dire ce que fera le Bitcoin, mais il est probable qu'il s'ossifie et s'en tienne à la cryptographie 1.0 pendant longtemps.

Ryan :
[1:56:15] Je suppose que le contexte est le suivant : serons-nous capables de le faire assez vite ? Tu parlais tout à l'heure du hachoir à viande de l'ACD et du fait qu'Ethereum est si grand, qu'il y a tant de pièces mobiles, que ça peut sembler difficile ou même frustrant pour les développeurs parce qu'ils se demandent pourquoi ça ne peut pas se faire plus vite. Sommes-nous capables d'évoluer suffisamment vite pour battre des concurrents centralisés, en particulier des concurrents dotés d'équipes d'ingénieurs chevronnées ? Et je pense que cette question réagit en partie au fait que nous avions l'un des premiers auteurs de la proposition de mise à l'échelle d'Ethereum EIP,

Ryan :
[1:56:51] Dankrad, a récemment quitté l'EF pour, on pourrait les appeler un concurrent d'Ethereum, peut-être que c'est simplifier les choses. Ils vont certainement contribuer à l'écosystème Ethereum, sous la forme de l'EVM et d'autres choses. Mais il s'agit d'une nouvelle société, qui a récemment levé 5 milliards de dollars de fonds. Elle a donc les poches pleines. Elle s'appelle Tempo. Elle travaille avec Stripe et a été investie par Stripe. Ils ont donc clairement accès à TradFi, aux stablecoins et à toutes ces choses. Et il semble qu'ils vont mettre en œuvre une partie de cette feuille de route en utilisant RETH. Je veux dire, c'est une équipe paradigmatique, n'est-ce pas ? Ils vont accélérer la mise en œuvre d'une partie de cette feuille de route. Et peut-être que cela aide Ethereum d'une certaine manière, mais peut-être aussi que cela concurrence Ethereum d'une certaine manière. Et du point de vue des talents, Donkrad a certainement fait beaucoup pour Ethereum, évidemment. Mais est-ce qu'il y a un rêve de cerveau qui se produit avec certaines de ces chaînes d'entreprises plus centralisées ? Et cela vous inquiète-t-il ? Vous parlez de centaines d'années, mais aurons-nous les talents nécessaires pour durer ? Allons-nous assez vite pour battre certains de ces concurrents et mettre en œuvre cette vision ?

David :
[1:57:59] Oui, je pense qu'en faisant un zoom arrière, il y a eu une fuite des cerveaux. C'est réel, c'est important, mais ce n'est pas dans la direction à laquelle on s'attend. Il y a eu une fuite massive des cerveaux vers Ethereum. Et oui, nous avons perdu un rat minable, mais je pense que nous en avons gagné 10. Depuis que j'ai donné ma conférence sur BeamChain il y a moins d'un an, des dizaines de personnes ont rejoint la Fondation Ethereum ou ont travaillé à l'extérieur par le biais de toutes sortes d'équipes de consensus allégées. Et la quantité de talents qui sont arrivés ces derniers mois est absolument époustouflante. Si vous regardez ce que faisait Dankrat, il faisait de la cryptographie appliquée pure et dure dans le contexte de Danksharding. Et il y a plusieurs cryptographes appliqués avec lesquels je travaille tous les jours et toutes les semaines maintenant, notamment Tomar et Emil.

David :
[1:59:08] Giacomo et Angus, et tous ces gens sont d'un calibre extrêmement élevé, au moins aussi bon que Dankrad. Ils n'ont pas la réputation parce qu'ils n'ont pas travaillé pendant sept ans. Mais en termes de talent brut, je pense que nous l'avons. Et ce sont des gens, encore une fois, qui n'étaient pas sur mon radar il y a encore quelques mois. En ce qui concerne la coordination, nous avons recruté Will, qui m'impressionne chaque jour un peu plus. Nous avons Ladislaus, nous avons Sophia, et il y a aussi des gens qui ne font ni de la cryptographie pure et dure, ni de la coordination. Il y a, par exemple, Felipe qui s'occupe des spécifications, Raul qui aide avec le réseau peer-to-peer, Kev qui s'occupe des ZKBM et Farah qui travaille sur les preuves EVE. Et quand vous faites un zoom arrière, beaucoup de ces gens... Vous savez, ils sont venus à Ethereum. Par exemple, Will et Farah sont venus de Bitcoin.

David :
[2:00:13] Kev et Sophia, pardon, pas Kev, Camille, qui est l'un des coordinateurs de l'équipe de consensus et Sophia, sont venus de Polkadot. Nous avons Kev qui est venu d'Aztec. Nous avons Raul, qui vient de Filecoin, Tomar, qui vient de Kakarot et de l'écosystème StockNet, et Angus, qui vient de Polygon. Vous voyez ce que je veux dire. L'exode des cerveaux est beaucoup plus important que leur départ. Pour ce qui est de la raison de cette fuite des cerveaux, je pense qu'elle est liée à des choses que des concurrents comme Tempo n'ont tout simplement pas. C'est vrai ? Vitalik a cette fameuse citation : un milliard de dollars ne vous achètera pas une âme en tant que blockchain. Et nous avons une communauté, une vision, une idéologie, et nous avons aussi cette technologie étonnante. Et vous avez mentionné que, vous savez, vous pensez que Tempo pourrait sauter le pas et utiliser les ZKVM. Je ne retiens pas mon souffle à ce sujet. Vous savez, mon hypothèse de base est qu'ils vont avoir un très petit nombre de validateurs fonctionnant dans les centres de données. Et en fait, j'ai demandé à Ancrad, combien de validateurs pensez-vous que Tempo aura au lancement ? Et j'espère que je me souviens bien, mais je pense que sa réponse était quatre, environ quatre validateurs.

David :
[2:01:41] Et, vous savez, la communauté est également très différente. Une chose qui m'a beaucoup frappé, c'est que lorsque Dankrad est parti, il y a eu un énorme élan de gratitude pour tout le travail qu'il avait fait et pour sa contribution massive à Dank Shardang. Et puis on regarde du côté de Stripe et, vous savez, c'est vraiment triste que Patrick, vous savez, le fondateur de Stripe ait fait ce tweet à son demi-million de followers en disant, hey, bienvenue à Dankrat. Et son tweet a eu environ trois retweets.

David :
[2:02:22] Il n'y a pas de communauté à Tempo. Il y a très peu d'âme. Et je suis sûr que Dankrad a toutes sortes de raisons de quitter l'écosystème Ethereum. Mais le fait est qu'il y a une fuite massive des cerveaux vers Ethereum. Et je pense qu'une autre chose qui mérite d'être mentionnée est que je pense qu'il y a une chance raisonnablement élevée, disons un pourcentage à deux chiffres, que tempo fasse en fait d'une certaine manière partie de l'écosystème Ethereum, même si aujourd'hui ils ne sont pas prêts à le reconnaître explicitement. À mon avis, les incitations seront telles que tous les L1 voudront devenir des L2 afin de pouvoir exploiter les effets de réseau qu'Ethereum a à offrir. Pas plus tard qu'hier, en fait, ou avant hier, Ethereum a franchi les 100 milliards de dollars de Tether sur L1. Et si vous voulez effectuer des paiements, vous devez avoir accès à des pièces stables. Et il y a beaucoup d'effets de réseau autour des pièces stables sur Ethereum. Je ne serais donc pas surpris si, dans quelques années, Tempo annonçait qu'il allait devenir un L2 et que Dankrat revenait dans l'écosystème Ethereum.

Ryan :
[2:03:34] As-tu une idée de la raison pour laquelle il n'y a pas eu plus de L2 ? Certaines de ces chaînes d'entreprises, pourquoi choisissent-elles des L1 plutôt que des L2 ? Ce n'est pas seulement Tempo. S'il n'y avait que Tempo, vous diriez peut-être cela, mais Circle va dans cette direction, ainsi que Plasma, qui est en quelque sorte la fondation de Tether. Il y a eu beaucoup de nouveaux L1. Et le point de vue d'Ethereum a toujours été ce que vous avez dit, à savoir : pourquoi être un L1 quand on peut être un L2 ? C'est moins cher, les effets de réseau sont meilleurs. Pourquoi cela ne s'est-il pas encore vérifié ?

David :
[2:04:00] Oui, je veux dire que nous avons vu cette prime à la L1. Je pense que cela s'explique en partie par l'existence d'un nouvel espace de conception qui n'a pas été exploré. Les gens valorisent donc peut-être l'inconnu, comme un très grand potentiel. Je ne sais pas, ce n'est qu'une hypothèse. Je pense que Tempo, comme vous l'avez mentionné, a levé 500 millions de dollars pour une valorisation de 5 milliards de dollars. Je pense qu'elle a fait un excellent travail en cultivant la prime L1. Et maintenant qu'ils ont obtenu leurs 500 millions de dollars, je pense qu'ils peuvent pivoter en toute sécurité pour faire ce qu'il faut en matière d'incitation, c'est-à-dire exploiter au maximum les effets de réseau. Je leur recommande certainement de conserver une partie de leur trésorerie, disons au moins 1 %, afin de pouvoir pivoter d'urgence vers une L2 s'ils ne réussissent pas en tant que L1.

Ryan :
[2:04:59] Justin Drake, c'était fantastique. Lean Ethereum. Les prochaines étapes sont quoi ? DevConnect et tu vas faire une présentation, je crois.

Justin ou David :
[2:05:08] DevDisconnect du nœud Geth.

David :
[2:05:11] Oui.

Ryan :
[2:05:12] Parlez des prochaines étapes et de ce que les gens peuvent faire pour rester informés et s'impliquer.

David : [2:05:16] Oui :
[2:05:16] Oui. J'espère que DevConnect nous ouvrira les yeux et qu'en tant que communauté, nous nous mettrons tous d'accord sur le fait que nous voulons suivre la voie de ZKVM. Il y a quelques étrangleurs qui ne sont pas encore totalement convaincus, mais je pense que ce qui se passe maintenant, c'est que nous sommes en désaccord sur les délais plutôt que sur les fondamentaux. Je pense que les plus sceptiques vous diront que les ZKVM sont quelque chose pour 2029 ou 2030. Mais je pense que ce qui se passe, c'est qu'au fil du temps, de plus en plus de gens deviennent optimistes sur les échéances. Et une histoire amusante, je suppose, est que Kev, qui dirige l'équipe ZKABM, historiquement, il y a au moins un an, était, je suppose.

David :
[2:06:11] Sceptique à propos des ZKABM. Vous savez, il y avait beaucoup de questions ouvertes dans son esprit. Et c'est vraiment magnifique de voir sa pensée évoluer, vous savez, semaine après semaine, alors qu'il a été capable de cocher toutes les inconnues et tous les risques qu'il avait à l'esprit. Je pense que Kev n'est pas encore totalement convaincu des délais exacts. Mais si la technologie continue à progresser comme elle l'a fait au cours des 12 derniers mois, alors je pense que les délais ne peuvent que se raccourcir à partir de maintenant. Je tiens à souligner qu'il y aura un point de bascule lorsque la technologie ZKVM aura atteint la parité avec le débit et la qualité de la norme L1. À partir de ce moment-là, je m'attends à ce que les ZKVM ne deviennent plus le goulot d'étranglement, ce qui signifie que la technologie ZKVM s'améliorera plus rapidement que les 3x par an, ce qui est, je pense, le rythme le plus rapide auquel nous pouvons espérer mettre à niveau la L1. Le fardeau reviendra donc aux ingénieurs en mathématiques traditionnels qui ne font pas partie de la lune, pour optimiser les bases de données, le réseau et d'autres choses que la cryptographie.

Ryan :
[2:07:27] Nous allons nous arrêter là. Justin Drake, merci beaucoup de nous avoir rejoints.

David :
[2:07:31] Absolument. Merci de m'avoir invité.

Ryan :
[2:07:32] Bankless Nation, je dois vous dire que, bien sûr, les crypto-monnaies sont risquées. Vous pouvez perdre ce que vous avez investi, mais nous allons vers l'ouest, c'est la frontière, ce n'est pas pour tout le monde, mais nous sommes heureux que vous soyez avec nous dans ce voyage sans banque, merci beaucoup.