Introduction
Au fil des années, le géant Ethereum a su trouver certaines réponses à ses problématiques de débit de traitement de ses transactions. En effet, outre son passage au Proof of Stake laissant présager une meilleure scalabilité future, la communauté autour de l’écosystème Ethereum fait preuve d’imagination.
Dans cet article nous nous attèlerons sur le projet Fuel qui vient proposer une alternative des plus innovantes aux solutions de type « Rollup » sur Ethereum & Celestia.
Découvrez en quoi consiste Fuel et quelle technologie se cache derrière ce projet pour le rendre aussi efficient.
Cet article est réalisé en collaboration avec Fuel
Tout le contenu Coin Academy pour Fuel
Fuel qu’est-ce que c’est ?
Fuel se décrit au départ comme le premier Optimistic rollup pour Ethereum lancé en 2020. Depuis le projet a fait du chemin et se trouve être une couche d’exécution modulaire offrant des contrats intelligents sur Ethereum exploitant le modèle UTXO.
Fuel compte plus de 65 ingénieurs parmi les plus brillants et le soutien d’entreprises leaders de l’industrie. Fuel offre la plus haute sécurité et un débit flexible, tout en proposant une excellente expérience utilisateur pour les développeurs.
Toujours en quête de mise à l’échelle (scalabilité) d’Ethereum, la première version de Fuel ou FuelV1 s’est concentré autour des paiements peer to peer (pair à pair).
Cette version est opérationnelle sur le mainnet Ethereum depuis 2020 et reste à ce jour le seul rollup avec des preuves de fraude, des smart contracts immuables et une production de blocs permisionless (sans permission).
Ce qui nous intéresse réellement est bien évidement FuelV2 qui promet des contrats intelligents d’Ethereum basé sur le modèle UTXO.
Le projet lancera plusieurs instances, en utilisant Ethereum/Celestia pour le règlement, la disponibilité des données et le consensus.
Ci-dessous, un exemple rudimentaire des possibilités d’exploitation de Fuel :
En tant que couche d’exécution modulaire, Fuel peut fonctionner dans n’importe laquelle de ces catégories. Les développeurs peuvent configurer Fuel selon leurs besoins en changeant quelques modules dans le client.
La plus grande différence entre Fuel et les Optimistic rollup d’aujourd’hui est qu’il exécute une toute nouvelle architecture de VM (virtual machine) appelée FuelVM avec sa chaîne d’outils et son langage Sway.
FuelVM s’inspire de plusieurs homologues robustes tels que WASM, EVM et Sealevel la machine virtuelle de Solana pour se construire.
Comme brièvement évoqué, un fait important à relever est que FuelVM s’exécute sur un modèle de données basé sur UTXO (dont nous parlerons plus en détail par la suite).
SwaySwap, une application décentralisée semblable à Uniswap fut la première implémentation fonctionnelle d’un AMM de type UNI V2 lancée sur le réseau testnet Beta-1.
Vous pouvez d’ores et déjà essayer le réseau testnet Beta-2 ici pour :
- Créer un porte-monnaie Fuel intégré basé sur un navigateur. (les portefeuilles autonomes seront implémentés par la suite.)
- Utiliser le faucet pour obtenir des jetons test ETH à votre portefeuille.
- Échanger deux types différents d’actifs natifs comme par exemple testETH et testDAI.
- Interagir avec des pools d’actifs natifs.
L’une des particularités à relever est que les jetons LP (liquidity provider tokens) sont considérés comme des actifs natifs au même titre que les testETH.
La technologie derrière Fuel
Vous l’aurez compris les équipes de Fuel voient en la modularité des blockchains un avenir radieux pour celles-ci.
Les chaînes monolithiques couplent le calcul et la vérification sur la même couche, ce qui entraîne une sécurité moins bonne et une évolutivité limitée.
Les couches d’exécutions modulaires comme FuelV2, elles, contournent ce problème en dissociant le calcul et la vérification leur permettant d’obtenir une sécurité bien supérieure tout en augmentant fortement la scalabilité du réseau.
Dans un premier temps il est très important de comprendre certains aspects des chaines modulaires qui en font des solutions très intéressantes.
Exécution modulaire vs monolithique
Pour rappel, les chaines monolithiques fonctionnent par le biais de deux procédés se trouvant sur la même couche.
Ces deux procédés sont la production de blocs (calcul) traduisant l’exécution des transactions et transition d’état individuel et la validation de bloc (Vérification) confirmant la validité des transitions d’états.
Pour ce faire, sur la majorité des blockchains monolithiques, ces deux processus sont effectués par des Validateurs (Nœuds complets).
Parfois, les applications sur le réseau ou les utilisateurs eux-mêmes ont besoin d’accéder à l’état de la blockchain. Cependant le montage d’un nœud complet implique des exigences élevées en termes de ressources.
C’est pourquoi ils peuvent alors exécuter des clients légers afin de ne pas avoir à télécharger toute l’historique de la blockchain pour y consulter des états.
Ils doivent donc faire confiance en la validité des blocs fournis par les nœuds complets précédemment en supposant que la majorité d’entre eux sont bienveillants.
C’est ainsi que rentre en jeu l’hypothèse de la majorité honnête, rendant bon nombre de blockchain monolithiques vulnérables aux attaques 51 % dont vous avez déjà dû entendre parler.
Voici comment peut être représenté le rapport établi entre la sécurité et le coup en ressource pour un full node et un client léger.
Pour les blockchains modulaires, vous l’aurez compris, la couche d’exécution responsable du calcul (traitement des transactions et applications des transitions d’états individuelles) se fait off-chain, c’est-à-dire en dehors de la couche de niveau 1 (layer 1).
Ils ne fourniront que des preuves de la validité des blocs de transactions sur la chaine de Layer 1.
Le gros point fort de l’exécution modulaire est que contrairement aux systèmes monolithiques, la vérification n’est pas traitée au niveau de la couche d’exécution.
Cela implique que tant que la vérification (validation des blocs) est décentralisée (comme elle l’est sur Ethereum) la production de bloc (le calcul) peut être centralisée.
Ainsi la modularité permet d’utiliser de puissants producteurs de blocs qui regroupent et exécutent des lots de transactions et les postent périodiquement sous forme de blocs sur la chaîne mère.
Autrement dit, le fait de permettre le calcul en dehors de la chaîne mère permet d’augmenter massivement le débit des transactions. La taille des blocs peut être considérablement augmentée sans que l’on s’inquiète de la centralisation de la production des blocs, car le processus de validation (vérification) des blocs permet de maintenir l’honnêteté des producteurs de blocs.
FuelVM – La machine virtuelle de Fuel
La FuelVM (Fuel Virtual Machine) est conçue pour être modulaire et ainsi être utilisée comme moteur d’exécution pour n’importe quelle blockchain.
Son but premier est d’être déployée comme rollup L2 sur Ethereum, mais en théorie, la FuelVM pourrait être déployée n’importe où comme un Layer 2 (exemple : Tezos, Cardano etc.)
En plus de cela, Fuellabs a créé un langage de programmation (DSL) appelé Sway (dont nous parlerons par la suite) pour le développement de smart contracts sur la FuelVM.
La FuelVM, est basée sur les UTXO et oblige chaque transaction à définir explicitement les UTXO qu’elle va toucher. Ainsi, l’identification des transactions non litigieuses étant rendue aisée, le moteur d’exécution peut les paralléliser.
C’est la structure de fonctionnement de la VM qui permet cette parallélisation d’exécution faisant défaut à l’EVM qui elle utilise un modèle séquentiel.
Ainsi, La FuelVM peut utiliser tous les threads et les cœurs des CPU pour valider les transactions de manière parallèle.
Également, FuelVM utilise une architecture de mémoire partagée permettant de passer des données entre les contrats sans stockage coûteux.
Comment parler de la VM de Fuel sans parler des actifs natifs ? Vous n’êtes pas sans savoir que sur Ethereum le seul actif natif se trouve être l’Ether.
Dans Fuel, n’importe quel contrat peut frapper (minter) son actif natif basé sur UTXO en utilisant un ensemble d’opcodes (commandes servant à programmer des actions spécifiques) d’actifs faciles à utiliser.
Contrairement à Ethereum qui gère tous les autres actifs avec des smart contracts gérant la compatibilité avec des soldes ERC20 (norme de jeton), Fuel possède une alternative permettant à la VM de gérer ces actifs de manière native.
Cela implique un certain nombre de choses puisque la gestion des actifs dits “natifs” est bien moins couteuse en termes de frais de gaz que la manipulation d’état au travers d’un contrat intelligent.
D’autre part, les actifs natifs ont une meilleure interface utilisateur, de la même manière que l’envoi d’ETH est beaucoup plus simple que l’envoi de Token ERC20.
En outre, la FuelVM possède un grand nombre de spécificités qui viennent la surclasser par rapport à son homologue EVM. Si vous souhaitez plus d’information concernant la machine virtuelle de Fuel et toutes ses spécificités techniques, nous vous recommandons de vous plonger dans la documentation officielle du projet.
Les contrats UTXO de Fuel
Comme mentionné précédemment, Fuel adopte un modèle de données UTXO. Dans Bitcoin (uniquement concerné par des paiements), les UTXO sont des éléments d’état déterminants qui possèdent combien de jetons.
Comme pour bitcoin, sur FuelV2, les états sont représentés par un ensemble d’UTXO. Cependant dans le cas de FuelV2 il existe des UTXOs de coin ou jeton comme pour Bitcoin, mais aussi des UTXOs de contrat.
En plus d’un solde et d’une condition de dépense, les UTXOs de contrat ont un code, un stockage et un ID de contrat unique.
Les UTXOs de coin sont régis par la règle bien connue “la somme des sorties ne peut pas dépasser la somme des entrées”. Entendez là que vous ne pouvez pas dépenser plus que ce que vous ne possédez.
Les UTXOs de contrat, en plus de cette règle, sont régis par de nouvelles règles dont voici les plus importantes :
- Lorsqu’une transaction consomme un UTXO de contrat, elle crée un nouvel UTXO de contrat avec la même condition de dépense et le même ID de contrat, mais potentiellement un nouveau stockage et un nouveau solde.
- Les UTXOs contractuels dépensés dans la même transaction peuvent interagir entre eux.
Voici comment les UTXOs de contrats rentrent en interaction dans les transactions de Fuel.
Comme expliqué précédemment, c’est grâce à l’utilisation de listes d’état strictes sous forme de modèle UTXO que le réseau peut exécuter des transactions en les parallélisant et ainsi offrir un débit important.
Le langage Sway et Forc
Sway est le langage (DSL ou domain spécific langage) créé pour le développement de smart contrat sur la FuelVM. Le langage Sway est un langage priorisant la sécurité et la vitesse.
Il se dit apporter la PLT (programing language theory) ou théorie des langages de programmation en français à la blockchain.
Il s’agit ici d’un langage optimisé tirant parti du meilleur de plusieurs autres langages ayant déjà fait leurs preuves. En effet il se dit être l’alliance parfaite entre les langages RUST et Solidity tous deux bien connus du milieu de la blockchain.
En effet, Sway tire parti de la syntaxe du langage RUST, tout en adoptant la notion de langage de paradigme présent chez Solidity le rendant très efficient pour la programmation de smart contrat avec un stockage de contrat de haut niveau intégré.
Le langage Sway, outre le fait de proposer une expérience de programmation de contrat ergonomique et sure, apporte la notion d’audit statique aux contrats intelligents. Cet aspect permet au compilateur de détecter des éléments habituellement confiés à des sociétés d’audit.
En effet tout porte à croire que le Langage Sway soit en partie responsable des solutions innovantes apportées par Fuel.
Il est bon de noter que le langage s’accompagne de Forc (Fuel Orchestrator), le système de construction et le gestionnaire de paquets pour Sway, similaire à Cargo pour Rust.
Pour faire simple, Forc fournit une variété d’outils et de commandes pour les développeurs travaillant avec l’écosystème Fuel tel que le formatage, l’exécution de scripts, le déploiement de contrats, le test de contrats, etc.
Par ailleurs le projet Fuel vise à fournir une expérience de développement complète comprenant la chaîne d’outils Forc, le compilateur, l’indexeur, l’explorateur de blocs, etc.
Afin de simplifier davantage la construction est la maintenance des applications Sway, Fuel donne accès à Fuelup, un gestionnaire de package permettant de passer facilement d’une chaîne d’outils à une autre.
Fuelup tire son inspiration de Rustup (le gestionnaire équivalent pour le langage Rust) et permet en fin de compte, une simplification de l’usage du langage Sway.
Dans les faits, Fuelup viendra rassembler toutes les chaînes d’outils disponibles sur Fuel et les présentera sous la forme d’un seul ensemble d’outils. Fuelup fournira alors un mécanisme simplifié permettant de jongler entre ces différents outils de manière aisée.
C’est au travers de multiples commandes que vous pourrez naviguer entre les différentes chaînes d’outils ou personnaliser la vôtre.
Il existe des guides afin de se lancer dans la programmation de contrats intelligents avec Sway et son ensemble d’outils pouvant vous aider à vous lancer.
Conclusion
Grâce à la combinaison des mécanismes et innovations citées tout au long de cet article, toute sorte de cas d’utilisations deviennent possibles, en voici quelques exemples :
- Prise en charge de plusieurs actifs natifs : les contrats peuvent transformer leurs jetons en actifs natifs.
- Approbation et transfert dans une seule et même transaction.
- Coin mixers et autres applications de confidentialité.
- Support multi-sig natif, sans contrat.
- Support natif des méta-txs, sans contrat (payer du gaz pour la transaction de quelqu’un d’autre, etc.)
- Cas d’utilisation à haut niveau de calcul : courbes complexes pour les pools AMM, trading/prêt flash, etc.
Fuel V2 est encore actuellement en phase de testnet mais des cas d’utilisations ont déjà été construits notamment durant un Hackathon, tel que AMMs, multisig, oracle et vote DAO.
L’équipe Fuel prévoit de construire d’autres cas d’utilisations populaires comme le prêt, les emprunts, les places de marché NFT etc.
Le projet est à surveiller de près et pour cause son mainnet est à seulement quelque mois du lancement.
Liens utiles pour suivre Fuel
🔗 Site Web
