Comment partager équitablement cette ressource commune qu'est la blockchain Ğ1?

Là je ne comprends pas. Les utilisateurs doivent bien envoyer leurs transactions via l’API d’un ou plusieurs nœuds, qui les propageront dans le réseau ou les écriront quand ce sera leur tour, non ? Donc ils peuvent placer des filtres à ce niveau-là.

La méthode que j’ai décrite plus haut me fait penser à… par exemple une distribution de légumes périssables d’une AMAP. Tout le monde a le droit de prendre autant de légumes qu’il souhaite, car le reste pourrit vite. Si trop de monde exerce ce droit, il n’y en aura pas pour tout le monde. Alors on diminue le quota pour tout le monde, ce qui garantit l’égalité spatiale, tout en évitant les pertes de légumes. L’indexation des quotas sur une monnaie libre (la “monnaie-poids”) permet en plus l’égalité temporelle.

2 Likes

Dans ce cas, il faut trouver un moyen pour que ça ne puisse pas être le cas. Un nœud inscrit doit porter la signature connue et vérifiée d’une version de Duniter officielle.

C’est impossible techniquement, et puis c’est un logiciel libre. La seule chose qu’on peut vérifier de l’extérieur c’est le comportement observable du nœud (comme la validité des blocs qu’il publie, le respect de son obligation d’écrire des blocs). On ne peut pas vérifier que toutes les requêtes valides sont traitées, de plus il aurait de bonnes raisons de ne pas en traiter (régulation de la bande passante, antispam, bug réseau, IP-ban…).

1 Like

Le logiciel est libre oui, cela signifie qu’on peut le réutiliser et le modifier pour une autre blockchain. Mais au sein de la même blockchain, il ne doit pas y avoir le droit d’avoir des nœuds modifiés.

Tu m’arrêtes si je me trompes @elois mais pour moi, il doit y avoir une vérification pour être certain que n’importe quelle requête légitime puisse passer par n’importe quel nœud autorisé sur la blockchain

On peut utiliser une méthode similaire à celle de Tor : certains nœuds de confiance envoient des requêtes à tous les autres nœuds pour les tester, et leur attribuer un mauvais score publiquement s’ils ont visiblement mal agi.

Mais c’est un autre sujet, et puis ce n’est pas nécessaire tant que le réseau est petit, ni quand il sera grand puisqu’il y aura assez de nœuds pour contrebalancer l’apparition de nœuds malveillants.

Edit: pour se passer de nœuds testeurs de confiance on peut autoriser tout membre à émettre un jugement sur un nœud, mais alors ça ouvre la porte à la diffamation, or on est sur des affirmations irréfutables donc si un nœud bloque une IP ou un compte en particulier on ne saura pas quoi faire de jugements contradictoires.

Si cela peut se gérer de manière transparente pour l’utilisateur, c’est forcément mieux. Maintenant, est-ce un problème ou non ? Est-ce possible aujourd’hui ? Je n’ai pas les réponses :wink:

Oui, car dans le nouveau système de consensus BABE/GRANDPA, le temps d’exécution d’un bloc est limité à 2 secondes. Et vérifier un bloc consiste à l’exécuter, donc tous les nœuds validateurs doivent avoir des ressources au moins égale à une machine de référence, sur laquelle on va étalonner le temps d’exécution de chaque type de transaction (pour simplifier).

Étant donné que c’est une ressource quantifiable et limitée, et que cette limite est fixée par le protocole commun, c’est bel et bien une ressource commune.

Oui, à la différence qu’il n’y a plus de PoW, donc aucun intérêt d’avoir un nœud plus puissant que la machine de référence sur laquelle a été fait l’étalonnage. Du moins pour la création des blocs, ça peut rester intéressant pour pouvoir fournir d’autres services.

Malheureusement oui, il n’y a aucun moyen de prouver qu’un nœud n’a volontairement pas inclus une transaction, il pourra toujours prétexter ne pas l’avoir reçue, ce qui peut être vrai car tout réseau décentralisé est nécessairement incomplet et incohérent.

