Les transactions

Protocols Ğ1v2 protocol
1

Actuellement Duniter fonctionne sur un mode UTXO, avec un système d’unités qui permet l’élagage des anciennes unités à mesure qu’elles deviennent trop petites du fait de l’augmentation du DU.

Substrate permet tout à fait de rester sur ce mode, même si par défaut c’est plutôt un fonctionnement sur le mode Compte qui est mis en avant (X possède 100 Ğ1, Y possède 50 Ğ1, etc.).

Le soucis c’est que les UTXO de Duniter v1 sont un peu bancales, avec le système de conditions multiples qui est un peu le scripting du pauvre. Les traduire en Substrate risque d’être acrobatique, alors qu’il existe certainement des pallets qui permettent de faire la même chose mais en plus propre.

2 Likes
2

Bon je confirme, Substrate est très orienté Comptes car développé pour Polkadot par Gavin Wood, ex-cofondateur et CTO d’Ethereum.

Quelques avantage et inconvénients du mode Comptes

Simplifier la gestion côté client et côté Duniter

Migrer Duniter vers un mode Comptes est assez simple dans la mesure où 100% des échanges se font déjà dans ce mode. De plus les clients n’auraient plus à gérer d’UTXO ni à réaliser des transactions de change intermédiaires (gain de temps à l’exécution d’une TX, plus simple à coder pour un client).

Pour les 0% restants, j’avais implémenté les fonctions CSV et CLTV dans Duniter v1 afin de pouvoir faire de l’Atomic Swap (échanges interblockchains sans tiers), mais Substrate peut aussi le faire en mode Comptes et dispose déjà d’une pallet toute faite.

Problème de la double-dépense

Les comptes ont toutefois ce problème de devoir gérer la double dépense, car concrètement en mode compte on signe des chèques : si le chèque est dupliqué par un attaquant, il peut « vider » le compte de l’émetteur. Ce n’est pas le cas en UTXO où chaque source de monnaie est bien identifiée et consommée à chaque transction.

Ce point est contré par l’ajout d’un Nonce (compteur) associé au compte, et chaque chèque numérique doit comporter ce n° afin que la blockchain puisse l’identifier et refuser un duplicata. Cela implique que, en émettant trois chèques numérotés 4, 5 et 6, tant que le n° 4 n’est pas passé, les n°5 et n°6 restent bloqués.

Moins rapide que les UTXO

Implication du point précédent, là où les UTXO permettent d’exécuteur plusieurs transactions en parallèle, les Comptes ne le permettent pas. Les dépenses sont séquentielles.

Pas de transactions lightning

Il faut développer une pallet permettant de créer un compte de type lightning, ou bien permettant aussi le transfert de monnaie en UTXO. Ce serait du travail supplémentaire.

Rester en UTXO pour Duniter ?

Je continue de me poser la question à ce stade, car pour les clients :

  • Cesium est déjà compatible, pas de surcoût ;
  • Tikka reprendrait le code de Sakia je suppose @vit ?
  • Ğecko, je ne sais pas : les transferts de monnaie sont-il déjà gérés en UTXO, @poka ?

Mais bon, à part cette compatibilité existante, je n’ai pas trop d’arguments en faveur d’une conservation des UTXO à ce jour.

3 Likes
3

Non Tikka ne reprend pas le code de Sakia, mais si je dois faire quelque chose que Sakia fait déjà très bien je reprendrai le code bien évidemment. Mais Tikka est réécrit de zéro. On fait ce qu’on veut.

4

Oui Ğecko utilise les UTXO via GVA.
Mais grâce aux paiements simplifiés qu’offre GVA, je n’ai même pas besoin de gérer les transactions de changes, celles-ci se font côté Duniter, avec aller-retour de documents signés jusqu’à obtention du document final. Ça fonctionne bien.

De toute façon je me suis fait une raison, la migration sur Substrate va me faire changer tout un tas de chose dans Ğecko.
En utilisant les libs fournis par Substrate, je ne pense pas que ça change grand chose côté client, UTXO ou Comptes (à voir si les libs permettent une gestion des transactions de change simplifié).

Personnellement je pense que si la méthode Comptes a fait ses preuves (et c’est le cas au vue du succès de Polkadot), et que celà simplifie plusieurs couches (l’ajout du nonce pour éviter la double dépense ne me paraît pas d’une complexité particulière), autant partir là dessus.
J’ai tendance à me dire, restons collé un max sur ce que Substrate met en avant, par soucis de simplification, documentation, support et maintenance pour l’avenir.

C’est le point le plus embêtant mais bon, ce genre de transaction est assez rare (je pense notamment à remuniter), et dans les faits ça ne fera que exécuter un groupe de transactions les une après les autres.

Je suppose que cela n’impacte pas la génération des DU quotidiens ?

1 Like
5

À chaque DU on augmente chaque compte cocréateur de la valeur du DU, tout simplement.

1 Like
6

OK, est-ce que Ğecko vérifie les documents renvoyés par Duniter quand même ?

1 Like
7

