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

Protocols Ğ1v2 protocol
1

Je me rends compte que c’est la 1ère fois que je réfléchis vraiment pleinement à ce problème, et j’en viens à une conclusion que je n’ai jamais vu ni lu nulle part, je vous partage donc ma réflexion :slight_smile:

Quelle ressource commune ?

Le temps d’exécution sur la blockchain, que l’on peut vulgariser comme « l’espace disponible dans une page de notre grand livre de comptes commun ».

Comment font les autres ?

Toutes les crypto-monnaies que je connais choisissent de gérer la répartition de cette ressource via le paiement de frais de transaction dont le montant varie en fonction de la demande: plus il y a de demande, et plus c’est cher (l’offre - la capacité maximale de la blockchain - étant fixe).

Techniquement ça fonctionne, mais est-ce juste ? Cela conduit inexorablement à une exclusion des plus pauvres lorsque la demande augmente, quand bien même ces derniers ne sont pas responsables de cette augmentation de la demande.

Comment partager équitablement cette ressource commune ?

Une idée qui vient assez vite est celle des quotas.
Cela nécessite toutefois de quantifier correctement la ressource à partager, ce que substrate permet grâce au système de «poids».

Une fois que l’on a déterminé le poids maximal sur une période donnée, on peut accorder comme quota à chaque identité le poids maximal divisé par le nombre d’identités.

Cela demande de choisir une période, car si on choisit une période trop courte (par exemple 1 bloc), ça ne fonctionnera pas, chaque identité disposant d’un quota trop faible pour faire ne serait-ce qu’un simple transfert. Dans la pratique tout le monde n’effectue pas des transactions en même temps, donc il faut choisir une période plus grande pour la définition des quotas.
Si on choisit une période trop grande (par exemple 80 ans), un utilisateur peut cramer tout son « droit d’utilisation de la blockchain » trop rapidement, et se retrouver condamner à ne plus utiliser la blockchain Ğ1 pour le reste de sa vie.

Mais fixer une bonne période n’est pas le plus gros problème, il y a bien pire !

Comment fait-on pour les « comptes » qui ne sont pas rattachés à une identité certifiée ? Et donc qui ne sont pas limités par être humain ?

On peut décider que les quotas sont « transférables », et qu’une identité doit transférer une part de son quota (en nombre de « poids »), à un compte pour que ce compte puisse exécuter des transactions (transaction au sens large, ça peut être n’importe-quel extrinsic).

Une solution : une « monnaie poids »

Finalement, si ces « poids » deviennent transférables, c’est comme une monnaie vu qu’ils sont fongibles, donc pourquoi ne pas partager ces « poids » comme on partage la Ğ1 ?

Il faudrait donc que chaque utilisateur créer une proportion des nouveaux « poids » à parts égales avec tous les autres.

Cette « monnaie poids » doit-elle être séparée de la Ğ1 où être la Ğ1 elle-même ?

La Ğ1 donne un pouvoir d’achats de bien de services, les poids donnent un pouvoir d’exécution d’extrinsics sur la blockchain. C’est différent, mais des gens peuvent accepter de vendre des bien ou service contre du temps d’exécution sur la blockchain.

Une monnaie ne sert t’elle justement pas à gérer le partage des ressources ?

Supposons que cette « monnaie poids » soit la Ğ1 elle -même, on pourrait fixer le prix de poids de manière à ce qu’utiliser 100% des capacités de la blockchain corresponde exactement à verser 100% des Ğ1, mais cela signifie que la blockchain sera en sous-régime tout le temps.

Autre problème: que fait-on des Ğ1 allouées à la consommation de poids, sont-elles détruites ? sont-elles versées à une trésorerie commune ? Où à « autre chose » ?