Mais ce n’est pas gênant, car la transaction sera juste incluse au bloc d’après par un autre nœud. Ça ne deviens problématique que si une proportion significative des créateurs de blocs décident conjointement de bloquer les mêmes transactions, ce qui va alors se voir.

Je pense que l’on doit expliciter dans la licence forgeron que de telles pratiques sont interdites, et que si des faisceaux d’indices montrent qu’un membre forgeron fait cela, il peut être sanctionné voir exclu via un mécanisme de gouvernance à définir.
L’un des avantages de substrate c’est qu’on a les outils pour mettre en place de la gouvernance onchain relativement facilement.

Comme on veut, pour le moment dans Duniter-v2s il n’y a aucune rémunération, il faut qu’on discute si on en veut une et si oui comment.

Techniquement c’est impossible à mettre en place, je ne connais aucune blockchain qui y arrive. Il vaut mieux se concentrer sur du monitoring de tout les créateurs de bloc, et des mécanismes de gouvernance pour décider collectivement des sanctions où exclusions de ceux qui ne respectent manifestement pas les règles de bonne conduite.

2 Likes

Si j’ai bien compris la problématique, on cherche donc comment gérer les congestions (quelles exécutions doivent passer).

La première proposition, basique, est celle des frais qui augmente quand ca congestionne. Le soucis c’est que ces frais seraient fixés arbitrairement, et surtout que les plus riches seraient favorisés, et les plus pauvres ne pourraient plus exécuter de transactions et donc échanger. Ce qu’on, à priori, ne souhaite pas.

Une deuxième proposition est celle des quotas. Chaque individus a le droit à la même quantités d’exécutions, pour faire simple. Si une personne veut réaliser plus d’exécutions que tout le monde, elle va devoir acheter un droit à le faire aux autres qui exécutent moins que tout le monde, et qui peuvent donc vendre leur droits.
Dit comme ça, cette proposition semble favoriser ceux qui exécute moins, au détriment de ceux qui exécutent plus (qui, pour exécuter plus, doivent acheter des droits aux autres). Une personne qui utilise peu la monnaie se retrouve à recevoir une sorte de rente, en vendant ses droits à prix libre, car justement il l’utilise peu. Ca me semble également ne pas être souhaitable.

Une troisième proposition serait, seulement en cas de congestions, de diminuer la priorité à ceux qui ont déjà eu des exécutions de réalisé, afin de laisser place à ceux qui n’en n’ont exécuter aucune. Le soucis c’est que du coup, chaque exécution doit être signé par un membre. Les transactions ne seraient plus anonymes, et pas disponible pour les non-membres. Également, des fois, on aimerait bien quand même passé en priorité, en proposant et compensant ceux qui nous laisse la priorité bien entendu, ce qu’on ne peut pas faire ici.

Une bête implémentation, sans signature, serait que chaque exécution puisse être paramétrée pour indiquer combien de G1 peuvent être acceptée pour que l’exécution soit dépriorisée, ou au contraire combien de G1 peuvent être payé en supplément pour être priorisée. Ainsi, même si je suis « pauvre en monnaie », en refusant une compensation, je ne serais pas dépriorisé.
Malheureusement, ca n’empêche pas une autre personne de faire exprès de congestionner la blockchain avec pleins d’exécutions avec compension, afin justement de se faire rémunérer. C’est une autre chose que l’on ne souhaite pas.

Une autre problématique étant la rémunération des nœuds. Qui doit compenser les mainteneurs de ces nœuds ? Les membres à égalité ? Ou plutôt ceux qui réalise le plus d’exécutions ? Répondre à cette question peut peut-être nous aider à réaliser nos arbitrages sur la question des « compensations ».

J’espère être utile et faire avancer la réflexion.

2 Likes

Je pense que ce n’est pas implémentable, ou alors je ne comprends pas ce que tu entends pas “dépriorisée”.

