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 reste relativement long. En effet, de nombreux concepts qui sous-tendent le design de Radix diffèrent – radicalement – de l’existant. Nous commencerons donc 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.
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.
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.
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).
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.
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 :
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.
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.
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 :
Un swap de jetons avec Radix : les flux et les interactions sont simplifié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 :
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.
Des briques Lego pour la DeFi
Derrière cette appellation (on-network DeFi Lego Bricks) se cache des librairies, des frameworks et autres outils pour les développeurs Scrypto sur Radix. Comme pour les suites logicielles classiques, ils permettent aux programmeurs de créer plus rapidement leurs dApps, en réutilisant ce que d’autres ont déjà réalisé. De plus, cette standardisation générale améliore l’interopérabilité entre les applications.
Radix est donc résolument orienté vers l’open source et la collaboration. Les fonctionnalités classiques de la DeFi sont préexistantes, éprouvées et maintenues :
Actifs fongibles ou NFT ;
Comptes ;
Représentations de parts d’un fonds ou d’un pool ;
Contrôle multipartite ;
Pools de liquidité ;
Échanges (swaps) ;
Oracles ;
Etc.
L’avantage du réseau décentralisé est que la collaboration communautaire et la gestion des packages s’effectue directement sur ce dernier. Les blueprints peuvent être utilisés de façon modulaire, adaptés, mis à jour, versionnés et combinés. Il n’y a pas à copier/coller du code au sein d’un projet : il suffit d’utiliser l’environnement partagé du réseau pour utiliser les blueprints déjà déployés et opérationnels.
Ainsi, les développeurs n’ont donc pas à construire leur dApp de A à Z : ils peuvent réutiliser et combiner des blueprints fonctionnels. La philosophie de Radix est ainsi très proche de celle des créateurs d’UNIX dans les années 70. Des programmes simples et efficaces, pouvant être facilement combinés, pour bien fonctionner dans un ensemble plus complexe. Cela maximise l’interopérabilité et la modularité, tout en permettant à chacun de contribuer à son niveau pour l’ensemble de la communauté.
Le Catalogue des Blueprints
Le modèle de Radix diffère grandement des plateformes de smart contracts classiques, où les développeurs écrivent leur code, le déploient sur le réseau, et laissent les utilisateurs interagir avec. Le code Scrypto déployé sur Radix devient un blueprint ajouté à un registre appelé Blueprint Catalog.
Tout code déployé sur le réseau est ajouté au catalogue des blueprints.
Pour instancier un composant à partir d’un blueprint disponible dans le catalogue, le développeur appelle une fonction qui active le ou les composants et ressources désirés. Il spécifie les paramètres pour personnaliser son instance, et peut ainsi instancier plusieurs composants à partir d’un unique blueprint.
Il suffit de spécifier les paramètres désirés pour instancier plusieurs composant à partir du même blueprint.
Avec ce nouveau paradigme d’environnement applicatif, les développeurs accèdent de façon rapide, facile et sécurisée aux fonctionnalités déjà créées, testées et éprouvées. Les Blueprints peuvent être instanciés et personnalisés grâce à une simple transaction. On peut programmer leur instanciation via d’autres Blueprints ou Composants, et construire ainsi les fonctionnalités d’une dApp de façon modulaire. En d’autres termes, c’est comme si sur Ethereum, il suffisait d’appeler une fonction et de spécifier ses paramètres pour créer plusieurs jetons ERC-20 en quelques lignes de codes.
Exemple
Bob souhaite par exemple déployer un protocole de prêt sur Radix. Pour cela, il utilise un AMM à fonction constante afin de réaliser les swaps des actifs pris en charge par sa dApp. Dans son Blueprint Lender, il va alors instancier un blueprint existant correspondant à l’AMM, puis le configurer à sa guise.
Les Blueprints possèdent leur adresse unique, associée à celle de leur créateur. Radix propose un système de versionnage, chaque mise à jour nécessitant révision. Cependant, les différentes versions d’un Blueprint cohabitent de façon immuable sur le réseau. La mise à jour d’un blueprint n’entraîne donc pas automatiquement celle des blueprints ou composants instanciant ce dernier.
Un écosystème de développeurs auto-incitatif
Radix étend le concept d’incitation économique propre aux réseaux blockchains à l’écosystème de ses développeurs.
Les royalties
Le système de Developer Royalties de Radix est particulièrement intéressant et innovant. Il est conçu pour catalyser la croissance de l’écosystème, de la même façon que les récompenses de bloc incitent mineurs et valideurs à participer. Il s’appuie sur le Blueprint Catalog.
Les Developer Royalties sont pour les développeurs l’équivalent économique des récompenses de bloc pour les mineurs/validateurs d’un réseau blockchain.
Le système est simple mais efficace : le développeur d’un blueprint/composant peut définir des royalties pour chaque utilisation de son code au sein d’une transaction. Lors de chaque transaction nécessitant son utilisation, son développeur touche ainsi une petite commission. Les royalties sont donc basées sur l’utilité réelle du composant.
Puisque les blueprints et les composants sont présents sur le réseau (il ne s’agit pas de copier/coller du code pour les utiliser), le Radix Engine assure que ces royalties seront versées. De plus, ces paiements s’effectuent de manière complètement décentralisée, en fonction de l’utilité du travail apporté par le développeur. Cette propriété exclusive de Radix établit une sorte de place de marché developer-2-developer. Les royalties sont versées de façon automatique, et garanties par le mécanisme de consensus de Radix.
Un système de récompense basé sur l’utilité des contributions
Les Composants sont instanciés via des blueprints originaux. Ainsi, le développeur fixe ses royalties avant de déployer son blueprint dans le Catalogue. Lorsqu’une transaction fait appel à un composant instancié via son blueprint, son créateur perçoit sa royalty.
Les royalties sont automatiquement calculées et ajoutées aux frais par le Radix Engine, au moment de la création de la transaction. L’utilisateur verra donc leur montant sur son wallet, en plus des traditionnels frais de transaction. Il incombe à chaque développeur la responsabilité de calculer finement ses royalties, en fonction de l’utilité et de la valeur de son code. Ainsi, certaines méthodes pourront être gratuites, tandis que d’autres seront payantes.
De nouveaux flux de revenus pour les développeurs
Ce modèle incite donc les développeurs à fournir les fonctionnalités les plus utiles et efficaces pour être récompensés. Cela incite également à créer des blueprints standards, largement adoptés, améliorant d’autant plus la modularité générale de la plateforme.
Dans l’exemple de l’utilisation d’un AMM, le créateur du blueprint de base et le développeur de la dApp utilisant un composant instancié via ce blueprint sont tous deux récompensés.
Les royalties peuvent être cumulatives. Par exemple, le créateur d’un blueprint d’oracle percevra des royalties à chaque utilisation, tandis que le développeur d’un composant instancié à partir de cet oracle pourra être aussi récompensé pour son usage spécifique (par exemple s’il fournit des données originales, ou si sa version est adoptée par une dApp).
Ce modèle inédit permet de créer des flux de revenus on-chain pour les développeurs, pouvant inspirer de nouveaux business modèles. Il est possible de modifier le montant des royalties, toutefois, il faudra préalablement accepter l’ensemble des royalties associé à chaque nouvelle version d’un blueprint ou d’un composant pour l’utiliser.
Le guide du développeur
Le guide du développeur est l’interface regroupant les différents blueprints du Catalogue, qui sera fournie par la Fondation Radix. On y trouvera facilement toutes les informations les concernant : frais de transaction, prix des royalties, historique des versions, identifiant et réputation du développeur, usage, etc. De même, ce front-end facile d’accès permettra d’accéder aux données des différents composants instanciés sur le réseau. Cela permettra aux développeurs de découvrir tous les blueprints et les composants pour accélérer leur travail.
La Radix Foundation, résolument axée sur l’open source, compte voir croître un écosystème d’applications DeFi portée par une communauté de développeurs, récompensée à la juste mesure de son travail. La Fondation est là pour épauler cette communauté, en fournissant des blueprints-clés, exempts de royalties. De même, lors des stages initiaux de la croissance du réseau, elle récompensera les opérateurs de nœuds et les développeurs.
Cerberus, le protocole de consensus BFT parallélisé de Radix
À l’instar des plateformes de smart contracts et DLT de dernière génération, Radix présente un très haut débit de transactions. Plus précisément, Radix vise une scalabilité illimitée selon trois axes :
Débit de transactions illimité ;
Utilisation des applications DeFi illimitée ;
Composabilité illimitée entre les applications décentralisées.
Nous avons passé en revue le fonctionnement du Radix Engine, il est maintenant temps de s’intéresser au mécanisme de consensus de Radix : Cerberus.
Composabilité versus scalabilité
L’approche la plue répandue pour améliorer la scalabilité d’un DLT est celle du sharding (la fragmentation du réseau). Il s’agit de paralléliser les opérations à travers différentes parties du réseau (shards), pour augmenter son débit global. Certains réseaux utilisent une architecture en sidechains, articulées autour d’un hub : c’est le cas de Cosmos et de Polkadot. D’autres fragmentent les blocs, afin que différents nœuds traitent ces morceaux indépendamment, comme Near. Avec cette approche, applications et transactions sont réparties au sein de différents shards, pour être traitées en parallèle.
Les différents shards doivent communiquer entre eux. Les limites de ces architectures se posent lorsque les consensus des shards sont différents. Il faut trouver des méthodes de coordination. Dans tous les cas, elles vont affecter le débit du système, d’autant plus si le nombre de shards est fixe, et que les dApps et actifs du réseau global sont assignés à des shards statiques. Cela ralentit l’ensemble, peut provoquer des erreurs et renforce la complexité du code.
La scalabilité des plateformes DLT est donc souvent atteinte au détriment de la composabilité des applications décentralisées. Par composabilité, on entend la capacité des différents dApps et actifs à être interopérables. L’idéal est la composabilité « atomique » : valider ou rejeter des séries de transactions complexes entre différentes dApps en une seule étape. Cet objectif est au cœur du design de Cerberus.
Le consensus « tressé » de Cerberus
En tenant compte des observations ci-dessus, Radix et son système de sharding est conçu selon trois principes :
Nombre de shards illimité ;
Protocole de consensus dynamique et synchrone entre les shards concernés par une opération atomique ;
Couche applicative adaptée.
Le concept central de Cerberus est nommé le « pré-sharding ». Le registre est initialement fragmenté en un très grand nombre de shards (virtuellement illimité). Ces fragments sont ensuite utilisés pour représenter tout type d’objet. Cerberus peut alors « tresser » un consensus sécurisé pour un nombre arbitraire de shards. On parle de « braided consensus » : nous allons nous contenter dans cet article d’explorer ce concept dans ses grandes lignes. Afin d’avoir plus de détails, il faut se référer au whitepaper dédié : Cerberus – A Parallelized BFT Consensus Protocol for Radix.
Ordonnancement partiel
Les registres distribués reposent sur l’ordonnancement global des transactions : elles sont toutes placées sur la même échelle temporelle. Avec Cerberus, l’ordonnancement ne concerne que la transaction à traiter. Tout d’abord, la couche applicative de Radix spécifie quels shards sont requis pour son exécution.
Sélection des shards concernés par la transaction.
Tressage
Une fois la sélection des shards effectuée, l’algorithme de consensus BFT consiste à exécuter une instance de 3 rondes de consensus pour chaque shard (appelée 3-chain). Toutes ces instances (donc ces shards) sont « tressées » les unes avec les autres, grâce à des mises en gage cryptographiques. Ces commitments sont produits et partagés par les nœuds leaders des shards concernés. On obtient alors un consensus « émergent », qui assure que tous les shards peuvent peuvent s’engager dans la transaction – atomic multi-shard transaction.
La transaction est bien atomique grâce aux mises en gage entre les shards (d’où l’appellation « tressage »).
Consensus dynamique
Le protocole est conçu pour paralléliser ces processus de consensus. Chaque shard a sa propre instance locale. Elles sont exécutées de façon indépendante, comme toute instance multi-shard qui n’est pas reliée temporellement à une autre à l’instant t au moment de l’exécution.
Cerberus est donc un algorithme de consensus conçu pour des réseaux d’applications et de transactions simultanées divers, de très grande taille. La scalabilité est linéraire, car la parallélisation des ensembles de shards est illimitée. De multiples opérations peuvent être effectuées en même temps sans ralentir le reste du système. Si la charge du réseau augmente, il suffit d’augmenter le nombre de nœuds. La section « Labs » du site officiel de Radix comporte un calculateur du débit de transactions en fonction du nombre de nœuds.
La scalabilité linéaire de Radix
La couche applicative de Radix
La parallélisation des tâches grâce à Cerberus confère donc au réseau un débit virtuellement illimité en termes de transferts d’actifs. Pour ce qui est de l’exécution des smart contracts, il faut concevoir une couche applicative adaptée. Cette dernière définit les règles qui régissent les sous-états du registre (substates). De plus, elle doit assurer que chaque transaction définit quels sous-états (et donc les shards concernés) doivent être inclus dans le consensus.
Un substate est donc un enregistrement qui fixe les règles d’une opération précise. Par exemple, lors d’un transfert de jetons entre Alice et Bob, les sous-états définissent :
Les 5 jetons se trouvent sur le compte de Bob ;
Ces 5 jetons ne se trouvent plus sur le compte d’Alice.
Ces deux substates permettent de s’assurer que les jetons ne sont ni perdus, ni créés. Il est donc très important, pour paralléliser les tâches, que la couche applicative donne à Cerberus la liste des shards concernés pour chaque transaction.
C’est grâce au Radix Engine que l’on peut définir les sous-états et leur importance pour une transaction donnée. En effet, les jetons sont traités comme des objets, au niveau de la plateforme. Ce concept de ressources permet de paralléliser les transferts autant que possible : les actifs sont disséminés au sein des sous-états et des shards à la demande. Ce n’est pas possible avec l’EVM, où les jetons sont représentés à travers des smart contracts individuels.
Structure des transactions
Conceptuellement, la façon dont les déplacements d’actifs fonctionnent sur Radix diffère des modèles UTXO classiques, comme Bitcoin ou Cardano.
Une transaction sur le Radix Engine spécifie l’intention de la transaction. Pour comprendre, imaginons le fonctionnement d’un smart contract devant traiter un grand nombre de transactions en même temps. Dans la version naïve, chaque transaction devrait spécifier quels substates/shards sont concernés et identifier les actifs à déplacer. Cela poserait des problèmes en cas d’utilisation massive du réseau :
Le portefeuille de l’utilisateur identifie les jetons à déplacer lors du swap, puis initie la transaction ;
Dans le même temps, un autre utilisateur effectue un swap, mais son portefeuille identifie les mêmes jetons ;
La première transaction devient alors invalide, et échoue.
C’est un problème qui s’est posé lors du lancement du premier DEX sur Cardano. Ces conflits proviennent du modèle de transaction : les UTXO doivent être identifiés préalablement au transfert des fonds.
Avec Radix, les jetons ne sont pas identifiés lors d’une transaction. Il s’agit simplement de communiquer l’intention :
« Je souhaite envoyer cette quantité de jetons A sur le DEX (peu importe lesquels), et souhaite recevoir en échange cette quantité de jetons B en retour (peu importe lesquels). »
Les substates spécifiques à la transaction sont donc déterminés par le Radix Engine au moment de son exécution sur le réseau. Il « regarde » quels jetons sont disponibles, et prend la quantité désirée au moment où le réseau opère la transaction. Cela évite ainsi les conflits.
Structure des composants
Les composants de Radix, ainsi que leurs données et ressources, sont assignés à un shard unique, à n’importe quel moment dans le temps. De la sorte, chaque composant peut traiter autant de transactions que nécessaire. Pour chaque composant, le Radix Engine « capture » l’état de ce dernier au sein d’un unique substate. Toute ressource entrant dans le composant est incluse dans ce sous-état. À l’inverse, si une ressource quitte le composant, elle disparaît du substate.
Il en va de même pour les comptes, qui sont aussi des composants. Les applications décentralisées utilisant plusieurs composants font donc usage de plusieurs shards. Par exemple, dans le cas d’un DEX, chaque paire de trading utilisera un shard différent, et les échanges pourront être traités en parallèle.
Le sharding avec le Radix Engine et Cerberus
Nous en revenons à la notion de composabilité, qui ne doit pas être affectée par l’aspect hyperscalable de Radix. Sur Ethereum, les dApps peuvent être composables, mais toutes les transactions et les appels entre smart contracts passent par le même mécanisme de consensus global.
Dans le cas classique, les transactions composées entre de multiples dApps (entourées en gris) restent traitées par l’algorithme de consensus global du réseau.
Les mécanismes de sharding permettent de paralléliser les opérations, à travers un nombre fixé de shards ou de sidechains. Comme nous l’avons vu, bien que cela augmente le débit global, cela limite la composabilité entre les shards/sidechains. Le débit de chaque shard reste également limité.
Avec le sharding classique ou les systèmes de chaînes secondaires, la composabilité entre les dApps est compromise.
La combinaison du Radix Engine et de Cerberus permet de s’affranchir de ce compromis :
Transactions (« déplacement » des ressources) effectuées en parallèle sans goulot d’étranglement ;
Exécution des composants simultanée et sans conflits ;
Parallélisation des opérations des dApps, grâce aux multiples composants logiquement indépendants, qui augmente encore le débit ;
Sélection des ressources et composants nécessaires pour chaque transaction, qui maximise l’efficacité de la parallélisation.
La composabilité est assurée par Cerberus, qui exécute les transactions atomiques entre les shards. La scalabilité de Radix est ainsi virtuellement illimitée sans compromettre la composabilité atomique grâce au système de transactions cross-shards.
Radix : scalabilité et composabilité.
Le design unique de Radix a pour but de créer une plateforme DeFi réellement adaptée à une adoption de masse et à la finance globalisée !
La feuille de route de Radix vers l’hyperscalabilité
Nous avons passé en revue la technologie de Radix de façon théorique. En pratique, le projet est toujours en développement. La feuille de route de Radix vise à atteindre l’objectif d’hyperscalabilité – la capacité du réseau à accueillir des milliards d’utilisateurs – vers 2027.
Elle comporte 3 étapes :
Cassandra (2025). Il s’agit de la plateforme de test du Radix Engine.
Radix Engine (2025). Déjà implémenté lors de l’étape Babylon, il sera testé par la communauté après implémentation de la mise à jour du système de sharding, puis audité.
Xian : il s’agit de l’étape finale, la mise en production. La version alpha est prévue pour début 2027, et son lancement vers la mi-année. Xian sera implémenté en Rust en 2026, et intégrera toutes les fonctionnalités de la plateforme.
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.
En tant que développeur, Radix est bien sûr une opportunité à ne manquer si vous souhaitez travailler dans l’industrie Web3. Le système unique des royalties est particulièrement incitatif si vous souhaitez contribuer. Le Developer Hub vous permettra de vous familiariser avec Scrypto. Radix propose également un programme (incluant des récompenses) pour bâtir sa communauté, et l’accès à de futurs événements. Quant aux offres d’emploi, elles sont disponibles ici.
Réseaux sociaux
Discord
Facebook
GitHub
Medium
Reddit
Telegram
X
YouTube
LinkedIn
Ressources
Site officiel
Blog
Podcast
DeFi Whitepaper
Cerberus Whitepaper
Peer review de Cerberus et analyse mathématique formelle
L’article Radix DLT – Présentation complète – Un nouveau paradigme pour les smart contracts et la DeFi est apparu en premier sur Journal du Coin.
