Radix DLT – Présentation complète partie 1 – Un nouveau paradigme pour les smart contracts et la DeFi

Radix DLT est une plateforme full stack, une pile technologique complète dédiée à améliorer le Web3 sous tous ses aspects, issue de plusieurs années de recherche et de développement.

Le protocole Radix est développé en open source par la Radix Foundation. Radix possède des propriétés uniques, qui vont au-delà de ses performances techniques et de son accessibilité pour les développeurs et les utilisateurs.

Cet article de présentation générale se veut synthétique, mais la complexité technologique nous a poussé à diviser l’ensemble en 2 parties. En effet, de nombreux concepts qui sous-tendent le design de Radix diffèrent – radicalement – de l’existant. Nous commencerons donc dans cette première partie par poser les principes généraux du protocole, avant d’entrer dans des détails plus techniques. Nous nous baserons sur le livre blanc du projet afin de comprendre son fonctionnement. L’équipe de RDX a réalisé de nombreux schémas explicatifs, qui nous permettront de saisir les différences majeures de ce nouveau Layer 1 avec les plateformes existantes.

Le Journal du Coin vous propose cet article promotionnel en collaboration avec Radix.

Les principes généraux de Radix

La finance décentralisée reste en 2025 difficilement accessible, tant pour l’utilisateur moyen que pour les développeurs souhaitant se lancer dans l’industrie. Les plateformes de smart contracts, telle Ethereum, se sont considérablement améliorées en termes de performances techniques ; cependant, les applications DeFi ne sont pas aussi fluides que leurs équivalents centralisés.

L’équipe de Radix souhaite supprimer les barrières technologiques à l’entrée du Web3, qui sont un frein pour de nombreux utilisateurs potentiels, mais aussi pour les développeurs. L’équipe de développement de Radix a identifié quatre freins principaux au développement du potentiel de la finance décentralisée. En réponse, la plateforme est donc conçue autour de quatre piliers technologiques que nous allons énumérer ci-dessous. Chacun sera ensuite explicité sur le plan technique tout au long de l’article.

Des smart contracts faciles à coder

Dans le paradigme actuel de la DeFi, les applications décentralisées présentent différents standards en termes de sécurité et d’accessibilité que leur équivalent de la finance traditionnelle. Si on prend l’exemple d’Ethereum et de son langage de programmation, Solidity, chaque dApp nécessite un agencement très complexe de smart contracts. La moindre fonctionnalité est difficile à coder, et requiert l’expérience de programmeurs chevronnés. Le code des contrats doit être précautionneusement audité pour éviter les bugs et les failles dont l’exploitation occupe régulièrement nos colonnes.

Radix propose un nouvel environnement de développement pour permettre à l’industrie d’attirer les développeurs. Dit « orienté actifs » (asset-oriented), il s’articule autour du Radix Engine (sa couche applicative) et de Scrypto (son langage de programmation). Ces outils permettent de faciliter le développement des dApps, de renforcer leur sécurité, et d’attirer plus de profils qualifiés pour notre industrie par leur accessibilité.

Des briques lego pour la DeFi 

Actuellement, chaque fonctionnalité d’une dApp doit être codée et déployée en silo. L’industrie manque de standardisation et de modularité. Il est impossible de réutiliser simplement telle ou telle fonctionnalité, comme les oracles, les pools de liquidité, les comptes multi-signatures, et ainsi de suite. Chaque dApp doit effectuer un travail de ré-implémentation, ce qui ralentit son développement tout en entraînant souvent un manque de fiabilité.

Radix est conçu pour faciliter la modularité et la réutilisation du code. Au cœur même de son réseau, Radix propose un catalogue de fonctionnalités pour les développeurs, qui peuvent ainsi réutiliser, combiner et configurer ces « briques Lego ». 

Des incitations économiques pour les développeurs

Dans le paradigme actuel, les développeurs sont financièrement récompensés par des fonds de trésorerie, centralisés et administrés par des fondations. Cela pose plusieurs problèmes pour les développeurs talentueux qui souhaitent être récompensés à la mesure de leur travail, lorsqu’ils conçoivent une fonctionnalité largement utilisée, ou proposent une contribution exceptionnelle. Les équipes chassent alors les grants attribués par telle ou telle fondation, sans s’attarder à bâtir des communautés solides et à développer continuellement des applications fiables et durables.

