Transactions axées sur les actifs de Radix : donner du sens aux transactions

Dans l' article précédent , nous avons expliqué comment le concept des transactions blockchain d'aujourd'hui rend impossible la résolution de plusieurs problèmes graves rencontrés par les utilisateurs et les développeurs DeFi - des problèmes qui bloquent le potentiel grand public de DeFi et Web3.

La conception de la plupart des plates-formes L-1 de contrats intelligents limite les transactions à un simple message envoyé à un contrat intelligent de type boîte noire, et cette limitation signifie que les transactions ne peuvent tout simplement pas être suffisamment flexibles, puissantes ou transparentes .

La seule façon de vraiment résoudre le problème est de redéfinir ce que signifie une transaction sur une blockchain, et c'est exactement ce que Radix a fait. Transactions Radix (sur le réseau Babylon qui inclut Capacité de contrat intelligent unique de Radix ) contiennent un « manifeste » d'instructions axées sur les actifs qui rendent les transactions compréhensibles, composables et incroyablement puissantes.

Parlons de ce qu'est une transaction Radix et de certaines des choses incroyables qu'elles rendent possibles pour les utilisateurs et les développeurs.

Redéfinir une « transaction »

Oubliant un instant la technologie, que devrait idéalement être une transaction ?

Que devrait -il contenir pour qu'il soit suffisamment flexible pour faire tout ce qui rend Web3 et DeFi passionnants et également compréhensibles et sûrs pour les utilisateurs ?

Comme point de départ, examinons une transaction du monde réel qui fait quelque chose d'utile et qui est déjà très compréhensible pour tout le monde. Prenons l'exemple de l'utilisation de la version réelle d'un DEX : un kiosque de change.

Imaginez que je suis le client, marchant jusqu'à un comptoir de change à l'aéroport pour échanger des devises. Je pourrais décrire la transaction de cette façon :

• Je prends 20 USD de mon portefeuille et le pose sur le comptoir.

• J'informe le caissier d'échange que j'aimerais échanger ces 20 USD contre des GBP .

• Le caissier prend mon USD , tape sur son ordinateur pendant un moment et met 16,08 GBP sur le comptoir.

• Je suis satisfait du taux de change que j'ai obtenu, prends le GBP et mets-le dans mon portefeuille.

  
  

Dans ce scénario typique du monde réel, bien que je ne contrôle pas la façon dont la bourse fonctionne en interne, je contrôle pleinement ce qui compte pour moi : retirer des actifs de mon portefeuille, donner des actifs à la bourse avec des instructions pour ce que je veux, accepter (ou rejeter) ce qu'ils me rendent et remettre des actifs dans mon portefeuille.

Cette connaissance et ce contrôle de ce qui compte pour moi sont une attente naturelle et évidente chaque fois que j'interagis avec quelqu'un et que mes actifs sont impliqués. Je contrôle quels actifs sortent de mon portefeuille, je précise à qui je les donne et ce que je veux, et je peux voir ce qui me revient et approuver. C'est fondamentalement ce que le mot « transaction » signifie pour moi dans le monde réel. Ne serait-ce pas bien si les transactions blockchain fonctionnaient comme ça ?

Sur Radix, ils le font. La conception des transactions de Radix a commencé à partir de ces premiers principes d'attente et de contrôle intuitifs de l'utilisateur et a modélisé les transactions sur le réseau Radix de la même manière.

Rendre les transactions significatives

La chose la plus importante pour moi à propos de la transaction réelle ci-dessus est qu'il s'agit d'une description directe des mouvements d'actifs entre mon portefeuille et la bourse. Pour que les transactions Radix fonctionnent ainsi, la conception de la plate-forme doit commencer par les actifs. Et heureusement, l'une des caractéristiques déterminantes de la conception de la plate-forme Radix (du Machine virtuelle Radix Engine au Langage de contrat intelligent Scrypto ) est que le réseau a une compréhension native des actifs et du comportement des actifs .

