Évolution de la Blockchain
Maintenant que vous comprenez comment fonctionnent les mécanismes de consensus et les primitives cryptographiques, explorons comment ces concepts ont évolué depuis le simple transfert de valeur de Bitcoin jusqu'aux plateformes blockchain programmables d'aujourd'hui.
Chaque blockchain majeure représente différentes décisions techniques et compromis, façonnés par les contraintes fondamentales que nous avons apprises.
Bitcoin
Bitcoin n'a pas été conçu pour être un ordinateur à usage général. En effet, il a été créé pour résoudre un problème spécifique : créer une monnaie numérique qui fonctionne sans banques ni gouvernements. Chaque décision de conception dans Bitcoin reflète cette orientation unique.
Consensus
Bitcoin utilise l'implémentation originele de la preuve de travail conçue par Satoshi. Les mineurs rivalisent pour trouver un nonce (nombre aléatoire) qui, lorsqu'il est haché avec les données du bloc, produit un hachage commençant par un nombre spécifique de zéros.
Le réseau ajuste automatiquement la difficulté tous les 2 016 blocs (environ deux semaines) afin de maintenir un temps moyen de création de bloc de 10 minutes.
Ce timing n'est pas arbitraire. Des blocs plus rapides entraîneraient des divisions du réseau, les mineurs travaillant alors sur différentes versions de la blockchain. Des blocs plus lents rendraient les transactions extrêmement lentes.
Le modèle UTXO
Bitcoin ne suit pas les soldes des comptes comme le font les banques. Au lieu de cela, il suit les "pièces" individuelles à l'aide d'UTXO (Unspent Transaction Outputs, ou sorties de transaction non dépensées), qui fonctionnent de manière similaire à l'argent liquide physique.
Imaginez que vous avez trois billets de 20$ dans votre portefeuille et que vous voulez acheter quelque chose qui coûte 35$. Vous ne pouvez pas diviser un billet de 20 $, vous donnez donc deux billets (40$) au caissier et recevez 5$ de monnaie. Le Bitcoin fonctionne exactement de la même manière :
Supposons qu'Alice ait reçu des bitcoins dans le cadre de trois transactions distinctes :
- UTXO #1: 0.5 BTC (de Bob)
- UTXO #2: 0.3 BTC (de Carol)
- UTXO #3: 0.8 BTC (de Dave)
Le "solde" d'Alice est de 1,6 BTC, mais aucun compte ne stocke ce montant. Au lieu de cela, la blockchain enregistre trois UTXO distincts qu'Alice peut dépenser.
Lorsque Alice souhaite envoyer 1,0 BTC à Eve, elle doit :
- Sélectionner les UTXO dont le total est d'au moins 1,0 BTC (elle choisit les UTXO #1 et #3, pour un total de 1,3 BTC)
- Créer une transaction dans laquelle elle envoie 1,0 BTC à Eve et 0,3 BTC à elle-même en guise de monnaie -Signer la transaction avec sa clé privée pour prouver qu'elle est propriétaire des UTXO d'entrée
La transaction consomme les UTXO #1 et #3 (qui sont désormais "dépensés") et crée deux nouveaux UTXO : un pour Eve et un UTXO de rendu de monnaie pour Alice.
Ce modèle offre des fonctionnalités puissantes :
- Traitement Parallélisable : Étant donné que chaque UTXO ne peut être dépensé qu'une seule fois, les transactions utilisant différents UTXO ne sont pas en conflit. Les mineurs peuvent valider simultanément des milliers de transactions sans se soucier des doubles dépenses, à condition que chaque transaction fasse référence à des UTXO différents.
- Confidentialité : Il n'existe aucun compte global qui indique votre solde total. Vos bitcoins sont répartis sur plusieurs UTXO, ce qui rend plus difficile pour les observateurs de déterminer votre richesse totale. Chaque UTXO peut être lié à une adresse différente, ce qui rend encore plus difficile l'identification des propriétaires.
- Vérification Simple : Chaque transaction peut être vérifiée indépendamment en vérifiant que les UTXO d'entrée existent et n'ont pas été dépensés, et que les signatures numériques sont valides. Vous n'avez pas besoin de gérer un état de compte complexe ni de vous soucier de l'ordre des transactions affectant les soldes.
- Opérations Atomiques : Une transaction réussit complètement (en consommant toutes les entrées et en créant toutes les sorties) ou échoue complètement. Il n'y a aucun risque de situation partielle où une partie de l'argent est déduite mais n'est pas transférée.
Ethereum
Alors que Bitcoin résolvait le problème des paiements numériques, Vitalik Buterin a identifié une opportunité plus importante : et si la blockchain pouvait exécuter n'importe quel programme, et pas seulement transférer de l'argent ? Cette vision a donné naissance à Ethereum : le premier ordinateur blockchain polyvalent.
Le modèle UTXO de Bitcoin fonctionne parfaitement pour les paiements, mais devient peu pratique pour les applications complexes qui nécessitent un état persistant, une logique complexe et une composabilité entre différents programmes.
Consensus
Ethereum utilisait à l'origine le Proof of Work, mais est passé au Proof of Stake en 2022 lors de "The Merge." Cette transition a permis de maintenir la sécurité tout en apportant des avantages cruciaux :
- Finalité Mathématique : Après environ 13 minutes, les transactions deviennent mathématiquement irréversibles
- Efficacité Énergétique : Fini la consommation massive d'électricité
- Mises à Niveau Futures : Le Proof of Stake permet le sharding : la division du réseau en chaînes parallèles pour un débit plus élevé.
Le Modèle de Compte
Ethereum a remplacé le système UTXO de Bitcoin par des soldes basés sur des comptes, ce qui permet :
- Contrats Intelligents (Smart Contracts) : Programmes qui résident sur la blockchain et gèrent leur propre état
- Comptes Externes : Comptes contrôlés par l'utilisateur, tels que les adresses Bitcoin
- Appels Inter-Contrats: Les contrats intelligents peuvent interagir entre eux de manière transparente
Sur Ethereum, il existe deux types de comptes :
- Comptes Détenus par des Entités Externes (Externally Owned Accounts ou EOAs): Contrôlé par les utilisateurs à l'aide de clés privées, à l'instar des adresses Bitcoin. Ils disposent d'un solde et peuvent envoyer des transactions.
- Comptes de Contrats : Contrôlé par du code et non par des clés privées. Ils ont un solde ET stockent du code exécutable ainsi que des données persistantes.
Pour cette raison, sur Ethereum, les contrats intelligents sont des programmes autonomes qui résident sur la blockchain, gèrent leur propre état et peuvent être appelés par d'autres comptes.
Ce modèle de compte permet un état persistant, c'est-à-dire des données qui survivent d'une transaction à l'autre. Un contrat intelligent peut mémoriser les informations issues d'interactions précédentes, gérer des structures de données complexes et évoluer au fil du temps.
Cela rend possibles des applications telles que les protocoles de prêt, les systèmes de gouvernance et les instruments financiers complexes.
Tout cela est possible grâce à la Machine Virtuelle Ethereum (EVM), qui fonctionne sur chaque nœud et rend la blockchain programmable. Elle définit les programmes qui peuvent être exécutés, leur mode d'exécution et les ressources qu'ils consomment.
Solana
Ethereum a démontré que les blockchains pouvaient prendre en charge des calculs à usage général, mais ce succès a révélé des contraintes en matière de scalabilité. À mesure que les applications décentralisées ont gagné en popularité, la congestion du réseau a entraîné des frais de transaction élevés et des délais de confirmation plus longs.
Ces limitations découlaient de décisions architecturales fondamentales prises lors de la conception d'Ethereum, auxquelles Solana tente de remédier grâce à des innovations architecturales en repensant les composants essentiels de la blockchain à partir des principes de base.
Consensus
Solana utilise le Proof of Stake, mais y ajoute une innovation cruciale : le Proof of History. Au lieu d'attendre un consensus sur le moment où les événements se sont produits, Solana crée une horloge cryptographique qui horodate toutes les transactions avant le consensus, permettant ainsi aux validateurs de traiter les transactions en parallèle puisqu'ils connaissent déjà l'ordre correct.
Cet ordre temporel permet d'atteindre un consensus beaucoup plus rapidement : Solana produit des blocs toutes les 400 millisecondes, contre 12 secondes pour Ethereum.
Machine Virtuelle Solana
L'EVM traite les transactions de manière séquentielle car les contrats intelligents partagent un état global : lorsqu'un contrat modifie des données partagées, toutes les autres transactions doivent attendre. Cela crée des goulots d'étranglement à mesure que l'utilisation du réseau augmente.
Solana repense fondamentalement cette architecture :
- Programmes sans État : Contrairement à Ethereum, où les contrats intelligents stockent les données en interne, les programmes Solana sont sans état. Toutes les données sont stockées dans des comptes distincts que les programmes lisent et dans lesquels ils écrivent. Cette séparation permet un traitement parallèle car les programmes ne se disputent pas un état partagé.
- Parallélisation des Transactions : Les transactions Solana doivent déclarer à l'avance les comptes qu'elles vont lire et modifier. Le runtime peut alors exécuter simultanément des transactions non conflictuelles sur plusieurs cœurs CPU. Si la Transaction A modifie le compte X et la Transaction B modifie le compte Y, elles peuvent s'exécuter en parallèle.
- Exécution Optimisée : Le SVM utilise une architecture basée sur des registres plutôt que l'approche basée sur une pile de l'EVM, ce qui réduit la charge liée au déplacement des données pendant le calcul. Les programmes sont compilés en code machine natif plutôt qu'en bytecode ce qui élimine la charge supplémentaire liés à l'interprétation.
- Coûts Prédictibles : Au lieu des prix fixes du gaz d'Ethereum déterminés il y a plusieurs années, Solana utilise des marchés de frais dynamiques où les coûts de transaction reflètent la demande réelle du réseau et les ressources informatiques consommées.
Le résultat est que Solana peut traiter plus de 5 000 transactions par seconde (TPS) contre 15 TPS pour Ethereum, tout en conservant une finalité inférieure à la seconde et la décentralisation. Cette performance résulte de choix architecturaux qui privilégient l'exécution parallèle au modèle de traitement séquentiel hérité de l'informatique monothread.