Je pense qu’il faut que pour toute transition état(t+1)=transition(état (t)) il faut prévoir une transition inverse : état(t-1)=transitionInverse(état(t)) . C’est la méthode la plus simple pour garantir un reverse non limité.
2 Likes
En fait @nanocryk depuis le début c’est exactement ça que je nomme réversibilité, pour moi c’était évident mais comme disais @cgeek il y a avait un quiproquo, tu parlais d’une autre forme de reversibilité qui pour moi n’en est pas une car faisant appel a des informations extérieures au bloc a revert.
Il me semble essentiel qu’un bloc puisse être réversible uniquement a partir de ce qui se trouve dans le dit block. A noter que en v10 ce n’est pas strictement le cas, il y a un type “d’événement” qui n’est pas stocké dans les blocs et que Duniter doit deviner a partir d’informations extérieures (ses tables d’index en bdd) : l’expiration d’une certification. On pourrait peut etre en profiter pour modifie ce point 
3 Likes
Any undefined operators will prevent the script from running and mark the transaction as
valid. They cause an anyone can spend behavior.
Ok, donc supposons que je trafique un noeud duniter membre a moi pour qu’il traite un nouveau type d’opérateur inconnu. Je vais pouvoir créer des transactions à opérateurs inconnus que les autres nœuds ne pourront pas traiter mais ils valideront quand même les blocs que j’écris avec ces transactions à opérateurs inconnus ? (Si ce n’est pas ça alors il y a une typo qui m’induit en erreur).
On pourrait arguer que ce n’est pas gênant dans le sens ou je ne pourrais pas dépenser la monnaie injectée dans ces transactions à opérateurs inconnus que seul mon noeud comprend, mais qu’est ce qui m’empêche, puisque j’écris de blocs de temps et temps, de consommer la monnaie de ces transactions à opérateurs inconnus en écrivant d’autres transactions à opérateurs inconnus ayant cette fois ci des output a opérateurs connus ?
Pourquoi ne pas considérer systématiquement la transaction invalide (du point de vue du noeud qui applique le bloc contenant cette transaction j’entends), et donc le bloc qui la contient invalide également ?
Ça imposera que la majorité des nœuds calculant sachent manipuler ces nouveaux opérateurs, mais ça me semble sain. Autant la compatibilité ascendante est une nécessité pour la fiabilité et la durabilité de la monnaie, autant la compatibilité descendante me semble être peu utile et offrir des vecteurs d’attaques dangereux !
When inserted into the state, signatures are no longer needed
Alors pour la réversibilité si, il faut stocker les signatures dans l’état. Sinon on ne peut pas recréer les documents en piscine quand on rool back !
Et que n’importe qui pourra dépenser, il n’a donc aucun interet à en faire. Par exemple sur le réseau Bitcoin dès qu’une transaction anyone can spend passe tu peux être sur que quelqu’un l’a consommé dans le bloc suivant.
Du coup chaque mise à jour est un hard fork. C’est bien dommage vu que c’est plus compliqué à déployer.
Elle ne sont pas stockées dans l’état, mais dans la partie transformation oui. Pas de problème pour reconstruire la piscine du coup.
@nanocryk Ok j’ai relu en détail ta RFC 5 et je t’ai fait des retours et outre ces quelques retours tout les reste me semble bon pour les parties que j’ai compris
J’attends surtout le format bloc, pour lequel je pourrais t’aider nottament je veile sur toute la partie wot du protocole que je maitrise très bien.
Par contre pour la partie scripts de transaction je comprend les grandes lignes mais ça me dépasse un peu, je ne suis donc pas en capacité te de dire s’il y a des problèmes ou pas.
Je pense qu’a un moment ou un autre il faudra qu’on lance un appel a relecteurs extérieurs par exemple depuis le compte duniter team sur mastodon et diaspora (ainsi que par un article sur le site duniter.org).
On pourrait expliquer publiquement, dans cet article, que nous sommes en train de définir de nouvelles spécifications pour le futur protocole de duniter et que nous avons besoins de relecteurs avertis qui maitrise bien les protocoles de crypto-monnaies. On pourrait même proposer de rémunérer ce service de relecture en G1, mais là j’ai l’impression qu’il n’y a que toi qui maitrise vraiment en profondeur le nouveau système de script des transactions et donc on ne peut pas reviewer !
transform: list of document discribing transformations on the previous statefinal_state: state after all transformations
Sauf que attention, certaines transformations ne sont pas causés par des documents mais par l’expiration d’un délai. il s’agit notamment de :
- l 'expiration du membership (champ Excluded en v10)
- l’expiration d’un cert faisant tomber un membre sous sigQty cert (champ Excluded en v10)
- la révocation implicite (champ Excluded en v10)
etc
Il peut y avoir des documents spontanés liés aux procédures automatiques comme celles que tu as cité. Ca sera détaillé plus tard.
1 Like
@nanocryk je propose de définir conceptuellement la transformation comme une liste d’événements.
Chaque événement pouvant être causé soit par un document soit par le fait d’atteindre une certaine date.
Il faudrait alors définir un format spécifique pour chaque événement qui n’est pas causé par un document, ces événements sont :
- l 'expiration du membership (champ Excluded en v10)
- la révocation implicite (champ Excluded en v10)
- l’exclusion d’un membre suite a un passage sous sigQty cert (champ Excluded en v10)
- l’expiration d’une certification (actuellement pas stocké en blockchain v10, ce qui est a mon sens une erreur conceptuelle, l’ensemble des certifications actives faisant parti de l’état courant ).
EDIT : ok, on peut appeler ça document spontané si tu veut, qu’importe le nom 
En fait j’appellais document tout ce qui faisait changer l’état pour coller avec la definition actuelle d’un document. Le terme évenement me semble cependant très bien.
Alors c’est peut être mon coté réseau qui parle, mais pour moi un document c’est tout ce qui transite par le réseau. C’est pour ça qu’au rml10 lorsque j’ai présenté la partie wot du protocole j’ai bien différencier la notion de document de la notion “d’acte” (=évènements). En protocole v10 il y a 5 types de documents wot et 7 types d’actes wot.
3 Likes
@nanocryk alors en théorie si la partie transformation est bien complète il n’y a pas besoin de stocker la partie État dans les blocs. En v10 on ne stocke que la partie transformation.
Ceci étant si la partie État est bien faite ça peut permettre au noeud de ne stocker que les windowForkSize derniers blocs, puis seulement les en-têtes pour les blocs précédents.
Seul les nœuds de type archive ou/et statistiques garderaient l’intégralité des blocs.
En revanche, ça demande de repenser entièrement le process de synchronisation pour éviter que celui ci ne repose que sur les nœuds de type archives ou/et statistiques. Mais ça rendrait la synchro bien plus rapide, il y aurait juste a vérifier la chainabilité des en-têtes du bloc génésis jusqu’au bloc (current-windowForkSize) puis la sync classique ce fait sur les windowForkSize derniers blocs.
3 Likes
Tout à fait d’accord.
2 Likes
Article expliquant le système de script de Bitcoin : http://davidederosa.com/basic-blockchain-programming/bitcoin-script-language-part-one/ . J’ai aussi mis quelques exemples dans la RFC, mais ce n’est peut-être pas suffisant. 
N’hésitez pas à essayer de faire des scripts avec et de me poser des questions si vous ne comprenez pas quelque chose.
1 Like
De la mince expérience que j’ai dans ce domaine, c’était à Tera, où une vie en communauté s’est organisé. Fonctionnement au départ sur un système de prise de décision en Consensus, puis consentement, puis sinon, 2/3 des voix, ceci à vite cessé car bien trop looooong et énergivore comme organisation.
Donc depuis on se base sur les méthodes de Frédéric Lalou qu’il décrit dans son livre “Reinventing Organization”, ou il explique le succès de différente entreprise fonctionnant sur des prises de décision et d’action par sollicitation d’avis: Chacun peu faire se qu’il veut dans l’organisation, même si cela impact la trésorerie, su moment qu’il sollicite (demande) l’avis de 3 personnes au préalables de l’organisation, quelque soit leur fonction.
Ainsi, la personne peut décidé d’enter en action quelque soit la réponse qu’elle a obtenu suite à sa sollicitation d’avis. Cela responsabilise chacun et permet de fluidifier les actions, en partant du principe que tout va s’autogérer à l’amiable entre les gens. Ce sont des entreprises où chaque salarié décide du montant de son salaire par exemple, en toute transparence, et cela semble fonctionner à petite et grande échelle comme son étude de 4 ans l’explique…
Seul condition donc: Demander l’avis à 3 personnes pour chaque décisions. Si ce n’est pas fait, on peut se faire virer ou recevoir de très lourdes sanctions. Ces sollicitation doivent êtres suivit publiquement (blockchain ? 
).
Bref, Duniter n’est pas une entreprise et n’a pas vocation à le devenir, mais cela peut s’appliquer à n’importe quel type d’organisation en soit.
3 Likes
C’est une approche intéressante quand on peut faire confiance aux autres membres de cette entreprise qui vont pour la plupart avoir un intérêt dans le succès de l’entreprise, ce qui n’est hélas pas le cas de potentiels attaquants. De plus ces décisions s’appliquent aux individus ce qui me semble trop léger alors que l’on cherche à définir des paramètres qui feront consensus de manière globale.
J’ai publié un premier essai pour la structure des blocs ainsi que pour l’évènement d’une transaction. Il manque sûrement des choses mais j’aimerais être sur que ça soit OK avant de continuer.
Globalement c’est très clair, j’apprécie vraiment l’effort que tu fais sur ce doc.
Petite remarque : les documents v10, il faut probablement prévoir une date à partir de laquelle ils ne sont plus acceptable dans la blockchain. Sinon, dans 10 ans on pourrait encore en publier, ce serait dommage 
Par exemple :
- 100 ans pour les révocations ( )
- 2 mois pour les certifications, identités, adhésions
2 Likes
However if its invalid and the block is rejected,
a node can query its data to investigate where the problem comes from.
je confirme, ws2p a sont propre système de requête, on peut donc créer sur mesure les requêtes nécessaires afin d’avoir un réseau “intelligent” ou ne transiteront que les informations utiles. D’ailleurs quand la RFC 5 sera mergée j’ouvrirai une RFC pour réfléchir dés a présent aux spec de ws2p v3 qui sera adaptée au protocole blockchain v11. (v3 car on fera une v2 pour duniter-ts 1.7).
Aussi j’ai rerelu toute ta RFC et j’ai signalé quelques manques coté wot (c’est normal hein je sais que tu ne maitrise pas parfaitement le protocole wot ).
Une suggestion : Si la partie transformation est bien totalement réversible alors le noeud peut même ne garder que la partie state de son bloc courant et supprimer les parties states des blocs précédent puisqu’il peut les reconstruire intégralement.
Cependant comme des éléments de states précédent pourrait être demandes par requête ws2p pour s’assurer de la validité d’un bloc douteux par exemple, Il nous faut pour des raisons de performances conserver le state intégral sur les quelques derniers blocs (les 6 derniers par exemple). Ça pourrait être un paramètre du protocole v11 a spécifier dans le tout 1er bloc v11, ainsi que d’autres valeurs comme RememberWindow
1 Like
Merci.
En effet, je pense l’inclure dans la partie transformation
Je proposerais plusieurs idées a ce niveau là, notament de pouvoir request une preuve, les enfants, les parents, etc.
1 Like
Alors en fait je partirai plutôt sur un format générique pouvant encapsuler n’importe qu’elle requête ou même tableau de requêtes, afin de rester dans ce qui fais la force d’internet : le réseau est bête, l’intelligence est en périphérie. Ce serais donc un autre module qui se chargerai de traiter les requêtes puis d’adresser la réponse au module ws2p, par exemple le module DAL puisque toute requête est une demande de données. Si le noeud n’a pas la donnée, il peut éventuellement la reconstruire mais si c’est couteux en calcul il doit pouvoir répondre “demande a un autre”, quitte a demander aux nœuds d’archive en dernier ressort, après tout il serviront aussi a ça. je pense d’ailleurs proposer un nouveau format de endpoint ws2p ou le noeud indiquera son niveau de rétention des données (on peut définir plusieurs niveaux entre l’extrême archive tout depuis le début et l’autre extrême noeud ultra-light ne garde que l’état courant).