La prochaine évolution ne ressemblera ni à Bitcoin, ni à Ethereum, ni à Solana. Elle ne sera pas dominée par l’art NFT ou les memecoins. Il est probable qu’elle ne s’appuiera pas sur l’Ethereum Virtual Machine (EVM) ni sur la Solana Virtual Machine (SVM). Les blockchains s’intégreront discrètement au web comme couche de communication sécurisée entre les applications, à l’image du passage de HTTP à HTTPS. L’impact sera notable, mais l’expérience des utilisateurs et des développeurs restera quasiment inchangée. Cette transition est déjà en cours.
Les stablecoins, qui représentent simplement des soldes en monnaie fiduciaire sur les blockchains, traitent déjà près de 9 000 milliards $ de volume annuel ajusté. Ce chiffre rivalise avec Visa et PayPal. Les stablecoins ne diffèrent pas fondamentalement des dollars PayPal. La différence réside dans le fait que les blockchains leur offrent une couche de transport plus sûre et plus interopérable. Après plus de dix ans, l’ETH n’est toujours pas utilisé de façon significative comme monnaie et il est facilement remplacé par les stablecoins. La valeur de l’ETH provient des flux générés par la demande d’espace de bloc Ethereum et les incitations au staking. Sur Hyperliquid, les actifs les plus échangés sont des représentations synthétiques d’actions et d’indices traditionnels, plutôt que des tokens natifs crypto.
La principale raison pour laquelle le web financier intègre les blockchains comme couche de communication sécurisée est l’interopérabilité. Un utilisateur PayPal ne peut pas facilement payer un utilisateur LINE Pay aujourd’hui. Si PayPal et LINE Pay fonctionnaient comme des chaînes, comme Base et Arbitrum, des market makers tels que Across, Relay, Eco ou deBridge pourraient faciliter ces transferts instantanément. L’utilisateur PayPal n’aurait pas besoin d’un compte LINE et l’utilisateur LINE n’aurait pas besoin d’un compte PayPal. Les blockchains permettent ce type d’interopérabilité et d’intégration sans autorisation entre applications.
L’engouement récent autour de Monad en tant que nouvel écosystème EVM montre combien de personnes dans la crypto restent attachées à un modèle dépassé. Monad dispose d’un système de consensus bien conçu et de bonnes performances, mais ces caractéristiques ne sont plus uniques. La finalité rapide est désormais un standard minimal. L’idée que les développeurs vont migrer massivement et se retrouver enfermés dans un nouvel écosystème monolithique n’est pas confirmée par l’expérience de la dernière décennie. Il est facile de déplacer des applications EVM d’une chaîne à une autre, et l’internet ne va pas se réarchitecturer autour d’une seule machine virtuelle.
En termes crypto : une couche de base pour les chaînes Layer 2.
Les applications numériques modernes sont fondamentalement modulaires. Il existe des millions d’applications web et mobiles. Chaque application utilise son propre framework de développement, langage de programmation et architecture serveur. Chacune maintient une base de données qui définit son état sous forme de liste ordonnée de transactions.
En crypto, chaque application est déjà une app-chain. Le problème est que ces app-chains n’ont pas de source de vérité sécurisée et partagée. Interroger l’état d’une application implique de faire confiance à des serveurs centralisés qui peuvent être défaillants ou compromis. Ethereum a tenté à l’origine de résoudre ce problème via le modèle d’ordinateur mondial. Dans ce modèle, chaque application est un smart contract à l’intérieur d’une machine virtuelle unique. Les validateurs réexécutent chaque transaction, calculent l’état global et exécutent un protocole de consensus pour s’y accorder. Ethereum met à jour cet état environ toutes les quinze minutes, moment où une transaction est considérée comme confirmée.
Cette approche présente deux problèmes majeurs. Elle ne passe pas à l’échelle, et elle n’offre pas assez de personnalisation pour les applications réelles. La découverte clé a été que les applications ne doivent pas tourner à l’intérieur d’une VM globale unique. Au contraire, elles doivent continuer à fonctionner de façon indépendante, avec leurs propres serveurs et architectures, tout en publiant leurs transactions ordonnées dans une base de données Layer 1 décentralisée. Un client Layer 2 peut lire ce journal ordonné et calculer indépendamment l’état de l’application.
Ce nouveau modèle est à la fois évolutif et flexible. Il peut prendre en charge de grandes plateformes telles que PayPal, Zelle, Alipay, Robinhood, Fidelity ou Coinbase avec seulement des modifications modérées de leur infrastructure. Ces applications n’ont pas besoin d’être réécrites pour l’EVM ou le SVM. Elles doivent simplement publier leurs transactions dans une base de données partagée et sécurisée. Si la confidentialité est importante, elles peuvent publier des transactions chiffrées et distribuer les clés de déchiffrement à des clients spécifiques.
Faire évoluer une base de données mondiale est bien plus simple que de faire évoluer un ordinateur mondial. Un ordinateur mondial exige que les validateurs téléchargent, vérifient et exécutent chaque transaction produite par chaque application dans le monde. Cela demande beaucoup de ressources informatiques et de bande passante. Le goulot d’étranglement vient du fait que chaque validateur doit exécuter entièrement la fonction de transition d’état globale.
Dans une base de données mondiale, les validateurs doivent seulement s’assurer que les données sont disponibles, que les blocs sont ordonnés de façon cohérente, et que l’ordre ne peut pas être annulé une fois finalisé. Ils n’ont pas à exécuter de logique applicative. Ils doivent simplement stocker et propager les données de manière à garantir que les nœuds honnêtes peuvent reconstruire l’ensemble du dataset. Il n’est donc pas nécessaire que chaque validateur reçoive une copie complète de chaque bloc de transactions.
Le codage par effacement rend cela possible. Par exemple, supposons qu’un bloc de 1 mégaoctet soit réparti entre dix validateurs à l’aide d’un code d’effacement. Chaque validateur reçoit environ un dixième des données, mais n’importe quels sept validateurs peuvent combiner leurs fragments pour reconstruire l’ensemble du bloc. Ainsi, plus le nombre d’applications augmente, plus le nombre de validateurs peut augmenter, et la charge de données par validateur reste constante. Avec dix applications produisant des blocs de 1 mégaoctet et cent validateurs, chaque validateur ne gère qu’environ dix kilo-octets par bloc. Avec cent applications et mille validateurs, chaque validateur traite toujours à peu près la même quantité de données.
Les validateurs exécutent toujours un protocole de consensus, mais doivent seulement s’accorder sur l’ordre des hachages de blocs. C’est bien plus simple que de faire consensus sur les résultats d’exécution globale. Le résultat est un système où la capacité de la base de données mondiale évolue avec le nombre de validateurs et d’applications, et où aucun validateur n’est surchargé par l’exécution globale.
Cette architecture soulève un nouveau problème : l’interopérabilité entre les chaînes Layer 2. Les applications dans une même VM peuvent communiquer de manière synchrone. Les applications opérant sur des L2 distincts ne le peuvent pas. Prenons l’exemple ERC20. Si je possède des USDC sur Ethereum et que vous avez des JPYC, je peux utiliser Uniswap pour échanger mes USDC contre des JPYC et vous les envoyer en une seule transaction. Les contrats USDC, JPYC et Uniswap se coordonnent au sein d’une seule VM.
Si PayPal, LINE et Uniswap fonctionnent chacun comme des chaînes Layer 2 distinctes, il faut une méthode pour une communication inter-chaînes sécurisée. Pour payer un utilisateur LINE depuis un compte PayPal, Uniswap (sur sa propre chaîne) devrait vérifier la transaction PayPal, exécuter plusieurs échanges, initier une transaction LINE, vérifier sa réalisation et envoyer une confirmation finale à PayPal. C’est la messagerie inter-chaînes Layer 2.
Pour assurer la sécurité en temps réel, deux éléments sont nécessaires. Premièrement, la chaîne de destination doit disposer d’un hachage à jour des transactions ordonnées de la chaîne source. Il s’agit généralement d’une racine Merkle ou d’une empreinte similaire publiée sur la base Layer 1. Deuxièmement, la chaîne de destination doit pouvoir vérifier la validité du message sans réexécuter l’intégralité du programme de la chaîne source. Cela peut être réalisé via des preuves succinctes ou des environnements d’exécution sécurisés (TEE).
Les transactions inter-chaînes en temps réel exigent un Layer 1 offrant une finalité rapide combinée à une génération de preuves en temps réel ou à des attestations TEE.
On revient ainsi à la vision d’ensemble. Aujourd’hui, la finance numérique est fragmentée entre des systèmes fermés, obligeant les utilisateurs et la liquidité à se regrouper autour de quelques plateformes dominantes. Cette concentration limite l’innovation et empêche de nouvelles applications financières de rivaliser à armes égales. Nous imaginons un monde où toutes les applications d’actifs numériques sont connectées via une couche de base partagée, permettant à la liquidité de circuler librement entre les chaînes, aux paiements de devenir fluides et aux applications d’interagir en temps réel et en toute sécurité.
Le paradigme Layer 2 a permis à toute application de devenir une chaîne Web3. Un Layer 1 rapide, servant uniquement de base de données mondiale, rend possible la communication en temps réel entre ces chaînes et leur interopérabilité aussi naturelle que celle des smart contracts au sein d’une seule chaîne. C’est ainsi que la finance sans friction émerge : non pas à partir d’une blockchain monolithique qui tente de tout faire, mais via une couche de base universelle qui permet une communication sécurisée et en temps réel entre toutes les chaînes.





