Environnement de test pour une nouvelle implémentation de Duniter (elixir)

Bonjour,
je fais partie du groupe d’étudiant qui a pour projet le développement d’une implémentation en elixir de duniter. Nous n’en sommes qu’au tout début, mais quand nous allons commencer à tester l’API côté nœud, nous aimerions savoir s’il est approprié qu’on se connecte directement aux nœuds publics de la g1-test avec la nouvelle implémentation (sans doute défectueuse initialement). J’imagine qu’on peut aussi créer une branche séparée de la g1-test dans un réseau complètement isolé, à partir d’un nœud initial déjà synchronisé et utilisant duniter typescript, mais si ça ne pose pas de problème, j’imagine qu’il serait encore mieux d’utiliser directement le réseau g1-test tel quel.

2 Likes

Vous pouvez bien sûr tester vos clients sur l’API de Ğ1Test, mais en lecture seule s’il vous plaît.

Le problème si vous écrivez dans g1-test, c’est qu’on ne saura pas d’où ça vient si il y a un problème.

Merci de votre compréhension.

1 Like

Je crois que le pattern utilisé pour le nonce pseudo aléatoire permet de “signer” en quelque sorte quel outil a forgé tel block.

1 Like

Effectivement. Le nonce peut prendre une valeur quelconque. Mais pour Duniter-TS (ça ne fait pas partie du protocole), le nonce est de forme XYYZZZZZZZZZZZ.

X : numéro du noeud parmi les noeuds appartenant à la même clef publique.
YY : numéro du coeur du noeud sur lequel s’exécute le thread.
ZZZ… : valeur quelconque.

Pour faire les changements de protocole, Duniter a un motif de nonce particulier. Les noeuds ayant installé la nouvelle version produisent des blocs avec une nonce de forme XYY999ZZZZZZZZ. Ceci permet de voir quand une majorité de noeuds a installé la nouvelle version, et quand passer à la nouvelle version des blocs.

De même, les noeuds Elixir pourraient avoir leur propre motif de nonce.

Contrairement à @vit, je pense que les noeuds Elixir peuvent écrire dans GTest, avec quelques précautions :

  • mettre un motif de Nonce, pour savoir quel logiciel écrit quoi,
  • faire en sorte que les noeuds Duniter-TS soient toujours majoritaires. Par ex. que vous mettiez en place 3 noeuds Duniter-TS (3 membres différents) et un Elixir (4e membre). Ainsi :
    • si le noeud Elixir écrit des blocs faux, ils seront écartés par les noeuds Duniter-TS, mais ceci n’empèchera pas la blockchain d’avancer.
    • si le noeud Elixir écrit un bloc valide qui bloque tout le réseau, alors c’est un bug de Duniter ou du protocole, qu’il faut corriger. Le réseau de test est là pour être cassé, que diable !
6 Likes

Concrètement si quelqu’un à plus de 9 nœuds calculant il se passe quoi ? :stuck_out_tongue:

Charles est déjà à mi-chemin.

Mes nœuds utilisent les préfixes 21 et 42.

1 Like

Je suis plutôt de l’avis de @matograine, casser le réseau test peut être intéressant, à condition qu’on arrive à comprendre comment, d’où l’intérêt d’utiliser un schéma dédié pour le nonce !

1 Like

Je suis OK si vous êtes OK, c’était juste pour ne pas voir le réseau test s’effondrer sans prévenir et perdre un temps précieux à retracer les requêtes qui ont causé le problème.

@q18puber, tu as le feu vert pour lire/écrire sur le réseau de test.

Le mieux est tout de même de nous prévenir sur ce forum si vous faîtes des tests critiques et comme précisé plus haut, de bien identifier vos nonces.

Merci à vous et bon tests ! :wink:

6 Likes