Hé! Vous semblez être en United States, souhaitez-vous utiliser notre site English ?
Switch to English site
Skip to main content

BlockChainPart3-Smaller_aa3cfa62860f3575b0be1db7efcf6af8aba79a49.jpg

Dans la 22e partie de notre document, nous avons abordé l'idée qu'un système pair à pair comme un blockchain public doit atteindre un consensus quant à l'historique de la chaîne et aux nouvelles données autorisées à être ajoutées, afin d'être efficace. Bien sûr, c'est plus facile à dire qu'à faire, en particulier lorsque des milliers de nœuds sont en jeu.

L'ouvrage fondamental explorant ce problème est un essai publié en 1982 par Leslie Lamport, Robert Shostak et Marshall Pease intitulé Le problème des généraux byzantins. Cet ouvrage universitaire est facile à lire et très intéressant.

2zcek9_69fe9bd7f5861bbcd1d8628d5f3edc7e3c0c854e.jpg

Le problème des généraux byzantins

Pour concevoir une situation où plusieurs parties doivent trouver un consensus à propos de leurs actions futures, en dépit de l'existence possible d'éléments perturbateurs ou traîtres au sein du groupe, l'article décrit un scénario où plusieurs généraux de l'ancien Empire byzantin sont positionnés autour d'une cité rebelle. Chaque général et son armée sont dans un camp séparé et la communication entre les camps est seulement possible par l'envoi d'un messager sur un terrain ouvert et potentiellement hostile.

Le problème pour les généraux, c'est la force de la cité qu'ils assiègent. Celle-ci peut facilement écraser une armée et peut résister à une attaque non coordonnée de plusieurs armées. Pour réussir, les généraux doivent lancer une attaque coordonnée. L'autre option, qui leur permettrait de conserver leur force pour continuer à combattre, c'est de décider de battre en retraite ensemble.

Pour ce qui est du messager que chaque général doit envoyer pour assurer ce résultat, l'article montre que le problème pour chaque général (dans sa forme la plus simple) pourrait être décrit par un général commandant et deux lieutenants. Les conditions énoncées dans le document sont :

Le problème des généraux byzantins. Un général commandant doit envoyer un ordre à ses lieutenants-généraux n-1 de la manière suivante :

IC1. Tous les lieutenants loyaux obéissent au même ordre.
IC2. Si le général commandant est loyal, alors tous les lieutenants loyaux obéissent à l'ordre qu'il donne.

Cela semble assez simple, mais lorsque nos généraux utilisent des messages ouverts (oraux), aucune solution n'est possible sauf si plus des 2/3 des généraux sont fidèles. Autrement dit, pour nos trois généraux, aucune solution ne fonctionnera s'il y a un traître. Ceci peut être illustré dans les deux illustrations suivantes :

generals_8624b21fd1a2242b96b3ee58f856edfddb73a5d2.png

Dans l'illustration 1, le commandant ordonne aux deux lieutenants d'attaquer. Le Lieutenant 2 est un traître et informe le Lieutenant 1 messages qu'il a reçu un ordre de repli. Pour satisfaire à la condition IC2, le Lieutenant 1 obéira à l'ordre d'attaquer.

Cependant, dans l'illustration 2 où le commandant est le traître, celui-ci envoie un ordre d'attaque au Lieutenant 1 et un ordre de repli au Lieutenant 2. Sans savoir qui est le traître, ou quel message a été envoyé au Lieutenant 2, le Lieutenant 1 se retrouve avec exactement les mêmes informations que celles reçues dans l'illustration 1. Tant que le traître est cohérent dans ses mensonges, le Lieutenant 1 devra toujours attaquer.

Le document poursuit en démontrant mathématiquement qu'aucune solution avec moins de 3m + 1 généraux ne peut faire face à m traîtres : c'est-à-dire moins d'1/3 des généraux peuvent être un traître pour qu'il existe toujours une solution viable.

Arrêter les fausses informations

Comme nous l'avons vu dans les illustrations 1 et 2, la capacité du ou des traîtres à mentir est ce qui rend le problème des généraux byzantins si percutant. Nous pouvons faciliter la solution si l'on peut limiter la capacité à mentir. Ceci peut être fait par l'envoi de messages avec des signatures qui ne peuvent pas être falsifiées. Les hypothèses qui sont faites dans ce cas sont :

