Interprétation du billet de Vitalik : La prochaine étape des infrastructures Web3 sera-t-elle l'emballage ou l'extension ?
TechFlow SélectionTechFlow Sélection
Interprétation du billet de Vitalik : La prochaine étape des infrastructures Web3 sera-t-elle l'emballage ou l'extension ?
Cet article explorera les compromis de conception entre « encapsulation » et « extension » adoptés par les infrastructures Web3, ainsi que quelques réflexions personnelles sur cette question concernant les infrastructures des blockchains publiques.
Dédié à des analyses Web3 approfondiesAuteur : CP, CTO et cofondateur d'Artela
Vitalik a publié la semaine dernière un article de blog intitulé « Should Ethereum be okay with enshrining more things in the protocol ? », partageant ses réflexions sur l'intégration (« enshrine ») dans le protocole des fonctionnalités fondamentales nécessaires aux applications de couche supérieure, et explorant comment établir un cadre pour intégrer davantage de ces fonctions essentielles.
Il s'agit d'une question clé à laquelle tout système de type plateforme est confronté : faut-il que l'équipe intègre directement certaines fonctionnalités critiques des applications dans la couche inférieure, ou bien les développeurs d'applications doivent-ils étendre eux-mêmes ces fonctionnalités au niveau applicatif ? Lorsque les infrastructures atteignent le stade précédant une expansion à grande échelle, le choix entre « intégration vs extension » devient crucial et peut déterminer leur capacité à être adoptées massivement.
Ces derniers mois, plusieurs grandes infrastructures ont annoncé des mises à jour technologiques importantes : Uniswap a introduit le mécanisme Hook permettant de créer des pools personnalisés ; MetaMask a lancé Snaps, offrant aux développeurs la possibilité d’ajouter des extensions utilisateur ; et Ethereum fait désormais face à son propre dilemme entre « intégration et extension ».
Cet article examine les choix effectués par les infrastructures Web3 concernant ce dilemme « intégration vs extension », ainsi que mes propres réflexions sur cette problématique dans le contexte des blockchains publiques.
Quel problème Ethereum doit-il résoudre ? Intégrer ou étendre
Sur la question du « intégrer vs étendre », Ethereum a toujours choisi l’option « extension ».
La philosophie de conception d’Ethereum s’inspire d’Unix : créer un noyau minimaliste et universel, et laisser les besoins des utilisateurs être satisfaits par les développeurs au niveau applicatif. La technologie clé qui rend cela possible est la machine virtuelle Ethereum (EVM). Grâce à un langage de contrats intelligents Turing-complet, les développeurs peuvent personnaliser librement leurs applications.
Ce modèle semble logique, mais il ne fonctionne pas si bien sur un « Unix décentralisé ». L’une des raisons principales est que la prétendue « complétude de Turing » de l’EVM n’est pas vraiment complète en pratique. En raison du mécanisme de gas et du nombre limité d’opcodes, les programmes doivent accomplir leurs tâches en un nombre fini d’étapes avec des opcodes restreints. Cela limite fortement la capacité des applications à être aussi puissantes que les logiciels Web2 au niveau utilisateur. De nombreuses fonctionnalités avancées dont les dApps ont besoin ne sont pas supportées par l’EVM. Que ce soit les rollups ou les wallets AA, même s’ils peuvent fonctionner sans modifier la couche L1, ils restent des produits MVP dont l’efficacité et l’expérience utilisateur sont encore loin de leurs objectifs.
Les développeurs ont alors une autre option : les EIP. Faire intégrer par l’équipe centrale d’Ethereum les fonctionnalités critiques dont ils dépendent, afin qu’elles soient disponibles nativement au niveau du protocole.
Puisque l’approche « extension » basée sur l’EVM ne suffit plus aux besoins croissants des applications, il est maintenant nécessaire de sérieusement envisager l’« intégration ».
Mais intégrer des fonctionnalités applicatives dans une infrastructure décentralisée n’est pas simple. Ce n’est pas seulement ajouter du code : c’est affronter le plus grand défi des systèmes décentralisés — la gouvernance. L’« intégration » signifie que l’équipe centrale, en plus du développement et de la maintenance, doit assumer la gouvernance de ces nouvelles fonctions. Cela risque aussi d’affaiblir le modèle de confiance d’Ethereum et d’introduire des problèmes durables.
Le résultat est donc facile à prévoir : le nombre de fonctionnalités pouvant être intégrées par l’équipe centrale est limité ; elles doivent bénéficier d’un large consensus communautaire ; et leur mise en œuvre est lente, souvent sur plusieurs années.
Cela signifie également que si votre fonctionnalité n’est pas considérée comme fondamentale par la communauté, Ethereum pourrait ne jamais l’accepter. Vous seriez alors contraint de construire votre propre chaîne d’application, supportant des coûts élevés de développement et d’exploitation, et perdant ainsi les bénéfices de la composable des contrats intelligents.
Sur la question du « intégrer vs étendre », Ethereum n’a pas encore de solution claire. Comment organiser efficacement ce processus d’« intégration » ? Comme le mentionne Vitalik, ils explorent encore un cadre permettant d’identifier quelles fonctions intégrer, et comment les intégrer.
Que pouvons-nous encore apprendre d’Unix ? Les Extensions Natives !
Le problème d’Ethereum vient principalement du fait que l’EVM manque de capacité d’extension, obligeant l’équipe centrale à compenser via l’intégration. Changeons de perspective : et si nous augmentions la capacité d’extension au niveau applicatif ? Par exemple, permettre aux développeurs d’ajouter eux-mêmes des fonctionnalités de base selon leurs besoins, sans attendre que l’équipe centrale les intègre.
Nous savons qu’Ethereum s’inspire largement de la philosophie d’Unix. Continuons donc à explorer les idées dans l’univers Unix.
Les systèmes d’exploitation commerciaux basés sur Unix font face à une grande diversité de besoins applicatifs, y compris des exigences spécifiques aux entreprises. Pourtant, leurs équipes centrales n’ont pas un fardeau élevé d’« intégration », car elles offrent une forte extensibilité, permettant aux utilisateurs de résoudre eux-mêmes la plupart des fonctionnalités.
Prenons Mac OS X comme exemple. Comme la plupart des systèmes d’exploitation, il distingue le mode noyau (kernel) et le mode utilisateur (user). Les applications s’exécutent généralement en mode utilisateur, utilisant les services fournis par le noyau. Une analogie simplifiée (mais imparfaite) serait que les contrats intelligents sur EVM sont comme des applications utilisateur, tandis que la couche protocole d’Ethereum correspondrait au noyau.
Mais Mac OS X permet aux développeurs d’installer leurs propres programmes dans le noyau pour étendre ses fonctionnalités, sans avoir besoin que l’équipe centrale intègre chaque cas individuellement. Le système propose deux mécanismes : « kernel extensions » et « system extensions », autorisant les développeurs à étendre le noyau sous certaines règles de sécurité, avec des privilèges plus élevés, afin de réaliser des fonctions impossibles en mode utilisateur.
L’idée inspirante est donc : ce modèle d’« extension de noyau » pourrait-il fonctionner sur un « Unix décentralisé » ? Son fonctionnement est illustré ci-dessous.
Sur une blockchain, en plus des « contrats intelligents », on pourrait supporter un autre type de programme appelé « Native Extension », qui :
1) dispose d’un accès plus large aux API du protocole de base
2) bénéficie d’un environnement d’exécution nettement plus efficace que l’EVM
3) est isolé du protocole de base, sans compromettre sa stabilité
4) n’a donc pas besoin d’être maintenu par l’équipe de base, mais peut être géré indépendamment par les équipes applicatives
Si ce modèle répondait techniquement à ces quatre critères, il résoudrait de nombreux problèmes : les développeurs pourraient personnaliser leurs fonctionnalités de base sans attendre l’intégration par l’équipe centrale.
Appelons provisoirement ce paradigme le « paradigme Native Extension », et voyons maintenant s’il existe déjà des traces de ce concept dans les infrastructures Web3 existantes.
Hook, Hook, Hooks…
Dans le monde logiciel, les grandes innovations naissent souvent de grands besoins. Uniswap, en tant qu’infrastructure DeFi, se trouve à un tournant décisif vers le statut de « plateforme », et a proposé une solution élégante au dilemme « intégrer vs étendre » : les Hooks. Ils permettent aux développeurs d’étendre librement les pools sans permission, créant des expériences variées sans que l’équipe centrale doive constamment intégrer de nouvelles fonctionnalités.
Le mécanisme Hook ressemble fortement aux conditions du « Native Extension » décrit plus haut :
· Un Hook peut s’insérer dans le cycle de vie d’un pool et accéder aux données d’exécution, offrant un niveau d’accès plus élevé
· Un Hook est un contrat séparé du pool, et sa sécurité n’affecte pas celle du pool
· Du point de vue de la gouvernance, les Hooks sont développés et déployés sans permission par des tiers, ne sont pas activés globalement, mais liés spécifiquement par chaque pool selon ses besoins.
Le design des Hooks est simple et efficace, résolvant brillamment la question de l’extensibilité des pools. Les infrastructures applicatives ont été les premières à adopter ce concept. Voyons maintenant comment les protocoles de base (L1/L2) abordent cette problématique.
Les approches d’extension des nouvelles blockchains
Face aux difficultés d’Ethereum, examinons les projets Layer 2, qui cherchent à étendre la couche L1, et leurs solutions.
Arbitrum Stylus : permettre aux développeurs de créer eux-mêmes des contrats précompilés !
Comme vous le savez probablement, l’EVM peut étendre ses fonctionnalités via des « contrats précompilés ». Leur code ne s’exécute pas dans l’EVM, mais est intégré directement dans les nœuds, au niveau bas. Par exemple, pour ajouter un nouvel algorithme de cryptographie trop coûteux en calcul, on peut l’implémenter comme contrat précompilé, que les autres contrats peuvent ensuite appeler. Toutefois, seul l’équipe d’Ethereum peut ajouter de tels contrats, via un processus EIP — les développeurs n’y ont pas accès directement.
Arbitrum Stylus propose un paradigme « EVM+ » : tout en restant compatible avec l’EVM, la couche L2 permet aux développeurs de déployer sans permission des contrats précompilés plus performants, dépassant les limites de l’EVM. Techniquement, cela repose sur l’ajout d’un environnement d’exécution WASM au niveau exécutif, capable de charger dynamiquement des contrats WASM. Le WASM offre une efficacité supérieure d’un ordre de grandeur à l’EVM, et supporte plusieurs langages de programmation.
C’est une solution prometteuse au problème d’« intégration » d’Ethereum : les besoins d’extension de l’EVM n’attendent plus l’équipe centrale. Cette dernière se concentre sur la maintenance de l’environnement d’exécution, tandis que l’introduction, le développement et la gouvernance des nouvelles fonctionnalités sont délégués à la couche applicative.
Toutefois, Stylus en est encore à ses débuts. Les défis potentiels n’ont pas encore tous émergé, et les cas d’usage sont limités : pour l’instant, seul le déploiement dynamique de contrats précompilés est supporté. Or, Ethereum fait face à bien d’autres problèmes d’intégration. Néanmoins, c’est l’une des réalisations les plus proches du paradigme « Native Extension ». En tant que représentant des nouvelles infrastructures, elle introduit une conception d’extensibilité pensée pour la croissance future de son écosystème.
Native Extension : une approche de « encapsulation modulaire » !
Après cet aperçu des projets Web2 et Web3, revenons à la question du « intégrer vs étendre ». Une piste claire émerge : améliorer la capacité d’extension pour permettre aux développeurs d’encapsuler eux-mêmes leurs fonctionnalités de manière modulaire.
C’est précisément le rôle central du paradigme « Native Extension » dans les infrastructures : en renforçant leur extensibilité, on redonne le contrôle aux développeurs. Ainsi, sans compromettre la stabilité du protocole de base, ils peuvent librement encapsuler et étendre les fonctionnalités dont ils ont besoin, de façon modulaire.
Ethereum cherche à améliorer l’efficacité de l’« intégration », Arbitrum Stylus libère les contrats précompilés. À plus long terme, les blockchains peuvent adopter le paradigme Native Extension pour libérer pleinement la créativité applicative, à l’image de l’impact ressenti avec Uniswap V4.
Une nouvelle blockchain L1 basée sur le paradigme Native Extension : Artela
Changeons maintenant de perspective. « Nous » désigne ici mon équipe, en tant que CTO d’Artela. Voici nos réflexions et actions sur ce sujet.
Sur la blockchain Artela, outre l’EVM, nous avons intégré un environnement d’exécution WASM. Celui-ci peut exécuter des programmes avec état, similaires à des contrats précompilés persistants. En outre, il supporte un mécanisme similaire aux Hooks, capable de déclencher l’exécution à différents points du cycle de traitement des blocs et des transactions. Ainsi, contrairement à Arbitrum Stylus qui se limite aux contrats précompilés, Artela permet de personnaliser entièrement le flux d’exécution des transactions et des blocs, offrant une encapsulation fonctionnelle bien plus large. Par exemple, un « Native Extension » WASM peut être déclenché lors de la phase de validation d’une transaction, utilisant un nouvel algorithme pour identifier et vérifier celle-ci. Ces points d’insertion s’appellent des « Join Points », et les extensions ne sont pas appelées « Smart Contracts », mais des « Aspects » — une notion proche de la programmation orientée aspect (AoP). Ainsi, dans le système blockchain en cours d’exécution, de nouvelles fonctionnalités peuvent être insérées dynamiquement à chaque « Join Point » !
Prenons un exemple concret. Lors de discussions avec des investisseurs et institutions Web2, nous avons identifié le principal frein à l’adoption massive du Web3 : la sécurité ! Les technologies de gestion des risques de niveau Web2 garantissent la sécurité de milliards d’actifs, mais elles peinent à s’intégrer à la pile technologique Web3. Carl, venu du domaine spatial chez NASA, exprime un avis similaire : pourquoi avons-nous besoin de Runtime Protection et des Aspects ?
La protection au runtime est essentielle en matière de sécurité. Actuellement dans le Web3, nous disposons de nombreuses solutions : audits statiques, vérification formelle, surveillance en temps réel, anticipation de transactions… Mais comparé aux systèmes de contrôle de risque en temps réel du Web2, nous sommes encore loin du compte. Le problème fondamental est que les mesures de sécurité autour du mempool sont limitées : une fois la transaction sortie du mempool, il n’est plus possible d’intervenir. Si, après le mempool, pendant l’exécution, on disposait d’une capacité d’extension, permettant aux experts de sécurité de déployer des politiques de sécurité au niveau runtime, le niveau de sécurité grimperait d’un cran. C’est exactement ce que les Aspects offrent : une capacité d’extension sécurisée au niveau exécutif !
Un développeur peut déployer un Aspect dédié à son projet, pour personnaliser des fonctionnalités au niveau protocole. Par exemple, activer une sécurité au runtime : si une transaction risque de provoquer un vol important de fonds, elle sera interceptée par l’Aspect.
Un développeur peut aussi déployer un Aspect public, encapsulant des fonctionnalités de base réutilisables par plusieurs projets. Par exemple, un Aspect implémentant un algorithme ou un type de transaction spécifique, rendant les wallets AA plus programmables et composable. D’autres développeurs peuvent alors activer cet Aspect pour bénéficier de cette fonctionnalité au niveau fondamental.
Pour Artela, notre conviction s’est renforcée au fil du chemin :
· Permettre aux développeurs de résoudre les problèmes via des Native Extensions sans permission, plutôt que d’attendre l’intégration par l’équipe centrale
· Encourager les grandes institutions et capitaux venus du Web2 à s’engager sur la blockchain (grâce à une supervision runtime de niveau Web2)
· Offrir aux développeurs un écosystème propice à l’innovation transversale (l’EVM atteint vite ses limites ; combiné aux Native Extensions, il offre bien plus de potentiel)
· Créer un foyer idéal pour les dApps comme les jeux multichaînes ou les actifs réels (RWA), qui souhaitent migrer davantage de logique métier sur la blockchain
Nous constatons qu’Ethereum est encore dans une phase où il réfléchit à la manière d’« intégrer » des caractéristiques applicatives, sans plan clair pour alléger cette pression d’intégration et redonner la créativité aux développeurs. Pour la prochaine génération d’innovateurs audacieux souhaitant repousser les limites des applications décentralisées, cette situation est très contraignante : ils ont besoin d’un réseau décentralisé robuste, mais ne peuvent pas pleinement s’exprimer. C’est pourquoi nous avons choisi de construire une nouvelle blockchain L1 basée sur le paradigme Native Extension : une infrastructure qui ne freine pas l’innovation.
Importer le Web2
Pour conclure, terminons par ces deux mots. Bien que, du point de vue du code, les piles Web3 décentralisées et Web2 relèvent de logiques totalement différentes, rien ne nous empêche d’aller puiser des trésors dans la bibliothèque du Web2, au niveau de la philosophie de conception ou de l’histoire du développement. Continuez à construire !
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
@Artela_Network
