Comme je l’ai déjà dit a nano mais je le redit ici : s’il n’y a pas de DHT global alors inévitablement il y aura des “frais de tenu de compte” pour acheter le service de stokage de ses UTXO, je ne crois pas a la philanthropie du dons a très grande échelle !
Ceci étant en monnaie dette nous avons déjà tous des frais de tenue de compte et ça ne choque personne donc ce n’est peut être pas gênant de payer pour faire stocker ses UTXO tant que les frais restent faible devant le DU.
EDIT : je parle évidemment du user lambda qui n’a pas les compétences ni l’envie de passer du temps a apprendre car il consacre déjà son précieux temps de vie a bien d’autres choses, c’est à dire 99% des utilisateurs
On en a déjà discuté. Je suis d’accord pour utiliser des DHT mais pas de manière globale. Dans des fédérations de noeuds, pourquoi pas. Mais de manière générale on perdrait largement l’optimisation énorme que ce protocole permet.
Des gens seront philanthropes et proposeront de stocker les données d’un certains nombre de clients. D’autres pourront essayer de développer un service par dessus et demander des frais. Pourquoi pas. Il y aura de tout, mais c’est en laissant ce choix que ça sera possible. Et si des membres veulent utiliser un DHT global, ils pourront le faire. Mais ce n’est pas à nous de décider à leur place.
Pour le noeud individuel, quid des défauts de fonctionnement ou le noeud crash sur une période plus longue que prévue et qui perd ses UTXO ? Quid de l’utilisateur qui n’a pas prévu de noeud de backup ? Ou dont les backups sont corrompus ?
On voit que ça pose de sacré risque, si la configuration du stockage des UTXO est à la discrétion de l’utilisateur…
Il faut prévoir un système dans le réseau pour pouvoir protéger les humains de leurs erreurs. Surtout pour des systèmes aussi techniques que ça. On est pas dans l’oubli de clé privée la, mais dans une technique bien plus complexe.
C’est pour ça que je parle de fédérations de noeuds pour avoir de la redondance.
Pour un Cesium V11, je vois bien une recommandation de noeuds tenus par des membres connus de la communauté, ainsi qu’un simple scan d’un QRCode permettant de s’inscrire à une instance. Ca sera toujours plus rassurant pour les utilisateurs de savoir que leurs données sont stockées chez des personnes de confiances que dans un truc flou comme “le cloud”. Ca sera aussi bien plus à même de protéger la vie privée des utilisateurs.
Quand il y aura beaucoup de transactions, ça sera difficile de tout stocker et de tracer les transactions, surtout si elles sont complexes et passent par des contrats indépendants de la monnaie, des side chains ou des caneaux de paiements. Je pense pas que beaucoup de monde pourront stocker les données de toutes les blockchains depuis leur création. (et encore, il pourrait être possible de faire des sidechains privées pour des groupes d’utilisateurs)
Avant de penser “fédération” & co, il faut viser simple. J’aimerai donc que l’archivage de données soit implémenté comme un mode de fonctionnement des noeuds. Mais aussi puisse être utilisé comme un mode de synchronisation.
On peut imaginer de superbes architectures, mais il faut y aller par pallier. En première version, avoir des noeuds légers d’un côté et des noeuds d’archivage de l’autre pour la synchronisation, c’est un objectif simple, réalisable et mesurable.
Même la DHT & co, c’est déjà se projeter loin de toute manière.
Plus tard, dans 3 ans, on aura peut être même d’autres idees encore meilleures pour le stockage et sa répartition regarde Duniter, Ya 3 ans, @cgeek s’est projeté sur un objectif atteignable. 3 ans plus tard, tu debarques et tu arrives avec tes Ğidées !
Donc, pas la peine de réfléchir de trop sur cette problématique pour le moment je pense. Regardons bitcoin et ethereum, ça fait des années qu’ils arcbivent tout sans se stresser…
Pourtant leur problème de scalabilité est bien réel, et des solutions sont cherchées. Et pourquoi ils ne sont pas scalable ? Parce que la taille des blocs est limitée, et elle est limitée pour ne pas faire exploser les besoins en stockage, et que n’importe qui puisse en théorie faire tourner un noeud chez lui et vérifier la validité de la blockchain.
Je pense que c’est important de réflechir à cette problématique, car c’est ce qui freinera l’expention de Duniter quand il sera plus utilisé. Et à ce moment là ça ne sera plus possible de passer aussi “facilement” à un meilleur systeme.
Comme dit au dessus, ayons des modules KISS faisant une chose et bien, et que chaque partie soit optionnelle (a part le coeur) pour que chaqu’un puisse utiliser que ce dont il a besoin. Dans la meme logique, il faut que le coeur fasse uniquement le minimum nécéssaire pour faire fonctionner le système.
Bitcoin avec segwit est déjà dans une direction similaire il me semble. Mais ils y vont par pallier. C’est ce qui sera toujours fait dans un projet de logiciel moderne.
Déjà, la blockchain conçue permet de distinguer le stockage de la validité des données. C’est largement suffisant pour savoir que le problème de la répartition du stockage pourra être traité plus tard, et proprement.
Si on veut absolument pouvoir oublier les anciens blocks dès la première version du protocole, il faut alors penser à la redondance des données qui ne repose pas sur l’organisation et les pratiques humaines (c’est trop faillible). Et donc dans ce cas, il y a un trou dans la RFC.
La redondance, ça coûte très cher à développer et c’est très complexe à mettre en œuvre. Je préfère vraiment qu’on évite de s’aventurer sur ce terrain dans un premier temps.
Pour moi il est donc souhaitable dans cette première version de :
garder une taille limite de blocks (qui puisse évoluer automatiquement dans le temps)
avoir un système anti spam pour limiter l’inflation des archives
garder un archivage brut et simple de la chaîne de blocs
Après, si vous trouvez une méthode qui ne repose pas sur les humains pour organiser la redondance des UTXO, pourquoi pas (vous avez pensé à IPFS j’imagine ?)
Il est alors nécessaire et suffisant que la RFC rappelle qu’en dernier recours, l’exploitation d’une archive de la blockchain permet de remonter toutes les données non stockées par le cœur.
Toutefois, c’est un peu en contradiction avec :
Car pour le coup la blockchain contient absolument tout : l’ensemble des UTXO et les preuves depuis le début de la vie de la monnaie. Comparé au protocole actuel, l’archivage est plus coûteux qu’avant car on stocke désormais aussi les preuves.
Ceci dit l’élément clé est bien d’avoir un maximum de validateurs, et devant cet impératif la RFC5 est bel et bien une avancée.
Pourquoi pas, encore faut il pin les données à stoker, ce qui reviens à développer notre système de répartition.
Si je stocke tout l’historique, je n’ai pas besoin de stocker les preuves, puisque je peux les reconstruire avec les données que j’ai sur le disque.
C’est le but principal, et ça amène de nouveaux problèmes que l’on a à résoudre, mais qui permettent de distribuer la charge. C’est justement ce qu’essayent de faire les grosses blockchains, notament Ethereum avec son sharding. Mais en basant toute la logique sur des tokens, on peut potentiellement éxécuter plusieurs partie d’un contrat en parallèle, stocker soit même ses données tout en faisant partie de l’état consensuel
Et d’ailleurs, les transactions chaînées fonctionnent-elles toujours ici ? Car si je dois fournir une preuve pour un arbre encore non existant (principes des transactions chaînées : on peut toutes les mettre ensemble dans un seul bloc), j’ai du mal à voir comment ça fonctionnerait.
Oui mais en dehors de la preuve de travail, donc on peut les élaguer pour le stockage.
Un token créé possède certains champs qui vont changer plus tard. Il a donc un premier hash, qui peut être ciblé comme entrée d’une transaction suivante. Le logiciel sera tout à fait capable de repérer que c’est le même. D’ailleur un token qui est créé et consommé dans un même bloc ne sera pas ajouté dans l’arbre. Enfin certains tokens pourront être marqués “instables” et ne pourront exister que pendant la création d’un bloc, ce qui permettra d’obliger des enchainements de transactions.
C’est ça. Les tokens sont une généralisation des UTXOs qui peuvent representer des UTXOs, des membres, des certifications, des votes, des objets réels, etc.
Ca pourrait permettre pas mal d’optimisations, notament de ne pas passer les preuves sur le réseau à un noeud dont on sait qu’il a déjà les preuves. Ca pourrait faire d’énormes économies dans le cadre d’un DHT.
Cette idée de ne pas stocker les UTXO a-t-elle évolué depuis ? Elle m’intéresse, je pourrais vouloir l’intégrer plus tôt que prévu dans Duniter.
Ce que je comprends, pourrais-tu le confirmer @nanocryk :
pour un nœud “light” qui calculerait des blocs, il n’y a pas besoin de stocker le moindre epochX ni même rootX sauf le Merkle root. Et encore moins stocker les UTXO.
pour qu’un client puisse connaître les preuves nécessaires à la dépense d’une UTXO, seul un nœud (ou un service basé sur un nœud) est capable de lui fournir cette information et ceci nécessite au préalable que le nœud soit configuré pour stocker ces preuves là a minima.
Une fois ces principes posés, peux-tu me dire :
ce qu’il en est des preuves « obsolètes » ? c’est-à-dire des preuves qu’un client aurait récupéré à l’instant t, puis que ces preuves soient périmées par l’impact d’autres UTXO consommées sur le même arbre à un instant t2, en-dehors de la fenêtre de fork ?
Si j’ai bien suivi, étant donné que les epochX ne sont pas stockés sur les nœuds light, la transaction ne passera pas sans que le client ne mette à jour ses preuves, lesquelles auront été maintenues à jour par le nœud configuré pour ça.
concernant les DU, ne penses-tu pas qu’il serait plus intéressant de générer des UTXO « ex-nihilo » plutôt que de gérer un arbre supplémentaire de N feuilles ?
Car si j’ai bien compris l’intérêt de cette idée que tu as eu de ne pas obligé de stocker les UTXO, alors mettre les DU dedans permet d’alléger encore plus ce qu’un nœud doit stocker.
Il faut quand même prendre le temps de faire ça bien. Et rédiger une RFC précise avant toute chose
Je pense qu’au niveau du protocole il y a d’autres priorités a court-terme. Les sources utxo prennent encore très peu de place sur la Ğ1.
C’est les sources DU qui prennent de la place. Mais pour régler ce problèmes des sources DU il y a bien plus simple, il suffit de supprimer la notion de source pour les DU et de stocker plutôt une unique balance DU par membre donc le montant sera réduit a chaque tx qui pioche dedans et créditer a chaque block DU.
EDIT : et encore les sources DU peuvent dés a présent prendre moins de place sans rien changer au protocole, il suffit de modifier le façon de les stocker, dans durs l’ensemble de toutes les sources DU me prennent exactement 630,5 Ko (au bloc #124968)
regarde Duniter, Ya 3 ans, 