ūüßĶTHREAD : Le bitcoin, les blockchains, comment √ßa marche ?

On entend parler tous les jours de ces bases de données décentralisées qui sont censées révolutionner internet, mais connaissez-vous le fonctionnement étonnamment simple de cette technologie ?

Je vous explique ‚§ĶÔłŹ
Les blockchains ont été inventées fin 2008 via le Bitcoin, dans un papier signé par "Satoshi Nakamoto". On ne sait rien de cette personne, qui est peut-être un collectif.

Même s'il existe plein de types de blockchain, ce thread va se concentrer sur le fonctionnement de Bitcoin.
Petit disclaimer avant de commencer : bien que cryptographiquement superbe, je suis opposé à 99% de ce qui est fait avec les blockchains : entre sa consommation énergétique démesurée, les manipulations de marché et l'arnaque des NFT, difficile pour moi d'apprécier la technologie.
Bref, commen√ßons : pourquoi "cha√ģne de blocs" ? On souhaite partager entre plein de gens un fichier contenant plein de virements qui arrivent en permanence.

Perso j'aurais fait un Google Docs, mais on va vite avoir des soucis de synchro et de modifications malveillantes ūüėč
Pour avoir un système fiable, tout le monde travaille sur un fichier en lecture seule sur lequel on ajoute de temps en temps un groupe de virements.

Faire un ajout à ce fichier demande beaucoup de puissance de calcul, et c'est donc un effort commun (on reviendra sur ce point).
C'est exactement comme ça que fonctionne une blockchain : chaque groupe de virements représente un bloc, et pour faire évoluer le "fichier" on ajoute un nouveau bloc à la suite des existants.
Chaque bloc contient le hash (un "résumé" cryptographique) du bloc précédent. Ainsi, un bloc repose sur tout l'édifice des blocs qui le précèdent, et il est impossible d'effacer discrètement une partie du passé de la blockchain.
Je vous explique dans un instant comment les virements peuvent être créées et authentifiés de manière sécurisée, mais d'abord on va voir pourquoi c'est si difficile d'ajouter un nouveau bloc à la blockchain et pourquoi il faut dépenser tant d'énergie pour le faire.
Pour éviter d'avoir des blocs trop petits et des évolutions dans tous les sens, on ajoute une contrainte aux blocs ajoutés : leur hash doit commencer par au moins 76 bits consécutifs à zéro (76 est la valeur actuelle mais elle évolue au cours du temps).
Pour avoir un tel bloc qui commence par plein de zéros, pas d'option facile : il faut tester des milliards et des milliards de configurations du bloc jusqu'à en trouver une dont le hash soit valide. Cette forme de bruteforce demande énormément de puissance de calcul.
Chacun va donc essayer de son c√īt√© de trouver un nouveau bloc valide qui contient les quelques transactions qui attendent d'√™tre inscrites dans la blockchain.

Mais pourquoi les gens s'embêteraient-ils à dépenser du temps de calcul et de l'électricité pour ça ?
La réponse est simple : l'incentive.

Quand un utilisateur trouve un bloc, il a le droit d'ajouter une transaction spéciale : son compte se voit crédité de quelques bitcoins en récompense, qui sont "fabriqués" pour l'occasion et ne proviennent pas d'un autre compte.
Avoir plein d'ordinateurs (appelés mineurs) qui travaillent en parallèle sur le même problème permet de décentraliser le système de transactions, mais on fait également face à un problème de taille : que faire si deux blocs différents sont trouvés en même temps ?
On pourrait avoir un système d'autorité centrale qui tranche et choisit un bloc parmi les deux, mais ça contredit le principe fondamental de décentralisation ! Du coup, on autorise la blockchain à avoir des divergences temporaires.
Les deux blockchains concurrentes (avec seulement le dernier bloc qui diffère) coexistent, jusqu'à ce qu'un nouveau bloc soit ajouté à l'une des deux branches.