Radix propose un écosystème décentralisé et auto-incitatif pour les développeurs. Son système de royalties permet aux développeurs Scrypto d’être rémunérés pour leur code lors de chaque transaction.

Une scalabilité illimitée

Les plateformes de smart contracts actuelles souffrent soit d’un manque de scalabilité, soit d’un manque de composabilité (la capacité des dApps à interagir entre elles). Il s’agit généralement d’améliorer l’une au détriment de l’autre. D’un côté, Ethereum et ses frais excluent de la DeFi de nombreux utilisateurs. De l’autre, les couches secondaires ou les plateformes de dernière génération compromettent l’expérience développeur.

Radix présente Cerberus, un protocole de consensus assurant un très haut débit mais également une scalabilité maximale pour les dApps du réseau. Couplé au Radix Engine, il permet de paralléliser des transactions simples et complexes grâce à un mécanisme de sharding (fragmentation du registre) unique en son genre. La scalabilité du système est illimitée, sans pour autant compromettre la composabilité des applications.

Le Radix Engine, un nouveau paradigme de développement pour les smart contracts

Afin de comprendre le design du Radix Engine, il nous faut tout d’abord rappeler quel est le paradigme de développement actuel des plateformes de smart contracts. Il est, dans la plupart des cas, très largement inspiré d’Ethereum, de sa machine virtuelle (EVM), et de son langage de programmation (Solidity).

Vers l’adoption de masse de la DeFi

Le constat de l’équipe de Radix est le suivant : les environnements de développement actuels sont mal adaptés à l’adoption massive de la finance décentralisée. Il faut des années aux développeurs pour maîtriser un langage tel que Solidity. De plus, il faut avoir une connaissance profonde du fonctionnement de chaque plateforme. Une fois le niveau d’expertise requis atteint, déployer un jeton ou une simple fonctionnalité nécessite un ou plusieurs smart contracts dédiés. Chaque actif doit être conçu from scratch, et les enjeux sont élevés : la moindre erreur peut coûter des millions de dollars.

La communauté des développeurs DeFi est restreinte, et donc inadéquate pour répondre aux besoins des entrepreneurs de l’industrie. Les dApps restent élémentaires pour minimiser les risques, et la vérification du code monopolise un temps précieux.

L’environnement de développement actuel

L’environnement applicatif typique inspiré de l’EVM est le suivant : 

  • Le réseau blockchain permet d’exécuter des calculs, en utilisant le code déployé sur le réseau :
  • Chaque smart contract possède son propre état interne (l’ensemble de ses donnés) ;
  • Les différents smart contracts peuvent interagir, et mettre à jour leurs soldes respectifs.
EVM - Architecture simplifée
Architecture simplifiée de l’EVM

Toutes les fonctionnalités doivent donc être implémentées en tant que smart contracts communiquant les uns avec les autres. Par exemple, un jeton ERC-20 est un contrat gardant la liste des soldes associés à différentes clés publiques. Un compte multisig est un contrat nécessitant un certain nombre de signatures pour pouvoir agir. Absolument toutes les fonctionnalités des applications sont donc implémentées en silos. Chaque opération nécessite une logique complexe, un ensemble de messages et de données.

La complexité du code, un frein à l’adoption de la DeFi

Dans le cas d’une application de finance décentralisée, la complexité du code explose. Dans son DeFi Whitepaper, Radix prend l’exemple d’Uniswap et de sa fonctionnalité de base : l’échange (swap) de jetons :

  • Les fournisseurs de liquidité apportent des paires de jetons dans les pools, et reçoivent en échange des jetons LP, représentant leur part du pool.
  • Lors d’un swap, les traders peuvent échanger ces paires suivant la formule du produit constant, et paient des frais.
Uniswap - Fonctionnement simplifié
Représentation schématique d’un swap

Bien que le concept soit simple, le processus est en pratique très complexe au niveau de la logique interne du protocole. Le schéma ci-dessous présente une vue simplifiée du fonctionnement des opérations effectuées au sein des différents smart contracts :