Voici comment ça fonctionne, pour que tu comprennes ce que l’on peut faire :

Tout d’abord on définit un format de méta-données (SignedExtra), pour chaque Transaction(=Extrinsic), ça peut contenir les données que l’on veut, mais c’est protocolaire donc ça ne peut pas changer (enfin si mais ça demande une mise à jour du runtime ET de tout les wallet).

Ensuite, on doit définir une fonction qui affecte une priorité à chaque transaction, cette fonction ne peut se baser que sur les données contenues dans la Transaction à évaluer, et dans le onchain storage du dernier bloc.
En particulier, on ne peut pas se baser sur les autres transactions dans la pool.

Ensuite, la seule décision que l’on puisse prendre c’est soit d’accepter la transaction et de lui affecter une priorité, soit de la refusée (elle sera alors supprimée et jamais inscrite en blockchain).

Enfin, la partie qui génère le contenu du bloc itère sur les transactions ordonnées par priorité, et les inscrit une par une jusqu’à ce que le bloc soit plein. Les transactions non inscrites restent dans la pool avec le même niveau de priorité jusqu’à ce qu’elle soit inscrite dans un prochain bloc où supprimer après un délai d’expiration.

Il faut comprendre que tant qu’une transaction n’est pas inscrite en blockchain, elle ne peut rien exécuter, donc en particulier aucune rémunération basée sur le contenu de cette dernière ne peut être appliquée.

C’est là que j’en reviens à ta proposition de rémunérer quelqu’un qui propose d’être dé-priorisé, ça me semble impossible car s’il est dé-priorisé cela signifie que la transaction n’est pas exécutée, donc il ne peut pas être rémunéré.


Du reste, tu apportes des réflexions très intéressantes sur les limites des autres propositions, merci beaucoup pour ça :slight_smile:

Je garde l’espoir que quelqu’un finisse par trouver une solution satisfaisante à ce problème, mais ton message me confirme que pour le moment pour n’en disposons d’aucune :confused:

1 Like

Bonsoir à chacun, c’est incroyable de voir le niveau de réflexion ici avec tellement de créativité et d’imagination. C’est beau !! :slight_smile:

Dans la vie j’aime bien le principe KeepItStupidSimple, du coup je me demande pourquoi ne pas simplement mettre en place un « coup automatique en pourcentage du montant de la transaction » ?

Il me semble que :

  • ça tue dans l’oeuf les attaques en faisant pleins de petits virements successif en les limitant dans le temps à cause de la diminution du volume,
  • ça ne tombe pas dans le piège des frais fixes (c’est dans les 60€ par transaction pour Ethereum en ce moment il me semble, c’est énooorme) et n’avantage pas les riches

En plus laissant ce paramètre libre de varier dans le temps en fonction de la congestion justement ça pourrait pousser certains utilisateurs à choisir de retarder leur transaction de quelques minutes/heures.

  1. Un exemple : je doit faire un virement à un ami pour la soirée pizza, je suis en train de le faire, mais une petite alerte de mon appli me dis que les frais sont haut parce que le réseaux est en saturation. Du coup je clique sur l’option « faire le virement plus tard quand les frais seront moins important », et voilà. Ça reste dans mon appli pour ne pas congestionner le réseau bien sur.
  2. Un autre exemple : je veux faire tomber la june, j’ai un milliard de compte avec le minimum (1G1 si je me souviens bien) soit un milliard de june. Je lance mon script pour faire un milliard de transaction en même temp. Première transaction ça passe, sauf que j’ai perdu 1% et que le système se dit « woooo » y’a du monde, on va augmenter le pourcentage à 10% !!!" De mon côté deuxième tentative, mais là je tombe sous la limite d’existence des portefeuilles et mon attaque s’arrête là. Elle aura duré 1 bloc et m’aura couté 1 milliard !!!