Cette architecture "axée sur les actifs" donne à tout sur la plate-forme un comportement intuitif en matière de propriété numérique. Les jetons et les NFT ne sont pas des soldes dans les contrats intelligents ; ils agissent comme des objets physiques qui se déplacent d'un endroit à l'autre. Les comptes d'utilisateurs ne sont pas que des paires de clés ; ce sont des conteneurs d'actifs où l'utilisateur a le pouvoir de retirer ou de gérer les règles sur les types de dépôts qu'il acceptera. Les contrats intelligents ne se limitent pas à accepter des messages ; ils peuvent accepter des «seaux» d'actifs comme intrants - comme pousser de l'argent à travers le comptoir de change.

Ces fonctionnalités de la plate-forme fournissent les outils nécessaires pour reformuler la définition des transactions sur Radix afin qu'elles fonctionnent de manière intuitive et prévisible, de la même manière que les transactions du monde réel.

Les transactions Radix sont un « manifeste » d'instructions qui décrivent directement les mouvements d'actifs entre les comptes et les composants (la forme de contrat intelligent de Radix).

Voici un véritable manifeste de transaction (sans adresses, pour plus de clarté) décrivant une transaction comme notre exemple d'échange réel :

Notez que vous ne regardez pas un résumé - c'est en fait à quoi ressemble le contenu d'une vraie transaction Radix ! Semblable à la façon dont un utilisateur décrirait une transaction dans le monde réel, le manifeste décrit la transaction en termes de mouvements d'actifs importants pour l'utilisateur.

Voici ce qui se passe dans les 4 instructions de ce manifeste :

1. Je dis à l'un de mes comptes de retirer 20 jetons USD. (Je m'attends à ce que les jetons de 20 USD soient retournés à quelque chose appelé le "plan de travail des transactions", que vous pouvez considérer comme le comptoir d'échange. C'est juste un endroit temporaire où les actifs peuvent s'asseoir lorsqu'ils sont déplacés pendant une transaction.)
2. Je balaie ces 20 USD du plan de travail et les mets dans un "seau". (Les compartiments ne sont que des conteneurs d'actifs que je peux transmettre à d'autres choses.)
3. Je passe directement le seau d'USD à la méthode "trade" du composant d'échange. (Je m'attends à ce que l'échange détermine le taux de change et renvoie des jetons GBP sur le plan de travail.)
4. Je ramène le contenu du plan de travail dans mon portefeuille.

Je signe cette transaction – c'est ainsi que mon compte sait que je suis autorisé à retirer les jetons de 20 USD – et je la soumets au réseau.

Comme dans le scénario du monde réel, même si je n'ai peut-être pas le contrôle du fonctionnement interne de l'échange, j'ai un contrôle direct sur ce qui compte pour moi : les jetons entrant et sortant de mes comptes et ce avec quoi je veux interagir.

C'est déjà une énorme amélioration par rapport à une transaction qui envoie simplement un message à un contrat intelligent. Mais il manque quelque chose…

Donner le contrôle à l'utilisateur

Dans l'exemple du monde réel, je me suis assuré que j'obtenais 16,08 GBP (peut-être en fonction du taux de change actuel et des frais prévus) pour mes 20 USD avant d'accepter la transaction. Ne devrais-je pas m'attendre à pouvoir faire le même genre de chose avec une transaction Radix avant de la signer et de la soumettre ?

