Imaginez un instant pouvoir écrire un smart contract en Solidity, l’outil préféré de millions de développeurs Ethereum, et le voir s’exécuter nativement au cœur de Solana, sans passer par un pont lourd ni sacrifier la vitesse. Ce scénario, longtemps resté théorique, prend aujourd’hui forme concrète grâce à Rome Protocol. Le projet vient de dévoiler les détails techniques de son testnet Hadrian, un environnement complet financé en USDC de test, tandis que sa documentation officialise déjà l’existence d’un réseau principal baptisé Rubicon.
Une porte d’entrée inédite entre deux univers blockchain
Depuis des années, la communauté crypto observe un fossé culturel et technique entre l’écosystème Ethereum et celui de Solana. D’un côté, la richesse des outils, des bibliothèques et de l’expérience développeur héritée d’Ethereum. De l’autre, les performances brutes, les frais dérisoires et le débit élevé de Solana. Rome Protocol s’attaque précisément à ce fossé. En implémentant une machine virtuelle Ethereum complète sous forme de programme Solana, le projet permet d’exécuter du code Solidity à l’intérieur même du runtime Solana.
Le 18 octobre, Rome a publié les informations de connexion de Hadrian. Ce testnet tourne sur le Devnet de Solana, porte l’identifiant de chaîne 200010, dispose de son propre point de terminaison RPC et d’un explorateur dédié. Les développeurs y trouvent également un guide précis pour obtenir des USDC de test via le faucet de Circle et un pont dédié. L’objectif est clair : offrir un terrain de jeu réaliste où l’on peut déployer et tester des applications Ethereum-style sans risquer de vrais fonds.
Hadrian et Rubicon : deux environnements complémentaires
La documentation de Rome distingue nettement deux réseaux. Hadrian sert de terrain d’essai. Il utilise des USDC de test et s’appuie sur le Devnet Solana. Rubicon, en revanche, est présenté comme le réseau principal. Son identifiant de chaîne est 7531. Il consomme de vrais USDC et dispose de son propre point de terminaison RPC. Cette séparation claire rassure les développeurs : ils peuvent expérimenter librement sur Hadrian avant d’envisager un déploiement en production sur Rubicon.
Cette architecture à deux niveaux n’est pas anodine. Elle reflète une philosophie pragmatique. Beaucoup de projets d’interopérabilité se contentent d’annonces marketing. Rome, lui, fournit dès maintenant les éléments concrets nécessaires pour commencer à coder. Les instructions de financement, les captures d’écran, les adresses de contrats de référence : tout est déjà accessible. On sent une volonté de passer rapidement de la théorie à la pratique.
Comment fonctionne réellement Rome EVM
Au cœur du système se trouve un programme Solana qui implémente l’Ethereum Virtual Machine. Un proxy reçoit les transactions signées au format Ethereum. Ces transactions sont d’abord vérifiées par un émulateur hors chaîne, puis empaquetées sous forme d’instructions exécutables par les validateurs Solana. Le résultat est transparent pour le développeur : il continue d’utiliser MetaMask, Hardhat ou Foundry, tandis que l’exécution se déroule dans l’environnement Solana.
L’un des aspects les plus intéressants réside dans la possibilité d’appeler des programmes natifs Solana via le mécanisme d’invocation inter-programmes, plus connu sous le nom de CPI. Un contrat Solidity peut ainsi interagir directement avec des protocoles Solana existants. L’état de l’application est partagé entre les utilisateurs EVM et les utilisateurs Solana natifs. Il n’est donc pas nécessaire de créer un pont interne pour faire communiquer les deux mondes à l’intérieur de Rome.
Attention toutefois : les instructions de financement de Hadrian mentionnent bien un pont pour faire entrer les USDC de test depuis Solana. La phrase « aucun pont n’est nécessaire » s’applique uniquement aux interactions une fois les fonds déjà présents dans l’environnement Rome. Cette nuance technique est importante pour éviter les confusions.
Deux modes d’exécution adaptés à la complexité
Rome a prévu deux modes de traitement. Le premier, appelé exécution atomique, s’applique aux opérations qui tiennent dans une seule transaction Solana. Dans ce cas, soit tout réussit, soit tout est annulé. C’est le mode le plus simple et le plus sûr pour la majorité des interactions DeFi classiques.
Pour les opérations plus lourdes, le projet propose une exécution itérative. Les comptes concernés sont verrouillés pendant le processus. Les effets sont mis en cache puis validés à la fin de la session. Une limite de 160 étapes a été fixée, et seuls certains appels de programmes Solana sont autorisés dans ce mode. Ces garde-fous techniques visent à préserver la cohérence et la sécurité du réseau sous-jacent.
Cette dualité reflète une compréhension fine des contraintes de Solana. Les transactions y sont historiquement limitées en taille. Des évolutions récentes ont porté la capacité de 1 232 octets à 4 096 octets, mais les limites de compute units restent strictes. Rome intègre ces réalités dès la conception de son architecture.
Compound et Aave : des démonstrations, pas encore des migrations officielles
Parmi les applications de référence validées sur Hadrian, on trouve des implémentations de Uniswap, Compound v3 et Aave v3. Ces déploiements méritent une attention particulière. Le dépôt Aerarium décrit une version de Compound v3 avec deux parcours utilisateurs distincts qui partagent pourtant le même pool de prêt. Le premier parcours accepte les signatures Ethereum via MetaMask. Le second utilise Phantom et une identité dérivée de Solana, sans nécessiter de clé Ethereum.
Les deux routes accèdent au même marché Comet. Elles permettent les dépôts d’USDC, les dépôts de collatéral, les emprunts, les remboursements et les retraits. L’adresse de l’application pointe vers un domaine Devnet. De son côté, le dépôt d’interface Aave qualifie explicitement le produit de démonstration et le localise sur Hadrian. Le code des contrats est présenté comme un fork.
Il est essentiel de souligner ce point : ces implémentations restent des applications de référence. Rien n’indique à ce stade que les organisations gouvernantes de Compound ou d’Aave aient approuvé un déploiement de production ou le transfert de positions utilisateurs existantes vers Rome. Il s’agit d’une preuve de concept technique solide, pas d’une migration officielle.
Ces démos prouvent qu’il est possible de faire tourner des protocoles de prêt sophistiqués dans un environnement hybride. Elles ne remplacent pas encore les instances officielles sur Ethereum ou d’autres chaînes.
USDC comme token de gaz : une approche configurable
Sur Hadrian, le gaz se paie en USDC. Le guide réseau identifie le mint USDC du Devnet Solana de Circle. Les développeurs qui arrivent depuis Solana ont besoin à la fois d’USDC de test et d’un peu de SOL Devnet. Circle distribue actuellement 20 USDC de test par demande, dans les limites de son faucet, et précise que ces tokens n’ont aucune valeur réelle.
La documentation des chaînes applicatives de Rome va plus loin. Elle permet à un opérateur de choisir n’importe quel token SPL comme moyen de paiement des frais et de rediriger les revenus vers une trésorerie applicative. Un service de tarification convertit le token choisi en SOL pour couvrir les coûts réels des transactions Solana. Les prix peuvent provenir de pools Meteora ou d’un mécanisme de secours Pyth/Hermes.
Des paramètres configurables existent également pour le prix minimum du gaz et un multiplicateur au niveau du proxy. Cette flexibilité signifie qu’il n’existe pas de coût unique en dollars pour toutes les transactions. Chaque application peut ajuster sa politique tarifaire. C’est un avantage concurrentiel potentiel face aux solutions plus rigides.
Sécurité et limites de compatibilité
Le dépôt EVM de Rome indique qu’un programme mainnet a fait l’objet d’un audit par Halborn. Les instructions de reconstruction du programme sont fournies, avec un mécanisme de comparaison du binaire déployé qui masque certaines métadonnées de compilation. Cette transparence relative constitue un point positif pour les équipes de sécurité.
Cependant, la documentation de compatibilité liste plusieurs différences avec Ethereum. La fonctionnalité d’exponentiation modulaire est désactivée. Le comportement du gaz ne reproduit pas exactement le barème par opération d’Ethereum. Les transactions Rome doivent déclarer à l’avance les comptes Solana qu’elles touchent. Une limite de 64 adresses par transaction s’applique, ainsi qu’environ 1,4 million d’unités de calcul.
Le guide recommande d’ailleurs de mesurer la consommation réelle de compute units Solana à partir des reçus de transaction, car la figure de gaz EVM n’est pas un indicateur fiable de la ressource consommée. L’autorité de mise à niveau du déploiement mainnet est un portefeuille multisignature Squads. Ces éléments montrent que Rome assume ses écarts par rapport à Ethereum pur plutôt que de promettre une compatibilité parfaite.
Au-delà des prêts : d’autres horizons financiers
Rome ne se limite pas aux protocoles de prêt. En mars 2025, le projet a annoncé une collaboration avec KiiChain autour d’actifs tokenisés et de finance de paiement cross-chain destinée à l’Amérique latine. Les dirigeants ont évoqué des plans impliquant de l’immobilier, des matières premières agricoles et un accès à la liquidité Solana. Ces ambitions illustrent une volonté d’aller au-delà de la simple couche technique pour toucher des cas d’usage concrets.
Dans le même temps, d’autres initiatives d’interopérabilité se multiplient. Certaines ciblent les marchés institutionnels avec des moteurs d’échange cross-chain reliant plusieurs réseaux. Rome se positionne dans ce paysage concurrentiel en misant sur une intégration profonde plutôt que sur des ponts superficiels.
Ce que cela change pour les développeurs
Pour un développeur habitué à l’écosystème Ethereum, l’arrivée de Rome représente une opportunité rare. Il peut conserver ses outils, ses habitudes de signature et une grande partie de son code, tout en bénéficiant des performances de Solana. La courbe d’apprentissage se réduit considérablement. Plus besoin de tout réécrire en Rust ou d’apprendre les particularités de l’Account Model de Solana pour les cas d’usage les plus courants.
Cette accessibilité pourrait accélérer le déploiement de protocoles DeFi sophistiqués sur Solana. Les équipes qui disposent déjà d’une expertise Solidity peuvent tester rapidement leurs idées. Les utilisateurs Solana, de leur côté, accèdent à des interfaces familières sans changer de portefeuille pour certaines interactions.
Il reste toutefois des contraintes techniques à maîtriser. La déclaration préalable des comptes, les limites de compute units et les modes d’exécution imposent une discipline différente de celle d’Ethereum. Les équipes les plus expérimentées sauront en tirer parti. Les débutants devront peut-être ajuster leurs pratiques.
Les enjeux plus larges pour l’écosystème
L’émergence de solutions comme Rome s’inscrit dans une tendance plus profonde : la recherche d’une interopérabilité réelle plutôt que cosmétique. Les ponts classiques ont montré leurs limites en matière de sécurité et d’expérience utilisateur. Les approches qui intègrent nativement une machine virtuelle dans un autre runtime offrent une alternative intéressante.
Solana gagne ainsi un nouveau vivier de développeurs. Ethereum conserve son rôle de standard de facto pour le développement de smart contracts. Les utilisateurs finaux, eux, pourraient bénéficier d’applications plus rapides et moins chères sans sacrifier la familiarité des interfaces auxquelles ils sont habitués.
Bien sûr, le succès dépendra de plusieurs facteurs. La robustesse de l’implémentation EVM sous charge réelle. La qualité de l’expérience développeur au quotidien. L’adoption par des protocoles majeurs au-delà des démos. Et la capacité de Rome à maintenir la sécurité face à des attaques de plus en plus sophistiquées.
Perspectives techniques et évolutions possibles
Les prochains mois seront déterminants. Hadrian va permettre de collecter des retours concrets de la part des développeurs. Les ajustements de paramètres de gaz, les optimisations de compute units et l’éventuelle extension des fonctionnalités supportées dépendront de ces retours. Rubicon, de son côté, devra prouver sa stabilité en conditions de production.
On peut imaginer que d’autres protocoles de prêt, de trading ou d’actifs tokenisés tenteront l’expérience. Les partenariats comme celui avec KiiChain pourraient se multiplier si les premiers résultats sont concluants. La question de la gouvernance des contrats déployés restera également centrale : qui contrôle les mises à niveau, comment sont gérés les risques, quelle est la répartition des responsabilités entre Rome et les protocoles hébergés.
Dans un marché où les cycles d’innovation s’accélèrent, la capacité à combiner le meilleur de deux mondes constitue un avantage stratégique. Rome Protocol a choisi une voie technique ambitieuse. Les détails publiés sur Hadrian et Rubicon montrent que le projet est passé du stade conceptuel au stade opérationnel. Il reste maintenant à observer comment la communauté développeurs s’en empare.
Un moment charnière pour l’interopérabilité
L’annonce de Rome arrive à un moment où de nombreux acteurs cherchent des solutions concrètes aux problèmes d’isolation des liquidités. Les utilisateurs ne veulent plus choisir entre performance et compatibilité. Les développeurs ne veulent plus réécrire entièrement leurs applications pour chaque nouvelle chaîne. Les solutions qui réduisent ces frictions ont de fortes chances de trouver leur place.
Rome ne prétend pas résoudre tous les problèmes d’un coup. Les limites techniques sont clairement documentées. Les démos de Compound et Aave restent des références et non des versions officielles. L’audit Halborn est un premier pas, pas une garantie absolue. Cette transparence relative est peut-être l’un des points les plus appréciables du projet.
En mettant à disposition dès maintenant les endpoints, les instructions de financement et les applications de référence, Rome invite concrètement la communauté à tester. C’est dans cette phase d’expérimentation que se jouera une partie de l’avenir de l’interopérabilité entre Ethereum et Solana. Les prochains mois diront si Hadrian et Rubicon deviennent de simples curiosités techniques ou de véritables catalyseurs d’adoption croisée.
Pour l’instant, une chose est certaine : la barrière qui séparait les développeurs Solidity du runtime Solana vient de s’abaisser significativement. Ceux qui souhaitent explorer cette nouvelle frontière disposent désormais d’un terrain de jeu documenté, financé en USDC de test, et déjà peuplé de premières applications de référence. L’expérience commence aujourd’hui sur Hadrian.
Les implications à plus long terme touchent également la structure même de la liquidité DeFi. Si des pools de prêt peuvent fonctionner de manière unifiée pour des utilisateurs MetaMask et Phantom, de nouveaux modèles de composition deviennent envisageables. La frontière entre les écosystèmes s’estompe progressivement, non pas par la force des ponts, mais par l’intégration profonde des environnements d’exécution.
Cette évolution s’accompagne de responsabilités nouvelles. Les développeurs devront maîtriser à la fois les subtilités d’Ethereum et les contraintes de Solana. Les auditeurs de sécurité devront adapter leurs méthodes. Les utilisateurs devront comprendre les nuances entre les différents modes d’exécution. Mais ces défis semblent moins insurmontables que le maintien de silos complets entre les deux univers.
Rome Protocol a choisi de documenter ses choix techniques avec une précision rare dans le secteur. Cette attitude mérite d’être saluée. Elle permet à chacun de se forger une opinion éclairée plutôt que de se contenter de slogans marketing. Dans un domaine où la confiance se construit sur la transparence, c’est un signal encourageant.
Le chemin vers une adoption massive reste long. Il faudra prouver la résilience sous charge, attirer des protocoles de premier plan au-delà des forks de démonstration, et convaincre les utilisateurs que l’expérience reste fluide. Mais les fondations techniques posées aujourd’hui avec Hadrian et Rubicon constituent déjà une avancée notable. Elles ouvrent un chapitre nouveau dans l’histoire de l’interopérabilité blockchain, un chapitre où Solidity et Solana ne s’opposent plus, mais se complètent.
