Alors mon rôle sera plus périphérique hein, lorsque j’ai dit que je comptais aider nano sur duniter-rs je n’ai pas parler de la partie protocole. Je ne compte pas développer le protocole v11 (clairement pas assez de temps pour ça), en revanche je suis motivé pour développer toute la partie WS2P en Rust pour assurer une communication parfaitement compatible entre les deux implémentations.
Et notamment je serais un peu le relecteur/vérificateur des commit de nano, je poserai des questions et documenterai, et j’aiderai plus sur la structure générale du cœur, l’enrobage en quelque sorte.
1 Like
Ca me va totalement. La création de ce protocole est un plaisir considérable, et si tu t’occupe de la partie WS2P ça m’évitera de partir dans tous les sens.
Ca par contre ça sera important, il faudra que le code soit en peer reviewing.
… j’ai pensé a des bonbons au chocolat, j’ai faim maintenant …
1 Like
Oui dans ce cas ça va, je disais cela pour la partie protocole car il y a beaucoup d’éléments qui doivent s’imbriquer et cela demande concentration.
Après peut-être que vous y arriverez très bien en codant 2h par jour ! Perso je n’ai pas pu, il y avait trop de choses à penser pour les débuts de uCoin/Duniter.
Et puis nanocryck couche tout sur papier contrairement à ma démarche, ça va sûrement bien aider 
Je n’exclue d’ailleurs pas de participer aussi ! Mais plus en mode “vérifications” je pense.
1 Like
Donc nouvelle version du logiciel, donc des logiciels d’anciennes version ne pourront plus utiliser la monnaie : hardfork.
Par exemple dans le protocole V11, tous les opcodes non définis renvoient true, et les versions du système de script non définies donnent une transaction “anyone can spend”. De ce fait a chaque MAJ du protocole ce sont des nouvelles restrictions qui sont rajoutés, et les anciens clients/nodes voient la suite comme valide. Les noeuds outdate ne peuvent par contre pas publier de blocs, puisqu’ils peuvent poster des blocs qui ne sont plus valides avec les nouvelles règles. Impossible alors de causer des forks qui vont plus loin que leur noeud, et qui pourraient perturber le réseau.
Ca, ce sont des soft forks, et ça évite les problèmes de mise à jour de tout le park de noeuds.
1 Like
Si je prends cette définition : https://www.cryptoencyclopedie.com/single-post/Soft-Fork-Hard-Fork-quest-ce-que-cest-
Alors c’est un soft-fork pour duniter-ts, et un hard pour duniter-rs qui ne gère pas le protocole v10.
edit : enfin ceci dit, quand tu prends la définition dans son ensemble la règle c’est qu’il doit être possible d’émettre des blocs d’ancienne version après la nouvelle. Dans ce cas là c’est effectivement “hard”.
Enfin bref, je suis pas pour la bascule genre “on force tout le monde à se mettre à jour” d’un seul coup.
1 Like
“Les anciens blocs validés restent compatibles avec les nouvelles règles, plus strictes.”
C’est donc l’inverse de ce que tu dis.
Dans un softfork, à partir de la mise à jour les anciens noeuds sont susceptibles de proposer des blocs invalides selon les nouvelles règles, par contre les blocs valides selon les nouvelles règles sont valides aussi selon les anciennes, et c’est ça le plus important : que la partie majoritaire du réseau ne créé par des forks chez les autres.
Dans notre cas, il n’a aucun fork si tous les noeuds calculants mettent à jour, et les noeuds mirroir non. Soft fork. Hors au passage à la v11, les noeuds calculants posteront des blocs qui seront invalides pour les v10, du coup c’est un hard fork obligatoire. Mais si mon protocole est assez souple, ça pourrait être l’un des derniers hard fork, et ils ne seraient plus nécéssaires que pour corriger des bugs critiques ou des fonctionnalités bien trop complexes (quoique quand on voit ce que change Segwit en soft fork 
).
1 Like
C’est pas vraiment clair comme définition “plus strict”. Par exemple, la v11 ne me paraît pas “plus stricte” que la v10, elle est surtout très différente.
Enfin bref peu importe le terme qu’on met, il me semble préférable d’avoir une migration qui se déclenche spontanément par résolution de fork plutôt que de faire une “grosse intervention” avec coupure.
Et ne respecte pas les règles précédentes.
Bref, si tous les logiciels sont compatibles avec la v11, alors il y aura hard fork mais aucun split, et du coup ça passe aussi, même si ça va demander du temps et de l’organisation. C’est quelque chose qui ne sera pas réalisable aussi facilement avec une plus grosse masse d’utilisateurs, alors autant le faire rapidement.
Qui limitent les possibilités. Dans Bitcoin, avant l’introduction des time locks, les operateurs étaient des Nop que ne faisaient rien. Maintenant, il peuvent rendrent invalide la transaction. Le protocole est donc plus strict, il accepte moins de choses. Mais pour les anciens noeuds, qui ne connait pas cette restriction, rien ne le choque, toutes les transactions valides dans un bloc sont valides pour lui, et les transactions invalides ne sont pas en bloc donc il ne les vois pas. Il ne va donc pas refuser les blocs et split.
T’es pas plus avancé. Par exemple si l’ancienne version du logiciel autorisait les valeurs [0;10] pour l’objet A et que les nœuds en version supérieure génèrent uniquement des valeurs [0;5], alors ils limitent bien les possibilités mais restent totalement compatibles.
Tu me dirais “mais non c’est pas ça le sens”. Oui c’est bien ce que je dis : c’est pas clair “limiter les possibiltiés”. Faut être plus précis.
On avait déjà eu la conversation sur ce forum avec @Inso, des définitions se contredisaient sur le web.
Je ne vois pas pourquoi tu ne veux pas que ça soit fait spontanément par les nœuds duniter-ts ?
En effet. Les nouvelles règles peuvent même imposer d’être dans cet intervale [0;5], c’est donc des règles plus strictes que celle d’avant. Les anciens noeuds ne vont donc jamais refuser les nouveaux blocs. Soft fork.
Où tu as lu que je disais ça ?
Depuis tout à l’heure je précise juste la distinction softfork/hardfork/split, c’est tout. On sera obligé de faire un hardfork (vu que l’on changement completement la structure), mais je n’ai jamais dis que c’était une mauvaise chose.
Edit : première ligne de l’article Softfork du wiki Bitcoin.
Vous avez pas autre chose a faire que de pinailler sur des définitions ?! on s’en fiche que le passage au protocole v11 puisse être nommé soft fork/hard fork ou tartenpion 
La seule chose qui compte c’est de décider techniquement comment faire la migration sans coupure dans le fonctionnement de la g1, après on n’est pas obliger de trouver une réponse détaillée maintenant, ça se dessinera au fur et a mesure que le nouveau protocole deviendra palpable
Dans cette définition je vois bien qu’il manque au moins 1 cas, celui que justement je souhaite pour Duniter : les nœuds en nouvelle version acceptent malgré tout les blocs v10, contrairement à un softfork ou un hardfork qui les refusent.
Le ğfork, tu vois ?
2 Likes
Le protocole v11 n’acceptera pas les v10 (sauf revocation wrappé), et les noeuds v10 n’accepteront pas les blocks v11. Je vais arrêter là.
C’est pas ce que je dis. Je dis que le logiciel est capable de gérer plusieurs protocoles, d’ailleurs c’est ce qu’on a toujours fait dans Duniter.
Ça évite la rupture, et permet que le protocole supérieur émerge spontanément quand suffisamment de nœuds le supportent.
Les bitcoiners ne s’embêtaient pas autant j’ai l’impression, le logiciel ne gérait qu’un seul protocole à la fois.
1 Like
Si tu te sent de le faire pour duniter-ts alors moi ça me vas 
Je préfère que se soi toi et nano qui restiez référents/responsables du protocole blockchain de chaque implémentation, de mon coté je préfère me spécialiser sur le protocole réseau et le développement d’outils de monitoring/statistiques/historisations (je prévois un nouvel outil qui remplacera g1-monit tout en allant beaucoup plus loin).
1 Like
En fait c’est plus ça, ce n’est même pas un fork, c’est un changement de protocole et de blockchain. Une nouvelle blockchain va être crée (vu qu’il y a un nouveau genesis), et les utilisateurs vont être déplacés dessus.
En pratique faudra donc prévoir une méthode de construction du Genesis à partir de la chaîne V10.
Quand un noeud est mis à jour en v11 , il resync totalement sur un autre noeud v11.
Les nœuds V10 continuent de fonctionner en v10 jusqu’à désactivation.
Par contre pour protéger les utilisateurs dans ces conditions c’est assez compliqué…
1 Like
En effet.
Il applique la partie transformation du bloc, et vérifie qu’il obtient le même résultat.
On pourra faire des tests, mais après le bloc genesis il sera difficile (même très certainement impossible) d’insérer les transactions v10 dans la v11. Je pense qu’on fera de nombreux tests d’“amorçage” sur g1test, et quand tout est bien rodé on lance sur g1. Et si l’amorçage de g1 v11 fonctionne, on passe dessus.
Il y aura forcement une petite interruption, mais il suffira de tester de manière intensive ce mecanisme d’amorçage pour que la coupure soit la plus courte possible, voir indécelable (calcul du dernier bloc v10, vérification, calcul du bloc v11, v11 validé, le bloc v10 suivant est ignoré et on arrête l’écoute).
1 Like
Pour les transactions OK, mais pour les identités, certifications, adhésions et révocations en piscine il faudrait les accepter également. Ce devrait être assez simple, car en conservant la valeur de version on est alors capable d’interpréter le document selon l’un ou l’autre protocole en termes de signature, les données restant les mêmes (donc on peut les transformer en binaire aisément).
Sinon, cela fait jeter aux ordures les documents de toile des 2 derniers mois encore en piscine, ce qui à la louche représente plus de 400 identités et 200 certifications.
Par ailleurs je préconise de programmer à un instant donné la bascule en v11 côté duniter-ts (comme d’habitude), ce qui permet une bascule d’un seul coup et sans coupure. Mais il faudra alors que Cesium, Sakia et autres clients soient déjà prêts et gèrent la production de documents en v10 ou v11 selon la version du bloc courant.
3 Likes