L’avantage d’avoir une « monnaie poids » dédiée est double :

  1. On peut allouer 100% de cette monnaie poids à la consommation de temps d’exécution sur la blockchain, et donc utiliser à blockchain à sa capacité pleine et entière.
  2. On peut détruire cette « monnaie poids » lorsqu’elle est consommée pour acheter du temps d’exécution, sans que cela ne détruise des Ğ1.

Dans la pratique, cette « monnaie poids » si elle était mise en place, pourrait être achetée et vendue contre des Ğ1 (ou n’importe-quoi d’autre), il y aurait donc un marché des poids, il serait donc possible d’acheter des poids.

D’un point de vue expérience utilisateur, ça revient à avoir un quota gratuit (les poids que l’on crée chaque jour), puis des frais au-delà de ce quota (le prix des poids sur le marché de change poids/Ğ1).

Les interfaces utilisateur pourraient très bien parler uniquement de quotas transférables et achetables pour que ça reste simple à comprendre, et occulter le fait que techniquement c’est une monnaie que l’on crée tout comme on crée son DU Ğ1.

Avoir techniquement une monnaie dédiée pour les poids résout plusieurs problèmes que je ne vois pas comment résoudre autrement:

  • Ça laisse le marché (qui est la résultante des actions de chaque utilisateur), décider du prix poids/Ğ1, donc nous développeurs n’avons aucun prix à fixer.
  • Ça évite la question de qu’est-ce qu’on fait des Ğ1 qui ont payé les frais, car en réalité les Ğ1 ne payent pas les frais, elles payent celui qui vend ses poids dont il n’a pas besoin.

Quantification d’ordre 1 (pour avoir un ordre de grandeur)

Concrètement, chaque bloc dispose de 2000 milliards de poids, mais certains de ses poids sont consommés par des actions automatiques, et ne peuvent donc pas être alloués à des utilisateurs.
D’autres encore peuvent être alloués à des call collectif en root via la démocratie, et ne peuvent donc la non plus pas être alloués à des utilisateurs.

On peut définir une proportion des poids alloués aux actions utilisateurs, d’ailleurs substrate demande de le faire, et propose par défaut 75%.

Supposons donc que l’on ait 1500 milliards de « nouveaux » poids pour les utilisateurs à chaque bloc. Si l’on a 1 million de membres, chacun d’eux est «crédité» de 1,5 millions de poids à chaque bloc.

À titre d’exemple, dans Polkadot un simple transfert nécessite environ 69 millions de poids. Cela signifie que si l’utilisateur ne réalise que des simples transferts, et si notre simple transfère coûtait le même nombre de poids que sur Polkadot, cela signifie qu’un utilisateur pourrait faire un simple transfert tout les 46 blocs, où dit autrement, 313 simples transferts par jour.

Supposons que les autres types d’extrinsic (par exemple une certification), coûte en moyenne 10 fois plus de poids, on reste encore large avec 1 million d’utilisateurs, le besoin de layers 2 ne se ferait donc pas sentir avant au moins 10 millions d’utilisateurs.

4 Likes
2

Notez également que le temps d’exécution non utilisé est définitivement perdu, si un bloc n’a utilisé que la moitié de sa capacité, l’autre moitié n’est pas transférable dans le futur.

Il faudrait donc que cette monnaie poids soit « dévaluée » en fonction de la capacité non utilisée (donc perdue).

Bref, ça reste ure question ouverte, si un matheux veut bien étudier sérieusement ce problème, je me ferai un plaisir de répondre à ses questions :slight_smile:

3

Comment je fais pour utiliser des G1 reçues si je ne suis pas membre ? Il faut qu’on me donne en même temps les poids nécessaires pour envoyer une transaction, et que je me dépêche pour qu’ils ne fondent pas ?

Les transferts de poids vont coûter des poids, non ?

Et il ne faudrait pas que le marché du poids incite (oblige) les pauvres à vendre tous leurs poids, ce qui entretiendrait des inégalités.

Enfin ça sera compliqué pour les utilisateurs de gérer leurs transferts de poids, je pense qu’il vaudrait mieux éviter d’avoir à les gérer à la main.