A1. Chaque message envoyé est délivré correctement
A2. Le destinataire du message sait qui l'a envoyé
A3. L'absence d'un message peut être détectée

Ces hypothèses étaient aussi vraies pour les messages oraux précédents, mais les nuances suivantes sont ajoutées :

A4. (a) La signature d'un général loyal ne peut pas être falsifiée et toute modification du contenu de ses messages signés peut être détectée.
(b) N'importe qui peut vérifier l'authenticité de la signature du général.

Dans ce scénario, le commandant envoie un ordre signé à chacun de ses lieutenants. Chaque lieutenant ajoute alors sa propre signature sur l'ordre avant de l'envoyer aux autres lieutenants et ainsi de suite. Si l'on applique cet algorithme au scénario précédent nous obtenons ceci :

generals2_7f3c39063960e91901f1db2c46a472854b8662a1.png

Le commandant signe ses ordres avec un "0". Chaque lieutenant signe l'ordre qu'il a reçu et le transmet au suivant. Dans ce cas, les lieutenants savent que leur commandant est un traître car sa signature est présente sur deux ordres contradictoires et que l'hypothèse A4 indique que seul le commandant peut apposer la signature.

Le document continue et prouve mathématiquement que cet algorithme peut maintenant faire face aux m traîtres avec n'importe quel nombre de généraux et la façon dont cela fonctionne dans d'autres scénarios comme lorsqu'il manque des chemins de communication. Ces informations sortent probablement du champ d'un article d'introduction et, si vous avez lu les parties précédentes du présent article, vous savez déjà probablement comment ces idées sont employées (cryptographie pour créer des signatures) pour la création de consensus et la protection contre les attaques dans le cadre des blockchains.

Orphelins, oncles et expiration

Souvenez-vous, chaque mineur d'un réseau blockchain essaie d'être le premier à résoudre l'énigme cryptographique pour le bloc en cours. Une fois l'énigme résolue, le mineur envoie la solution au réseau pour vérification. En supposant que tout est correct, les mineurs commencent alors à travailler sur le bloc suivant.

Mais que se passe-t-il si deux mineurs résolvent le même bloc en même temps ? Tous les réseaux distribués souffrent d'une latence car il faut du temps pour que les données soient transmises de nœud en nœud. Cela peut aller de quelques millisecondes à quelques secondes, ce qui signifie qu'il est tout à fait possible qu'un grand nombre de nœuds soit susceptible de valider et d'ajouter à la chaîne les blocs de deux mineurs distincts.

Le blockchain présente désormais un embranchement qui se développera comme deux chaînes distinctes, car elles sont toutes les deux valides et le minage ne peut pas s'arrêter le temps que la situation soit résolue. C'est un problème pour un blockchain car, comme dans Highlander, il ne peut en rester qu'un.

Différents blockchains ont leurs propres approches pour résoudre ce dilemme, c'est pourquoi nous nous intéresserons aux méthodes que les plus courants, Bitcoin et Ethereum, utilisent pour revenir à la normale.

Bitcoin

Prenons une situation où le mineur X et le mineur Y viennent tous deux de résoudre le bloc numéro 1001. Parce qu'il se trouve dans une partie du monde avec des latences réseau inférieures, le mineur X a transmis son nouveau bloc à 60 % du réseau Bitcoin. Le mineur Y a transmis son bloc aux 40 % restants. À ce stade, les deux blocs sont considérés comme valides et le minage se poursuit.
Les nœuds de minage ayant accepté le bloc du mineur X minent pour ajouter le prochain bloc après le bloc du mineur X, alors que les nœuds qui ont accepté le bloc du mineur Y minent pour compléter la chaîne d'Y.

orphan01_1e0ffc3465b73dac334344d6da92837511ecb5bd.png

Les mineurs complétant la chaîne de X ajoutent un autre bloc, mais ceux complétant la chaîne d'Y ont ajouté deux blocs. Dans un blockchain, la longueur de la chaîne est le critère roi, et en dépit du nombre supérieur de nœuds minant pour la chaîne de X, cela sera la chaîne du mineur Y qui, plus longue, sera retenue comme chaîne valide.

orphan02_c4291633e08e4a07520244efe163b91e85c3ae24.png

Le bloc n°1001 de X est exclu de la chaîne et demeure sans bloc parent. C'est désormais un bloc orphelin. Les mineurs de X ne recevront aucune récompense pour le bloc supplémentaire qu'ils ont trouvé, celui-ci est à présent un bloc expiré inutilisable.

