Raiden, une réponse à la confidentialité des échanges sur Ethereum ?

Le monde de la finance s’intéresse de près à la blockchain, qui pourrait les aider à réduire certains coûts et à se passer d’intermédiaires. Néanmoins une blockchain destinée à un milieu financier doit se démarquer d’une blockchain publique sur certains points, car les objectifs ne sont pas les mêmes.

Les architectures des blockchains publiques comme Bitcoin et Ethereum impliquent en effet la traçabilité des transactions et la transparence des valeurs échangées. Ces blockchains souhaitent assurer un système résistant à la censure en n’ayant aucune entité centrale, en garantissant la transparence des échanges et un pseudo-anonymat (un compte peut être créé sur n’importe quelle machine mais peut être tracé). Implémenter la confidentialité dans une blockchain de type Bitcoin ou Ethereum est donc un défi.

Les canaux d’états pourraient être la solution et auraient également d’autres atouts qui seraient applicables à une blockchain publique ou privée (dans cette dernière les acteurs se connaissent et définissent une gouvernance au préalable : qui a le droit de valider des blocs, de les soumettres et même de les lire ?).

Nous allons nous intéresser à Raiden Network, un canal de transaction off-chain pour Ethereum qui pourrait résoudre ces problèmes de confidentialité et permettre d’augmenter le débit de transactions.

Voici certains points qui sont mis en avant sur leur site internet :

• Offrir une confidentialité : les transactions ne sont pas inscrites unitairement dans la blockchain.
• Exécuter de nombreuses transactions par seconde : le temps d’attente de validation d’une transaction et la scalabilité des blockchains publiques font partie des limites actuelles.
• Réduire les frais associés à l’envoi d’une transaction.
• Envoyer des petites transactions grâce à la baisse des frais.

Notre intérêt porte sur lui car nous nous intéressons particulièrement à Ethereum, même si le Lightning Network de Bitcoin semble être à un stade développement également avancé. Raiden a accompli son premier Proof of Concept le 5 août 2016, qui consistait en l’envoi d’une transaction transitant par 2 canaux qui était par la suite inscrite dans la blockchain du réseau de test d’Ethereum.

Principe

En une phrase, Raiden permettrait de condenser des centaines voire des milliers de transactions en une unique transaction.

Le principe est de créer un canal de paiement en dehors de la blockchain qui va contenir plusieurs transactions entre les deux comptes de ce canal.

La gestion de l’état du canal est écrite dans un smart-contract.

Un dépôt initial est soumis au smart-contract du canal de paiement par chacune des deux parties de façon à prouver qu’elles possèdent bien la somme qu’elles souhaitent dépenser par le biais de ce canal.

Toutes les transactions que nous échangeons sont off-chain, ce ne sont pas des transactions au sens Ethereum. Chaque transaction off-chain contient une mise à jour de la valeur des échanges précédents et chacune des deux parties peut retirer à tout moment son dû.

Elles peuvent maintenant s’envoyer des transactions signées dans le réseau Raiden avec le smart-contract qui sert de tiers de confiance : si une transaction est supérieure au dépôt initial, c’est la dernière transaction valide qui est prise en compte.

Combinaison des canaux

Si on reste sur l’aspect transactionnel, les canaux de paiements peuvent donc être très intéressants pour les couples de comptes ayant beaucoup de transactions, mais en réalité on effectue généralement des transactions avec plusieurs destinataires différents et avoir un canal pour chaque destinataire est fastidieux à mettre en place, donc où est l’avantage ?

C’est en créant des graphes de ces canaux que cela devient performant.

Imaginons que A souhaite envoyer une transaction à C. Il ne dispose pas d’un canal existant vers C mais il se trouve qu’il en a un avec B, et B a lui aussi un canal avec C.

Ces deux canaux vont donc constituer une “route de paiements” qui fait partie du réseau des canaux existants et B recevra une petite somme comme motivation à transmettre la transaction de A.

Pour empêcher B de garder l’argent que je souhaite envoyer à C, on peut utiliser une technique spécifiée dans le Lightning Network :