D’autre part, je donne régulièrement à Remuniter, mais « il faut que j’y pense ». Perso je préfèrerai que ce soit automatique lorsque j’utilise la June via la blockchain. Personnellement je me dis que 1% comme valeur de base minimal ça serait pas mal. Et concrètement ça pourrait aller directement à tout les serveurs qui on calculé le blocs et qui donc maintiennent le service.

Pour résumer : quand on utilise un service on devrait le payer → mettre en place des frais de transaction automatique.

Merci pour votre attention :slight_smile:

Mais si je fais plein de très petites transactions, ça me coûte très peu mais ça coûte énormément au réseau, il faut donc une limite basse aux frais.

Et il y a d’autres transactions que les mouvements de monnaie, par exemple tout ce qui touche à la toile de confiance. Comment calcule-t-on les frais dessus ?

Enfin ce mécanisme de poids fait partie du fonctionnement de Substrate, et c’est ce qui détermine la quantité de transactions à intégrer dans un bloc. Il est plus sûr et optimal de se baser sur le temps de calcul, que sur le montant d’une transaction. On aurait donc deux systèmes différents, les frais et les poids.

Bonsoir @lascapi :slight_smile:

Car une transaction n’a pas forcément de montant, ici le terme transaction ne désigne pas “transfer de monnaie”, mais “action en blockchain qui modifie l’état du système”. Avec duniter-v2s il y a de très nombreux types de transactions possibles (plusieurs dizaines), et seulement 3 ou 4 ont un montant.

Aussi comme l’explique bien @tuxmain, il y a un “coût de base” à l’exécution d’une transaction, qui est indépendant de son montant.
Ainsi envoyer 2 transactions de 1Ğ1 coûte 2 fois plus de ressources à la blockchain qu’une seule transaction de 2 Ğ1.

Ta proposition ne peut donc pas convenir pour répartir le temps d’exécution en blockchain, en revanche elle peut convenir pour financer des choses, comme pas exemple (liste non-exhaustive):

  • La rémunération des créateurs de bloc
  • La rémunération de ceux qui stockent les données des utilisateurs
  • L’alimentation d’une trésorerie commune gérée par gouvernance onchain

Ces frais proportionnels additionnels aux poids sont intéressants en fait : ils réduisent l’asymétrie entre riches et pauvres. Avec seulement les poids, les grosses transactions sont taxées autant que les petites, donc elles sont négligeables quand on achète une maison, mais importantes quand on achète une baguette. Est-ce encore une monnaie libre dans ce cas ?

Donc l’introduction d’une faible taxe monétaire (donc prélevée en G1 et non en monnaie-poids), par exemple de formule floor(taux * montant) ne me semble pas une mauvaise idée. Pour un montant assez grand, le poids devient négligeable devant la taxe, ce qui n’avantage pas les grosses transactions par rapport aux petites.

Après, peut-être que privilégier les grosses transactions est utile, notamment pour réduire la fréquence des transactions. Mais il faut voir les conséquences économiques, par exemple l’inégalité entre ceux qui peuvent faire des grosses transactions (les riches) et les autres (les pauvres).

1 Like

Si, ça avantage ceux qui ont les moyens de faire de plus grosses transactions.

Exemple : Je paye 100 Junes de 2 manières différentes et avec 2 coûts différents :

  • Coût de la transaction : 1 June et pas de taxe
    • 1 transaction de 100 Junes : Côut total => 101 Junes (100 + 1)
    • 10 transactions de 10 Junes : Côut total => 110 Junes ( 10 * 10 + 10 * 1)
  • Coût de transaction : 1 June + 1% de taxes
    • 1 transaction de 100 Junes : Côut total => 102 Junes (100 + 1 + 1)
    • 10 transactions de 10 Junes : Côut total => 111 Junes (10* 10 + 10 * 1 + 10 * 0,1)

En gros, la taxe est la même pour tous (complètement inégalitaire au même titre que la TVA).

Pour conclure, introduire une taxe qui sera payer par tous en fonction du montant n’équilibre rien. Par contre, le coût de la transaction peut vite faire grimper le coût total d’utilisation si nous faisons de multiples opérations. Donc, ce n’est pas très juste non plus.

