OK c’est donc bien une file. Et donc, quid de l’élagage ? Conserve-t-on toutes les epoch ad vitam aeternam ?
D’accord mais donc, réutilise-t-on la case ainsi vidée ?
OK je vois, on stocke uniquement les epoch et leur enchaînement, pas le détails des epoch qui doit lui être fourni. Toutefois celui qui conserve tous les blocs a forcément la vue complète de toutes les preuves et de tous les UTXO (même s’il ne les enregistre pas pour les exploiter, si besoin il pourrait aller vérifier).
Bien vu !
Yes
Sur le fond je dois dire que je trouve cette solution très élégante, et le découplage induit promet effectivement de belles perspectives d’optimisation. Même les clients vont être contents au final. Les nœuds se spécialisent dans leur rôle de validateurs, et n’ont plus besoin d’être requêtés pour connaître l’état des données.
Bien joué @nanocryk, je vais suivre tout cela d’un peu plus près.
Non, seulement l’unique Merkle root, les “epoch” étant contenu dans les preuves fournies avec la transaction.
Je veux juste suivre l’état de “mes comptes”, je fais tourner un noeud et je ne stocke que les tokens qui me concernent, tout en pouvant vérifier intégralement la blockchain et sa validité.
Je veux être calculateur, je stocke des transaction dans la mempool.
Je veux proposer le stockage des tokens pour des clients qui n’ont pas les connaissances pour le faire, je peux, et uniquement pour eux.
J’ai le choix de stocker ce que je veux, sans besoin de faire confiance a personne.
Merci J’espère que tu vas aimer la généralisation de ce concept qui est donnée dans la RFC et qui permet d’optimiser plus que des UTXOs
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.
J’espère que tu vas aimer la généralisation de ce concept qui est donnée dans la RFC et qui permet d’optimiser plus que des UTXOs 
regarde Duniter, Ya 3 ans,