Sauf erreur « Pallet » n’est jamais défini. 
Sinon ça va, ça me semble assez clair. 
1 Like
Je viens d’ajouter “Pallet”, ainsi que “Dispatch class”
2 Likes
Tu avais à un moment parlé de la différence entre session et epoch, mais je ne me souviens plus. Epoch n’apparaît pas dans la liste.
Je viens de rajouter « Epoch », et de modifier « Session » pour expliquer le lien.
1 Like
Si tu veux bien : pourrais-tu rajouter une phrase sur ce qu’il se passe si jamais aucun bloc primaire ni secondaire n’est émis ? J’avais posé la question sur le GitHub Substrate, j’ai eu la réponse qu’un bloc pouvait être sauté mais sans comprendre comment la blockchain acceptait une absence de bloc.
Il ne se passe juste rien, c’est d’ailleurs ce qui est arrivé plusieurs milliers de fois pendant les quelques heures où ton nœud était down. C’est lié à la notion de “Slot”, que je viens d’ajouter
2 Likes
Peut-être qu’il faudrait préciser le vocabulaire « adresse » « pubkey ».
De mémoire, une adresse, c’est 2 octets de préfixe, 32 octets de clé publique, et 4 octets de checksum concaténés dans cet ordre. L’adresse au format ss58 est l’encodage en base58 de ces 38 octets.
J’ai l’impression qu’il y a régulièrement des confusions à ce propos et je ne retrouve pas le schéma qu’on avait fait sur un paperboard aux RML16.
[edit]
Je vois
julia> base58decode(b"5GAT6CJW8yVKwUuQc7sM5Kk9GZVTpbZYk9PfjNXtvnNgAJZ1")
35-element Vector{UInt8}:
0x2a
0xb5
0x52
0xb2
⋮
0xc4
0xef
0x7e
0x5c
soit 35 octets, pas 38. Où est-ce que je me trompe ?
[edit]
ok, donc je résume pour ss58 :
- préfixe 1 à 2 octets en fonction de la valeur
- clé publique 32 octets
- checksum 2 octets
Soit 35 ou 36 octets au total.
Une « adresse » c’est « quelque chose qui identifie un compte ». C’est un terme générique qui peut désigner des choses différentes selon comment est codé le runtime.
Dans notre cas c’est 32 octets libres.
Le préfixe et le checksum sont des notions inhérentes au format ss58 qui n’existent donc pas au format binaire. Et c’est bien normal car leur existence ne sert qu’à gérer les erreurs de saisie humaine.
Dans le format ss58, le checksum fait 2 octets, et le préfix 1 à 2 octets selon sa valeur. Pour nos réseaux de test le préfix est 42, encodé sur 1 octet, donc nos adresses ss58 encodent 35 octets en base58, ce sera 36 pour la Ğ1v2.
3 Likes
Je propose l’ajout de la définition de ChainSpec, « chain specification ».
Les chain specification sont un ensemble d’informations décrivant un réseau précis. Elles sont composées de :
- des spécifications du client (nom/id de la monnaie, bootnodes, code substitute…)
- un état genesis (bloc zéro) incluant le runtime initial
Certaines spécifications du client peuvent être modifiées après le lancement du réseau (par ex les bootnodes), alors que le genesis est fixé une fois pour toutes (d’où l’utilisation du hash du genesis comme identifiant de blockchain).
4 Likes
Accordé, je te laisse modifier le post
1 Like
Je propose l’ajout d’une définition pour Random ID suite à la discussion La solution pour des identicones sécurisées: le random id
Le Random ID est un identifiant unique attribué à un compte par la blockchain. Il rend très coûteux les attaques visant à obtenir un randomid choisi et peut donc servir de graine solide pour un système d’identification visuel (identicon).
Même si en pratique on n’est pas parti pour s’en servir, ça peut être utile de le documenter parce qu’actuellement il est dans le code.
2 Likes
Non, je n’ai pas la notion de Providers pour Substrate, pour moi les provider c’est ce que je dois virer de Gecko pour passer à Rivderpod lol…
(oui c’est qui consomme un consumer, c’est ce qu’il faut chercher pour comprendre ce qui utilise un consumer donc)
1 Like
Extensions
Parmi les Externalities, on peut ajouter des Extensions.
Pour l’instant la seule définition parlante que j’ai trouvée : sp_externalities - Rust :
Extensions are for example the keystore or the offchain externalities. These externalities are used to access the node from the runtime via the runtime interfaces.
Autrement dit, les extensions font partie, avec le Storage, des éléments auxquels le Runtime a accès.
En cherchant dans le code source de Substrate, je tombe principalement sur des extensions du genre :
- offchain workers
- transaction pool
Mais en fait j’ai l’impression que les extensions, ce sont en quelques sortes les “modules” que l’on peut brancher sur le Runtime pour étendre ses capacités, et que l’on peut définir à volonté.
1 Like
Canonicalization
Fait, pour Substrate, de considérer qu’un bloc fait partie de la chaîne principale et participe à constituer l’état courant de la monnaie. Les blocs présents dans des forks ne sont pas canonicalisés.
Cependant, un fork peut évoluer en chaîne principale : ses blocs sont alors canonicalisés, et les blocs non finalisés de l’ancienne branche principale sont décanonicalisés et relégués au rang de fork.
Par ailleurs :
- les blocs canonicalisés voient leurs modifications apportées au storage inscrits dans le Main Trie, sur disque ;
- les blocs non-canonicalisés voient quant à eux leurs modifications apportées au storage inscrites dans l’Overlay, en mémoire vive (persisté sur disque et rechargé entre 2 redémarrages du nœud).
Finality
C’est une canonicalisation définitive, irréversible. Un bloc finalisé ne sera jamais annulé, sauf hard-fork.
Source : https://docs.substrate.io/learn/state-transitions-and-storage/
2 Likes
J’ai rayé sur mon message précédent une fausse information.
J’aimerais aussi donner une meilleure définition, ci-dessous.
Si c’est OK pour vous, j’aimerais la pousser officiellement dans le Vocabulaire.
Canonicalization
Fait pour le Client de considérer qu’un bloc fait partie de la chaîne principale de façon irréversible (sortie de la fenêtre de fork).
La canonicalisation peut intervenir de deux façon :
- finalisation d’un bloc (via Grandpa par ex., canonicalisation par le Runtime)
- sélection forcée par dépassement de la taille de la fenêtre de fork (canonicalisation par le Client)
Un bloc canonicalisé voit ses modifications au Trie impactées sur le backend, et donc persistées sur disque.
La canonicalisation supprime tous les forks qui ne sont pas basés sur le bloc canonicalisé (et leurs modifications sur le Trie).
Finality
C’est une canonicalisation par le Runtime.
Source : documentation Substrate
1 Like
Merci pour ces nouvelles définitions ! Ils sont étranges d’avoir inventé le mot “canonicalization” plutôt que d’utiliser “canonisation” qui se comprend bien.
2 Likes
Amen 
1 Like