Entretien avec Vitalik : Explorer la vision d'Ethereum pour 2025, l'innovation convergente de la PoS, des couches 2, de la cryptographie et de l'IA
TechFlow SélectionTechFlow Sélection
Entretien avec Vitalik : Explorer la vision d'Ethereum pour 2025, l'innovation convergente de la PoS, des couches 2, de la cryptographie et de l'IA
Cet entretien était en chinois, et le chinois de Vitalik s'est avéré très fluide.
Dédié à des analyses Web3 approfondiesAuteur : DappLearning
Le 7 avril 2025, lors de l'événement Pop-X HK Research House organisé conjointement par DappLearning, ETHDimsum, Panta Rhei et UETH, Vitalik et Xiao Wei étaient tous deux présents sur place.
Pendant une pause de l'événement, Yan, fondateur de la communauté DappLearning, a interviewé Vitalik. L'entretien couvre plusieurs sujets tels que le passage d'ETH à la preuve d'enjeu (POS), les couches 2 (Layer2), la cryptographie et l'intelligence artificielle (IA). Cet entretien s'est déroulé en chinois, et le niveau de chinois de Vitalik s'est révélé très fluide.
Voici le contenu de l'interview (légèrement retravaillé pour plus de clarté) :
01 Avis sur la mise à niveau vers POS
Yan :
Bonjour Vitalik, je suis Yan de la communauté DappLearning. C’est un grand honneur pour moi de pouvoir vous interviewer ici.
J’ai commencé à m’intéresser à Ethereum dès 2017. Je me souviens qu’en 2018-2019, le débat entre PoW et PoS était très intense, et ce sujet suscite encore probablement des discussions aujourd’hui.
Désormais, après plus de quatre ans de fonctionnement stable du système PoS sur Ethereum, avec un réseau de consensus comptant des centaines de milliers de validateurs, le taux de change entre ETH et BTC continue toutefois de baisser. Il y a donc des aspects positifs, mais aussi certains défis.
Ainsi, à ce moment précis, quelle est votre opinion sur la mise à niveau PoS d’Ethereum ?
Vitalik :
Je pense que les prix du BTC et de l’ETH n’ont absolument rien à voir avec PoW ou PoS.
Les communautés BTC et ETH ont des voix très différentes, et leurs façons de penser sont fondamentalement distinctes.
Concernant le prix de l’ETH, il existe un problème : l’ETH peut connaître de nombreux futurs possibles. Dans certains de ces scénarios, Ethereum abrite de nombreuses applications réussies, mais celles-ci ne créent pas nécessairement assez de valeur pour l’ETH lui-même.
C’est une préoccupation partagée par beaucoup dans la communauté, mais c’est normal. Par exemple, Google développe de nombreux produits intéressants, mais plus de 90 % de ses revenus proviennent toujours de sa recherche.
La relation entre les applications de l’écosystème Ethereum et la valeur de l’ETH suit une logique similaire. Certaines applications génèrent de fortes frais de transaction, consomment beaucoup d’ETH, tandis que d’autres peuvent être prospères sans apporter proportionnellement autant de valeur à l’ETH.
C’est donc une question à laquelle nous devons réfléchir et continuer d’optimiser. Nous devons davantage soutenir les applications qui offrent une valeur à long terme aux détenteurs d’ETH.
À mon avis, le succès futur de l’ETH pourrait venir de ces domaines-là. Ce n’a pas grand-chose à voir avec l’amélioration de l’algorithme de consensus.
02 Architecture PBS et craintes de centralisation
Yan :
Oui, la prospérité de l’écosystème Ethereum est une raison importante qui attire les développeurs comme nous à y contribuer.
Alors, qu’en pensez-vous de l’architecture PBS (Proposer & Builder Separation) d’ETH2.0 ? Cela semble être une bonne direction : à l’avenir, on pourrait utiliser un simple téléphone comme nœud léger pour vérifier les preuves ZK, et chaque personne pourrait devenir validateur avec seulement 1 ether mis en jeu.
Mais le rôle du Builder risque de devenir plus centralisé. Il doit non seulement lutter contre le MEV, mais aussi produire des preuves ZK. Si l’on adopte des rollups basés (Based Rollup), le Builder aura encore plus de responsabilités, comme celle de Séquenceur.
Le Builder ne deviendrait-il pas trop centralisé ? Même si les validateurs restent suffisamment décentralisés, toute chaîne est vulnérable si un maillon faible apparaît. Comment alors garantir la résistance à la censure dans cette architecture ?
Vitalik :
Oui, je pense que c’est une question philosophique importante.
Au début du Bitcoin et d’Ethereum, il existait une hypothèse implicite :
Construire un bloc et le vérifier étaient une seule et même opération.
Par exemple, si vous construisez un bloc contenant 100 transactions, votre propre nœud doit exécuter les 100 gas correspondants. Ensuite, lorsque vous diffusez ce bloc au monde entier, chaque autre nœud doit effectuer exactement le même travail (consommant le même gas). Ainsi, si nous fixons la limite de gas de manière à ce que chaque ordinateur portable, Macbook ou petit serveur puisse construire un bloc, alors chaque nœud doit avoir une configuration équivalente pour le vérifier.
C’était la technologie précédente. Maintenant, nous disposons de nouvelles technologies comme les preuves ZK, DAS, et la validation sans état (statelessness).
Avant d’utiliser ces technologies, la construction et la vérification des blocs devaient être symétriques. À présent, elles peuvent devenir asymétriques. Construire un bloc peut devenir extrêmement coûteux, tandis que la vérification peut devenir très peu coûteuse.
Prenez l’exemple du client sans état : si nous utilisons cette technologie et augmentons la limite de gas d’un facteur 10, la puissance de calcul requise pour construire un bloc devient énorme. Un ordinateur classique ne suffit plus ; il faut alors recourir à un Mac Studio performant ou à un serveur haut de gamme.
Mais le coût de vérification diminue considérablement, car la vérification n’exige plus de stockage, seulement de la bande passante et du CPU. Avec les preuves ZK, le coût CPU disparaît également. Et avec DAS, le coût de vérification devient extrêmement faible. Ainsi, bien que construire un bloc devienne plus cher, le vérifier devient très bon marché.
Est-ce une amélioration par rapport à la situation actuelle ?
C’est une question complexe. Voici comment j’y vois : supposons qu’il existe des super-nœuds dans le réseau Ethereum, ayant une puissance de calcul élevée, nécessaires pour effectuer des calculs intensifs.
Comment empêcher qu’ils ne deviennent malveillants ? Plusieurs types d’attaques sont possibles :
Premièrement : une attaque 51 %.
Deuxièmement : une attaque par censure. S’ils refusent certaines transactions utilisateur, comment réduire ce risque ?
Troisièmement : les opérations liées à la lutte contre le MEV. Comment réduire ces risques ?
Pour l’attaque 51 %, la vérification étant assurée par les Attesters, ceux-ci doivent valider DAS, les preuves ZK et les clients sans état. Le coût de cette vérification est très faible, donc la barrière d’entrée pour être un nœud de consensus reste accessible.
Imaginons que des Super Nodes construisent les blocs, avec 90 % contrôlés par vous, 5 % par lui, et 5 % par d’autres. Si vous refusez complètement certaines transactions, ce n’est pas forcément catastrophique, car vous ne pouvez pas perturber le processus de consensus lui-même.
Vous ne pouvez donc pas lancer une attaque 51 %. Votre seul pouvoir serait de rejeter certaines transactions.
Les utilisateurs peuvent simplement attendre dix ou vingt blocs, jusqu’à ce qu’un autre nœud inclue leur transaction. C’est le premier point.
Deuxièmement, il y a le concept de Fossil.
Fossil permet de séparer le rôle de « sélection des transactions » du rôle d’« exécution des transactions ». Ainsi, le choix des transactions incluses dans le prochain bloc peut être décentralisé. Grâce à Fossil, les petits nœuds conservent une capacité indépendante d’inclusion des transactions. En revanche, les grands nœuds ont très peu de pouvoir [1].
Cette méthode est plus complexe que l’ancien modèle où chaque nœud était un simple ordinateur portable. Mais regardez Bitcoin : son architecture est déjà hybride, car les mineurs sont des centres de données spécialisés.
Dans PoS, une partie des nœuds aura besoin de plus de ressources, mais leurs pouvoirs seront limités. Les autres nœuds peuvent rester largement distribués et décentralisés, assurant ainsi la sécurité et la décentralisation du réseau. Cette approche est plus complexe, ce qui constitue un défi.
Yan :
Une excellente réflexion. La centralisation n’est pas nécessairement mauvaise, tant que nous pouvons limiter les comportements malveillants.
Vitalik :
Oui.
03 Relations entre Layer1 et Layer2, et orientations futures
Yan :
Merci pour ces précisions qui dissipent mes doutes depuis longtemps. Passons à la deuxième partie. En tant que témoin du parcours d’Ethereum, je constate que Layer2 a connu un grand succès. Le problème du TPS est désormais résolu, contrairement aux ICO d’autrefois, où les réseaux étaient saturés.
Personnellement, je trouve que L2 est très pratique aujourd’hui. Toutefois, le problème de la **fragmentation de liquidité** fait l’objet de nombreuses propositions. Quel est votre avis sur la relation entre Layer1 et Layer2 ? Est-ce que le réseau principal d’Ethereum est trop laxiste, trop décentralisé, sans imposer aucune contrainte à Layer2 ?
Layer1 devrait-il définir des règles pour Layer2, ou des modèles de partage de revenus, ou adopter des solutions comme Based Rollup ? Justin Drake a récemment proposé cela sur Bankless, et je suis d’accord. Qu’en pensez-vous ? Et si des solutions existent déjà, quand seront-elles déployées ?
Vitalik :
Je pense que nos Layer2 ont actuellement plusieurs problèmes.
Premièrement, leurs progrès en matière de sécurité sont insuffisants. J’encourage vivement toutes les L2 à passer au stade 1, voire au stade 2 cette année. Je les pousse constamment dans ce sens, tout en soutenant L2BEAT pour plus de transparence sur ces questions.
Deuxièmement, il y a le problème d’interopérabilité entre L2. Les transferts et communications entre deux L2 d’un même écosystème doivent devenir plus simples, rapides et moins coûteux.
Nous avons lancé ce travail l’an dernier, appelé Open Intents Framework, ainsi que les adresses spécifiques aux chaînes, principalement axé sur l’expérience utilisateur (UX).
Je pense que 80 % du problème d’interopérabilité entre L2 est en réalité un problème UX.
Résoudre les problèmes UX peut sembler fastidieux, mais avec la bonne orientation, on peut transformer une complexité apparente en simplicité. C’est notre objectif.
Prenons l’exemple du retrait sur Optimistic Rollup, qui prend encore une semaine. Si vous détenez un jeton sur Optimism ou Arbitrum, le transférer vers L1 ou une autre L2 prend une semaine.
Vous pouvez payer un market maker pour attendre cette semaine (contre une commission). Pour les petits montants, les utilisateurs peuvent utiliser Open Intents Framework Across Protocol pour passer d’une L2 à une autre. Mais pour les gros transferts, la liquidité des market makers est limitée, ce qui entraîne des frais élevés. J’ai publié un article la semaine dernière [2], dans lequel je soutiens la méthode 2 sur 3 : OP + ZK + TEE.
Car cette combinaison satisfait trois exigences :
Premièrement, elle est totalement sans confiance (complètement trustless), sans besoin d’un Security Council (conseil de sécurité). La technologie TEE joue un rôle d’assistance, donc on n’a pas besoin de lui faire entièrement confiance.
Deuxièmement, nous pouvons commencer à utiliser ZK, bien que cette technologie soit encore immature, donc nous ne pouvons pas encore nous y fier entièrement.
Troisièmement, nous pouvons réduire le délai de retrait d'une semaine à une heure.
Imaginez : si les utilisateurs adoptent Open Intents Framework, le coût de liquidité des market makers diminue de 168 fois, car le temps d’attente pour rééquilibrer passe d’une semaine à une heure. À long terme, nous envisageons de ramener ce délai d’une heure à 12 secondes (la durée actuelle d’un bloc), voire à 4 secondes avec SSF.
Actuellement, nous utilisons aussi l’agrégation zk-SNARK pour traiter les preuves ZK en parallèle et réduire la latence. Bien sûr, si l’utilisateur utilise directement ZK, il n’a pas besoin d’Intents. Mais via Intents, le coût est très bas. Tout cela concerne l’interopérabilité.
Concernant le rôle de L1, au début de la feuille de route L2, beaucoup pensaient pouvoir copier celle du Bitcoin : L1 aurait un rôle très limité (essentiellement la vérification des preuves), et L2 ferait tout le reste.
Mais nous avons compris que si L1 n’a aucun rôle, cela devient dangereux pour ETH.
Comme nous l’avons vu, notre plus grande inquiétude est que le succès des applications sur Ethereum ne se traduise pas par celui de l’ETH.
Si ETH échoue, la communauté manquera de fonds pour soutenir la prochaine vague d’applications. Sans rôle pour L1, l’expérience utilisateur et l’architecture seraient entièrement contrôlées par L2 et les applications. Personne ne représenterait alors l’ETH. Donc, donner plus de rôles à L1 dans certaines applications profiterait à l’ETH.
La question suivante est donc : que fera L1 ? Que fera L2 ?
J’ai publié un article en février [3] : dans un monde centré sur L2, L1 doit assumer des fonctions essentielles. Par exemple, les L2 doivent publier des preuves sur L1 ; si une L2 a un problème, les utilisateurs doivent pouvoir migrer via L1 vers une autre L2. De plus, les portefeuilles Key Store Wallet, les données d’Oracle, etc., peuvent être placés sur L1. Beaucoup de mécanismes dépendent de L1.
Certaines applications à haute valeur ajoutée, comme la DeFi, conviennent mieux à L1. Une raison clé est leur horizon temporel long : les utilisateurs doivent attendre un an, deux ans, voire trois ans.
C’est particulièrement vrai pour les marchés prédictifs. Par exemple, une question posée en 2025 pourrait porter sur un événement en 2028.
Or, si la gouvernance d’une L2 pose problème, théoriquement, tous les utilisateurs peuvent sortir (Exit) vers L1 ou une autre L2. Mais si une application sur cette L2 bloque des actifs dans des contrats intelligents à long terme, les utilisateurs ne peuvent pas sortir. Beaucoup de systèmes DeFi théoriquement sécurisés ne le sont donc pas en pratique.
Pour ces raisons, certaines applications devraient rester sur L1, ce qui nous pousse à nous intéresser davantage à l’évolutivité de L1.
Nous avons une feuille de route : d’ici 2026, environ quatre à cinq méthodes devraient améliorer l’évolutivité de L1.
Premièrement, l’exécution différée (Delayed Execution) : nous validons le bloc à chaque slot, mais l’exécutons au slot suivant. Avantage : le temps maximal d’exécution pourrait passer de 200 ms à 3 ou 6 secondes, offrant plus de temps de traitement [4].
Deuxièmement, la liste d'accès au niveau du bloc (Block Level Access List) : chaque bloc indiquera quels comptes et stockages il doit lire. C’est un peu comme un système sans état sans Witness. Cela permet de paralléliser l’exécution EVM et les entrées/sorties, une méthode simple d’exécution parallèle.
Troisièmement, la tarification multidimensionnelle du gaz [5], qui fixe une capacité maximale par bloc, cruciale pour la sécurité.
Quatrièmement, la gestion historique des données (EIP4444) : plus besoin que chaque nœud garde toutes les données indéfiniment. Chaque nœud pourrait n’en garder que 1 %, distribué via P2P : votre nœud conserve une partie, celui d’un autre une autre, etc. Cela rend le stockage plus décentralisé.
En combinant ces quatre solutions, nous pourrions multiplier par 10 la limite de gaz de L1. Nos applications pourront alors s’appuyer davantage sur L1, ce qui bénéficiera à L1 et à l’ETH.
Yan :
D’accord. Prochaine question : aurons-nous bientôt la mise à niveau Pectra ce mois-ci ?
Vitalik :
Nous espérons réaliser deux choses : la mise à niveau Pectra vers la fin de ce mois, puis Fusaka au troisième ou quatrième trimestre.
Yan :
Wow, aussi vite ?
Vitalik :
Nous l’espérons.
Yan :
Ma prochaine question est liée. En tant que témoin de la croissance d’Ethereum, nous savons qu’afin de garantir la sécurité, environ cinq ou six clients (clients de consensus et d’exécution) sont développés simultanément, impliquant une coordination massive et des cycles de développement longs.
Cela a ses avantages et inconvénients. Comparé à d’autres L1, c’est lent, mais plus sûr.
Existe-t-il des solutions pour ne plus attendre un an et demi entre chaque mise à jour ? J’ai vu que vous avez proposé quelques idées. Pouvez-vous les détailler ?
Vitalik :
Oui, une solution consiste à améliorer l’efficacité de la coordination. Nous voyons désormais plus de personnes circuler entre les équipes, facilitant la communication.
Si une équipe cliente rencontre un problème, elle peut le signaler à l’équipe recherche. L’un des avantages de Thomas, devenu l’un de nos nouveaux ED, est qu’il vient d’une équipe cliente et travaille maintenant chez EF. Il peut assurer cette coordination. C’est le premier point.
Deuxièmement, nous pouvons être plus stricts avec les équipes clientes. Actuellement, nous attendons que les cinq équipes soient prêtes avant de lancer un hard fork. Nous envisageons désormais de ne plus attendre que quatre équipes soient prêtes, évitant ainsi de bloquer sur la plus lente, ce qui stimulera l’engagement général.
04 Vision sur la cryptographie et l’IA
Yan :
Un peu de concurrence est donc bénéfique. Très bien. Chaque mise à jour est attendue avec impatience, mais sans trop faire attendre.
Passons maintenant à la cryptographie, avec des questions plus larges.
En 2021, lors de la création de notre communauté, nous avons réuni des développeurs des principales bourses chinoises et des chercheurs de capital-risque pour discuter de la DeFi. C’était vraiment une ère où tout le monde participait, apprenait et concevait la DeFi — un véritable engouement collectif.
Depuis, que ce soit pour le grand public ou les développeurs, apprendre la ZK — Groth16, Plonk, Halo2 — est devenu de plus en plus difficile à suivre, surtout avec les progrès techniques rapides.
En outre, la montée rapide des ZKVM rend les ZKEVM moins populaires. À mesure que les ZKVM mûrissent, les développeurs n’auront plus besoin de se soucier des bases de la ZK.
Quels conseils ou avis pouvez-vous donner là-dessus ?
Vitalik :
Pour l’écosystème ZK, la meilleure direction est que la plupart des développeurs ZK utilisent des langages de haut niveau (HLL). Ils peuvent écrire leurs applications en HLL, pendant que les chercheurs en systèmes de preuve continuent d’optimiser les algorithmes de base. Les développeurs doivent être stratifiés : ils n’ont pas besoin de comprendre ce qui se passe au niveau inférieur.
Un problème actuel est que l’écosystème Circom et Groth16 est très développé, mais impose de fortes limitations à l’application ZK. Groth16 présente plusieurs défauts : chaque application nécessite un Trusted Setup, et son efficacité n’est pas optimale. Nous devons donc investir davantage pour aider les HLL modernes à réussir.
Une autre bonne voie est celle du ZK RISC-V. RISC-V devient un HLL : de nombreuses applications, dont l’EVM, peuvent être écrites dessus [6].
Yan :
Parfait, ainsi les développeurs n’auront plus qu’à apprendre Rust. L’année dernière, à Devcon Bangkok, j’ai été impressionné par les progrès de la cryptographie appliquée.
Que pensez-vous de la convergence entre ZKP, MPC et FHE ? Avez-vous des conseils pour les développeurs ?
Vitalik :
Oui, c’est très intéressant. Je pense que FHE a un bel avenir, mais un souci demeure : MPC et FHE nécessitent toujours un comité, par exemple sept nœuds ou plus. Si 51 % ou 33 % de ces nœuds sont compromis, tout le système échoue. C’est comme avoir un Security Council, voire pire. Car si une L2 est au stade 1, le Security Council doit perdre 75 % des nœuds pour que le système échoue [7]. C’est le premier point.
Deuxièmement, concernant le Security Council : s’il est fiable, ses membres mettent généralement leurs clés hors ligne (cold wallet). Mais dans MPC et FHE, le comité doit rester en ligne pour que le système fonctionne, souvent sur un VPS ou serveur, ce qui le rend plus facile à attaquer.
Cela m’inquiète un peu. Ces technologies permettent de belles applications, mais ne sont pas parfaites.
Yan :
Pour finir, une question plus légère. Je vois que vous suivez aussi l’IA. Permettez-moi de mentionner quelques idées :
Elon Musk dit que l’humanité pourrait n’être qu’un programme d’amorçage pour une civilisation basée sur le silicium.
Dans « The Network State », on affirme que les États autoritaires préfèrent l’IA, tandis que les démocraties préfèrent la blockchain.
D’après notre expérience dans la crypto, la décentralisation suppose que chacun respecte les règles, s’équilibre mutuellement et assume les risques, ce qui aboutit souvent à une élite dirigeante. Qu’en pensez-vous ? Juste un échange d’idées.
Vitalik :
Oui, je réfléchis par où commencer.
L’IA est un domaine complexe. Il y a cinq ans, personne n’aurait prédit que les meilleurs IA fermés viendraient des États-Unis, et les meilleurs IA open source de Chine. L’IA renforce les capacités de tous, mais parfois aussi celles des régimes autoritaires.
Mais l’IA peut aussi avoir un effet démocratisant. Quand j’utilise l’IA, je remarque que dans les domaines où je suis déjà parmi les 1000 meilleurs mondiaux — comme le développement ZK — l’IA m’aide peu ; j’écris encore la majorité du code. Mais dans les domaines où je suis novice, l’IA m’aide énormément. Par exemple, je n’avais jamais développé d’application Android native. Il y a dix ans, j’avais utilisé un framework JavaScript transformé en app, mais rien de natif.
Au début de cette année, j’ai testé GPT pour créer une app. En une heure, c’était fait. La différence entre experts et novices a été fortement réduite grâce à l’IA, et l’IA ouvre de nombreuses nouvelles opportunités.
Yan :
Pour compléter, merci pour ce nouvel angle. Je pensais qu’avec l’IA, les programmeurs expérimentés apprendraient plus vite, au détriment des débutants. Mais effectivement, les débutants gagnent aussi en compétences. Plutôt une forme d’égalisation, pas de division, non ?
Vitalik :
Oui. Mais une question importante à méditer est l’impact social de la combinaison de nos technologies : blockchain, IA, cryptographie, etc.
Yan :
Vous espérez donc que l’humanité ne sera pas dominée par une élite ? Vous visez plutôt un optimum de Pareto pour toute la société. Grâce à l’IA et à la blockchain, l’individu moyen devient un super-individu.
Vitalik :
Oui oui, super-individus, super-communautés, super-humains.
05 Espoirs pour l’écosystème Ethereum et conseils aux développeurs
Yan :
Ok, dernière question : quels sont vos espoirs et messages pour la communauté des développeurs ? Qu’aimeriez-vous dire aux développeurs d’Ethereum ?
Vitalik :
Pour les développeurs d’applications Ethereum, réfléchissez bien.
Désormais, développer sur Ethereum offre énormément d’opportunités. Des choses impossibles auparavant sont désormais faisables.
Plusieurs raisons à cela :
Premièrement : la TPS de L1 était insuffisante, ce problème est résolu ;
Deuxièmement : la confidentialité était impossible, elle l’est désormais ;
Troisièmement : l’IA a rendu le développement de tout bien plus facile. Malgré la complexité croissante de l’écosystème Ethereum, l’IA permet à chacun de mieux le comprendre.
Ainsi, de nombreux projets qui ont échoué il y a cinq ou dix ans pourraient réussir aujourd’hui.
Dans l’écosystème actuel des applications blockchain, le plus grand problème est qu’il existe deux types d’applications.
Le premier type est très ouvert, décentralisé, sécurisé, très idéaliste… mais n’a que 42 utilisateurs. Le second type, ce sont des casinos. Or, ces deux extrêmes sont malsains.
Nous voulons donc des applications :
Premièrement, utiles, appréciées des utilisateurs, ayant une vraie valeur,
des applications qui améliorent le monde.
Deuxièmement, dotées de modèles économiques viables, capables de fonctionner durablement sans dépendre uniquement des fonds limités de fondations ou d’organisations. C’est un défi.
Mais aujourd’hui, chacun dispose de plus de ressources qu’avant. Trouver une bonne idée et bien l’exécuter offre de grandes chances de succès.
Yan :
En regardant le chemin parcouru, Ethereum est vraiment un succès, guidant constamment l’industrie, résolvant activement les problèmes dans un cadre décentralisé.
Un autre point fort : notre communauté est aussi à but non lucratif. Grâce aux subventions Gitcoin de l’écosystème Ethereum, aux récompenses rétrospectives d’OP, et aux airdrops d’autres projets, nous constatons que construire sur Ethereum apporte un large soutien. Nous réfléchissons à la pérennisation de notre communauté.
Construire sur Ethereum est passionnant. Nous espérons vivement voir la réalisation de l’ordinateur mondial. Merci pour votre temps précieux.
Entretien réalisé à Mosheung Ling, Hong Kong
7 avril 2025
Photo souvenir avec Vitalik 📷
Voici les références mentionnées par Vitalik dans cet article, compilées par l'équipe TechFlow :
[1] :
https://ethresear.ch/t/fork-choice-enforced-inclusion-lists-focil-a-simple-committee-based-inclusion-list-proposal/19870
[2] :
https://ethereum-magicians.org/t/a-simple-l2-security-and-finalization-roadmap/23309
[3] :
https://vitalik.eth.limo/general/2025/02/14/l1scaling.html
[4] :
https://ethresear.ch/t/delayed-execution-and-skipped-transactions/21677
[5] :
https://vitalik.eth.limo/general/2024/05/09/multidim.html
[6] :
https://ethereum-magicians.org/t/long-term-l1-execution-layer-proposal-replace-the-evm-with-risc-v/23617
[7] :
https://specs.optimism.io/protocol/stage-1.html?highlight=75#stage-1-rollup
Bienvenue dans la communauté officielle TechFlow
Groupe Telegram :https://t.me/TechFlowDaily
Compte Twitter officiel :https://x.com/TechFlowPost
Compte Twitter anglais :https://x.com/BlockFlow_News