En conditions réelles, le réseau blockchain n'attendra pas si longtemps pour prendre la décision. Dès que bloc n°1002 est miné, le réseau favorise cette chaîne et l'autre devient orpheline.

Si vous vous demandez ce qui se passe pour les transactions qui composent le bloc orphelin (et expiré) : elles sont automatiquement replacées dans la file d'attente pour être ajoutée au bloc suivant.

Ethereum

Ethereum a une approche légèrement différente à cette question sous la forme du protocole GHOST (Greedy Heaviest Observed Subtree), qui récompense les mineurs qui trouvent l'équivalent des blocs orphelins et expirés sur Bitcoin. Sur Ethereum, ils sont appelés "blocs oncles" et bien qu'ils ne sont pas toujours pas ajoutés au blockchain principal, le mineur obtient une récompense, bien qu'inférieure à celle qu'il aurait pu recevoir pour un bloc standard ajouté à une chaîne.

Ethereum accepte 7 niveaux de blocs oncles (l'équivalent d'un bloc orphelin et de six blocs expirés chez Bitcoin) et les récompenses sont en fonction d'une formule :

([Numéro du bloc oncle numéro] + 8 - [numéro de bloc]) x ([récompense Ethereum] /8)

Donc, si la récompense pour un bloc standard était de 3 ETH, alors le premier bloc oncle vaudrait 2,625 ETH, le prochain 2,25 ETH et celui d'après 1,87 ETH et ainsi de suite. Encore une fois, en situation réelle, un nœud mineur abandonne les chaînes oncles après un ou deux blocs tout au plus.

L'avenir

Les blockchains sont une technologie en développement et on peut s'attendre à ce que leur utilité soit optimisée une fois que l'engouement du grand public aura ralenti. La technologie sous-jacente devra également probablement être améliorée pour être véritablement utile.

Prenons comme exemple Martin Cooper qui travaillait pour Motorola en 1973 lorsqu'il a déposé un brevet pour un "système radiotéléphonique". Cette même année, il a passé le premier appel avec un téléphone mobile mais il a fallu attendre la mise en place des réseaux GSM dans le milieu des années 1990 (qui ont permis l'apparition d'appareils plus économes en énergie et moins chers et d'une meilleure couverture cellulaire grâce à un usage bien plus efficace de la bande passante de transmission qu'il n'était possible avec la technologie analogique) que la technologie a pu commencer à se répandre et ajouter des fonctionnalités encore inédites à l'époque.

De même, le blockchain a quelques limitations qui doivent être surmontées. Par exemple, le blockchain Bitcoin ne peut traiter que 7 transactions par seconde et le minage d'un bloc prend en moyenne 10 minutes. Cela freine son utilité pour les institutions financières qui traitent des millions de transactions par jour. Il faut aussi prendre en compte le fait que chaque transaction ajoutée effectivement à un bloc demande la même quantité d'énergie que ce qui est nécessaire en moyenne à 1,6 ménage américain pour 24 heures. Il y a ensuite la taille de la chaîne qui, à plus de 25 Go (et à la hausse), est de plus en plus difficile de stocker sur les appareils personnels.

D'un autre côté, des sommes importantes sont consacrées à la recherche avec des groupes comme le Global Blockchain Business Council (DU GBBC) cherchant activement à développer de nouvelles utilisations pour les blockchains et le projet Hyperledger qui travaille à créer des standards ouverts pour permettre une interopérabilité entre les industries. En partenariat avec Samsung, IBM planche sur ADEPT (Autonomous Decentralized Peer-to-Peer Telemetry) en utilisant la technologie blockchain pour sécuriser les réseaux distribués d'appareils autonomes dans un écosystème IoT décentralisé.

À l'heure actuelle, les blockchains peuvent trouver leurs applications avec les types de données qui auraient été auparavant consignés dans un registre, comme les transactions financières (y compris les microtransactions), les registres gouvernementaux locaux (votes, cadastre et immatriculation des véhicules, etc.), les données médicales, les données de suivi et autres. Cependant, des améliorations de la technologie sous-jacente sont à prévoir pour permettre de nombreuses autres applications de stockage de données sécurisées pour que la technologie soit viable.

Mark completed his Electronic Engineering degree in 1991 and worked in real-time digital signal processing applications engineering for a number of years, before moving into technical marketing.
DesignSpark Electrical Logolinkedin