• C génère un nombre aléatoire, qui est secret. Elle envoie à A une empreinte (hash) de ce nombre.
• A envoie une transaction off-chain à B avec l’empreinte. (Pour que B demande son argent, il doit envoyer le secret de C au smart-contract)
• B envoie une transaction off-chain à C qui contient également l’empreinte. Elle a la même valeur que celle qu'A lui a envoyé moins les frais de commission qu’il prélève.
• C envoie le secret au smart-contract et récupère la somme envoyée par B.
• B peut donc demander son argent à A, car le secret est maintenant visible dans la blockchain.

A va donc effectuer une série d’échange avec C et la blockchain recevra l’actualisation de la valeur des deux comptes A et C que lorsqu’ils le souhaitent : ils sont d’accord sur l’état des  comptes à des intervalles plus grandes.

D’un côté on paye moins souvent les frais pour envoyer des  transactions in-chain et de l’autre on inclut des frais pour chaque relayeur de la transaction off-chain dans le canal, ce qui constitue la motivation pour ces derniers à faire suivre celle-ci.

Il est estimé que ces nouveaux frais annexes seront beaucoup moins élevés que ceux des transactions internes d’Ethereum et permettraient d’effectuer des micro-paiements.

Canaux à états

Le schéma suivant provient du papier de Vitalik Buterin pour le consortium R3 : Opportunities and Challenges for Private and Consortium Blockchains (p. 30). Ce papier est un document de 40 pages qui donne un aperçu de l'architecture d’Ethereum et de ses applications dans la finance.

Il présente dans ce schéma l’utilisation des canaux de paiements via un smart-contract ainsi que la marche à suivre si les deux parties ne sont pas d’accord sur la valeur off-chain qu’elles ont chacune trouvée.

Cet exemple étend l’utilisation des canaux à des états (states channels) et non plus seulement à des paiements. Dans Ethereum, une transaction peut non-seulement envoyer de la valeur, mais peut aussi modifier l’état d’un contrat.

Les deux parties utilisent ici un oracle, un programme qui récupère des données externe à la blockchain.

1. Ils se mettent d’accord sur le code qui sera exécuté et envoient les fonds nécessaires au smart-contract qui contient le hash de ce code (qui sert à le certifier dans le cas d’un conflit).
2. L’oracle va renseigner les valeurs à chacune des deux parties.
3. Une des deux partie va demander au smart-contract d’envoyer les fonds en se basant sur les données qu’elle a reçue de son oracle. Ceux-ci sont normalement calculés depuis le code qu’ils ont en commun, ils sont donc censés avoir les mêmes résultats.
4. Il y a ensuite deux possibilités :
   • L’autre partie accepte les valeurs, ils sont d’accords. Le smart-contract envoie donc les fonds aux deux parties.
   • L’autre partie n’accepte pas les valeurs, ils ne sont pas d’accords. Ils envoient donc le code (qui doit correspondre au hash envoyé précédemment) au smart-contract qui s’occupera de l'exécuter puis d’envoyer les fonds aux deux parties. Il fait office d’arbitre.

Conclusion

On a donc un compromis entre la confidentialité des transactions et l’apport de performance que cela apporte :

• Si on privilégie la confidentialité, les transactions doivent passer seulement par 1 canal entre deux acteurs, dans ce cas il n’y pas beaucoup de gain de performances.
• Si on privilégie la performance, on met à bout de nombreux canaux, ce qui offre un gain de performance non-négligeable mais révèle les transactions à tous les noeuds intermédiaires.

Toutes les transactions ne sont donc pas visibles sur la blockchain, mais seulement une partie. Même si cela brouille les pistes, il est possible d’estimer chacune des transactions si on les analyses sur le long terme, surtout si leur soumissions dans le blockchain est récurrente.

Les canaux de paiements offrent donc une confidentialité relative, qui pourra convenir à certains cas d’usages mais certainement pas à tous. Ils offrent en tout cas des promesses qui pourraient grandement améliorer l’expérience utilisateurs des dApp (Decentralized Applications).

Seront-ils les lanceurs de l’IoT et des micropaiements dans Ethereum grâce à leurs très bonnes performances et leurs coûts réduits ? Nous en saurons plus le 19 septembre, lors de la Devcon 2 qui se tiendra à Shanghai.