Schéma simplifié des différents flux (appels, vérifications, mises en cache et mises à jour) lors de l’échange de deux jetons.

Toute cette complexité découle de l’environnement applicatif de l’EVM lui-même. Bien que cette approche reste fonctionnelle, l’expérience est mauvaise pour le développeur. De plus, elle présente des dangers pour l’utilisateur final. L’idée de Radix est donc de simplifier grandement l’environnement de développement des smart contracts de la DeFi. Tout part de l’observation suivante : l’interaction avec des actifs est la brique de base des transactions DeFi. Il faut donc faire des actifs une fonctionnalité native de la plateforme, plutôt que la responsabilité du développeur.

Le Radix Engine, un environnement orienté actif

Sur Radix, les actifs sont donc une fonctionnalité globale de la plateforme elle-même. Il ne s’agit pas d’implémenter du code à chaque fois pour créer de nouveaux smart contracts.

Dans l’environnement de développement du Radix Engine, les jetons sont traités par la plateforme comme des objets. Ces derniers sont conservés dans des comptes, et déplacés de l’un à l’autre. Sur Ethereum, les jetons des utilisateurs sont des soldes, dispatchés sur autant de smart contracts, ces derniers conservant une entrée correspondant à leur clé publique. En revanche, sur Radix, chaque compte est comme un coffre numérique contrôlé par l’utilisateur. En quelque sorte, les jetons sont comme des objets physiques, pouvant être déplacés d’un coffre à un autre.

Le Radix Engine, un automate fini

Le Radix Engine fonctionne comme un automate fini (finite state machine ou FSM). Ce modèle mathématique de calcul est restreint par rapport à une machine de Turing (telle l’EVM). La machine virtuelle peut être dans un nombre fini d’états, mais dans un seul état à l’instant t. C’est le cas, par exemple, d’un distributeur de billets.

Avec ce modèle, l’envoi de jetons n’est pas conceptualisé comme un ensemble de messages visant à mettre à jour les soldes d’un contrat. Il s’agit plutôt de dire à la plateforme : « je souhaite envoyer ces jetons, qui sont ma propriété ». Cela rend, entre autres, les erreurs de type duplication de compte impossibles.

Ce concept est la base du paradigme orienté actif de Radix. Les jetons sont ainsi créés par demande directe à la plateforme, avec les paramètres désirés. C’est beaucoup plus simple et intuitif pour les développeurs.

Conséquences sur les transferts de jetons

Les calculs, eux, restent décentralisés, comme avec l’EVM. Avec la deuxième version du Radix Engine, le modèle des jetons FSM est étendu à une forme plus générale, les « ressources ». La logique des smart contracts est écrite avec un langage dédié : Scrypto.

Radix Engine V2 - Vue simplifiée
Les transferts d’actifs s’apparentent à un déplacement « physique » de ressources entre différents coffres.

La logique des contrats créés par les développeurs change donc drastiquement. La complexité du code diminue fortement. De nombreuses erreurs deviennent impossibles à commettre, comme les ré-entrées. Cela supprime les vecteurs d’attaques associés (par exemple, les reentrancy attacks). La quantité de messages à passer devient minimale. Les smart contracts deviennent faciles à coder, sûrs, réutilisables et composables. Nous aborderons plus bas la notion de composabilité, qui est au cœur du design de Radix.

Sur Radix, on appelle les smart contracts des « composants ». Ils ont des fonctions claires, sont modulaires et composables. Radix introduit également le concept de Blueprints, des modèles (templates) pouvant être imbriqués les uns avec les autres au sein des composants.

Scrypto : un langage de programmation orienté actifs

Le langage de programmation de l’environnement applicatif de Radix répond à ce nouveau paradigme. Nommé Scrypto, il permet d’utiliser les fonctionnalités uniques de Radix tout en maintenant une expérience de développement familière, avec une logique expressive.

Scrypto dérive de Rust, et conserve ses fonctionnalités, tout en ajoutant des fonctions et une syntaxe spécifiques. Scrypto est ainsi un langage utilisant la logique de Rust pour interagir non seulement avec de la donnée, mais aussi avec des actifs, de façon native.

Les fonctionnalités orientées actifs de Scrypto

