G1-test dans les choux ? État monnaie

Networks Ğ1-Test
644

Oui, on est bien d’accord… d’ailleurs c’est exactement ce que j’avais écrit au moment où j’ai monté mes 6 comptes. :slight_smile:

1 Like
645

Par contre ça n’a pas l’air de repartir, pourrais-tu resynchroniser au moins l’un parmi tes nœuds 2, 4, 5 ou 6 ?

646

J’ai lancé une synchro sur le 2, mais il en est à 18 %. Je pense que je vais lancer une synchro sur les 4 et le copierai le premier qui gagne dans le répertoire des autres…

647

Et effectivement, je vois avec surprise que mes nœuds contribuent beaucoup à la blockchain… la dernière fois que j’avais regardé (probablement il y a 1 semaine ou 2), ils ne contribuaient que très peu (je les ai mis en CPU à 1 %), ce qui me rassurait pas mal. Essayons d’équilibrer tout ça. Je certifierai tes comptes dès que la blockchain est repartie.

648

C’est à partir du 3/4 décembre que mes nœuds ont commencé à calculer plus de blocs et à vraiment peser. Je n’ai rien touché de mon côté, peut-être que parmi vous certains ont diminué leur puissance CPU, ce qui pourrait expliquer la différence ?

Dans tous les cas, la meilleure tactique est peut-être de ne laisser que 2 nœuds tourner par personne au max, tout en ayant d’autres identités prêtes à prendre le relais en cas de pépin. Du coup, je ne vais probablement pas laisser tourner mes 6 nœuds à nouveau, mais je garde mes 6 identités.

PS : j’ai certifié cgeek-5 avec mes 6 identités mais pour ça il faut qu’il y ait un bloc… :smiley:

1 Like
649

Bon, j’ai redémarré mon serveur g1-test-dev.pini.fr, mais en repartant from scratch. J’espère que la conf est correcte. J’ai un peu oublié depuis la dernière fois…

1 Like
650

La blockchain est repartie, mais il n’y a plus que cgeek et moi qui la faisons tourner, elle a cavalé tellement vite à certains moments hier (il y a des moments où on était à plus d’une transaction par seconde…) qu’ on en a largués en route.
Du coup @vit et @Pini ainsi que g1-test.duniter.org (je ne sais plus qui le maintient) ce serait chouette si vous pouviez faire une resynchro. @Moul si tu es dans le coin tu peux aussi resynchro.

C’est d’autant plus important pour g1-test.duniter.org que le mini-client de cgeek l’utilise par défaut (je viens de voir dans le code qu’il est possible de le changer par la variable d’environnement DUNITER_NODE, bien joué ! :smiley: ), et donc certains cron qui ont pu tourner depuis hier vont potentiellement passer à la trappe.

(@matograine ça te dirait pas de monter un nœud, avec au moins une de tes identités ? :smiley: )

651

Que peut-on faire pour éviter que ça se reproduise trop souvent. Parce que bon… resynchroniser tous les jours, ça risque d’être un peu lourd :slight_smile:

Synchro en cours sur mon noeud. Si ça passe comme hier ça devrait prendre moins de 2h :crossed_fingers:

652

Mon nœud g1-test n’a plus de support physique fonctionnel pour tourner. La g1-test devra faire sans mon nœud le temps de retrouver un support physique fonctionnel pour l’héberger.

1 Like
653

C’est assez simple : moins on a de participants sur gtest, plus ça arrivera souvent. En faisant en sorte qu’on soit au moins 4 ou 5 à avoir des nœuds, on limite le nombre d’occurrences où la blockchain se coince.

654

C’est bon, je suis de retour dans la course au blocs ! :sweat_smile:

655

C’est moi, je viens de la lancer. Compter environ 12h de synchro :crazy_face:

edit : synchro terminée.

1 Like
656

Il y a un souci sur la version de dev avec la gestion des forks. Voici ce que je trouve dans mes logs pour le fork de ce matin :

