Ce n’est pas un secret, les dApps sont aujourd’hui confrontées à des problèmes majeurs de scalabilité, de sécurité et de complexité du développement qui freinent l’adoption massive de la DeFi en général.
C’est là que Radix entre en jeu, un layer 1 haute performance conçu spécifiquement pour les applications décentralisées (dApps) avec une architecture qui rend leur développement bien plus efficace.
Cet article vous est proposé en collaboration avec Radix (en savoir plus)
Sommaire :
- Radix : le premier layer 1 conçu pour les développeurs DeFi
- Comment fonctionne Radix ?
- Radix Engine : l’environnement idéal pour la création de smart contracts
- Scrypto : le langage de programmation adapté aux nouvelles dApps
- Cerberus : un consensus qui rend les dApps hautement scalables
- Radix : Une relation particulière avec ses transactions par seconde (TPS)
- Flash Liquidity de Radix : unifier la liquidité fragmentée de la DeFi
- L’importance des Blueprints réutilisables au sein de Radix
- Comment Radix récompense ses développeurs ?
- Radix Wallet : le wallet natif du réseau Radix
- Radix : un écosystème rempli de d’applications décentralisées (dApps)
- Radix roadmap : dernière ligne droite avant la version finale
- $XRD : le jeton natif de l’écosystème Radix
- Tokenomics du jeton Radix (XRD)
- Suivre Radix
- Radix est un protocole de couche 1 (layer 1) axé sur la création d’applications décentralisées vraiment optimisées
- Radix se base sur plusieurs technologies clés, comme Radix Engine, le consensus Cerberus ou encore le langage de programmation Scrypto.
- Radix possède deux jetons : $XRD et $eXRD
Radix : le premier layer 1 conçu pour les développeurs DeFi
Radix est un layer 1 conçu spécifiquement pour le développement d’applications décentralisées (dApps). Son objectif : créer un environnement décentralisé adapté au développement de dApps hautement scalables, sécurisées et bien moins coûteuses pour les utilisateurs.
Pour mener cette vision jusqu’au bout, l’architecture et le fonctionnement global de Radix se basent avant tout sur 4 principes fondamentaux :
- Un smart-contract “Asset-oriented” qui vise à résoudre les problèmes de complexité et de sécurité dans le développement de dApps, avec la mise en place de smart contracts centrés exclusivement sur les actifs.
- Un environnement DeFi “lego bricks” qui vise à résoudre les défis de modularité et de réutilisabilité des codes.
- Un mécanisme “Self-incentivizing” pour les développeurs qui vise à résoudre le problème de motivation financière (incentives) pour les créateurs et développeurs de dApps.
- Un environnement hautement scalable pour les dApps qui vise à résoudre les limitations de performance rencontrées sur d’autres réseaux comme Ethereum, en créant un écosystème scalable à l’infinie (ou presque).
Pour rendre cette vision possible, Radix se base sur tout un tas de technologies et d’infrastructures que nous vous proposons de découvrir dans les prochaines sections.
Comment fonctionne Radix ?
Il faut savoir que Radix se base principalement sur trois composantes clés :
- Radix Engine (application layer) : C’est là que les smart contracts sont déployés et exécutés. Il faut le voir comme un environnement optimisé pour la création et la gestion d’applications DeFi.
- Cerberus (consensus layer) : cette couche assure l’exécution et la scalabilité des transactions à travers le réseau Radix, en se basant sur différents principes comme le “Pré-sharding” ou encore sa méthode “Braiding” que nous aborderons plus tard dans l’article.
- Scrypto programming language : langage de programmation spécialement conçu pour Radix, à l’instar de Rust pour Solana.
Maintenant, ce qui rend Radix unique est son environnement “Asset-Oriented Smart Contract”. Pour résumer, cette approche simplifie radicalement le développement et l’exécution des smart contracts en se concentrant sur les actifs eux-mêmes plutôt que sur leur traitement. Pour cela, Radix se base sur sa propre couche d’application : Radix Engine.
Revenons plus en détail sur chacun de ces éléments 👇
Radix Engine : l’environnement idéal pour la création de smart contracts
Radix Engine est donc le moteur (engine) central, c’est-à-dire l’environnement d’exécution des smart contract au sein du layer 1. Il est spécialement conçu pour optimiser et sécuriser le développement de dApps.
Radix Engine traite les actifs numériques différemment des autres blockchains. Plutôt que de voir les actifs comme de simples données, Radix les traite comme des entités “physiques” avec des règles propres, et ce, grâce à l’utilisation d’une « finite state machine » (FSM). Ce mécanisme est utilisé pour garantir que les résultats soient corrects.
De plus, chaque actif, qu’il s’agisse de tokens, de NFT ou même de contrats intelligents, est géré individuellement.
Avec la version 2.0 du Radix Engine, la complexité est encore davantage réduite pour les développeurs. En effet, ils n’ont plus à écrire de longs scripts pour assurer la sécurité de leurs applications. Les actifs sont déjà protégés par les mécanismes internes du Radix Engine, ce qui élimine d’ailleurs le risque de « double dépense » et réduit le risque de fraudes.
D’autres aspects du Radix Engine ont été améliorés grâce à la version 2 comme l’intégration du langage Scrypto, la finalité des transactions, et des améliorations sur l’évolutivité du réseau et les performances.
Finalement, Radix Engine est conçu pour être extrêmement efficace. Il permet aux applications de fonctionner rapidement, même lorsqu’elles traitent un grand nombre de transactions ou lorsqu’elles interagissent avec de nombreux utilisateurs simultanément.
Pour en apprendre davantage sur Radix Engine 👉 cliquez sur ce lien
Scrypto : le langage de programmation adapté aux nouvelles dApps
Scrypto est un langage de programmation spécialement conçu pour le développement d’applications DeFi sur la blockchain Radix. Ce dernier s’inspire largement de Rust, le langage de programmation utilisé par Solana.
Toutefois, Scrypto ajoute des fonctionnalités spécifiques pour interagir non seulement avec des données, mais aussi directement avec des assets financiers, comme des monnaies ou des tokens. En effet, les assets sont intégrés dans le langage même du code, ce qui facilite leurs création, gestion et échange.
Un autre point important : avec Scrypto, les contrats intelligents sont appelés des “composants“, soit des blocs de code réutilisables qui “encapsulent” la logique et la gestion des actifs. Cela peut inclure des fonctionnalités comme des échanges de tokens, des prêts, ou des mécanismes de staking.
Pour faire simple : c’est l’équivalent d’un smart contract sur d’autres plateformes comme Ethereum. Cependant, contrairement aux smart contracts traditionnels qui sont souvent centrés sur des fonctions et des données, les composants dans Scrypto sont conçus autour des ressources (tokens, NFT ,etc.) qu’ils gèrent.
Pour comprendre leur fonctionnement, comprenez déjà qu’ils regroupent différentes entités, dont les “Buckets” et les “Vaults” :
- Buckets (seaux) : conteneurs temporaires qui transportent des ressources d’un point à un autre dans une transaction. Dès lors qu’une ressource est créée, cette dernière est immédiatement placée dans un « bucket« .
- Vaults (coffres): stockages pour les ressources au sein des composants. Ils sécurisent les actifs jusqu’à leur utilisation ou transfert ultérieur. Notez que chaque composant peut posséder un ou plusieurs vaults.
Vous l’aurez compris, toute l’interaction entre les composants et les ressources est centralisée autour de l’utilisation de buckets et de vaults.
Par exemple, lorsqu’un utilisateur souhaite effectuer une transaction impliquant des ressources, il les place d’abord dans un bucket. Ce bucket est ensuite utilisé pour passer les ressources à un composant, qui peut ensuite manipuler ces ressources conformément à sa “logique métier”, les stockant finalement dans un ou plusieurs vaults.
Nous le verrons plus en détail plus tard dans l’article, mais les composants sont générés à partir de « blueprints« , des modèles que d’autres développeurs peuvent utiliser pour reproduire ou modifier des fonctionnalités dans leurs propres projets.
Pour en apprendre davantage sur Scrypto 👉 cliquez sur ce lien
Cerberus : un consensus qui rend les dApps hautement scalables
Cerberus est la couche (layer) de consensus de Radix. Pour rappel, dans une blockchain, le consensus est la façon dont le réseau s’assure que toutes les transactions sont valides et enregistrées de manière sécurisée.
Il est important de mentionner que ce consensus arrive sur le mainnet via différentes couches de développements qui apportent des fonctionnalités à Cerberus (plus de détails dans la partie Roadmap).
Les fonctionnalités telles que la composabilité atomique et la scalabilité illimitée sont actuellement en cours de test sur le testnet Cassandra et devraient être déployées grâce à la mise à jour Xi’An, prévue pour fin 2024.
Quand un réseau blockchain devient très populaire, il doit gérer beaucoup de transactions à la fois. Cela peut ralentir le réseau et rendre les transactions coûteuses.
Pour résoudre cette problématique, Cerberus se base sur différents aspects, comme le Sharding, un ordonnancement partiel (partial ordering) des transactions, une composabilité atomique, et le plus important : son mécanisme “Braiding”.
Tout d’abord, Cerberus utilise une technique appelée « pre-sharding« . Concrètement, Cerberus divise le “ledger” (registre numérique) de Radix en plusieurs « shards », ou plutôt en un “espace de shards” (sharspace) pratiquement illimité.
Chaque shard peut gérer des transactions de manière indépendante. Cela permet à Radix de traiter beaucoup plus de transactions simultanément que le ferait une blockchain traditionnelle.
Mais ce n’est pas tout. Plutôt que de forcer toutes les transactions à suivre une seule séquence, Cerberus, grâce à son mécanisme de “Partial Ordering”, permet à chaque transaction de spécifier uniquement les shards qui sont directement concernés par elle.
Ces transactions ont ensuite comme objectif de transmettre ces shards à l’algorithme de consensus Cerberus que nous vous proposons d’analyser en détail :
Braiding : une version améliorée du BFT (Byzantine Fault Tolerant)
Le “Braiding” est le mécanisme de consensus utilisé par Cerberus pour lier et sécuriser les transactions qui s’étendent sur plusieurs shards, soit des transactions “multi-shard”. C’est un type de consensus BFT (Byzantine Fault Tolerant), notamment utilisé par Solana, Stellar ou encore Fantom. Mais la version développée par Cerberus est assez différente.
Accrochez-vous, la suite risque d’être un peu plus technique :
Lorsqu’une transaction doit être validée à travers différents shards, Cerberus « tresse » (braid) le consensus en intégrant les validations de chaque shard concerné. Plus simplement, le mécanisme relie les consensus des shards concernés par les transactions “multi-shard”, afin de former un consensus global et sécurisé pour chaque transaction.
Pour rappel, les transactions peuvent spécifier quels shards sont impliqués. Par exemple, si une transaction nécessite des données de trois shards différents, ces shards seront alors identifiés par le réseau.
Pour chaque shard, une instance de consensus BFT appelée « 3-chain » est créée. Autrement dit : chaque shard commence par valider sa partie de la transaction via le mécanisme de consensus BFT. Notez que le « braiding » est en capacité de traiter un nombre illimité d’instances (shards).
Par la suite, les leaders (responsables de tous les shards associés à la transaction) de chaque 3-chain partagent leurs engagements et signatures avec les leaders des autres shards impliqués. Ces interactions créent un consensus « braided » ou « 3-braid« , garantissant que tous les shards concernés par la transaction arrivent à une validation cohérente et simultanée.
Une fois que le 3-braid est formé, la transaction est validée de manière atomique. Cela signifie que soit toutes les parties de la transaction sont validées et enregistrées ensemble, soit la transaction échoue entièrement.
Radix : Une relation particulière avec ses transactions par seconde (TPS)
Les équipes marketing des projets de crypto monnaies adorent communiquer leurs nombre de transaction par seconde (TPS) max pour impressionner les initiés et attirer l’attention en mettant en avant leur capacité de traitement élevée, suggérant ainsi une potentielle supériorité technologique de leur blockchain. En 2019, Radix annonçait avoir atteint 1 400 000 TPS sur son réseau de test Tempo.
Les blockchains affichent souvent des statistiques de TPS incroyablement élevés obtenus dans des environnements de test optimisés, qui ne reflètent pas nécessairement les conditions d’utilisation réelles sur un réseau décentralisé.
Pour se rapprocher de la vérité, il est important de vérifier si les tests de Radix ont pris en compte des transactions très basiques ou complexes, la finalité des transactions, le nombre de validateurs sur le réseau ou des éléments comme la latence qui pourraient affecter la performance dans un contexte d’utilisation réel.
Il est important de comprendre la situation autour des chiffres de TPS des blockchains. Nous pouvons les distinguer en 3 catégories :
- Les TPS théorique : c’est le nombre maximal de transactions que la blockchain pourrait traiter. Cette valeur est souvent basée sur des simulations ou des calculs. Le nombre de TPS théoriques n’est jamais atteint en pratique.
- Les TPS en environnement de test : ces chiffres sont obtenus dans des conditions de test optimisées, où la blockchain fonctionne sans la complexité du monde réel (comme la latence réseau). En général, les paramètres sont souvent choisis pour optimiser au maximum les transactions par seconde. Il faut d’ailleurs différencier le nombre maximum de transactions par seconde qu’un protocole de crypto monnaie peut atteindre et son nombre de transactions par seconde sur une période de temps conséquentes (plusieurs heures) pour se faire une idée des TPS réelles.
- Les TPS réelles : cette donnée reflète les performances de la blockchain en conditions réelles, où le protocole de crypto monnaie doit gérer des charges imprévisibles, des interactions complexes, et maintenir le consensus. Cette valeur est systématiquement inférieure aux deux premières.
Lors de son test, Radix a récupéré et rejoué 10 ans d’historique de transaction de Bitcoin sur son réseau de test Tempo. Le test a été effectué avec plus de 1 000 nœuds répartis géographiquement dans 17 pays à travers le monde. Cette donnée se rapproche donc de conditions réelles et est vérifiable.
Cependant, des détails manquent quant à la légitimité de ce test :
- Le manque de transactions complexes. En effet, le réseau a décidé d’utiliser 50% de transactions complexes lors de leur test.
- Avec le cloud computing, il est possible de créer un superordinateur par le biais de l’informatique en utilisant différents ordinateurs reliés via le cloud pour fonctionner comme un seul, facilitant ainsi une valeur de TPS élevée. Pas de détails donnés à ce propos.
- Les articles ne mentionnent nulle part la réalisation de la preuve de l’enjeu. En effet, la seule chose qui est évoquée comme étant décentralisée est le registre. Un registre décentralisé ne signifie pas nécessairement que la preuve de travail ou d’enjeu est décentralisée.
Si le réseau de test Tempo a tout de même permis cette scalabilité, il est également apparu qu’il était vulnérable à deux vecteurs d’attaque. Le premier est un problème au niveau de la composabilité atomique qui signifie qu’un petit nombre de nœuds peut créer une situation où le consensus est suffisamment faible pour qu’ils aient une influence sur les transactions historiques. Le deuxième vecteur était la possibilité d’attaques de type Sybil.
A l’heure actuelle, le record de TPS réelles semble être de 50, mais le réseau n’est pas utilisé a 100%, il y a donc probablement beaucoup de marge. En effectuant un bref calcul suite aux arrivées des RadQuest, qui ont amené du trafic sur la blockchain, le réseau a tourné sur environ 10 TPS sur la plus grosse journée.
Plus récemment, Radix a annoncé une nouvelle étape en termes de performances avec son dernier testnet et le traitement de transactions exclusivement complexes. En effet, le traitement de 300 000 swaps atomiques par seconde a été effectué avec succès. L’utilisation du sharding avec 32 groupes de validateurs aurait permis une parallélisation efficace et une mise à l’échelle du réseau.
Actuellement, la finalité des transactions revendiquée par l’équipe Radix est de 5 secondes depuis la mise à jour Olympia du 28 juillet 2021.
Flash Liquidity de Radix : unifier la liquidité fragmentée de la DeFi
Flash Liquidity sur Radix est une innovation majeure qui unifie la liquidité provenant de diverses blockchains et plateformes dans un cadre décentralisé.
Contrairement aux systèmes traditionnels de la finance décentralisée (DeFi), où les fournisseurs de liquidité doivent verrouiller leurs actifs, Flash Liquidity permet aux market makers d’apporter la liquidité uniquement lorsqu’une transaction est confirmée, rendant ainsi les échanges plus efficaces. Cela réduit les risques de perte et offre une expérience de trading plus fluide avec des spreads plus serrés et une slippage minimale pour un prix optimisé.
Pour les utilisateurs, cette technologie facilite l’accès à une large gamme d’actifs cryptographiques sans avoir à naviguer entre différentes plateformes ou gérer des portefeuilles multiples. De plus, Flash Liquidity permet aux développeurs de la DeFi d’intégrer facilement cette liquidité dans leurs applications, ouvrant ainsi de nouvelles opportunités pour construire des solutions financières innovantes sur Radix.
👉 Plus d’infos sur Flash Liquidity sur le blog de Radix
👉 Plus d’infos sur Anthic sur le blog de Radix
L’importance des Blueprints réutilisables au sein de Radix
Comme vu précédemment, les développeurs au sein de Radix se basent sur un grand nombre de “Blueprints”. Ces composants agissent comme des modèles réutilisables pour les applications DeFi, ce qui simplifie la création et la maintenance des projets.
Un Blueprint est essentiellement un plan ou un schéma pour un composant spécifique d’une application DeFi. Il contient tout le code nécessaire pour que ce composant fonctionne. Les développeurs peuvent ensuite utiliser ces Blueprints pour déployer rapidement des fonctionnalités standard sans devoir réécrire le code à partir de zéro.
D’autre part, les Blueprints favorisent ce qu’on appelle une “architecture modulaire”. Cela signifie que les développeurs peuvent assembler différents Blueprints pour construire des applications très complexes, d’où le terme “Lego-Bricks” employé par Radix.
Au final, en réutilisant des Blueprints, les développeurs économisent du temps et des ressources. De cette manière, ces derniers peuvent se concentrer sur l’ajout de nouvelles fonctionnalités et l’innovation, plutôt que de réinventer la roue.
Comment Radix récompense ses développeurs ?
Radix a conçu un mécanisme qui motive les développeurs à créer des applications de haute qualité grâce à un système de récompenses automatisé, appelé « auto-incitatif« .
Au cœur de cet écosystème se trouve le concept de “royalties« . Concrètement, les développeurs qui créent des composants ou des applications sur Radix peuvent définir des frais de royalties. Ces frais sont des petits pourcentages prélevés sur chaque transaction utilisant leur création. Ce modèle de revenu crée une sorte de flux financier direct entre l’utilisation d’une application et son créateur.
Naturellement, ce système encourage les développeurs à produire des travaux de haute qualité. Plus une application est utile et populaire, plus elle génère de transactions, et donc de revenus pour son créateur. Cela incite les développeurs à innover et à améliorer continuellement leurs produits pour attirer et retenir les utilisateurs.
Radix Wallet : le wallet natif du réseau Radix
Radix dispose également de son propre portefeuille numérique (wallet) natif. Ce dernier est conçu pour que les utilisateurs puissent visualiser, gérer et stocker en toute sécurité tous leurs actifs sur le réseau Radix.
Les utilisateurs peuvent ensuite utiliser ce portefeuille pour interagir avec l’ensemble des dApps déployées sur le réseau Radix.
D’un point de vue plus technique, Radix Wallet utilise de nombreux mécanismes avancés, comme les “Smart Accounts” et des identités “Personas”. Ces derniers éliminent les besoins de mots de passe et améliore la sécurité des connexions aux dApps.
Pour en apprendre davantage sur le portefeuille natif de Radix 👉 cliquez sur ce lien
Radix : un écosystème rempli de d’applications décentralisées (dApps)
L’écosystème Radix renferme d’ores et déjà plusieurs dizaines d’applications.
Voici quelques unes des plus utilisées :
- Ociswap : un exchange décentralisé (DEX) qui dispose de fonctionnalités avancées comme le yield farming.
- Backeum : une plateforme décentralisée sur Radix dédiée à la gestion et au stockage sécurisé de données, permettant leur partage et leur monétisation via des contrats intelligents.
- Gable : une plateforme DeFi qui gère les flashloans
- Delphibets : une plateforme de paris décentralisée permettant aux utilisateurs de parier sur divers événements grâce aux smart contracts
- Trove : une marketplace NFT.
Pour prendre connaissance de tous les projets de l’écosystème Radix 👉 cliquez sur ce lien
Radix roadmap : dernière ligne droite avant la version finale
La complétion du consensus Cerberus arrive par des étapes qui, chacune, rajoutent des fonctionnalités au consensus Cerberus.
En juillet 2023, Olympia a introduit sur Radix le moteur de smart contracts Radix Engine V2 et le langage de programmation Scrypto, permettant des contrats intelligents plus sécurisés et évolutifs.
La version Xi’an du réseau principal est la prochaine étape majeure de Radix. Xi’an apportera la version finale entièrement shardée du protocole de consensus Cerberus décrit dans le whitepaper Cerberus. Initialement prévue pour fin 2023, cette mise à jour a été reportée àla fin de l’année 2024.
Certaines des implémentations possibles de Xi’an sont actuellement en cours de test et démontrées sur le testnet Cassandra. Tous les tests peuvent être suivis sur le compte Twitch de Dan Hughes, fondateur de Radix.
Xi’an offrira à Radix une scalabilité infinie et une composabilité atomique illimitée. Deux caractéristiques que Radix revendique comme nécessaires pour que la DeFi s’adapte aux demandes futures de milliards de personnes.
$XRD : le jeton natif de l’écosystème Radix
$XRD est le jeton utilitaire du protocole Radix et joue donc un rôle très important dans son bon fonctionnement.
Voici ces principales fonctions :
- Payer les frais : le jeton XRD est dans un premier temps utilisé pour payer les frais de transaction au sein de réseau Radix. Il est également utilisé pour le déploiement de contrats intelligents (smarts contracts).
- Staking : les détenteurs de XRD peuvent mettre en jeu (staker) leurs jetons dans des pools de liquidité afin de participer au bon fonctionnement du réseau. En échange de leur contribution, ces derniers perçoivent des récompenses sous forme de rendements.
- Gouvernance : les stakers ont la possibilité de participer à la gouvernance (DAO) du réseau. Ils peuvent en effet voter sur différentes propositions concernant l’avenir du protocole.
Notez que le protocole dispose également d’un jeton “eXRD”, qui est une version “wrapped” du jeton XRD, à l’instar de wBTC et BTC. Concrètement, eXRD est spécialement conçu pour interagir avec les différentes dApps sur Ethereum.
Bien évidemment, les utilisateurs peuvent échanger leurs jetons XRD / eXRD dans un ratio 1:1 (1 XRD = 1 eXRD).
Tokenomics du jeton Radix (XRD)
Voici comment les jetons XRD sont distribués au sein du réseau Radix :
Suivre Radix
🌐 Site Web
