- Je peux joindre le certifié par au moins 2 canaux (sms, email, xmpp, matrix…).
Je t’envoie mon tel par MP.
- J’ai noté le style de configuration (packet debian, docker-compose…) qu’utilise le certifié pour son noeud (et cette configuration n’a pas de faille connue, notament n’exposer pas l’api unsafe publiquement)
Voici mon fichier de config
# Sets the name of the node.
# This should be a unique identifier for your node within the network.
DUNITER_NODE_NAME=Matograine
# Specifies the blockchain network to connect to.
DUNITER_CHAIN_NAME=gdev
# Defines the address and port for node communication.
# The format is /ip4/[IP address]/tcp/[port]/[protocol].
# If SMITH NODE: `/ip4/0.0.0.0/tcp/<port>` and `/ip6/[::]/tcp/<port>`. Otherwise: `/ip4/0.0.0.0/tcp/<port>/ws` and `/ip6/[::]/tcp/<port>/ws`.
# ICI il faudrait des exemples commentés, je ne sais pas quelle est la valeur de <port>.
DUNITER_LISTEN_ADDR=/ip6/::/tcp/30333
#OLD : DUNITER_LISTEN_ADDR=/ip4/0.0.0.0/tcp/9944/ws
# adresse du endpoint p2p
DUNITER_PUBLIC_ADDR=/dns/gdev.matograine.fr/tcp/30333
# Specify browser origins allowed to access the HTTP & WS RPC servers.
# A comma-separated list with no space of origins.
# Value of `all` will disable origin validation. Default is to allow localhost and
#<https://polkadot.js.org> origins.
# Default: "http://localhost:*,http://127.0.0.1:*,https://localhost:*,https://127.0.0.1:*,https://polkadot.js.org"
#DUNITER_RPC_CORS=http://localhost:*,http://127.0.0.1:*,https://localhost:*,https://127.0.0.1:*,https://polkadot.js.org
DUNITER_RPC_CORS=http://localhost:*,http://127.0.0.1:*,https://localhost:*,https://127.0.0.1:*
# Configures the pruning profile to manage how old blockchain data is stored.
# This setting can only be set on the first creation of the database.
# Options:
# - 'archive': Keep the state of all blocks.
# - 'archive-canonical': Keep only the state of finalized blocks.
# - [number]: Keep the state of the last specified number of finalized blocks.
# Default: 256 for a balanced pruning strategy.
DUNITER_PRUNING_PROFILE=256
# Sets the directory for storing Duniter data.
# This should be a writable path on your system by the duniter user where the node can store its data.
# Default: /home/duniter/.local/share/duniter
BASE_PATH=/home/duniter/.local/share/duniter
# URL for the Oracle RPC server.
# This should point to the RPC endpoint that the oracle will use to communicate with the blockchain.
# Default: ws://127.0.0.1:9944 for a local WebSocket RPC server.
ORACLE_RPC_URL=ws://127.0.0.1:9944
# Determines the log level for the Oracle.
# Options include 'error', 'warn', 'info', 'debug', 'trace'.
# 'info' is a good default that provides useful runtime information without too much detail.
# Default: info
ORACLE_LOG_LEVEL=info
- Le certifié s’est engagé auprès de moi à m’informer de tout changement significatif de sa config (pour pouvoir transmettre les infos de manière ciblée si problème)
Je m’y engage
- J’ai vérifié que le certifié connait les délais de passage en ligne/hors ligne du validateur.
Pas vraiment, non. j’ai dû faire des recherches. Je sais qu’il y a une notion de Epoch et de Session, que ces deux périodes ont la même durée. Je vois dans PolkadotJS que une Epoch (donc une Session) dure une heure.
Je sais que, une fois que je serai membre de la TdC Forgeron :
- je devrai appliquer un rotate-keys sur mon noeud (je ne sais pas s’il est besoin de le refaire régulièrement)
- je devrai faire un appel set-session-keys pour déclarer une clef de session. Je devrai refaire ceci au plus toutes les trois semaines (je pense donc me mettre en place un rappel et le refaire toutes les semaines)
- je devrai faire un appel go-online. Après cet appel, ma clef de session sera candidate à la création de blocs à partir du début de la session suivante.
- si je veux déconnecter mon noeud, je dois faire un appel go-offline. Cet appel sera pris en compte à partir de la fin de la session courante, donc je ne pourrai pas déconnecter mon noeud immédiatement.
vocabulaire
schéma du parcours membre
Ceci mériterait d’être précisé dans la licence.
- J’ai vérifié que le certifié savait où consulter les règles détaillées de la TdC forgeron.
- J’ai vérifié avec le certifié qu’il connait les risques pour le réseau d’être offline sans l’avoir annoncé, et qu’il se considère en mesure d’assurer un uptime suffisant.
Justement, parlons-en. Il me semble que Polkadot prévoit des amendes dans le cas de mauvais comportements des noeuds. Mais les mauvais compotements que je vois listés résulteraient d’un bug dans le code ou d’une attaque, donc ce serait à corriger pour toute le monde, et je ne prévois pas d’attaquer le réseau V2.
Ceci est-il en place ?
Par ailleurs, j’ai compris que si je suis online (j’ai fait un go_online) mais que je ne crée pas de blocs, je sais qu’il y a une sanction qui m’empechera de calculer, mais je ne sais pas :
- s’il s’agit d’un simple go_offline forcé ou d’une exclusion de la TdC forgeron
- si cette sanction s’applique immédiatement
- à partir de combien de blocs ‘manqués’ cette sanction s’applique
- si cette sanction est assortie d’une amende
y a-t-il autre chose ?
Il serait pertinent d’ajouter ceci dans la licence.