Machine à état et réponses prouvées des noeuds aux clients ?

R&D
67

Le block précédent du block genesis a comme hash le hash d’une chaine vide :slight_smile:

E3B0C44298FC1C149AFBF4C8996FB92427AE41E4649B934CA495991B7852B855

Si je comprends bien ton algo :

  1. Au bloc 0, le blockchain_merkle_root vaut empty_hash
  2. Au bloc 1, le blockchain_merkle_root vaut hash(empty_hash, hash(0))
  3. Au bloc 2, le blockchain_merkle_root vaut hash(bloc(1), blockchain_merkle_root(1))
  4. Au bloc 3, le blockchain_merkle_root vaut hash(bloc(2), blockchain_merkle_root(2))

Sinon de manière générale, ton fonctionnement est intéressant pour les noeuds légers (Raspberry etc). Ca leur permettra de participer à l’avancée de la chaine sans consommer trop de ressources.

  • Lorsqu’un noeud léger se synchronise pour la première fois, il ne télécharge que les éléments nécessaires sur le chemin de merkle lui permettant de reconstituer la preuve de merkle.
  • Il télécharge tous les arbres des états de la chaine et vérifie avec des arbres de merkle que l’état est cohérent avec ce qu’il a téléchargé
  • Le noeud léger ne télécharge donc plus la blockchain complète. La synchronisation est beaucoup plus rapide.

Il faudrait cependant garder le fonctionnement “full sync” actuel permettant de plug des API clients, de l’historisation etc.

3 Likes