Scrypto permet aux développeurs de se concentrer sur la logique business de leur code, en se reposant sur la simplicité, la sécurité, la réutilisabilité et la composabilité du Radix Engine.

Ressources, seaux et coffres (resources, buckets et vaults)

Avec Scrypto, les jetons ne sont plus des contrats mais des ressources. Afin de créer une nouvelle ressource, comme un jeton ou un NFT, il faut utiliser une fonction Scrypto en spécifiant les paramètres désirés. Ils concernent entre autres sa quantité (supply), son nom, sa fongibilité… Les ressources doivent toujours se trouver « physiquement » quelque part. Les jetons issus de la fonction de création sont donc tout d’abord présents dans un contenant appelé bucket (seau). Ce dernier disparait à la fin de l’exécution : les ressources doivent donc ensuite être stockées dans un vault (coffre). Quant aux coffres, ils sont toujours localisés au sein d’un composant (l’équivalent d’un smart contract).

Radix - Création de ressources
Création d’une ressource : appel à la fonction, transport, stockage.

La création d’un jeton ne prend ainsi que quelques lignes de code en Scrypto. Différentes fonctions permettent de prendre n’importe quelle quantité de ressources à partir d’un seau ou d’un coffre, et de les placer dans d’autres buckets ou vaults.

Méthodes et composants (methods et components)

Avec Radix, les smart contracts deviennent donc des composants (components). Ces derniers détiennent, en plus des données, des coffres (vaults), contenant toutes les ressources qui sont la propriété du composant. Chaque type de données ou de ressources (spécifiques à un coffre) sont définies dans le code du composant. Il définit également les méthodes (methods) qui établissent la logique du composant, comme dans tous les langages de programmation orientée objet.

Radix - Composants
Architecture d’un composant, avec ses coffres, ses données et ses méthodes.

Blueprints et paquets (packages)

Sur le réseau Radix, les composants ne sont pas déployés comme des smart contracts classiques. Ils sont tout d’abord déployés comme des blueprints : des canevas ou plans à partir desquels de nombreuses copies du composant peuvent être instanciées puis personnalisées. L’état d’un composant (données et coffres) est en revanche exclusif.

Un composant devient actif sur le réseau, et accessible aux utilisateurs, une fois qu’il est instancié à partir d’un blueprint. On utilise pour cela une fonction dédiée :

Radix - Blueprints
Instanciation d’un composant à partir d’un blueprint.

Un groupe de blueprints est appelé un paquet (package). Les fonctions d’instanciation permettent de déployer plusieurs composants et ressources à partir d’un seul blueprint. Grâce à ce concept, il est possible de réutiliser le code, tout en le personnalisant.

Scrypto permet d’instancier puis de configurer de multiples composants et ressources à partir d’un seul blueprint.

Composants et ressources

Une fois instanciés, l’utilisateur interagit avec les composants grâce à ses méthodes. Au niveau de la programmation, le procédé est donc similaire aux smart contracts classiques. Cependant, au niveau des transferts de ressources (les jetons/actifs), le principe est différent. Il ne s’agit pas d’envoyer un message référençant des jetons : le Radix Engine transfère effectivement la propriété de ces jetons au composant.

Une fois propriétaire d’un ou plusieurs buckets de ressources, le composant peut les prélever hors du bucket, et les placer dans un coffre ou un panier différent. Il est ensuite impossible d’accéder à nouveau au bucket. Cela simplifie grandement l’utilisation et la manipulation d’actifs pour les dApps de Radix. Par exemple, lors d’un échange de jetons contre des USD, il n’y a pas à :

  • Appeler un contrat pour obtenir une autorisation de retrait ;
  • Spécifier le montant en entrée ;
  • Appeler le contrat pour effectuer le retrait ;
  • Appeler un contrat pour envoyer les jetons à l’utilisateur ;
  • Vérifier que les soldes sont corrects pour s’assurer qu’il n’y a pas d’erreur.

Tous ces appels aux smart contracts supplémentaires sont autant de vecteurs d’erreurs. Avec la logique du Radix Engine, la méthode du composant permet de transférer simplement les actifs d’un coffre à l’autre.

Les comptes et les transactions sur Radix