Oui bien sûr il est obligé, de toute manière pour détecter si il s’agit d’un document de change ou bien le document final.

Chaque champs est vérifié. Pour le moment c’est fait directement par le binding rust que elois m’expose, mais je suis en train de préparer une lib dart pour la crypto duniter pour me débarrasser de ce binding, je referais alors la méthode de paiement, comme fait dans jaklis.

2 Likes
8

En recherchant des infos sur les systèmes de blacklistage intégrés à Substrate, je suis tombé sur cet article intéressant qui explique très concrètement, code à l’appuie, comment garder des transactions sans fees tout en se protégeant des attaques DDoS:

Je me souviens que Elois me parlais de système de caution déjà, mais dans le cas du stockage libre qu’il voulais implémenter, pas pour les transactions.

Elois voulait implémenter des fees qui auraient étés directement distribués à une caisse commune géré démocratiquement.
J’avoue que si on peut se passer de fees dans un premier temps, je suis pour, on a le temps de voir arriver les vraies DDoS ennuyeux je pense.

2 Likes
9

Je suis également de cet avis.

Pour les comptes membres c’est assez simple car leur création est déjà contrainte par les règles de WoT. Il suffit de limiter à quelques transactions par jour, ce qui suffit pour les besoins d’achats personnels.

Par contre pour tout ce qui est compte non-individuel, imposer des frais de transactions comme solution pour éviter le spam ne me paraît pas inconcevable.

Aussi la 4ème liberté économique “liberté d’échange dans la monnaie” ne serait pas bafouée pour autant, car :

  1. pour les non-membres : la Ğ1 ne prétend être libre que pour sa WoT
  2. pour les membres : “libre” ne signifie pas “sans contraintes”

Enfin, concernant le besoin d’anonymisation, devoir payer des frais pour y satisfaire ne me paraît pas non plus impensable.

2 Likes
10

Sauf erreur de ma part, c’est moins rapide “en théorie”, mais pas en pratique, car Duniter écrit un bloc toutes les 5minutes, alors qu’on passerai à toutes les 6 secondes pour Substrate. La prise en compte séquentielle ne se verra donc pas, pour l’utilisateur final.
Par ailleurs, la gestion en mode comptes diminue le risque de perte de TX a cause d’un fork, puisque les TX ne sont pas liées à une branche mais seulement une séquence (via le nonce) qui d’ailleurs doit être plus facile à générer par les clients, y compris offline, non ?

En sais tu plus sur la gestion de cette séquence ? Un client peut-il bien déterminer (seul) le prochain nonce ? Ou bien a t’il besoin d’info provenant du dernier bloc incluant une TX du compte ? Merci.

2 Likes
11

Si j’ai bien compris, le nonce d’une transaction est choisi par l’émetteur de la transaction. Il suffit de faire +1 à chaque transaction et de les envoyer dans l’ordre.

Les situations qui poseront problèmes sont quand deux clients veulent envoyer des transactions d’un même compte en même temps, et quand on veut stocker des transactions avant de les envoyer.

4 Likes
12

Ou même si réalisées séquentiellement depuis deux clients, cela posera tout autant problème. Le Nonce d’un compte doit être à jour dans tout client, sans quoi la transaction¹ sera refusée.

Mais évidemment si un seul client est utilisé, le Nonce peut être géré offline.

¹ : comprendre « document » ou « extrinsic », ce n’est pas un comportement spécifique au transfert de monnaie.

1 Like
13

J’aimais bien l’approche UTXO, aussi parce que ça nous permettrait d’ajouter facilement un mécanisme antispam de transaction en faisant en sorte qu’une source n’est valide que si elle provient d’un transaction assez ancienne (par exemple 10 minutes). Ça rendrait plus difficile le « trading haute fréquence » autrement connu sous le nom de « SPAM », et ça ne devrait pas trop gêner les échanges. Si certains services ont besoin de faire circuler de la monnaie rapidement, ils devront avoir un volume important afin d’avoir toujours des sources « fraîches » à disposition.

1 Like
14

En quoi y aurait-il une différence ? Pour avoir de la monnaie disponible :

  • en UTXO : je multiplie les UTXO
  • en Compte : je multiplie les comptes
15

Je suis clairement contre les UTXO, qui sont beaucoup plus gourmandes en storage et qui sont donc beaucoup moins scalable que les comptes avec nonce.

Mais l’argument le plus fort en faveur des comptes avec nonce, c’est que ça simplifie énormément la migration sur substrate, toutes les pallet substrate sont basées sur la notion de compte avec nonce. Si on veut passer en UTXO on ne peut profiter d’aucune pallet existante, ça ferait beaucoup plus de truc à recoder nous -même.

Je pense même que techniquement ça n’aurait aucun sens de migrer sur subtrate et de garder un sytème d’UTXO.

3 Likes
16

Je suis clairement parti sur une logique de compte, le protocole ne parle quasiment qu’en ces termes. Et d’ailleurs ça le simplifie beaucoup. Ce sera publié cette semaine.

5 Likes