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.
Cet article est la suite de la première partie où nous avions récemment posé les principes généraux du protocole et les principaux détails techniques. Il est important d’avoir lu cette première approche au préalable.
Nous allons aujourd’hui aborder la mise en pratique et les outils spécialement conçus pour changer la vie des développeurs. En effet, de nombreux concepts qui sous-tendent le design de Radix s’éloignent radicalement des normes actuelles en la matière. Nous nous baserons sur le livre blanc du projet afin d’exposer cette boite à outils technologique. Pour nous y aider, l’équipe a réalisé de nombreux schémas explicatifs, qui nous permettront de saisir la manière dont le travail de développement sur Radix diffère fondamentalement des plateformes existantes.
Le Journal du Coin vous propose cet article promotionnel en collaboration avec Radix.
Un protocole taillé pour la DeFi
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.
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.
Des « briques Lego » pour décentraliser la finance
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.
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. En effet, 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. Il peut ainsi instancier plusieurs composants à partir d’un unique blueprint.
Spécifier les paramètres désirés est suffisant 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 ainsi ê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 se basent donc 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 le versement de ces royalties. 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 gagner des récompenses. 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 que fournit 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 se répartissent 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
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.
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
Discord
Facebook
GitHub
Medium
Reddit
Telegram
X
YouTube
LinkedIn
Ressources
Peer review de Cerberus et analyse mathématique formelle
Site officiel
Blog
Podcast
DeFi Whitepaper
Cerberus Whitepaper
L’article Radix DLT – Présentation partie 2 – Une nouvelle norme pour les développeurs est apparu en premier sur Journal du Coin.
