Oui, je suis aussi d’avis d’y aller par étapes. Néanmoins la PoW + la difficulté peuvent être mis ensembles, et quoi qu’il en soit le changement de règle devrait être inclus en même temps. Donc la prochaine version incluerait ces 3 points.
Mais ensuite, je suis d’avis de passer directement sur les UTXO. Ce serait l’occasion de tester le changement de règles, aussi.
Oui ok, mais de toute façon les preuves incluant les DU n’ont d’intérêt que pour les clients car le nœud peut les calculer au besoin. Donc c’était bien Sakia/Cesium/Silkaj auxquel je pensais ici
Mais de toute façon on les stocke pas ni ne les mettons dans un bloc, donc où est le problème ? Le calcul te paraît trop grand ?
Euh, si tu ne stocke pas ces UTXO générés, comment tu les utilises ? Meme si on les stocke, pour moi stocker 1UTXO/jour/membre est beaucoup trop, surtout si on compte en plus les UTXO crées par des transactions manuelles. On va se retrouver a stocker plein d’UTXO de 10.02 G1, alors que les UTXO “normales” n’ont pas cette limitation. Autant stocker le timestamp (date+heure) du bloc dans lequel le membre à vider sa “réserve de DU”, ce qui ne fait qui ne fait que quelques UTXO uniquement au moment de la dépense du DU, et aucun entre temps.
Parceque si tu stocke le BlockID tu dois stocker les blocs pour pour savoir dans quels blocs ont étés créés le DU. Or si tu stocke des dates, c’est très simple de savoir combien de “midi” se trouvent entre 2 Sans blocks, je peux savoir qu’entre le 2 mai à 9h et le 6 mai à 16h il y a eu 5 DU, alors que entre le block 102598 et 104219 ?
Outre le timestamp il faut de toute façon stocker un montant, qui sera créditer a chaque bloc DU, car sinon comment fait tu pour garantir que le membres était bien membre tout les jours entre 2 dates t1 et t2 lorsqu’il décide de consommer ses Du entre ceux 2 dates. Un membre pouvant leave et rejoins plusieurs fois d’affiler sur une courte période !
Tu la stocke, mais ça signifie que tous les jours tu stocke un UTXO DU de plus. Si je ne me sert pas de mon DU pendant 2 mois je vais en avoir ~60 ? Et quand je les dépenses, je vais devoir les donner 1 par 1 ?
Peut-être, mais n’oublie pas que la blockchain est une solution extrèmement inéficace en terme de débit comparé a des bases de données centralisées gérées par des banques.
Tous les noeuds stockent les données des membres, donc ce n’est pas compliqué de calculer combien il a obtenu en étant membre. Sinon, on peut faire que quand un membre est exclu/révoqué, une UTXO est automatiquement crée pour vider sa réserve, réglant ainsi le problème, et évite de stocker l’historique de l’état des membres.
Je comprends le point de vue de @cgeek : soit par cette architecture, générer des UTXO ne coute rien et on peut donc utiliser les UTXO pour générer les DU, soit c’est quand même couteux (mais moins cher) et il faut alors le dire
Bitcoin est limité par la taille des blocs qui prennent de la place a stocker, on peut donc augmenter la taille des blocs et gérer plus de transactions. En chiffre, je n’en sais rien encore. Pour fygg, ce n’est pas calculable, car s’il y a un “remplissage” des “blocs” alors on peut créer un nouvel arbre et déplacer une partie du trafic dessus.
C’est curieux que tu sois frileux à l’idée de voir passer 1 million d’UTXO/j, alors que Bitcoin en étant limité fait déjà 200k/j et que tu prétends qu’on puisse être largement plus scalable.
Personnellement ça ne me fait ni chaud ni froid, à la limite c’est plus le fait de devoir fournir inutilement pas mal de preuves qui me gêne un peu plus.
Mais de toute façon, étant donné qu’on stocke déjà tous les membres on peut aisément rajouter une colonne « solde DU » qui ne coûtera quasiment rien. Il suffit ensuite d’ajouter une règle dans la lecture d’un bloc : maximum une transaction consommant un DU avec la même clé au sein du bloc.
C’est pour ça que je propose une façon de faire sans le stocker, ça sera plus proche de fygg, mais aussi n’empechera pas plus tard de ne plus les stocker Autant prendre la solution qui utilise le moins d’informations
Pas forcément, la solution la plus optimale n’est pas nécessairement la meilleure option car elle peut demander plus de temps de développement, de tests et de stabilisation. Ça rejoins ce que Galuel essayait de te dire sur le fil de Fygg, il est important d’intégrer dans nos choix le fait que nous avons un temps limité et des priorités et que donc choisir la solution optimale peut être contre-productif selon les cas.
Je suis bien d’accord, mais la solution proposée ne me semble pas si compliquée à développer. Au contraire, elle à l’avantage d’être entierement explicite, contrairement à une création implicite d’UTXOs.
Le développement se faisant encore sur du temps humain, par des humains dotés d’une certaine connaissance, il faut aussi tenir compte de la complexité liée à l’agrégation de la puissance humaine nécessaire autour de l’idée à réaliser, et des contraintes expérimentales pour l’atteindre.
Par exemple le concorde était l’avion le plus avancé du monde, pas compliqué à réaliser, mais le résultat est qu’il n’a pas percé, et que ce sont les avions mal fichus, mais qui tenaient le marché qui l’ont laissé sur le bord du chemin en tant que curiosité intéressante, et il n’a pas réussi l’objectif de prendre une part de marché conséquente malgré sa supériorité technologique.
Pour cette raison le sage qui veut aller loin étudie la carte, soupèse les contraintes et les recours, et quand il se met en marche il avance d’un pas décidé sachant où il va, avec quoi, et en combien temps il arrivera à destination. De ce fait il ne se laisse pas perturber non plus alors qu’il est en route par des appels qui lui disent “arrête toi, et regarde, on va développer un véhicule permettant d’aller plus vite à ta destination”, il se dit "ce véhicule sera une bonne chose pour les voyageurs du futur, mais pour l’heure, je sais que j’ai ce qu’il faut pour atteindre mon objectif.
L’expérience démontre que le plus souvent c’est la tortue qui avance régulièrement qui arrive, alors que le Lièvre finalement perd la course.
C’est bien beau ce que tu dis, mais là on parle tous du futur, sur quelque chose qui n’a pas encore été développé. C’est bien le but d’en discuter avant et de se mettre d’accord sur la solution à retenir.
Sans blocks, je peux savoir qu’entre le 2 mai à 9h et le 6 mai à 16h il y a eu 5 DU, alors que entre le block 102598 et 104219 ?
