L’équipe de Neon Labs promet d’accélérer la croissance de l’écosystème Solana en cette année 2022. En effet, c’est grâce à elle que la machine virtuelle d’Ethereum (EVM) y fait son arrivée !
Les développeurs de smart contracts et d’applications décentralisées pourront ainsi utiliser tous les outils d’Ethereum comme Solidity, Truffle et Remix sur Solana. Ils bénéficieront du meilleur des deux mondes.
Introduction
On ne présente plus Ethereum, la plateforme de smart contracts la plus utilisée au monde. L’écosystème agrège des dizaines de milliers de développeurs autour de la planète, grâce à son langage de programmation, Solidity. Des milliers d’applications décentralisées y ont vu le jour, et il s’agit d’une véritable révolution. Grâce à Ethereum, de nombreuses applications ont révolutionné le Web : finance décentralisée, jetons non-fongibles (NFT), etc.
Solana est une plateforme blockchain extrêmement rapide et scalable. Grâce à son architecture, il est possible d’exécuter des smart contracts en parallèle. Cela permet d’obtenir un débit de transactions très élevé, le tout avec des frais d’exécution très faibles.
Architecture générale de Neon
Neon EVM est un émulateur de la machine virtuelle d’Ethereum sur Solana, programmé en Rust (le langage de programmation natif de Solana).
Le Berkeley Packet Filter est un code que l’on injecte directement dans le noyau d’un système opérationnel afin d’y effectuer du filtrage réseau. Concrètement, cette interface minimaliste permet de lier différentes couches de données : le BPF confère la possibilité d’intégrer plusieurs machines virtuelles sur Solana. La machine virtuelle Neon EVM est un smart contract, déployé sur Solana grâce au BPF.
Les règles d’Ethereum et de Solana ne sont pas les mêmes : il faut donc un mécanisme pour passer de l’un à l’autre. Le Neon Web3 Proxy permet alors de convertir des transactions Ethereum signées pour les rendre compatibles avec Solana. Dans les détails, étant donné que la taille d’une transaction Ethereum formée sur la Neon EVM peut dépasser celle d’une transaction Solana, la N-trx sera « découpée » en plusieurs S-trx. Chacune d’entre elles sera signée avec une clé proxy, et le proxy enverra le lot sur Solana.
Le proxy Neon Web3 fournit également une API pour que les logiciels clients (Metamask, par exemple) puissent se connecter à l’EVM Neon sans avoir à réécrire leur code. Il suffit d’entrer l’adresse du proxy au sein du client. Les dApps fonctionnent donc de la même façon, et l’interface est identique. Très pratique !
Fonctionnement de Neon
L’utilisateur génère sa transaction à l’aide de son logiciel client favori. Elle est alors envoyée au proxy Neon Web3 – instance de l’émulateur Neon EVM. La transaction est donc créée selon les règles d’Ethereum. Plus précisément, elle comporte les informations suivantes :
- Nonce : correspond au nombre de transactions envoyées depuis l’adresse émettrice ;
- Signature : elle est créée selon les règles d’Ethereum ;
- Prix du gas : frais payés par unité de gas (fixés par l’utilisisateur) ;
- Limite de gas : le nombre maximum d’unités de gas que l’utilisateur est prêt à payer pour la transaction ;
- Valeur : la quantité de jetons à transférer ;
- Adresse de réception.
L’émulateur Neon EVM doit tout d’abord effectuer une requête auprès du réseau Solana afin d’obtenir les données de l’état de la blockchain. C’est le proxy qui envoie cette requête. Avec l’état obtenu, il va effectuer une série de transactions (N-trx) de test.
Le proxy crée ensuite la nouvelle transaction, selon les règles de Solana. Elle comprend l’ensemble des N-trx ainsi que les données de compte nécessaires à son exécution (compte émetteur et autres comptes impliqués).
Cette transaction est diffusée vers Solana (les participants sont fixés par les données de compte). L’opérateur du proxy est considéré comme l’émetteur : il sera récompensé.
La transaction est enfin transférée vers la machine virtuelle Neon. Sa signature sera vérifiée selon les règles d’Ethereum. Si elle est valide, la transaction est exécutée sur la blockchain de Solana. Les N-trx ont été préalablement testées, ce qui signifie que Solana peut les exécuter en parallèle.
Avantages
D’un point de vue pratique, la première chose qui saute aux yeux est qu’il n’y a pas besoin de changer le code des dApps pour les transférer sur Solana. Aucune ressource supplémentaire n’est nécessaire. De même, il suffit pour les logiciels clients de se connecter au proxy Neon – nul besoin de les modifier.
Les développeurs peuvent désormais utiliser les outils d’Ethereum pour créer et déployer leurs smart contracts sur Solana (ou transférer leurs dApps). La machine virtuelle de Neon peut être mise à jour n’importe quand (contrairement à l’EVM). Il suffit de téléverser le code des mises à jours comme un nouveau contrat.
Fonctionnement avancé
Les développeurs de la machine virtuelle Neon (Neon EVM) se sont focalisés sur la rapidité de finalisation des transactions. De même, il proposent une solution permettant de créer des jetons liquides pour les utilisateurs de l’EVM Neon, circulant sur Solana.
Il y a différents composants au sein de l’architecture de Neon :
Utilisateur
Il possède un compte sur l’EVM Neon et un solde en ETH, ERC-20/ERC-721.
S-trx (transaction Solana)
Transaction générée selon les règles de Solana.
N-trx (transaction Neon)
Transaction générée et signée selon les règles d’Ethereum.
Logiciel client Neon EVM
L’application a le bytecode EVM d’un contrat au sein de l’EVM Neon. Les transactions N-trx sont générées selon les règles d’Ethereum et envoyées au proxy. Afin de couvrir les coûts de l’opération, les fonds nécessaires sont transférés au sein d’un dépôt Solana.
Opérateur Neon EVM
Un opérateur de la Neon EVM possède un compte Solana et peut déployer un ou plusieurs proxies. Il peut les donfigurer à sa guise. Il est aussi possible d’utiliser plusieurs comptes Solana et un seul proxy.
Proxy Neon Web3
Il s’agit du logiciel qu’utilise l’opérateur. Pour des raisons de vitesse de traitement des transactions, il s’agit d’un composant à part entière, bien qu’il eût été possible de l’intégrer au niveau du navigateur par exemple. Le proxy doit être capable de traiter de multiples processus en parallèle.
Le proxy intègre un émulateur de l’EVM Neon afin de pré-tester l’exécution de la transaction sur Solana. Ces tests vont déterminer la quantité de coins requis sur le solde de l’opérateur afin qu’il puisse accomplir sa tâche. De même, le taux de change SOL/ETH est fixé à ce moment-là.
Les N-trx sont transformées en S-trx. Les N-trx sont signées par un utilisateur, mais les S-trx sont signées par l’opérateur. Les messages correspondant aux N-trx sont stockés sur des comptes Solana séparés.
Les fonctionnalités déjà implémentées sur le testnet de Neon sont les suivantes :
- Réception des appels API Web3 ;
- Formation des réponses à ces appels ;
- Transformation des N-trx et S-trx ;
- Accès en lecture aux contrats Solidity ;
- Token wrapper : méthode permettant de lier les comptes des contrats SPL aux ERC-20 ;
- Conversion de jetons pour payer les frais de gas ;
- Possibilité d’exécuter une transaction Neon sans pré-test.
L’EVM Neon
La machine virtuelle Ethereum Neon est compilée en bytecode BPF. Cette VM est déployée sur Solana via un compte multi-signatures. C’est à partir de ce compte multisig qu’il est possible de changer les paramètres et le code de l’EVM Neon.
Les participants à la gouvernance de Neon
Les acteurs qui participent au processus de gouvernance peuvent mettre les contrats à jour, ajouter des fonctionnalités, et changer des paramètres importants (valeur des frais, valeur Mn, nombre maximum d’itérations, etc.)
Le wrapper ERC-20
Il n’existe pas de descriptif en français qui soit digeste pour décrire ce procédé « d’enrobage » des jetons. Il s’agit de créer sur Solana des jetons correspondant à leurs équivalents ERC-20 sur Ethereum. Le contrat correspondant est déployé dans l’EVM Neon mais il est indépendant et contient tous les soldes des utilisateurs.
Les jetons créés à la demande de l’utilisateur ne sont liquides qu’au sein de l’EVM Neon. Afin de rendre les jetons liquides sur Solana, les ERC-20 et les SPL doivent être inter-opérables : c’est le rôle du wrapper.
Opérateurs et incitations économiques
Le processus d’exécution d’une transaction comporte plusieurs étapes. Chaque étape ne peut être exécutée qu’une fois la précédente complétée. Bien entendu, le nombre d’étapes dépend de la complexité de l’opération.
On considère la transaction complète une fois que l’étape finale est exécutée. La valeur Mn définit le nombre de blocs alloués pour opérer cette transaction. Si la durée de l’opération dépasse cette période, elle est considéré incomplète.
L’opérateur doit allouer des fonds pour exécuter la requête de l’utilisateur. Il possède un compte de dépôt au sein de l’EVM Neon, qui est verrouillé (personne ne peut retirer ces fonds). Avant l’exécution de la transaction, L’EVM débite automatiquement le compte de l’opérateur, et place les fonds dans un compte de dépôt.
En cas de non-exécution d’une opération lors d’une étape, l’opérateur suivant prendra le relai. Ce nouvel opérateur n’a pas à déposer de fonds pour effectuer sa tâche : si l’exécution rencontre à nouveau des problèmes, c’est encore l’opérateur suivant qui la prend en charge. Les fonds présents en dépôt sont transférés à l’opérateur qui exécute l’étape finale. Ce mécanisme incite donc les clients tout comme les opérateurs à exécuter correctement la transaction.
Les informations relatives aux transactions de l’EVM Neon sont accessibles pour tous les opérateurs en consultant l’état de la blockchain de Solana. Le proxy scrute cette dernière et peut ainsi connaître les transactions incomplètes. Un opérateur prenant le relai devra signer à nouveau avec sa clef. Si le nombre de blocs nécessaire à la finalisation de la transaction incomplète ne dépasse pas MN, la signature de l’opérateur originel est conservée. Dans le cas contraire, le nouvel opérateur signe la transaction.
Transfert des jetons sur Solana
Le wrapper a un fonctionnement classique. Il s’agit d’une application décentralisée dont le contrat conserve le solde des utilisateurs. Les utilisateurs appellent donc ce contrat pour y déposer leurs fonds.
L’utilisateur possède donc deux soldes : son solde SPL concernant les tokens liquides sur Solana, et son solde ERC-20 correspondant aux jetons échangés au sein de l’EVM Neon.
Ce système permet donc à l’utilisateur de transférer ses jetons SPL sur son solde ERC-20, les échanger, puis les retirer.
Les ponts (« bridges« ) : transfert de jetons de Solana vers Ethereum
Il faut pouvoir transférer les jetons SPL créés par le wrapper vers l’extérieur. Un système de pont permet de passer de Solana a Ethereum. Sur Solana, les fonds sont verrouillés au sein de différentes adresses. Ils sont donc liquides sur Solana sous un nom différent. Le processus permettant de créer leur équivalent sur Ethereum est le suivant :
Les jetons sont générés sur Ethereum en tant qu’ERC-20. Il y a un wrapper déployé pour chaque type de jeton Solana. Le système permet donc aux applications Solana d’interagir avec les contrats EVM (Solidity, Vyper, etc.) et d’effectuer les transferts SPL – ERC-20 via un portefeuille Ethereum comme MetaMask.
Un pont est un contrat séparé, et les opérateurs de ponts sont récompensés en frais pour la conversion.
Les Transaction Value tokens
Les Transaction Value tokens sont les jetons qui circulent au sein de l’EVM Neon.
En effet, les ethers ne sont pas directement utilisés au sein de la machine virtuelle. Le calcul des récompenses serait complexifié. Les TVT sont donc l’équivalent des ethers, et sont générés à partir des deux ponts Sollet et WormHole.
Le procédé de transfert est automatique et les conversions peuvent être réalisées en parallèle.
Le compte Ethereum de l’utilisateur est présent dans la machine virtuelle. Il comporte deux champs : ETH ou USDT – le value token identifiant les coins, et PAYMENT, correspondant aux jetons destinés à payer les opérateurs réalisant les transactions.
Les comptes Solana, quant à eux, sont hors de la machine virtuelle et seuls les comptes Ethereum peuvent y accéder. Le solde de ces comptes sont en SPL et les opérations en value tokens font appel à ces comptes. Seuls les comptes Solana peuvent manipuler le solde des adresses concernées. Autrement dit, seul le compte Ethereum peut modifier le solde des comptes Solana.
Après la création d’un compte Ethereum via l’EVM Neon, les comptes SPL correspondants sont créés et le transfert des value tokens devient possible.
Récompenses des opérateurs
Quant au paiement des opérateurs, l’utilisateur a le choix du jeton qu’il souhaite utiliser. Le compte servant à payer les opérateur est créé dans l’EVM Neon : l’utilisateur peut y transférer des ethers grâce aux ponts. Le solde correspondant en jetons SPL sera automatiquement crédité mais attention : il faut utiliser le même pont pour déposer les fonds puis les retirer.
Développer avec Neon EVM : NeonSwap (Uniswap sur Solana)
NeonSwap est un fork d’Uniswap V2 en open source. L’application décentralisée phare de la DeFi est déployée sur Solana ! La migration d’une dApp d’Ethereum à Solana est d’une simplicité déconcertante :
- Déploiement des contrats dans l’environnement de développement Neon ;
- Tests ;
- Déploiement des interfaces.