Donc a priori je suis plutôt pour des poids non-transférables. Une transaction nécessiterait soit des poids (pour les membres), soit des frais (pour les portefeuilles ou les membres n’ayant plus de poids).

1 Like
4

Je me disais que pour les comptes non membres, il faudrait un transfert de poids automatique, vers ces comptes lors de transfert de Ğ1 ou de certification.

Et s’il y a une fonte de poids, il faudrait que cette fonte est une sorte de limite basse, un « minimum vital » à partir duquel il n’y a plus de fonte. Seul l’utilisation ferait baisser ce poids. Une fonte rapide pour les gros poids et plus lente pour les petits poids.

5

Tu peux acheter des poids avec tes Ğ1. On peut imaginer un mécanisme de change onchain, une sorte de DEX (Exchange Décentralisé), d’un point de vue utilisateur ce serait strictement équivalent à des frais, mais sans que les développeurs aient besoin de fixer un prix arbitraire.

Les Ğ1 aussi “fondent”, et tu n’as pas à te dépêcher pour qu’elles ne fondent pas, le phénomène est suffisamment lent, ce serait pareil pour les poids.

Cette approche pose 2 gros problèmes.

  1. Comment tu détermines les frais ? C’est une question au cœur du problème, une proposition qui n’y répond pas n’est pas implémentable.

  2. Les quotas non-transférables implique nécessairement soit une blockchain en sous-régime (car tout le monde n’utilise pas l’intégralité de ces quotas), soit de créer plus de quota que de capacité réellement disponible et donc risquer de congestionner la blockchain. C’est donc nécessairement sous-optimal.

C’est tout à fait possible, mais ça pose le problème de déterminer combien de poids on transfère. À priori, mon avis serait plutôt de laisser l’utilisateur choisir via un paramètre supplémentaire. Les clients grand-public fixerait une valeur par défaut pour masquer cette complexité, et les clients avancés (ou les «mode expert» des clients) laisserait la possibilité de remplir soi-même ce champ.

Le minimum vital est assuré par le “DU” en poids, de façon similaire à une monnaie libre comme la Ğ1.

Nous avons le temps, mais à travers ces discussions j’aimerais qu’on trouve la solution la plus satisfaisante à ce problème.
À court-terme je ferai plus simple au besoin, ce qui m’intéresse ici c’est comment «résoudre» ce problème théoriquement en admettant les mêmes axiomes que la TRM (les 4 libertés économiques).

1 Like
7

Je suis assez frileux concernant l’introduction explicite de cette monnaie « poids ». Ce n’est déjà pas hyper simple d’expliquer tous les mécanismes autour de la Ğ1.

Il me semble souhaitable que le mécanisme de répartition de la charge soit aussi transparent que possible sans introduire de complexité supplémentaire pour les utilisateurs lambda.

6 Likes
8

Le libre marché n’est pas optimal en général, il n’y a qu’à voir l’économie mondiale actuelle à toutes les échelles (pour ne citer qu’un seul exemple, les bullshit jobs). Et il n’est pas plus « naturel » qu’un autre système, donc j’ai l’impression que ça permettrait surtout aux développeurs (ou aux citoyens) de se défausser de la responsabilité d’en décider.

Par exemple, si les poids sont créés sous forme de DU, on peut définir le taux, à chaque bloc, tel que la masse monétaire des poids (masse pondérale ? :upside_down_face: ) égale une proportion p du poids maximal d’un bloc.

Donc p = 100% est sous-optimal. On pourrait prendre p plus grand, ce qui augmente le pouvoir d’écriture de chacun au risque de latence. Si tout le monde veut écrire en même temps et qu’on dépasse les 100%, certaines transactions passeront au bloc d’après, tant pis. Si cette situation est permanente on est coincé avec des transactions qui ne passeront jamais, mais la solution du marché du poids ne résout pas ce problème non plus, en plus d’être inégalitaire.