Dans le Radix Engine, les transactions sont également orientées actifs. Tout d’abord, les comptes sur Radix sont des composants comportant des coffres. Ils sont instanciés par un blueprint de type Account sur le réseau, avec ses méthodes afférentes.

Radix - Structure d'un compte
Un compte utilisateur simple : deux coffres, deux méthodes (dépôt et retrait).

Lorsque Alice souhaite envoyer 5 jetons CERB à Bob, sa transaction spécifie :

  • Le retrait des 5 jetons à partir du coffre correspondant (l’autorisation étant certifiée par la signature d’Alice) ;
  • L’envoi de ces jetons à la méthode de dépôt du composant compte de Bob.

Puisque les ressources doivent toujours être localisées quelque part, le Radix Engine utilise un bucket pour transférer les actifs à Bob.

Radix - Vue schématique d'une transaction
Vue schématique d’une transaction

C’est donc un bucket, un panier contenant les ressources, qui est envoyé à la méthode Deposit du composant de Bob. Il ne s’agit pas d’une référence, ou d’un appel à un contrat extérieur.

Badges et autorisations

La gestion des autorisations dans le paradigme classique des smart contracts est peu flexible et vecteur de failles. Typiquement, il s’agit de garder la trace d’une liste d’adresses (comptes ou smart contracts) autorisés à effectuer certaines actions.

Le Radix Engine a sa propre solution dans son paradigme orienté actifs. Les ressources peuvent être utilisées en tant que badges. Ces derniers ont le même comportement « physique », mais sont utilisés pour les autorisations. Grâce à des fonctions Scrypto spéciales, les composants peuvent demander la présentation d’un badge pour pouvoir utiliser certaines de ses méthodes.

Le concept de présentation diffère de celui de transfert. Il s’agit de prouver la propriété du badge, sans pour autant la modifier. Cela ouvre la voie à des séquences d’autorisations complexes. Ainsi, les listes blanches (whitelists) classiques sont remplacées par des ensembles de badges, pouvant être créés puis délivrés à des comptes ou à d’autres composants.

Ce sont les méthodes qui définissent quels badges sont requis pour que l’on puisse les utiliser. La non-présence du badge requis entraîne le rejet de toute transaction faisant appel à la méthode correspondante.

Les avantages de Scrypto

Le Radix Engine, Scrypto et leur approche asset-oriented permettent alors aux développeurs de se focaliser sur le code réellement important : la logique financière de la dApp. Les interactions entre jetons (ressources), pools (coffres, vaults) et utilisateurs (composants) sont simplifiées. En reprenant l’exemple d’Uniswap, voici à quoi ressemble un échange de jetons implémenté en Scrypto :

Uniswap - Radix version
Un swap de jetons avec Radix : les flux et les interactions sont ramenés au minimum.

Seules les mathématiques de l’échange doivent être codées : 

  • Calcul du taux de change en fonction du bucket de ressources (jetons A) et des réserves en ressources B du vault ;
  • Envoi de la quantité de jetons B correspondante.

Les transferts de jetons se résument à des fonctions take/put. La transaction ressemble donc schématiquement à ceci :

Uniswap - Swap via Scrypto

Non seulement cette approche est simple et sûre, mais elle est aussi très flexible. Cela ouvre la voie à des applications DeFi bien plus complexes que ce qui est actuellement possible. Nous aborderons ce volet dans le deuxième article à sortir très prochainement.

Ressources et références

Si l’ambitieux Radix vous intéresse, vous trouverez ci-dessous toutes les liens et ressources nécessaires pour rejoindre sa communauté, et approfondir votre compréhension du projet. Le jeton natif de Radix, le XRD, est disponible sur de nombreuses plateformes, et directement achetable sur le site officiel via Alchemy Pay. L’équipe communique très régulièrement sur les réseaux sociaux et sur son blog.

Afin de tester la plateforme, l’utilisation du Radix Wallet, clair et intuitif, est une première étape. Un système ludique de quêtes vous permettra d’obtenir vos premiers jetons XRD.

Réseaux sociaux

Ressources

Morgan Phuc

Cofounder @ 8Decimals & Partner @ Node Guardians - Making crypto great again - Journal du Coin / BitConseil