La création d’un compte portefeuille, a un poid sur la blockchain (je parle de poid réel, et non de la « monnaie poid »). Donc, pour aller au bout du raisonnement, si on veut vraiment garantir une parfaite égalité entre tous les être humains concernant l’utilisation de la blockchain, et si on veut avoir une solution anti-spam par la même occasion, en complément à la solution d’elois, il faudrait qu’un compte portefeuille soit lié à un compte membre. Sinon, n’importe quel être humain pourait créer une « infinité » de comptes portfeuilles, et donc « saturer » la blockchain à lui tout seul
Comment fait-on dans ce cas pour entrer dans la blockchain ? On passe tous par un compte portefeuille au départ il me semble
Je ne vois pas d’autres solutions que celles-ci :
_Soit il faut changer la manière de créer des comptes membre
_Soit admettre qu’une parfaite égalité n’est pas possible (mais ça n’est pas une solution ^^).
Concernant la solution 1, la comme ça, je vois 2 solutions (il peut y en avoir d’autres) :
_Les certifications pourraient se faire avant la création d’un compte. Ce seraient en quelque sorte des promesses de certifications. Et la création d’un compte membre nécessiteraient donc n promesses de certifications.
_Permettre de créer des « portfeuilles en attente », qui ne seraient pas écrit sur la blockchain, mais qui permettrait d’avoir la future clé publique (avec toutefois un risque qu’elle soit prise entre temps). Il faudrait donc permettre la certification d’un compte qui n’existe pas, mais qui devrait exister dans le future
C’est ça, de la même transaction pour être plus précis, il y aurait un ou plusieurs champs supplémentaire dans les méta-données de l’extrinsic, indiquant quelle quantité de poids tu es prêt à acheter et pour quel prix.
Ça s’en rapproche mais c’est différent. Les gas ne sont pas une monnaie, les “gas” correspondent au “weight” de substrate, que le traduit ici en “poid”, mais ce n’est pas une monnaie, c’est une grandeur qui quantifie les ressources nécessaires pour exécuter la transaction.
La “monnaie poids” que le propose porte mal son nom, car ce ne sont pas des poids directement, et à ce stade ce n’est qu’une proposition dont le doute moi-même, cette monnaie pourrait être la Ğ1 où une monnaie dédiée, les 2 choix ont des avantages et inconvénients, qu’il faut étudier.
C’est pour ça que je pense que les poids nécessaires à l’exécution d’une transaction doivent être achetables au sein même de la transaction a exécutée. Réponse plus simple: ils payeraient des frais, sauf si suffisamment de quotas leur ont été transférés.
Il existe un extrinsic dédié pour vider un compte (transfer_all), on peut envisager des règles spécifiques pour cet extrinsic.
Ce qui empêche tout anonymat, est complexe à mettre en place, et très limitant pour les utilisateurs, je suis totalement contre cette proposition.
Non car la création d’un simple portfeuille à un coup du fait de “l’existential deposit”, où dépôt d’existante, un montant en dessous duquel le compte n’existe pas dans le storage onchain.
Ce montant est actuellement de 1Ğ1 et devra être augmenté régulièrement, par exemple a chaque réévaluation du DU pour que ça devienne une proportion du DU.
Je vois une 3eme solution :
_Permettre la création d’un compte en y associant de la « monnaie poid ». Cela sous entend que le compte soit créé par un compte disposant de « monnaie poid » ou que de la monnaie poid peut être « externalisé » puis réutilisé plus tard (création d’un jeton avec un numéro « unique » par exemple)
Non car la création d’un simple portfeuille à un coup du fait de « l’existential deposit », où dépôt d’existante, un montant en dessous duquel le compte n’existe pas dans le storage onchain.
Ce montant est actuellement de 1Ğ1 et devra être augmenté régulièrement, par exemple a chaque réévaluation du DU pour que ça devienne une proportion du DU.
Si je comprend bien ce que tu as dis un compte portefeuille qui a toujours eu 0G1 n’est pas sur la blockchain ? Si oui, si j’ai bien compris, cela veut dire qu’envoyer 1G1 à ce type de compte sera plus coûteux en “monnaie poid” que l’envoi d’1G1 vers un compte déjà existant sur la blockchain
@Libertus je t’invite à respirer et prendre le temps de réfléchir d’avantage avant de proposer tous azimuts, il te manque certaines notions sur substrate de duniter-v2s pour pouvoir formuler des propositions pertinentes.
Notamment, on ne peut pas gérer des choses “en attente” en dehors de la blockchain, c’est justement un mauvais design de Duniter v1 dont on veut absolument sortir.
Non, car les opérations à faire pour réaliser le transfert reste les mêmes, dans les 2 cas il faut lire le solde actuel (on obtient zéro si le solde n’existe pas), et y ajouter le montant du versement, puis écrire le résultat s’il est supérieur au dépôt d’existence.
Ce que les poids mesurent c’est le temps d’exécution, pas l’espace occupé dans le storage onchain.
Cet espace n’est pas payé dans le cas général, et dans certains cas un dépôt de monnaie est exigé pour pouvoir stocker des données onchain, dépôt qui peut être rendu quand on supprime ces éléments, mais ça ne rentre pas dans la problématique que l’on traite dans ce sujet, c’est une problématique qui se traite dans les règles métier d’un extrinsic pour chaque extrinsic ou c’est pertinent.
Je la trouve super cette reflexion 
D’y penser, d’avoir cette idée… bien joué 
Effectivement, la blockchain est commune : elle n’appartient à personne en particulier, c’est une co-gestion de ses utilisateurs.
Maintenant ici tu parle du temps d’exécution sur la blockchain, est-ce vraiment un commun ? Il me semble que l’exécution se fait via des nœuds de calcul, maintenu par des individus, avec leur propres moyens humains, techniques, financiers etc… et que ça sera également le cas avec Substrate ?
Egalement, est-ce que ces mainteneurs peuvent choisir de privilégier ou interdire certaines transactions ?
Si c’est bien le cas, suivant leur idéologie, ces mainteneurs peuvent demander à être rémunéré pour exécuter certaines transactions plutôt que d’autres (et même être payé à explicitement en refuser certaines), d’autres mainteneurs seront plutôt tenter par ta proposition de considérer que les transactions doivent être réparti équitablement (et rémunéré via un pot commun comme actuellement ?)…
Plusieurs solutions me semble possible en même temps ^^ Si une personne ne se retrouve dans aucune solution, il peut toujours monter son propre nœud et attendre son tour pour y inscrire ses transactions (ce qui peut être long si le reste des nœuds l’ostracise ?).
Si ce n’est pas le cas, si les mainteneurs ne peuvent pas choisir de privilégier ou interdire certaines transactions, je vous prie de bien vouloir excuser ces minutes de lecture volées 
Et du coup je me demande comment est géré la « rémunération » des nœuds dans Substrate (plutôt compensation je dirais, du temps et de l’énergie passé à la maintenance de ces nœuds).
Effectivement, ce n’est pas le cas. Le maintainer du nœud n’a pas la main sur les transactions, et heureusement, pour éviter les effets de bord cités
Parfait 
Et du coup, est-ce que tu peux m’expliquer (ici ou en message privé), comment est géré la « rémunération » des nœuds dans Substrate ? ^^
On choisit qui paye et qui reçoit les frais de transaction, et on choisi comment les transactions sont priorisées, les deux questions étant indépendantes ? Le sujet d’elois étant donc seulement porté sur cette deuxième question ? ^^
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
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 
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 
1 Like