Pour trouver un p optimal (qui permette à tous d’écrire mais sans favoriser les embouteillages), on peut le faire varier en fonction du taux d’utilisation des derniers blocs. (p diminue quand le remplissage des blocs augmente)

2 Likes
9

Moi aussi, mais je ne veut pas sacrifier la qualité de la solution choisie pour ça. Je porpose qu’on essaye d’abord de trouver ce que serait l’idéal, et une fois qu’on à trouvé cet idéal voir comment on peut le simplifier de manière à perdre le moins possible en qualité :slight_smile:

Peut tu définir p plus précisément ? :slight_smile:

2 Likes
10

Une autre manière de formuler le problème:

À chaque bloc sont créés 1500 Gp (=GigaPoids). 6 seconde plus tard( au bloc suivant), ces 1500 Gp sont consommés ou détruit.

Comment gérer le partage d’une ressource limitée et dont la durée de vie est de 6 secondes ?

2 Likes
11

En notant p_n>1 au bloc n, u_n \in [0,1] l’utilisation du bloc n (e.g. 0 en l’absence de transactions, 1 quand les 1500Gp sont utilisés), et h un entier naturel.

p_{n+1} = f(p_n, (u_n, \cdots, u_{n-h}))

Reste à trouver f !

Par exemple on pourrait avoir h=0 et f(p, u)=2-u, ce qui donnerait vers 200% de pouvoir d’écriture en temps calme, et le réduirait progressivement quand la pression augmente, jusqu’à la limite (100%). (c’est un exemple sûrement pas optimal)

Ensuite, notons W_n la masse monétaire au bloc n de la monnaie-poids cocréée par les membres. Le poids auquel on a droit au bloc n quand on possède w monnaie-poids est p_n\frac{w}{W_n}\times 1500G. (il y a peut-être un n+1 quelque part, peu importe) La monnaie-poids utilisée est détruite.

À chaque bloc n l’ensemble des membres a donc le droit d’écrire p_n fois la capacité réelle, mais la répartition de ce droit entre les membres change : plus on a écrit dans les blocs précédents, moins il nous reste de monnaie-poids, mais puisque la monnaie-poids est libre, tout le monde converge vers la moyenne en ne faisant aucune transaction.

Il faut aussi fixer le taux de croissance c de la monnaie-poids.

2 Likes
12

Cet argument est faux, car l’économie mondiale n’est pas du tout un marché libre, c’est bourré de biais de centralisation et de copinage, les marchés crypto se rapproche un peu plus de marchés réellement libres, même si ce n’est pas encore totalement le cas.

On ne sait pas du tout ce qui donnerait un marché libre en monnaie libre, il y aurait peut-être d’autres inconvénients que l’on ne connaît pas encore, mais aucune solution n’est parfaite, et rejeter le principe de marché en général sur la base des expériences passées biaisés par de nombreux facteurs dont les monnaies non-libres me semble être un apriori idéologique qui n’a rien de rationnel.

5 Likes
13

Tu n’as pas défini \cdots, c’est une typo ?

14

C’est du LaTeX, ça ne fait pas le rendu chez toi ? En clair ça donne p(n+1) = f(p(n), (u(n), … , u(n-h))).

Si l’équation de la conversion sort mal aussi, c’est p(n) × w / W(n) × 1500G.

On pourra continuer la discussion d’ordre économique ailleurs pour ne pas polluer la discussion technique. :slight_smile:

1 Like
15

Oui je n’ai pas de rendu LaTeX, voici ce que je vois:

image
image701×285 88.4 KB

Je préfère que l’on continue ici. Sur le forum ML il y a trop de messages et trop de virulence à mon goût, je pense que ça serait bien à terme qu’on est un espace pour discuter des règles métier que l’on veut, où soient invités à participer tous les membres, y compris non-techniques.