Cependant, je ne vois pas trop de solution pour rendre le système plus juste. Je penses que ce sujet mérite vraiment d’être creusé.

1 Like

Je voulais dire que ça réduisait considérablement l’avantage donné aux grosses transactions.

Mais si on utilise la monnaie-poids transférable, ça ne devrait pas être nécessaire. C’est utile surtout si les poids sont payés en G1 ou que la monnaie-poids n’est pas transférable (et donc que les comptes non-membres doivent payer les poids en équivalent G1).

Il y a des propositions autres que la monnaie-poids :

  • quota gratuit par unité de temps pour les membres, avec possibilité de déléguer une partie de son quota à des comptes portefeuille.
    • Implémentation 1 : à chaque transaction, vérifier si l’origine est membre et compter le quota onchain immédiatement
      • :+1: facile à gérer pour les wallets, immédiat, facile à coder
      • :-1: coûteux (2 lectures storages) à chaque transaction
    • Implémentation 2 : pour profiter du quota, il faut mettre son extrinsic dans un extrinsic wrapper particulier. On ne vérifie le quota que si le wrapper est là.
      • :+1: n’augmente pas la complexité des transactions sans quota, immédiat, facile à coder, facile à gérer côté wallet
      • :-1: augmente la complexité des transactions des membres
    • Implémentation 3 : oracle de remboursement différé. Un indexeur note les transactions éligibles au quota et périodiquement rembourse (en inhérent) les membres.
      • :+1: n’augmente pas la complexité des transactions
      • :-1: long à coder, non-immédiat, difficile à gérer pour les wallets (afficher un solde futur après remboursement)
  • PoW côté wallet
    • :+1: facile à coder, léger à vérifier en blockchain, immédiat
    • :-1: revient à payer en € l’électricité plutôt que des G1, coûteux en énergie d’une manière invisibilisée, peut être délégué à un service de PoW commercial

Ici le terme “immédiat” se réfère au ressenti de l’utilisateur, qui n’aura pas l’impression de s’être vu prélever une taxe. Il a été exprimé que ce ressenti était important, et qu’un prélèvement suivi d’un remboursement serait quand même problématique. Les wallets peuvent toutefois minimiser cet effet en affichant le solde futur après remboursement.

Edit: mémo idée pour l’implémentation des quotas. Stocker pour chaque identité (ou membership ?) la dernière session (ou le dernier jour ?) où un extrinsic a été émis par cette identité, ainsi que la somme des frais accumulés non payés sur cette période.

6 Likes

Je propose de partir sur l’implémentation 1 du quota. (cf message précédent)

C’est la plus simple pour tout le monde (wallet et nœud, devs et utilisateurs) et le coût runtime est minime.

Le quota peut être glissant sur 24h avec granularité de 1 bloc : chaque membre a un quota maximum Q. À chaque transaction, on incrémente le quota (sans dépasser Q) proportionnellement au nombre de blocs passés depuis la dernière utilisation du quota, de sorte qu’un quota vide se remplisse complètement en 24h. Ensuite on le décrémente du poids de la transaction. Le reste est payé en G1.

Dites si vous êtes contre ou pensez qu’il y a encore à débattre.

3 Likes

Où se trouve la délégation au compte portefeuille dans cette solution ?

1 Like

Bien vu. Plutôt que de chercher si l’origine est membre, on peut regarder dans une StorageMap AccountId->IdtyIndex qui associe l’identité à sa clé publique et ses clés déléguées.

Pour commencer on peut se contenter des comptes membres, et l’ouverture aux délégués sera facile à faire.

1 Like

Quitte à faire en deux temps, je préférerais que tu conserves ta solution initiale : vérifier si le compte est membre ou non.

Pour moi le sujet des comptes portefeuilles sans frais n’est pas assez mûr, je préférerais que l’on ne s’engage pas trop dans une voie technique particulière qu’il faudrait possiblement démonter ensuite.

4 Likes