Le problème des transactions cryptographiques aujourd'hui

Web3 et DeFi aujourd'hui ne sont pas prêts pour les utilisateurs grand public ; c'est trop déroutant, risqué et coûteux pour quiconque n'est pas un chef de crypto dédié.

Il y a des choses évidentes qui doivent être corrigées, comme l'horrible expérience de développeur et l'exigence folle de gérer une longue phrase de départ pour sauvegarder un compte en toute sécurité. Mais il y a un autre énorme obstacle qui n'attire pas beaucoup l'attention : les transactions n'ont aucun sens et ne donnent pas aux utilisateurs et aux développeurs le contrôle dont ils ont besoin pour utiliser en toute confiance cette toute nouvelle technologie .

Le problème n'est pas seulement celui de l'interface utilisateur du portefeuille ; en fait, c'est surtout un problème avec l'architecture de la plate-forme L-1 elle-même. Les transactions d'aujourd'hui sont définies d'une manière qui est limitée par des hypothèses technologiques plutôt que définie par les besoins et les attentes des développeurs et des utilisateurs qui interagiront avec eux au quotidien. Aucun portefeuille ne peut contourner ces limitations.

C'est pourquoi Radix a dû redéfinir le concept de transactions à partir de zéro dans le cadre de son pile technologique complète .

Le résultat est l'un des avantages les plus puissants de Radix, résolvant une gamme surprenante de problèmes DeFi importants tels que l'expérience utilisateur de portefeuille non sécurisée, l'interopérabilité difficile des dApp, le trading en sandwich et l'impossibilité de déléguer le paiement des frais. Il permet également au portefeuille Radix de présenter des transactions aux utilisateurs comme celle-ci, en toute confiance :

Mais avant d'en venir à la solution de Radix, parlons des raisons pour lesquelles les transactions d'aujourd'hui ont tant besoin d'une refonte.

Qu'y a-t-il dans une transaction ?

Pour comprendre à quel point le problème des transactions est profond, nous devons parler de ce qu'est réellement une transaction blockchain .

Aujourd'hui, le contenu d'une transaction sur une blockchain de contrats intelligents dépend en grande partie de la technologie. Sur la plupart des réseaux de contrats intelligents, tout est un contrat intelligent - non seulement la logique dApp, mais la définition des actifs eux-mêmes . Dans les limites de ce modèle, il n'est pas surprenant qu'une transaction soit définie comme un appel à un contrat intelligent .

Cela signifie que sur ces réseaux, la partie principale d'une transaction est essentiellement un message envoyé à un seul contrat intelligent, contenant toutes les données nécessaires pour lui dire quoi faire.

Lorsque le contrat intelligent reçoit ce message, il peut apporter des modifications à ses propres données internes, et il peut appeler d'autres contrats intelligents dans les coulisses (comme les contrats intelligents à jeton ERC-20) qui à leur tour apportent des modifications à leurs données internes.

Tout ce qui se passe à la suite de cette transaction doit être lancé par ce message unique au contrat intelligent.

Un peu plus est nécessaire avant que la transaction puisse être soumise au réseau. L'appel de contrat intelligent est signé par la clé privée d'un seul compte en tant qu '«appelant», et cet appelant indique au réseau combien il est prêt à dépenser sur ce compte pour les frais de réseau (ou «gaz»).

De manière générale, c'est tout ce que contient la transaction : un message vers un contrat intelligent, une signature du portefeuille de l'utilisateur et une spécification des frais de réseau à payer .

Donc quel est le problème?

Cette façon de définir une « transaction » fonctionne, techniquement parlant, mais elle laisse beaucoup à désirer car elle ne décrit pas les choses comme le ferait l'utilisateur qui la signe. En tant qu'utilisateur, j'essaie peut-être d'effectuer une transaction qui échange des jetons via un DEX, ou achète un NFT, ou contracte un prêt - mais ce que je signe est toujours un seul message à une boîte noire de contrat intelligent que je l'espoir fera ce que j'attends.

Cette conception de transaction « message vers une boîte noire » crée de sérieuses lacunes que nous pouvons souvent tenir pour acquises dans la cryptographie aujourd'hui :

• Les utilisateurs de portefeuille (et le logiciel de portefeuille) ne peuvent pas connaître les résultats réels de la transaction . Le portefeuille sait seulement qu'un certain contrat intelligent est appelé. Tous les résultats de transaction sont des changements internes engagés par une logique de contrat intelligent interne qui est pratiquement inconnaissable à l'avance. En fait, sur de nombreuses chaînes, l'utilisateur signe un hachage de l'appel de contrat intelligent, ce qui le rend encore plus obscur.

  
  

• Les utilisateurs ne peuvent pas se protéger du "sandwich trading" ou du slippage . En prenant l'exemple d'un DEX, la seule façon d'offrir à l'utilisateur une protection contre le dérapage est que le contrat intelligent DEX l'offre dans le cadre de sa logique interne (et que l'utilisateur fasse confiance à cette implémentation).

  
  

• Les modèles d'autorisation sont très simplistes . La seule façon pour un utilisateur de s'autoriser à conclure des contrats intelligents est via sa signature de clé de compte unique. Tout ce qui est plus compliqué signifie (vous l'avez deviné) déployer un autre contrat intelligent.

  
  

• Composer ensemble plusieurs contrats intelligents signifie déployer un autre contrat intelligent . La transaction a besoin de son point d'entrée unique, qui peut ensuite passer plusieurs appels vers d'autres contrats intelligents. Cela signifie que la composabilité nécessite une planification à l'avance, et est laborieuse et rigide.

  
  

• Les dApps ne peuvent pas payer les frais de réseau au nom de leurs utilisateurs . Le modèle d'appelant à signature unique signifie que seul ce compte d'utilisateur peut payer les frais.

  
  

Il existe diverses propositions qui cherchent à réduire la gravité de ces lacunes du modèle transactionnel fondamental en les contournant. Par exemple, l'"abstraction de compte" de l'ERC-4337 permet (entre autres) la possibilité d'une forme de paiement délégué des frais, mais au prix d'une complexité et d'un risque importants du système .

Quelles que soient les solutions de contournement ajoutées, le problème demeure que les transactions ne fonctionnent pas comme le voudraient les utilisateurs ou les développeurs - si la technologie de la plate-forme n'était pas la limitation .

Pour résoudre les problèmes ci-dessus, nous devons redéfinir le concept de transactions afin qu'elles soient beaucoup plus puissantes et flexibles. Ils devraient donner aux développeurs plus de pouvoir pour définir directement des interactions plus complexes, et devraient permettre à l'utilisateur de contrôler ce qui compte pour lui lorsqu'il signe, plutôt que d'avoir à faire confiance à la logique de contrat intelligent de la boîte noire.

Dans le prochain blog, nous parlerons de la façon dont Radix fait exactement cela avec un nouveau type de conception de transaction, activé par la plate-forme complète unique de Radix.