Je n’ai rien à redire ça.
Merci pour toutes vos réponses très constructives, j’oublie l’idée du vote pour le moment, dans l’idée qu’a long terme on pourrait avoir quelque chose comme l’Holocraty.
Je vous invite à réfléchir à ces points :
- Les principes les plus stables, qui durent le plus longtemps, sont aussi les plus profondément cohérents et simples (point qui est semblable au rasoir d’Ockham).
- Le code de la monnaie n’est pas le code de la WoT.
- Le code de la WoT n’est pas le code de Duniter.
- Le code de Duniter n’est pas le protocole (DUP).
Puis :
- Le logiciel étant sous licence libre il est donc de fait transparent de par sa nature même.
- Le seul obstacle qui peut empêcher d’autres êtres humains de réaliser une modification économique non-nuisible est dès lors uniquement l’ignorance. L’ignorance vis à vis du code de la monnaie, du code de la WoT, du code Duniter, du code du protocole.
- Libre ne signifie pas sans auteur, et il est faux et trompeur d’appeler du même nom que l’auteur un objet libre que l’on modifie sans l’accord de l’auteur.
Et donc il s’ensuit que :
- Vouloir changer le code de la monnaie suppose de développer une autre monnaie sous un autre nom.
- Vouloir changer le code de la WoT suppose de développer une autre WoT sous un autre nom.
- Vouloir changer le code de Duniter suppose de développer un autre logiciel sous un autre nom.
- Vouloir changer le code du protocole suppose de développer un autre protocole sous un autre nom.
Et c’est pourquoi pour chaque objet, il existe un nom et qu’il y a dès lors :
- Une licence relative à la monnaie associée à son nom.
- Une licence relative à la WoT associée à son nom.
- Une licence relative à Duniter associée à son nom.
- Une licence relative au protocole associé à son nom.
Les auteurs étant dépositaires du nom, seul le code étant libre, tout changement relatif au même nom est donc in-fine relatif à la légitimité transmise par son auteur.
De sorte qu’il n’y a ainsi pas d’erreur en terme de désignation et d’évolution, et respect du principe de non-nuisance quant à la volonté du créateur.
3 Likes
Est-ce que la v11 du protocole prévoie la possibilité de changer de mot de passe (donc de clé publique) ?
Je me demandais également si ce ne serait pas une bonne idée d’avoir la possibilité de révoquer un certificat que l’on a attribué à quelqu’un. Dans le cas, par exemple, où l’on se rend compte que la personne envers qui on avait confiance ne respecte plus la licence Ğ1…
Cette possibilité existe déjà, la certification n’étant valable que 2 ans, peut ne pas être renouvelée.
Pour le moment non, mais tu peux révoquer ton compte et en faire un nouveau, puis te refaire certifier. Je ne pense pas que ça se fera, puisque ton IdentityUID dépend de la clé publique.
2 Likes
@nanocryk Au tu réfléchi a la réversibilité de chaque état ?
Duniter doit être en capacité a partir d’un état(t), et du dernier bloc, d’effectuer un revert sur ce bloc, c’est a dire d’appliquer le protocole blockchain a l’envers pour se retrouver a l’état (t-1). Cela est nécessaire pour permettre les rooling back (dépilement pour changer de branche suite a une décision de l’algo de résolution de fork).
Et je me demande si les arbres de merkle ne cassent pas cette reversibilité ?
On stocke toujours l’état se trouvant au début de la fenêtre de fork. On peut rollback les relations (transactions) entre des objets de l’état, mais pas tout leur contenu. Cependant si les documents sont stockés dans l’arbre plus longtemps que la fenetre de fork, pas de problème pour rollback. J’essaierai de developper un paragraphe sur ça dans la RFC, ça peut être une propriété très interessante 
Ils n’ont rien a voir la dedans, ils servent juste de preuve de l’état pour les clients.
Ok c’est bien ce qu’il me semblait le protocole v11 n’est pas réversible, il faut donc stocker deux états E(t) et E(t-windowForkSize) ce qui prend plus de mémoire c’est dommage 
Mais si ce n’est pas du aux arbres de merkel qu’est qui fait qu’il n’est pas possible de revert un état, les scripts de tx avancés ?
Ca ne répond pas à ta question ?
Mais on occupe alors beaucoup trop de mémoire pour rien, c’est trop couteux, il vaut mieux stocker 2 états complets a windowForkSize d’intervalle 
Ben non, ma question c’est de savoir qu’est ce qui rend fondamentalement le protocole v11 non réversible, je crois comprendre que c’est le nouveau système de script de tx.
Je parle ici de documents comme celui d’identité, comme expliqué ci-dessous.
Avant, il faudrait déjà vérifier “ce qui le rend fondamentalement non réversible”, et je ne vois pas ce que le système de script viens faire la dedans.
Dans un état les seuls nouvelles informations viennent de la partie transformation, qui est stockée pendant la periode de résolution de fork. La destruction d’informations est un type de transformation qui fait perdre de l’information, mais qui si elle concerne une information qui n’a pas changé depuis le debut de la fenêtre de fork alors ce n’est clairement pas un problème.
Par exemple dans le cas d’une identité révoquée. On peut dire qu’au bout de 6 mois cette identitée revoquée est obliée, ce qui peut par exemple permettre de réutiliser le pseudonyme. Vu la fenêtre de fork est de 100 blocs, soit un peu plus de 8h, on sait que cette suppression (irréversible vu qu’il y a perte d’information) concerne une information qui n’est plus utile depuis longtemps et qui ne changera pas d’un fork à l’autre. On peut donc suivre cette information sans connaitre ses détails. Vu que l’on connait la date de suppression, et on peut aussi compter à rebour le nombre de blocs qui lui reste a vivre, depiler le fork et repiler la nouvelle version, en réincrémentant le compteur.
Comme dit dans un message précédent, je vais essayer d’y consacrer une partie. Mais on ne peux pas encore en juger, vu que ni l’état ni la transformation n’a été définie clairement, ce qui est la prochaine partie de la RFC.
Il serait cependant une bonne idée de voir ensemble ce qui a déjà été proposé dans la RFC pour s’assurer qu’on part sur des bases solides validées, sinon ça voudrait dire écrire cette nouvelle partie avec le risque de devoir la refaire.
Exactement c’est pour cela que j’en parle maintenant, s’il est possible de revert un block v11 se serait fort préférable pour des raisons de performance et de stockage
Je reregarderai la RFC en détail d’ici quelques jours, la je suis sur autre chose
1 Like
Qu’on se comprenne bien : ce qui est important, ce que pour une fenêtre de fork de 100 blocs, il soit possible à partir de n’importe quel état(t) … état(t-100) de revenir à l’état précédent, sans perte de données.
Et je ne vois pas pourquoi tu dis qu’on ne peut pas rollbacker “tout leur contenu” ?
Et puis de non-régression : le protocole v10 permet le revert de bloc dans la fenêtre de fork sans aucune perte d’information, au sens où tout bloc dépilé voit son contenu mis en piscine et donc être réutilisable, je ne vois pas pourquoi le v11 ne pourrait pas le faire.
Je pense qu’il y a plusieurs quiproquos qui traînent dans notre discussion.
Si on ne stocke que le dernier état, hors je proposais de stocker l’état(t) et état(t-100). De plus les données qui ne peuvent pas être rollback sont des données qui ont été supprimées après un temps d’expiration qui, s’il est supérieur à la fenêtre de fork, ne pose aucun problème.
Pendant au moins 100 blocs, tous les documents entrés en blockchain sont référencés dans l’arbre et les noeuds doivent pouvoir les fournir avec leur preuve. Quand une source est complètement consomée, elle a son solde à 0 et si au bout de 100 block elle est toujours à 0, elle est supprimé. Cette suppression peut alors contenir les informations nécéssaires à rollback. Admetons qu’elle soit supprimée, et qu’il y a un fork. Quand on dépile les blocks, on va se retrouver avec l’association account -> (amount=0,index=18). On ne connait plus le script, mais ce n’est pas grave : personne ne peux le dépenser, et le met en output sur une nouvelle transaction pendant l’empilage du fork, alors le script sera a nouveau connu.
Bref, je n’ai jamais dit que qu’on ne pouvait pas rollback. Vous avez tendence à prendre certains de mes phrases en dehors de leur contexte, dans le sens ou je propose plusieurs solutions au problème soulevé et vous ne citez (lisez ?) que la première. Si vous voyez un détail qui ne vous semble pas réversible, donnez le moi. Mais supposer que c’est le cas sans donner ce qui coince, ça ne va pas beaucoup aider.
A nouveau, je précise que j’ai cette reversibilité en tête et que je détaillerais son processus dans la RFC quand je ferais la partie “Block”, mais j’attends d’abord un review de ce qui est déjà fait pour éviter d’avoir à la refaire plusieurs fois.
Mais il n’y a aucun problème avec ça, la notion de rollback n’a de sens que dans la fenêtre de fork. Une donné qui n’existe plus ni n’a aucune utilité que ce soit et qui se trouve hors fenêtre peut légitimement être supprimée.
Qu’est-ce donc que cette phrase ?
Tu es dans ta bulle de réflexion. Tes concepts et nouveautés sont peut être clairs dans ta tête, mais ne le sont pas pour ceux qui les découvrent (par définition). Aussi dans notre tentative de comprendre, on bute dès qu’un élément nous semble incorrect vu qu’on n’a pas tous les éléments.
Tu vois ! Donc ne le prend pas mal. Si tu t’agaces parce que tu crois qu’on rejette tes productions, dis-toi bien que c’est faux car sinon on ne s’embêterait pas à tout lire et à te répondre.
Bref, on attend la suite.
2 Likes
Quand les données sont supprimées, il y a perte d’information qui ne peut pas être rollback. Il faudra que je regarde exactement qu’est ce qui est supprimé et si ça pose problème en cas de fork.
Supprimées dans la fenêtre de fork ? Si oui, ça pose effectivement problème. Pour les transactions, certifications, adhésions.
Si hors fenêtre, il n’y a absolument aucun problème.
Elles seront forcement supprimée dans une fenêtre de fork, vu que celle-ci se déplace. Cependant ce seront des données qui ne seront plus utiles et dont seul d’une partie des information suffi (et qui sera dans le document de suppression de cette information).
Je parle de documents qui sont obsolètes mais qui sont encore stockés dans l’état pour des clients puissent exiger leur récupération. Si par exemple une identité est révoquée, on va quand même garder cette identité (marqué révoquée) dans l’état pendant une certaine période pour que les clients puissent le savoir sans stocker la blockchain. Si on dépile la blockchain en cas de fork, on peut utiliser les informations du document de suppression pour pouvoir suivre cette information (et vérifier les nouveaux blocs). Dans le cas d’une identité révoquée, elle sera supprimée de la nouvelle branche après le meme nombre de blocs, donc ces informations lacunaires suffisent.
Dans le cas d’un compte qui serait tombé à 0, alors n’importe quelle nouvelle transaction ayant comme output ce compte refournirai a nouveau toutes les informations (script complet principalement).
Tout ça, c’est dans le cas où on stocke des documents outdated dans l’état pour les clients. Une autre solution c’est de ne pas les stocker dans l’état mais de dire dans quel block ils se trouvent.
Quand un compte est détruit car tombe à 0, on ne le stocke plus dans l’état, mais on stocke pendant 100 blocs “à tel bloc le compte à été détruit”. Vu qu’on est dans la fenetre de fork, le noeud est obligé de pouvoir fournir cette information. Il doit donc permettre de :
- remonter dans la chaine au bloc désigné
- fournir le document et la preuve qu’il était dans ce block
On pourrait alors supprimer implicitement cette référence après que la fenetre de fork soit passée, et ce comportement peut être réalisé et vérifié indépendament de chaque noeud. Le système de requête deviens aussi plus puissant, puisqu’il permet de récupérer des informations dans les 100 derniers blocs et non pas uniquement le dernier bloc.
Si tu peux faire état(t) -> état(t-1), il n’y a aucune raison de ne pas pouvoir faire état(t) -> état(t-10000) par récursivité, même avec une fenêtre de fork de 100.
Ca veut alors dire que le document de suppression/oubli contient l’intégralité de l’information. Pourquoi pas.
Je vais avoir besoin de formaliser tout ça car sinon on va se mélanger les pinceaux. Je vais donc commencer la rédaction de la partie block, en espérant qu’il n’y aura pas trop de changement dans la première partie du document.