On peut peut-être créer une catégorie “Règles Métier” où “Non-technique”, ça permettrait aux membres non-techniques de situer où est-ce qu’ils peuvent participer, mais aussi ce qu’ils doivent lire en priorité s’ils ne souhaitent pas être noyés d’informations techniques.

1 Like
16

Ce que je comprends du problème soulevé par @tuxmain et @Maaltir ne me semble par résolu par ce que tu proposes :

  1. j’ai un compte portefeuille vide
  2. je reçois des Ǧ1 dessus (sans poids ou avec des poids qui ont fondu au-delà du nécessaire à émettre un virement)
  3. je veux faire un virement pour acheter quoi que ce soit (des poids, des pommes…), mon virement est rejeté faute de poids pour le financer.

La seule alternative que je vois, et c’est peut-être ce que tu proposes sans que je l’aie clairement compris :
Si je veux faire un virement sans avoir les poids pour le financer, mon wallet va construire une transaction qui contient l’acte de virement en Ǧ1 vers le destinataire de mon achat “classique” + le virement pour l’achat de poids suffisant pour financer les deux actes de virement précédents. La transaction ne pourra être acceptée que du fait que l’achat de poids se fait au sein du même bloc (voir de la même transaction) que les virements.

C’est ça ?

Autre point :
Cette monnaie poid, ne serait-ce pas la même différence dans Ethereum que la différence entre Ether/Ǧ1 et gas/poids ? ( et je crois qu’il y a un principe similaire pour l’holochain : holo et fuel )

Dernier point :

Du coup cette monnaie technique “poids” aurait des caractéristiques de monnaie libre et permettrait de gérer les Gp dont la durée de vie est strictement de 6 secondes ?
Si c’est bien ça, sans savoir comment faire la conversion entre poids et Gp, j’aurais tendance à penser les poids avec une demi-vie/convergence à la moyenne de l’ordre d’un jour à une semaine.

En effet, je côtoie une personne qui n’arrive pas à gérer ses sous, et crame tout son mois de ressources en quelques jours. Si pouvoir payer en Ǧ1 deviens essentiel à la vie quotidienne de certaines personnes, que leur stock de capacité de virement se renouvelle en max 1 semaine me semble essentiel, et en 1 jour ça me semble encore plus confortable et intuitif.

1 Like
17

Et comment cela fonctionnerait pour des comptes de type remuniter, ou contributeur ?
Comment ces comptes non membres obtiendrais du poids ?
Même question pour les comptes de types gbillets ou gdon ?

D’où mon idée de transferts automatique de poids avec les Ğ1 quand ce transfert se fait vers un compte non membre. Et d’une limite à la fonte, pour qu’un billet ne devienne pas inutilisable.

Autre idée (je ne sais pas si c’est possible et en terme d’UX ce n’est pas évident)
Lors d’une transaction, il faudrait la signature du compte d’origine et la signature du membre qui « paye » le poids si le compte d’origine n’as plus de « poids ». Le nom du payeur de poids ne devrait bien sûr pas être stockée (l’idée étant d’avoir quand même des comptes anonymes). Je me dis que je délire là.

Autre idée (ouais ça fuse) Un compte non membre ne pourrais faire un virement que vers un compte membre quand son « poids » aurait fondu, le poids serait alors payé par le compte membre en question.

18

Les poids servent aussi d’antispam, sans les poids il faudrait taxer les transactions. Donc si tu peux faire une infinité de transactions de 1 G1 sans jamais payer ni poids ni G1, c’est un problème. Donc on ne peut pas limiter la fonte du poids infiniment.

1 Like
19

Peut-être peut-elle être limitée à un minimum qui permettrait de faire 1 opération ? Ce qui permet de vider un compte par exemple…

20

Je distingue la fonte (dans le temps) de l’usure (à l’usage).

Oui, mais si tu vide ce compte sur un compte nom membre, ce nouveau compte non membre ne pourra pas faire de transfert.

21

Oui, ce n’est pas faux :smiley: