# Bitcoin: Proof of Work 

## <u>1 idée, 2 problèmes</u> :
L'idée de la blockchain bitcoin fait malheureusement face à deux problèmes majeurs:
- **La double transaction**: comment s'assurer de ne pas accepter deux transactions identiques en même temps ?
- **Les généraux byzantins**: comment s'assurer qu'un nœud intermédiaire lors d'échanges ne vienne introduire des *informations erronées* ?

Pour le premier problème, cela peut être résolu en utilisant différents nœuds qui viendront vérifier les transactions.
Cependant, pour le second, il faudra trouver une façon de s'assurer qu'un nœud ai dit la vérité, et c'est là qu'intervient l'algorithme de consensus. 

### <u>Proof of Work</u>
la blockchain bitcoin se base sur le protocole de consensus : Proof of Work.</br>
C'est un système de validation basé sur la résolution d'un problème dit **difficile à prouver**, mais **facilement vérifiable**.
On viendra un plus tard pour expliquer pourquoi un tel système de vérification est utilisé, mais avant cela une mise au point sur la constitution d'un block dans la chaîne bitcoin est nécessaire.

## <u>Bitcoin block header</u> :
![block_header.png](https://files.peakd.com/file/peakd-hive/moh4m/23tSzR6hh3wvukkLr4sYj7PhcKc9byQjbhZU9WW1zp2EoYNg1aAagZZ7FDL7NfbGttYSf.png)


- **Version number**: Numéro de la version du block, il est mis à jour avec le nouveau protocole à suivre de la chaîne bitcoin.
- **Previous block hash**: C'est le hash du block précèdent.
- **Merkle root**: C'est un arbre de hashage contenant le hash de chacune des transactions, grâce à celà il sera impossible de venir modifier une transaction après le hashage.
- **Time**: Heure à laquelle le mineur à commencer le calcul du hash du block.
- **Nbits**: C'est une version encodé du *target treshold*, c'est à dire le seuil du hash que le mineur calcul et qui ne doit pas dépasser pour faire valider le block. 
- **Nonce**: Un nombre de 32 byte choisi aléatoirement afin de faire varier le calcul du hash en dessous du seuil.

**le mineur est le nœud effectuant les calculs nécessaires pour valider un block.

## <u>Système de fonctionnement de l'algorithme</u>
L'algorithme de vérification s'inspire d'Hashcash, un algo bien connu utiliser pour la rémédiation aux mails spams.
![compute_step.png](https://zupimages.net/up/22/47/3y43.png)
*lien vers l'image: zupimages.net/up/22/47/3y43.png*

- **Ajustement de la difficulté**:
  On mesure la difficulté par l'effort qu'il faut pour résoudre le  problème.
    Celle-ci s'ajuste automatiquement tous les 2016 blocks crées dans le réseau à l'aide d'une fomule qui repose sur le *target treshold*.
    La difficulté doit être telle que il doit être possible de générer 1 block toute les 10 minutes environ.

- **Récupération et calcul de toutes les informations nécessaires à notre block**: 
  Nous récuperons ou calculerons toutes les informations relatives au block header.</br>En ce qui concerne le *merkle root* ,c'est le nœud qui choisira le nombre de transaction qu'il souhaite inclure dans son arbre (Parmi toutes les transactions faites à partir du dernier nœud crée).

- **Concaténation des informations et choix du nonce**:
  Les informations seront concaténées entre elles afin de former un message puis à ce message se rajoutera un nonce choisit aléatoirement.

- **Double hashage et verification du résulat**:
  Ce suit un double hashage du message ainsi que les vérifications finales.</br>
  Si un nœud a déjà résolu le problème alors nous devons recommencer les étapes depuis le début sinon on devra vérifier que le résultat soit bien inférieur ou égal au seuil.</br>
  Dans le cas où il le serait, on pourra diffuser notre block et gagner au passage quelques bitcoins sinon il faudra recommencer à l'étape du choix du nonce et faire varier celui-ci.

## <u>Conclusion:</u>
Pour répondre à l'interrogation du début: Pourquoi un tel système de vérification est utilisé.</br>
Grâce à cela si une personne souhaite modifier un bloc alors il devra recalculer tous les blocs précédents ce qui est quasiment impossible.</br>
Le proof of work répond bien à nos attentes concernant le problème des généraux byzantins en prenant compte nos technologies actuelles.


## <u>Source:</u>
- A Review on Consensus Algorithm of Blockchain (https://blockhack.osive.com/_downloads/33a65d87de38eaf5b8d817681a3e4674/7.pdf)
- Understanding Blockchain Consensus Model (https://web.archive.org/web/20220121100752id_/https://www.persistent.com/wp-content/uploads/2017/04/WP-Understanding-Blockchain-Consensus-Models.pdf?pdf=Understanding-Blockchain-Consensus-Models)