Comme c'est toujours la cha√ģne la plus longue qui fait foi, l'alternative la plus courte sera ignor√©e.
C'est d'ailleurs pour √ßa que les virements peuvent prendre quelques heures : pour √©viter d'accepter une transaction en t√™te de cha√ģne, on attend quelques blocs (appel√©s "confirmations") pour s'assurer que la transaction figure dans toutes les versions divergentes possibles.
Maintenant que vous comprenez mieux la structure d'une blockchain, je vous explique pourquoi seul le propriétaire d'un "compte" bitcoin est capable d'ordonner un virement depuis son wallet, même si n'importe qui peut insérer des transactions dans la blockchain.
Pour accéder à un portefeuille bitcoin, on n'utilise pas son email/mdp : chaque propriétaire est identifié par une adresse publique et détient la clé privée correspondante.

Pas besoin de s'inscrire pour détenir un portefeuille bitcoin, il suffit de générer une paire de clés.
Une transaction est un message qui transmet une certaine quantité de fonds d'une adresse A vers une adresse B, accompagnée d'une signature cryptographique de la clé privée A qui certifie que cet ordre de virement a bien été émis par le détenteur de la clé.
Dans chaque virement créé, l'émetteur inclut aussi un pourboire (les fees) qui reviendra au mineur du bloc correspondant. Comme chaque bloc contient un nombre de transactions limité, ce pourboire incite le mineur à inclure dans son bloc celles qui lui seront le plus rentables.
Un grand problème des blockchains par rapport à un système bancaire centralisé est que toutes les transactions sont forcément publiques. Mais comme les adresses ne sont pas directement rattachées à une identité, les échanges sont traçables mais restent entièrement anonymes.
Autre souci majeur : l'espace disque. Bitcoin a d√©j√† enregistr√© pr√®s de 700 millions de transactions depuis 2009, soit plus de 350GB pour avoir sa propre copie de la cha√ģne. Mais il existe une optimisation remarquable qui r√©duit largement ce volume sans compromettre la s√©curit√©.
En réalité, les transactions ne sont pas directement incluses dans les blocs : la blockchain est ultra légère, et chaque bloc pèse exactement 80 octets même si chacun contient plusieurs milliers de transactions.

Compression ultra efficace ? Non, arbres de Merkle !
Un arbre de Merkle est une structure optimisée pour calculer et vérifier un hash de plusieurs données (ici, les transactions d'un bloc). Pour calculer un arbre de Merkle, c'est simple : on prend le hash de chaque transaction, puis on concatène les hashs deux par deux :
Ensuite on calcule le hash de chaque paire de hashs, et on recommence l'opération jusqu'à n'avoir qu'un seul hash. Tout cet ensemble forme une structure appelée arbre de Merkle, le noeud tout en bas est la racine de cet arbre et c'est cette racine que l'on inclut dans le bloc.
Du coup les transactions ne sont pas dans la blockchain, on utilise leur représentation ultra-condensée à la place. Comme la fonction de hachage (SHA256) est sécurisée, on considère qu'il est impossible de fabriquer un ensemble de transactions différent ayant la même racine.
Mais pourquoi utiliser l'arbre de Merkle alors que le hash de toutes les transactions concaténées fonctionnerait tout aussi bien ?

C'est une question de performance lors de la validation des transactions.
Admettons que j'envoie un peu de bitcoin vers le wallet d'un restaurant pour payer mon repas. La preuve de paiement consiste à démontrer que ma transaction (ici T6) figure bien dans l'un des blocs de la blockchain.
Si la blockchain utilisait le hash de toutes les transactions du bloc qui était utilisé au lieu de la racine de Merkle, je devrais fournir une copie des 8 transactions pour que le destinataire recalcule le hash et vérifie qu'il correspond bien au bloc donné.
Au contraire, avec l'arbre de Merkle, je dois seulement fournir une copie de ma transaction T6 ainsi que les hashs H5, H7-8 et H1-4.

Avec seulement ces 4 données, je peux prouver de manière irréfutable que l'arbre de Merkle contient ma transaction.
Toujours pas convaincu.e ? C'est normal.

L'arbre de Merkle marche sur de grands ensembles de données. Pour un bloc d'un million de transactions, une preuve de transaction demande seulement 19 hashs pour remonter jusqu'à la racine, soit un volume 52 000 fois plus petit !
À retenir de ce thread :

- 1 bloc = hash du bloc précédent + racine Merkle
- Création de blocs = bruteforce très lent
- Récompense minage via l'incentive et les fees
- Transaction = signature avec clé privée de l'émetteur

Vous en voulez encore ? Ok, voici un chapitre bonus ;)
L'école @Guardia_School m'a demandé de vous parler un peu de cybersécurité, et ça tombe bien parce qu'il existe plein d'attaques contre les blockchains !

