Oui, mais il serait bien que les clients puissent quand même vérifier localement les données fournies par les noeuds. La confiance aveugle dans les données fournies par les noueds ça aboutit à des risques en cas de bugs ou de corruption logicielle (cf l’évènement Cesium post RML11)
Aujourd’hui, Sakia fait cette vérification en sondant le réseau. C’est plutôt lent comme comportement. SI sakia pouvait s’appuyer sur des preuves de merkle permettant de reconstituer des headers, ça serait quand même beaucoup plus propre et robuste je pense. Et même pour des clients comme Silkaj ou Cesium, l’implémentation serait beaucoup plus simple sans nécessiter de requêtes distribuées.
Je parlais d’une proposition qui avait été faite sur un autre fil de supprimer la notion de source DU au niveau du protocole.
Mais sinon il y a une autre solution niveau protocole : forcer la consommation des sources DU dans l’ordre de de leur création. Ainsi il suffirait de stocker un seul BlockId par membre : le BlockId du plus ancien DU non consommé.
Une tx qui consommerai des DU dans le désordre serait considérée comme invalide.
Comme proposé au dessus on peut simplement stocker la date de derniere consommation du DU. Car si on stocke uniquement le BlockID il faut alors les stocker pour pouvoir récupérer les dates et savoir combien de DU ont été créés.
Je ne comprend pas ce que ça change. Les sources DU sont déclarés en input sous le format PubKey:BlockId.
Stocker un timestamp plutôt qu’un BlockId me semble au contraire plus compliqué. Avec un BlockId il est facile de vérifier que le bloc correspondant est bien on block créateur de DU. Les blocks ne sont pas indexé par leur timestamp mais par leur number.
Mais c’est exactement ce dont on parle, non ? Le nœud configuré pour cela stockerait toutes les preuves du compte à suivre, et pourrait les fournir sur demande.
Du coup le client n’a qu’à vérifier ces preuves localement et à vérifier la présence de ce Merkle root comme HEAD sur le réseau.
Mais quitte à faire un changement de protocole, pourquoi ne pas utiliser les arbres à UTXO dont ce fil est le sujet ? Vous trouvez ça trop compliqué ? Je trouve au contraire la solution plutôt simple à implémenter, assez courte en code même.
Ben comme l’avais préconisé inso par le passé je préfèrerai qu’on fasse les choses par étapes, et qu’on s’occupe déjà d’un nouveau protocole qui permet de gérer les changement de règles en soft fork et qui change la pow. Puis qu’on s’occupe de ces points-ci dans l’ordre : Évolutions du protocole vers v11, v12, etc
EDIT : Je crains qu’a vouloir en faire trop d’un coup, on mette trop de temps a stabiliser cette nouvelle version et que la Ğ1 en pâtisse entre temps. Je pense qu’il est préférable de subdiviser les évolutions et plusieurs étapes.
Oui Ok, c’est bien ce dont on parle ici J’insiste pour que la conception de la structure des arbres pour avoir les bonnes preuves en face pour les DU, UTXO, etc. soit utilisable par les clients et pas juste la mise à jour de la blockchain
Le timestamp est stocké dans les données du membre, et la “source DU” est simplement “je prend le DU accumulé”. Tout est décompté, ce qui n’est pas utiliser dans la TX est mis dans une UTXO avec sa clé publique (classique pour le reste) et on stocke dans les données du membre la nouvelle date. Ainsi, on a pas besoin de stocker l’historique des blocks nécéssaire pour “vérifier que le bloc correspondant est bien on block créateur de DU.” Comment le vérifier si on ne stocke plus les blocs ?
Je suis tout à fait d’accord pour utiliser les abres à UTXO. Mais si on pouvait éviter d’avoir autant d’UTXO créés que de membre dans un bloc de DU ça serait pas mal. Ca me semble plus simple d’insérer des infos en blocs uniquement quand le DU est consommé (moins fréquent que 1 fois/jour pour tous les membres).
Il y a quiproquo, je parlais de comment stocker les sources DU de façon très légère en gardant le protocole actuel mais juste en ajoutant une règle qui dit que les sources DU doivent être consommes dans l’ordre de leur création.
La tu parle d’un tout autre paradigme, mais même dans ce cas je ne comprend pas, pourquoi veut tu stocker un timestamp dans les données du membre ?
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
J’insiste pour que la conception de la structure des arbres pour avoir les bonnes preuves en face pour les DU, UTXO, etc. soit utilisable par les clients et pas juste la mise à jour de la blockchain 
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 ?