Introduction à la blockchain

Vous avez probablement entendu décrire la blockchain comme une "monnaie numérique" ou "l'avenir d'internet". Ces explications passent complètement à côté du sujet.

Les blockchains sont des systèmes distribués : des réseaux d'ordinateurs qui doivent s'accorder sur des données partagées sans se faire confiance mutuellement. Ce cours enseigne la blockchain à partir des principes fondamentaux : les problèmes de systèmes distribués qu'elle résout, comment elle les résout, et pourquoi ces compromis sont importants.

Commençons par comprendre pourquoi la construction de systèmes distribués est l'un des problèmes les plus difficiles en informatique.

Systèmes distribués

La plupart des gens pensent que passer d'un ordinateur à plusieurs n'est qu'une question de "plus de la même chose". C'est comme penser que coordonner une personne est identique à coordonner un millier de personnes à travers différents fuseaux horaires qui pourraient ne pas toujours être joignables.

Lorsque vous écrivez du code sur un seul ordinateur, vous vivez dans un monde prévisible :

• Les opérations réussissent ou échouent immédiatement

• Les données ne changent pas mystérieusement entre les lectures

• Le temps avance de manière cohérente

• Quand vous sauvegardez quelque chose, c'est réellement sauvegardé

Prenons un système bancaire simple. Transférer 100 $ d'Alice à Bob dans ce cas est extrêmement facile :

def transfer(from_account, to_account, amount):
    if from_account.balance >= amount:
        from_account.balance -= amount
        to_account.balance += amount
        return "Transfer successful"
    return "Insufficient funds"

Cela fonctionne parfaitement... jusqu'à ce que vous ayez besoin de mettre à l'échelle.

Votre banque se développe au-delà de ce qu'un seul ordinateur peut gérer, vous répartissez donc les comptes uniformément entre différentes bases de données :

• Serveur A : Comptes 1 à 1 000 000

• Serveur B : Comptes 1 000 001 à 2 000 000

• Serveur C : Comptes 2 000 001 à 3 000 000

Maintenant, Alice (sur le serveur A) veut envoyer 100 $ à Bob (sur le serveur B). Ce simple transfert devient :

def distributed_transfer(alice_server, bob_server, amount):
    # Check Alice's balance on Server A
    if alice_server.get_balance("alice") >= amount:
        alice_server.deduct("alice", amount)    # Step 1
        bob_server.add("bob", amount)           # Step 2
        return "Transfer successful"
    return "Insufficient funds"

Cela semble toujours simple ? Voici ce qui peut mal tourner :

• Partition réseau : la connexion entre les serveurs échoue juste après l'étape 1 mais avant l'étape 2. Les 100 $ d'Alice disparaissent dans le néant numérique.

• Plantage du serveur : le serveur B plante après avoir reçu la commande "ajouter de l'argent" mais avant de confirmer qu'il l'a traitée. Bob a-t-il reçu l'argent ? Personne ne le sait.

• Conditions de concurrence : deux transferts d'Alice se produisent simultanément. Les deux vérifient son solde de 100 $, constatent qu'elle a des fonds suffisants, et les deux procèdent. Alice a maintenant dépensé 100 $ qu'elle n'avait pas.

Théorème CAP

En 1999, l'informaticien Eric Brewer a formulé le théorème CAP, qui stipule que tout système distribué peut garantir au maximum deux de ces trois propriétés :

• Cohérence (C) : tous les serveurs affichent toujours les mêmes données. Lorsque le solde d'Alice change sur le serveur A, tous les autres serveurs le reflètent immédiatement.

• Disponibilité (A) : le système continue de fonctionner même lorsque des serveurs plantent. Si le serveur A tombe en panne, les utilisateurs peuvent toujours accéder aux comptes via les serveurs B et C.

• Tolérance au partitionnement (P) : le système survit aux défaillances réseau qui divisent les serveurs en groupes isolés.

Nous devons garantir la tolérance au partitionnement car les partitions réseau sont inévitables : les câbles sont coupés, les routeurs tombent en panne, les centres de données perdent leur alimentation. Cela nous laisse choisir entre la cohérence OU la disponibilité.

Les systèmes bancaires traditionnels choisissent généralement la cohérence + la tolérance au partitionnement (systèmes CP). Ils préfèrent s'arrêter plutôt que d'afficher des soldes de compte incorrects.

Les plateformes de médias sociaux choisissent souvent la disponibilité + la tolérance au partitionnement (systèmes AP). Elles préfèrent vous laisser publier (même si vos amis ne peuvent pas le voir immédiatement) plutôt que de vous empêcher de publier.

Le problème des généraux byzantins

En plus du théorème CAP, la plupart des systèmes distribués supposent que les participants sont honnêtes : ils peuvent échouer ou se déconnecter, mais ils ne se tromperont pas activement les uns les autres. Cette hypothèse s'effondre lorsque les participants peuvent être malveillants.

Le problème des généraux byzantins, formulé par des informaticiens en 1982, illustre ce défi :

Vous êtes un général byzantin planifiant l'attaque d'une ville fortifiée. Vous avez plusieurs généraux alliés positionnés autour de la ville, chacun commandant sa propre armée. Pour réussir, vous devez coordonner une attaque simultanée. Si certains attaquent pendant que d'autres battent en retraite, les forces attaquantes seront massacrées.

Vous communiquez uniquement par messagers, et certains généraux pourraient être des traîtres qui veulent que l'attaque échoue. Les traîtres peuvent :

• Envoyer des messages "attaquer" à certains généraux et "retraite" à d'autres

• Modifier les messages des généraux loyaux lors de leur transmission

• Se coordonner avec d'autres traîtres pour maximiser la confusion

Comment parvenir à un consensus sur "attaquer" ou "battre en retraite" lorsque vous ne pouvez pas distinguer les généraux loyaux des traîtres, et que vous ne pouvez pas faire confiance aux canaux de communication ?

Cela semblait impossible. Pendant des décennies, les informaticiens ont cru qu'il était impossible de construire un système qui soit simultanément :

• Tolérant aux fautes byzantines (fonctionne malgré des participants malveillants)

• Sans permission (n'importe qui peut rejoindre sans approbation)

• Décentralisé (aucune autorité centrale)

Puis en 2008, quelqu'un se faisant appeler Satoshi Nakamoto a prouvé qu'ils avaient tort.

Bitcoin : la première blockchain

Bitcoin a été la première implémentation pratique de la technologie blockchain. Bien que les composants individuels existaient auparavant (hachage cryptographique, signatures numériques, réseaux pair-à-pair), Satoshi a été le premier à les combiner pour résoudre le problème de la double dépense pour la monnaie numérique.

La blockchain, ou "chaîne de blocs" comme elle était appelée dans le livre blanc original de Bitcoin, a finalement créé un système qui était à la fois distribué, tolérant aux pannes byzantines et sans permission.

La percée n'était pas d'essayer d'identifier à qui faire confiance, mais de rendre le mensonge économiquement plus coûteux que la vérité. La preuve de travail (Proof of Work) y parvient en obligeant les participants à dépenser une réelle énergie de calcul pour proposer des changements. Un attaquant devrait dépenser plus en électricité qu'il ne pourrait gagner par une attaque.