Je vais vous en pr√©senter une qui √©tait d√©j√† identifi√©e par Satoshi en 2008, et une autre qui utilise du calcul quantique ūüėć
La toute première attaque sur les blockchains fut baptisée "attaque des 51%". Ce nom vient du fait qu'il faut détenir plus de la moitié de la puissance de minage, autant vous dire que pour bitcoin il faut prévoir un sacré budget ! (mais ça a déjà été vu sur d'autres blockchains)
Le principe est simple : apr√®s avoir pay√© une Ferrari en bitcoins, on reprend une vieille copie de la blockchain (ant√©rieure √† notre transaction) et on utilise notre puissance de calcul √©norme pour g√©n√©rer une cha√ģne alternative o√Ļ nos bitcoins n'ont pas boug√©.
Comme on dispose de plus de 50% de la puissance, on va plus vite que tous les autres mineurs r√©unis et on peut cr√©er une cha√ģne plus longue.

Et comme c'est la plus longue cha√ģne qui est reconnue, on peut r√©√©crire l'histoire √† volont√© pour faire dispara√ģtre des transactions !
Une autre famille d'attaques cool implique l'utilisation d'un ordinateur quantique. Actuellement personne ne dispose d'un tel calculateur, mais si cette technologie voyait le jour (certains spéculent un horizon 2030) elle mettrait fin au bitcoin et plein d'autres blockchains.
Les transactions bitcoin sont signées via le cryptosystème ECDSA, qui est actuellement le standard principal dès qu'il s'agit de faire des signatures cryptographiques (c'est notamment ce qui sécurise les pass sanitaires en France). Mais ECDSA est menacé d'extinction.
En utilisant l'algorithme de Shor sur un ordinateur quantique, il est possible de casser n'importe quelle clé privée ECDSA pour voler l'argent du wallet correspondant. Le calcul quantique sera une révolution énorme pour internet, et la disparition de bitcoin en fera partie.
Et même pour les autres blockchains utilisant des signatures résistantes à l'algorithme de Shor, il existe toujours l'algorithme de Grover qui rendra inutile toute forme de minage.

La seule alternative viable sera le Proof of Stake, et la planète nous en remerciera !
Pour revenir un peu sur @Guardia_School dont je vous parlais plus t√īt : c'est une √©cole de cybers√©curit√© (bac+3 et bac+5) que je parraine, la premi√®re rentr√©e aura lieu en 2022 et les candidatures sont d√©j√† ouvertes. Plus d'infos sur guardia.school !
J'espère que ce long thread vous a plu, et félicitations d'être arrivé au bout !

Il m'a pris énormément de temps à préparer mais j'en suis super fier, je serai archi reconnaissant si vous le partagez via un retweet, ou un message pour vos proches/collègues à l'esprit curieux ;)
Quelques ressources supplémentaires :

- Le papier original de Satoshi Nakamoto : bitcoin.org/bitcoin.pdf

- Un autre thread pour comprendre les signatures cryptographiques, o√Ļ j'ai utilis√© comme exemple le QR code infalsifiable du pass sanitaire :

‚ÄĘ ‚ÄĘ ‚ÄĘ

Missing some Tweet in this thread? You can try to force a refresh
„ÄÄ

Keep Current with Mathis Hammel

Mathis Hammel Profile picture

Stay in touch and get notified when new unrolls are available from this author!

Read all threads

This Thread may be Removed Anytime!

PDF

Twitter may remove this content at anytime! Save it as PDF for later use!

Try unrolling a thread yourself!

how to unroll video
  1. Follow @ThreadReaderApp to mention us!

  2. From a Twitter thread mention us with a keyword "unroll"
@threadreaderapp unroll

Practice here first or read more on our help page!

More from @MathisHammel

16 Nov
THREAD : J'ai trouvé un bug qui affecte toutes les versions récentes de Python, et il est interdit de le réparer !

Je vous explique pourquoi ‚§ĶūüßĶ
Comme pour de très nombreux langages de programmation, le générateur de nombres aléatoires intégré à Python porte le nom de Mersenne Twister, ou MT19937.

C'est un RNG (Random Number Generator) très rapide et qui offre une entropie de très bonne qualité.
Mais le MT19937 n'est pas sécurisé contre les attaques cryptographiques : comme tous les générateurs de nombres aléatoires, il n'est en réalité que pseudo-aléatoire : après l'initialisation de ses variables internes, les bits en sortie sont produits de manière déterministe.
Read 32 tweets
6 Oct
Aujourd'hui, Twitch s'est fait pirater et une grande partie de ses fichiers sont dans la nature.

√áa veut s√Ľrement dire que votre mot de passe est compromis et qu'il faut le changer. Mais ‚ö†ÔłŹ attention ce changement peut poser un risque cyber.

Thread ‚§ĶÔłŹ
On va faire le focus sur un aspect tech intéressant pour comprendre. Aujourd'hui : comment on sécurise une base de données de mdp.

Le code source de Twitch et les mots de passe ne semblent pas concernés dans la partie 1 du leak, mais on peut quand même deviner pas mal de choses.
Pour stocker des mots de passe dans une appli web, on utilise une base de données, comme on le fait généralement pour tout ce qui se rapporte aux comptes utilisateur.

La méthode la plus simple est de stocker directement le mot de passe de l'utilisateur :
Read 24 tweets
5 Oct
Pour que vous puissiez les retrouver plus facilement, je vous propose un thread o√Ļ vous pourrez retrouver tous mes threads de vulgarisation technique ! ‚§ĶÔłŹ (oui, c'est m√©ta)
Read 10 tweets
5 Oct
THREAD : Hier, une panne massive a affecté Facebook et plein de ses services (Instagram, WhatsApp, Messenger, ...)

Mais il s'est pass√© quoi au juste ? Je vous explique tout √ßa. ‚§ĶÔłŹ
#FacebookDown #InstagramDown
On va en profiter pour présenter les protocoles BGP et DNS, que vous connaissez peut-être déjà. Ces deux loustics sont un support indispensable du réseau internet mondial, mais ils ont causé pas mal de soucis chez Facebook hier.
Tout d'abord, parlons DNS, ou Domain Name Service.

Le DNS, c'est toute une organisation qui vous permet de retenir des adresses faciles comme facebook‚Äć.com au lieu de devoir m√©moriser l'adresse IP de chaque service que vous utilisez.
Read 24 tweets
11 Aug
Cette semaine, #Apple a annoncé une nouvelle feature dans iOS 15 qui scannera l'album photo des utilisateurs d'iCloud à la recherche de contenus pédo-pornographiques.

J'ai étudié le protocole cryptographique sous-jacent, et je vous propose un #Thread de vulgarisation. ImageImage
Je me suis paluché la publication scientifique d'Apple, 32 pages de notation mathématique assez touffue que je vais me charger de simplifier. Première surprise, le papier est co-écrit par Dan Boneh, une pointure en cryptographie (membre émérite de l'IACR, prix Gödel, ...) Image
Comme je le rappelais en réaction à un titre d'article un peu trop clickbait, la détection se fait sur une liste de photos pré-établie pour limiter au maximum le risque de faux positifs.
Read 43 tweets
25 Jul
THREAD : Pourquoi on ne peut pas fabriquer son propre QR code de vaccination #PassSanitaire

Aujourd'hui, je vous propose un thread de vulgarisation sur quelques principes cryptographiques, promis ce sera beaucoup moins technique que celui d'hier ūüėČ

‚§Ķ
Comme je le disais dans des interviews récentes avec @libe et @Numerama, "Le pass sanitaire est signé numériquement, ce qui le rend théoriquement impossible à la falsification".

Mais qu'est-ce que c'est que cette signature, et pourquoi on ne peut pas juste l'imiter ?
Tout d'abord, on va prendre un exemple que j'utilise souvent pour illustrer la signature cryptographique : vous allez à la mairie pour faire certifier un document papier.

Ce scénario de la vie réelle a de nombreux parallèles avec les signatures numériques !
Read 24 tweets

Did Thread Reader help you today?

Support us! We are indie developers!


This site is made by just two indie developers on a laptop doing marketing, support and development! Read more about the story.

Become a Premium Member ($3/month or $30/year) and get exclusive features!

Become Premium

Too expensive? Make a small donation by buying us coffee ($5) or help with server cost ($10)

Donate via Paypal

Thank you for your support!

Follow Us on Twitter!

:(