Historique des offenses

query MyQuery {
  events(where: {pallet_eq: "Offences"}, orderBy: block_height_ASC) {
    id
    pallet
    name
    block {
      height
    }
  }
}
  • 104632 vit est mis offline par la blockchain
  • 115548 vit est mis offline par la blockchain
  • 115975 vit est mis offline par la blockchain
  • 142731 vit est mis offline par la blockchain
2 Likes

Ah super ! J’avais vu aussi que la blockchain était ralentie quand vous étiez tous les deux auteurs, j’imagine que @vit a eu un soucis de conf.

Mais je pensais que nous n’avions pas implémenté les offences (#26) ?

Effectivement, on a oublié d’associer la MR !161 à ce ticket.

1 Like

Et bah c’est une bonne nouvelle alors :slight_smile:

1 Like

Oui, c’est une bonne nouvelle d’avoir un @bgallois sur Duniter :smiley:

1 Like

Je me suis rendu compte que j’envoyais mes commandes localhost sur mon noeud RPC… :blush:

J’ ai refait un rotate_keys(), setSessionKeys() et go_online() avec le nœud Validator ce matin.

A suivre…

PS: c’est pas bô de balancer les copains en public sur le forum ! :rofl:

1 Like

Je pense que la blockchain va encore te virer :stuck_out_tongue:

Mais euuuuuh ! Qu’est-ce que j’ai encore fait ? :sweat_smile:

Mon identité 58 était dans la liste des

authorityMembers.incomingAuthorities: Vec<u32>

[
58
]

Et maintenant je ne suis plus dans les autorités…

Voici mon docker compose pour le RPC et le Validator. Je suis à jour avec un bon ping dans Telemetry pour mes deux nœuds.

La particularité de mon container docker du nœud validator est d’écouter sur les ports 30334 et 9945 :

  # ===== RPC =====
  duniter_rpc:
    image: "{{ duniter_v2s_rpc_image }}"
    restart: unless-stopped
    ports:
      # Prometheus endpoint
      - 9615:9615
      # rpc via http
#      - 9933:9933
      # rpc via websocket
      - 9944:9944
      # p2p
      - 30333:30333
    volumes:
      - "{{ duniter_v2s_rpc_data_path }}:/var/lib/duniter"
    environment:
      - DUNITER_CHAIN_NAME=gdev
      - DUNITER_NODE_NAME=vit-rpc

  # ===== VALIDATOR =====
  duniter_validator:
    image: "{{ duniter_v2s_validator_image }}"
    restart: unless-stopped
    ports:
      # Prometheus endpoint
      - 9616:9615
      # rpc via http
#      - 9933:9933
      # rpc via websocket
      - 127.0.0.1:9945:9944
      # p2p
      - 30334:30333
    volumes:
      - "{{ duniter_v2s_validator_data_path }}:/var/lib/duniter"
    environment:
      - DUNITER_CHAIN_NAME=gdev
      - DUNITER_VALIDATOR=true
      - DUNITER_NODE_NAME=vit-validator
      - "DUNITER_PUBLIC_ADDR=/dns/vit.fdn.org/tcp/30334"
      - DUNITER_LISTEN_ADDR=/ip4/0.0.0.0/tcp/30333

Ta configuration semble correcte, hypothèses :

  • le port 30334 n’est pas forwardé par ta box ?
  • vit-validator ne possède pas les bonnes session_keys (le plus probable)

Le nœud validateur semble bien connecté :

9 pairs sur le réseau dans la télémétrie

Donc je pense que le problème est ailleurs. Tu peux demander à ton nœud s’il a bien les session keys privées associées aux clé publiques que tu lui donnes en argument :

(il faut se connecter à son nœud validateur avec l’API RPC unsafe)

Je viens de corriger mon code de split de setSessionKeys() qui envoyait de la m… comme clefs de sessions.

Vérification de la clef privée en local OK :

Mes clefs publiques de session corrigées vu par polkadot.js :

session.nextKeys: Option<GdevRuntimeOpaqueSessionKeys>
{
  grandpa: 0x1dbd7d0df7b9f4e047d9920577ddae09a0d5f98fff720332755c57d0119dec05
  babe: 0x72ad4a7f262328d9b61fe1cf7557e51dead34ad0b314ee606ba9452342a5fd67
  imOnline: 0x141f823bc1037ccc733b287ccb064d4babb1548fefe4b06f9a4c946e3b384c65
  authorityDiscovery: 0x3cc0c34fda7f0de5339312ba5de70fdd7a9f372b80e3a235ef6707acd09a8d2e
}

Cela devrait fonctionner maintenant !

Je n’ai pas l’impression, pourtant tu es bien online.

Mes logs :

home_duniter_validator.1.iqza64vq4b0v@z68-gen3    | 2023-11-28 15:07:54 ♻️  Reorg on #131202,0xaa78…354b to #131202,0x3e12…822e, common ancestor #131201,0x1965…abea    
home_duniter_validator.1.iqza64vq4b0v@z68-gen3    | 2023-11-28 15:07:54 ✨ Imported #131202 (0x3e12…822e)    
home_duniter_validator.1.iqza64vq4b0v@z68-gen3    | 2023-11-28 15:07:56 💤 Idle (9 peers), best: #131202 (0x3e12…822e), finalized #104261 (0x374f…a162), ⬇ 2.1kiB/s ⬆ 1.9kiB/s    
home_duniter_validator.1.iqza64vq4b0v@z68-gen3    | 2023-11-28 15:08:00 ✨ Imported #131203 (0xc014…6089)    
home_duniter_validator.1.iqza64vq4b0v@z68-gen3    | 2023-11-28 15:08:01 💤 Idle (9 peers), best: #131203 (0xc014…6089), finalized #104261 (0x374f…a162), ⬇ 1.8kiB/s ⬆ 2.5kiB/s    
home_duniter_validator.1.iqza64vq4b0v@z68-gen3    | 2023-11-28 15:08:06 ✨ Imported #131204 (0x1b4e…7584)    
home_duniter_validator.1.iqza64vq4b0v@z68-gen3    | 2023-11-28 15:08:06 💤 Idle (9 peers), best: #131204 (0x1b4e…7584), finalized #104261 (0x374f…a162), ⬇ 1.8kiB/s ⬆ 1.5kiB/s    
home_duniter_validator.1.iqza64vq4b0v@z68-gen3    | 2023-11-28 15:08:11 💤 Idle (9 peers), best: #131204 (0x1b4e…7584), finalized #104261 (0x374f…a162), ⬇ 0.9kiB/s ⬆ 1.0kiB/s    
home_duniter_validator.1.iqza64vq4b0v@z68-gen3    | 2023-11-28 15:08:12 ✨ Imported #131205 (0xccd3…7587)

Tu peux comparer le trousseau de session hexadecimal avec ce que te génère :

docker run --rm -it duniter/duniter-v2s-gdev -- key generate-session-keys --chain=gdev

Tu trouveras le mnémonique dans l’un des 4 fichiers présents dans /var/lib/duniter/chains/gdev/keystore/ . Ou alors c’est que justement ton nœud ne possède pas les session_keys dans son dossier keystore/.

J’ai bien les 4 clef publiques en fichiers dans le dossier keystore, avec des mnemonics dans les fichiers :

vit@z68-gen3:~/duniter_validator$ ls -l chains/gdev/keystore/
total 16
-rw------- 1 vit vit 84 nov.  27 11:17 617564693cc0c34fda7f0de5339312ba5de70fdd7a9f372b80e3a235ef6707acd09a8d2e
-rw------- 1 vit vit 81 nov.  27 11:17 6261626572ad4a7f262328d9b61fe1cf7557e51dead34ad0b314ee606ba9452342a5fd67
-rw------- 1 vit vit 83 nov.  27 11:17 6772616e1dbd7d0df7b9f4e047d9920577ddae09a0d5f98fff720332755c57d0119dec05
-rw------- 1 vit vit 77 nov.  27 11:17 696d6f6e141f823bc1037ccc733b287ccb064d4babb1548fefe4b06f9a4c946e3b384c65

EDIT : je génère des blocs !!! depuis que j’ai rejoint les autorités dans le bloc 131,525 (je ne sais pas pourquoi j’étais dans la liste des autorités du storage et ne faisait rien avant…). Par contre les événements sont cohérents avec la chronologie des événements.

2 Likes

Oui je t’ai bien vu dans les autorités pendant nos échanges, j’ai du mal à comprendre. Peut-être que @HugoTrentesaux ou @bgallois auront une idée :face_with_raised_eyebrow:

1 Like

Vous parlez du storage babe.authorities() ? Ou authorityMembers.onlineAuthorities() ? Sur un nœud archive, on peut regarder la valeur du storage à n’importe quel bloc par son hash.

Dans authorityMembers.

Tu veux dire dans authorityMembers.members() ? J’ai l’impression qu’il y a des problèmes avec ce champ, je regarde ça en ce moment.

Non, comme tu l’as dit authorityMembers.onlineAuthorities().