En fait, je peux (avec l'aide de mon logiciel de portefeuille) faire la même chose en ajoutant une instruction au manifeste de transaction. C'est l'avant-dernière instruction "ASSERT_WORKTOP_CONTAINS_BY_AMOUNT" ici :

L'instruction dans le manifeste "affirme" que le plan de travail contient au moins 16,08 jetons GBP avant que je fasse le dépôt sur mon compte. Cela signifie que lorsque cette transaction est traitée par le réseau, si cette affirmation n'est pas vraie (par exemple, si l'échange n'a renvoyé que 15 GBP ou s'il a entièrement renvoyé le mauvais type de jeton), la transaction sera rejetée par le réseau . Tout cela n'arrivera pas parce que je n'ai pas obtenu ce que j'attendais.

Cela fonctionne car les manifestes de transaction sont atomiques . C'est juste une façon élégante de dire que tout dans le manifeste de transaction doit fonctionner avec succès sans problème, sinon rien de tout cela ne se produit.

C'est incroyablement puissant. Comme pour l'échange dans le monde réel, je n'ai pas du tout à me soucier de la logique d'échange interne. J'obtiens une protection contre des choses comme le glissement ou le fait d'être confronté à un résultat que je ne voulais pas d'une manière qui est entièrement sous mon contrôle sans compter sur la logique du contrat intelligent.

Le portefeuille Radix peut ajouter directement mes attentes en tant qu'utilisateur au manifeste de transaction pour moi, et le réseau garantira que toutes ces attentes sont respectées - sinon mes fonds ne quittent jamais ma poche.

Correction de l'expérience utilisateur des transactions

Avoir des transactions structurées de cette manière est également exactement ce qui est nécessaire pour permettre au portefeuille Radix de donner aux utilisateurs le type d'UX dont les transactions d'actifs Web3 ont besoin pour être prêtes pour le grand public.

Pour voir ce que cela signifie, voici comment notre transaction d'échange serait présentée à l'utilisateur dans le portefeuille Radix :

Cette vue n'a pas été créée par la dApp d'échange. C'est le portefeuille Radix lui-même qui résume en toute sécurité ce qui compte pour moi en lisant directement le contenu de la transaction elle-même . Et si vous regardez à nouveau le manifeste de transaction ci-dessus, vous pouvez probablement voir comment le portefeuille Radix est capable de le traduire automatiquement dans l'interface utilisateur récapitulative pour l'utilisateur :

• RETRAIT : les retraits des comptes sont affichés directement et le portefeuille peut voir quels comptes appartiennent à l'utilisateur du portefeuille.
• Utilisation de dApps : les autres composants impliqués dans la transaction sont répertoriés en tant que dApps compréhensibles par l'utilisateur. (Pour savoir comment le portefeuille Radix fait cela, jetez un œil à Radix's Système de définition dApp qui permet à un développeur d'associer des composants à une description claire dans le registre de leur dApp.)
• DÉPÔT : les dépôts sur les comptes de l'utilisateur sont également affichés directement. Tout dépôt qui n'a pas de quantité spécifiée dans le manifeste de transaction est "estimé" via un aperçu de la transaction, et une "garantie" (l'instruction "affirmer" que nous avons décrite précédemment) est automatiquement ajoutée en fonction des préférences de l'utilisateur.
• FRAIS DE TRANSACTION : Et bien sûr, le portefeuille indique les frais de transaction requis (plus d'informations ci-dessous).

Le résultat est un résumé de transaction qui est significatif et pertinent pour l'utilisateur, dont l'exactitude est garantie et qui est entièrement fiable . L'utilisateur sait exactement ce qu'il adviendra de ses comptes et de ses actifs s'il signe - comme il s'y attendrait. Lorsque chaque partie de la pile est conçue pour fonctionner ensemble pour permettre un produit compatible avec le grand public, vous n'avez pas à renoncer à une bonne UX pour devenir décentralisée.

Authentification claire et flexible

Parlons d'un autre outil de la boîte à outils de transaction Radix.

La machine virtuelle Radix Engine comprend un puissant système d'authentification intégré pour les composants utilisant des "badges". Tout comme une carte de membre dans votre portefeuille, les badges sont des actifs que vous possédez et dont vous pouvez «présenter» une preuve lors d'une transaction. Les composants peuvent vérifier que vous avez présenté une preuve donnée comme prérequis pour faire quelque chose.

La présentation d'une preuve d'un badge n'est qu'une autre instruction dans le manifeste de transaction qui demande cette preuve au compte détenant le badge. C'est comme sortir une carte de membre de mon vrai portefeuille pour la montrer à quelqu'un.

Cela signifie qu'une fois de plus, le portefeuille Radix peut montrer à l'utilisateur exactement ce qui se passe. Imaginez que notre dApp d'échange ait besoin de voir la preuve que je détiens un badge indiquant que j'ai effectué certaines vérifications KYC d'un tiers. Le résultat est une transaction qui se présente comme ceci :

Encore une fois, je reçois une présentation claire qu'un badge donné est présenté et je peux décider si je suis à l'aise avec celui-ci avant de signer.

Composabilité atomique sans code et à la demande

Parlons maintenant de la flexibilité et de la puissance des transactions Radix. L'une des superpuissances du manifeste de transaction est la capacité de "composer" ensemble plusieurs dApps dans une seule transaction atomique - sans code de contrat intelligent.

Imaginez que je veuille contracter un prêt auprès d'un contrat intelligent dApp de prêt, puis utiliser ce prêt pour effectuer une certaine transaction à partir d'un contrat intelligent DEX. Je voudrais peut-être m'assurer de ne contracter le prêt que si je suis effectivement en mesure de faire cette transaction.

Sur d'autres réseaux, vous n'avez qu'une seule option : écrire et déployer un contrat intelligent spécial que vous pouvez appeler et qui cuit dans cette logique. Une fois déployé, ce contrat intelligent recevra votre demande dans une transaction, appellera le contrat intelligent de prêt, tentera d'appeler le DEX (en supposant que j'ai reçu les fonds du prêt) et s'assurera de vérifier que l'échange DEX a réussi. Il s'agit d'un processus en plusieurs étapes qui nécessite une expertise en matière de contrats intelligents, prend du temps, est à but unique et coûte souvent très cher en frais de réseau.

Sur Radix, c'est juste un manifeste de transaction de quelques instructions :

• Appelez le volet prêt pour contracter le prêt
• Mettez les jetons prêtés dans un seau et passez-les au DEX
• Affirmer que le DEX a renvoyé ce que vous attendiez (la transaction échoue si ce n'est pas vrai)
• Déposez les résultats sur votre compte

Vous pouvez créer ce manifeste de transaction simple, à la demande, dans une simple interface Web. Pas de code de contrat intelligent ou de déploiement à l'avance, pas de contrôles élaborés sur les résultats des contrats intelligents ; vous décrivez simplement comment vous souhaitez que les actifs se déplacent entre votre compte et les composants dApp et les soumettez.

Cela ouvre une foule de nouvelles possibilités. Des segments entiers de DeFi dApps qui aident les utilisateurs à trouver les meilleurs itinéraires pour les échanges peuvent être construits uniquement comme des interfaces de site Web, par des développeurs qui ne touchent jamais au code de contrat intelligent. Des combinaisons très complexes de protocoles financiers peuvent être assemblées en temps réel pour tirer parti d'opportunités éphémères. Et en utilisant des barrières de sécurité « d'affirmation » dans les transactions, des limites claires et directes peuvent être placées sur le résultat final souhaité sans se soucier du fonctionnement interne des composants appelés.

Frais de réseau payés par dApp

Voici une autre caractéristique importante des transactions Radix pour les développeurs. De nombreux développeurs dApp aimeraient considérer les frais de réseau comme un coût d'infrastructure qu'ils supportent pour leurs utilisateurs, afin que les utilisateurs n'aient jamais à y penser. Par exemple : peut-être que leurs utilisateurs veulent uniquement effectuer des transactions en USDC et ne jamais toucher à l'ETH, ou peut-être veulent-ils simplement offrir cela comme un avantage invisible aux utilisateurs, comme un commerçant payant les frais de transaction Visa lors de l'exécution de la carte de débit d'un client.

Les transactions courantes rendent cela impossible – le signataire doit être le payeur. Sur Radix, le paiement des frais est beaucoup plus flexible ; n'importe quoi peut le payer au cours de la transaction.

En fait, je trichais un peu quand je vous ai montré les manifestes de transaction plus tôt. Dans le cas typique où l'utilisateur paie les frais de transaction, il existe une instruction manifeste supplémentaire sur l'un des comptes de l'utilisateur pour « verrouiller » les frais de réseau pour la transaction. Mais l'utilisateur ne verrouille pas ces frais si quelque chose d'autre est prêt à verrouiller ces frais au cours de la transaction.

Par exemple : imaginez que je suis un utilisateur enregistré et connu d'une application d'échange et qu'il souhaite payer les frais de réseau pour moi lorsque j'utilise son système. Ils me délivrent un badge utilisateur que je détiens dans l'un de mes comptes et qui représente mon inscription. Maintenant, dans les transactions, je peux présenter ce badge au composant d'échange (tout comme nous l'avons vu plus tôt avec le badge KYC), et l'échange peut vérifier cette preuve, puis verrouiller les frais de la transaction. Si c'est le cas, mon portefeuille Radix voit qu'aucun verrouillage de frais supplémentaires n'est requis, et c'est comme si les frais de réseau étaient magiquement nuls.

Une note finale sur le partage

Pour ceux qui aiment creuser dans la technologie, il y a un autre avantage merveilleux du modèle de transaction de Radix : il se fragmente bien.

Dans l'attente de la mise à niveau du réseau Xi'an lorsque le protocole de consensus Cerberus massivement parallélisé de Radix ( récemment évalué par des pairs ) se déploiera pour offrir une évolutivité illimitée, il est crucial que le modèle de transaction soit adapté.

Pour permettre un parallélisme massif, Cerberus s'appuie sur la capacité de séparer l'état des comptes et des composants sur un nombre pratiquement illimité de fragments (ou "threads" pourrait être un terme plus descriptif), tout en étant capable de savoir précisément lesquels de ces fragments doivent être réunis pour un consensus pour chaque transaction .

Cela peut sembler à première vue un peu comme Cardano, qui fragmente son état en bits d'état appelés «eUTXO». Les transactions Cardano (similaire à Bitcoin) incluent alors une spécification directe des eUTXO à utiliser pour créer le résultat d'une transaction donnée. Le problème, c'est que cela crée des conflits . Un contrat intelligent donné (comme, par exemple, un DEX) peut avoir un pool de jetons avec lesquels de nombreuses personnes essaient d'interagir en même temps. Si les transactions sélectionnent des jetons eUTXO individuels à utiliser dans ce pool, il est presque garanti que les clients choisiront souvent les mêmes eUTXO et entraîneront ainsi l'échec de nombreuses transactions, même s'il y avait beaucoup de jetons dans le pool pour répondre aux désirs de chacun.

Au lieu de cela, sur Radix, la liste des instructions dans un manifeste de transaction est une expression d' intention . Je n'ai pas besoin de spécifier les éléments d'état individuels à utiliser ; Je n'ai qu'à spécifier avec quels comptes et composants je veux interagir - comme je veux naturellement le faire de toute façon.

Ensuite, lorsque la transaction est réellement traitée par le réseau Radix, cette intention peut être traduite de manière déterministe en une définition de l'état qui doit être mis à jour - et en retour, quels fragments doivent être impliqués dans le consensus. Cela signifie que deux transactions interagissant avec le même contrat intelligent ne créeront pas automatiquement une course où une seule peut réussir. 10 personnes peuvent soumettre une transaction de manière fiable pour retirer 5 jetons d'un pool de 50 en même temps, et ils passeront tous l'un après l'autre sans problème.

L'essentiel

En redéfinissant le fonctionnement de toutes les transactions sur Radix, en utilisant les capacités nativement orientées actifs de Radix, les multiples problèmes des développeurs et des utilisateurs disparaissent. Ce type de solution ne peut pas être patché sur un réseau existant - toutes les hypothèses sur le fonctionnement des contrats intelligents, des actifs et des transactions sont déjà intégrées dans leur protocole et la conception de la machine virtuelle.

La nouvelle forme de transactions de Radix est introduite parallèlement à la capacité de contrat intelligent Scrypto et au tout nouveau portefeuille Radix sur le réseau principal Radix lors de sa version "Babylon".