2021-12-28T09:05:11+00:00 - info: Block resolution: 0 potential blocks after current#873878...
2021-12-28T09:05:11+00:00 - info: Fork resolution: 1 potential block(s) found...
2021-12-28T09:05:11+00:00 - info: Fork resolution: 1 potential suite(s) found...
2021-12-28T09:05:11+00:00 - info: Fork resolution: HEAD = block#873878
2021-12-28T09:05:11+00:00 - info: Fork resolution: suite 1/1 (-> #873886-0000F9) revert to fork point block#873877
2021-12-28T09:05:11+00:00 - info: Fork resolution: suite 1/1 REFUSED block#873878: Try to apply non genesis block on empty blockchain
2021-12-28T09:05:11+00:00 - error: Unhandled rejection: Error: ruleNumber
2021-12-28T09:05:11+00:00 - error: Error: ruleNumber
    at Function.checkBlock (/duniter/app/lib/blockchain/DuniterBlockchain.js:62:19)
    at process._tickCallback (internal/process/next_tick.js:68:7)
2021-12-28T09:08:00+00:00 - info: SIDE Block #873887-0005D459 added to the blockchain in 1 ms
2021-12-28T09:08:00+00:00 - info: Block resolution: 2 potential blocks after current#873877...
2021-12-28T09:08:00+00:00 - error: Error: ruleNumber
    at Function.checkBlock (/duniter/app/lib/blockchain/DuniterBlockchain.js:62:19)
    at process._tickCallback (internal/process/next_tick.js:68:7)
2021-12-28T09:08:00+00:00 - error: Error: ruleNumber
    at Function.checkBlock (/duniter/app/lib/blockchain/DuniterBlockchain.js:62:19)
    at process._tickCallback (internal/process/next_tick.js:68:7)
2021-12-28T09:08:00+00:00 - info: Fork resolution: 2 potential block(s) found...
2021-12-28T09:08:01+00:00 - info: Fork resolution: block #873878-000179BA is known as incorrect. Skipping.
2021-12-28T09:08:35+00:00 - info: SIDE Block #873888-00000B10 added to the blockchain in 14 ms
2021-12-28T09:08:35+00:00 - info: Block resolution: 2 potential blocks after current#873877...
2021-12-28T09:08:35+00:00 - error: Error: ruleNumber
    at Function.checkBlock (/duniter/app/lib/blockchain/DuniterBlockchain.js:62:19)
    at process._tickCallback (internal/process/next_tick.js:68:7)
2021-12-28T09:08:35+00:00 - error: Error: ruleNumber
    at Function.checkBlock (/duniter/app/lib/blockchain/DuniterBlockchain.js:62:19)
    at process._tickCallback (internal/process/next_tick.js:68:7)
2021-12-28T09:08:35+00:00 - info: Fork resolution: 3 potential block(s) found...
2021-12-28T09:08:35+00:00 - info: Fork resolution: block #873878-000179BA is known as incorrect. Skipping.
2021-12-28T09:08:57+00:00 - info: WS2P HG3eZ9dNp9cjdW1SfhaLiZPQ1ZnYTcywSF5LrgfPPXKi: new incoming connection from 172.18.0.10:37962!
2021-12-28T09:09:07+00:00 - info: SIDE Block #873889-0002E990 added to the blockchain in 3 ms
2021-12-28T09:09:07+00:00 - info: Block resolution: 2 potential blocks after current#873877...
2021-12-28T09:09:07+00:00 - error: Error: ruleNumber
    at Function.checkBlock (/duniter/app/lib/blockchain/DuniterBlockchain.js:62:19)
    at process._tickCallback (internal/process/next_tick.js:68:7)
2021-12-28T09:09:07+00:00 - error: Error: ruleNumber
    at Function.checkBlock (/duniter/app/lib/blockchain/DuniterBlockchain.js:62:19)
    at process._tickCallback (internal/process/next_tick.js:68:7)
2021-12-28T09:09:07+00:00 - info: Fork resolution: 4 potential block(s) found...
2021-12-28T09:09:07+00:00 - info: Fork resolution: block #873878-000179BA is known as incorrect. Skipping.
2021-12-28T09:09:27+00:00 - info: SIDE Block #873890-0001FCE0 added to the blockchain in 1 ms
2021-12-28T09:09:27+00:00 - info: Block resolution: 2 potential blocks after current#873877...
2021-12-28T09:09:27+00:00 - error: Error: ruleNumber
    at Function.checkBlock (/duniter/app/lib/blockchain/DuniterBlockchain.js:62:19)
    at process._tickCallback (internal/process/next_tick.js:68:7)
2021-12-28T09:09:27+00:00 - error: Error: ruleNumber
    at Function.checkBlock (/duniter/app/lib/blockchain/DuniterBlockchain.js:62:19)
    at process._tickCallback (internal/process/next_tick.js:68:7)
2021-12-28T09:09:27+00:00 - info: Fork resolution: 5 potential block(s) found...
2021-12-28T09:09:27+00:00 - info: Fork resolution: block #873878-000179BA is known as incorrect. Skipping.

Ça semble ne jamais pouvoir se résoudre. Une idée de ce qu’il se passe, et de comment ça pourrait être corrigé ?

1 Like
657

Nouveau fork cette nuit et mêmes erreurs ce matin. Ça va vite devenir ingérable s’il faut que je resynchronise tous les jours :confused:

658

Nous sommes désormais au moins deux (jytou et moi-même) à pouvoir reprendre la main sur la ĞT en cas de nécessité. Donc ce n’est pas gênant si tu préfères retirer ton nœud désormais.

Je ne compte pas maintenir la version de la branche dev, sauf gros problème sur la Ğ1. L’énergie et le temps seront investis dans Duniter V2S.

659

Dans la lignée de mon message ci-dessus, et avec le lancement imminent d’une ĞDev Duniter V2S, je pense que l’on peut éteindre la ĞT Duniter V1. Cette monnaie n’a plus d’intérêt, étant donné que tout l’effort est mis sur Duniter V2S.

J’ai d’ailleurs déjà éteint mes 2 nœuds ĞT cette semaine, à mon avis vous pouvez faire de même.

1 Like
660

Salut !
C’est drole que tu dise cela, car hier j’ai justement utilisé la GTest, pour tester la v1.9.1 du Pod Cesium+ !

Plus généralement, je penses qu’il faudra tester la migration vers Duniter v2s, non ?
Ca risque quand même d’etre mins long qu’avec la G1, non ?

D’ailleurs, il a un gros sujet sur la migration des clefs vers le nouveaux comptes… comment gérer cela ?

661

Mais qu’utilises-tu sur la ĞT qui ne serait déjà disponible sur la Ğ1 ?

Sauf à vouloir tester les documents de WoT sans utiliser sa vraie clé membre, il me semble que tout est déjà faisable dans la Ğ1. Et même pour ces documents de WoT, il y en a déjà largement assez sur la monnaie de prod. De plus, l’hétérogénéité des données est censée y être plus élevée vu le nombre d’utilisateurs.

Pour la durée de synchro, il suffit sur la Ğ1 de limiter celle-ci à un certain nombre de blocs.

Sur la migration des clefs, Ğ1 ou ĞT, il me semble qu’il n’y a pas grand-chose à faire justement : les clefs sont réutilisées telles quelles, il y a toutefois un travail côté wallets pour permettre de parler le « langage » Substrate avec la notion d’adresses (c’est un format qui associe à une clé publique une adresse, dérivable à tout moment par n’importe qui).

Je peux me tromper, mais je ne vois pas ce qui poserait problème :thinking:

1 Like
662

Je pense qu’il veut parler des format de génération de clés salt/password contre mnémonique non ?

Ça fait plusieurs semaines que j’y pense, je ne vois pas de moyen simple de faire si on est tous d’accord pour passer au mnémonique.

On pourrait n’autoriser que les comptes membres dans le client, avec une UX pour ne pas renouveler son adhésion mais plutôt la renouveler sur un nouveau compte dérivé mnémo.
Pour les portefeuilles on peut interdire l’import mais permettre le transfert vers un portefeuille dérivé local.

Pour le moment j’ai juste désactivé les salt/password en attendant qu’on se mette d’accords sur une marche à suivre.

Je pense justement que Elois compte sur e fait qu’on ai plein de Fake clé membre en GT pour tester les comportements, et aussi que les durées y sont compressés.

Il a calqué certains paramètres de la gdev sur ceux de la GT en prévision de la migrer en premier.
Ça fait partie de sa roadmap.

663

Perso je suis toujours ceinture et bretelle sur tout mes projets (certain diront parano :wink: ).
Mais je pense que à part renouveller les certifs, mon noeud gtest n’est pas une charge à maintenir sur mon serveur perso. Donc je garderai tout en attendant la migration, sait-on jamais ce qui peut arriver, un Ǧproblème sur la Ğ1 :wink: ?

Pour la conversion des compte Ğ1, c’est déjà géré dans Tikka comme ceci :

  • On rentre nos identifiants qui crée une seed.
  • Je crée une keypair V2S à partir de la seed, en ED25519.
  • La clef privée est stockée chiffrée et protégée par un mot de passe, comme les comptes V2S.
  • La seule différence est SR25519 pour les nouvelles clefs V2S et ED25519 pour les clefs issues de Ğ1.

Les identifiants ne servent que comme le mnémonique pour réimporter son compte.

4 Likes