Pour beaucoup, la blockchain reste encore une sorte de boîte noire. Il faut dire que ce terme est très utilisé, souvent sans être expliqué. Dans cet article, nous allons vous présenter la blockchain au niveau macro. Plus particulièrement, vous allez découvrir quels sont les 3 enjeux principaux sur lesquels les développeurs blockchain planchent. Vous comprendrez aussi pourquoi on parle souvent d’un « trilemme de la blockchain ».
Le triangle de la blockchain : scalabilité – sécurité – décentralisation
Une blockchain doit satisfaire trois grand critères : la scalabilité, la sécurité et la décentralisation. Qu’est-ce que cela veut dire ?
Commençons par la scalabilité. Ce terme définit la capacité d’une blockchain à gérer un grand nombre de transactions. La scalabilité s’exprime en TPS, c’est-à-dire « Transactions Par Seconde ». Par exemple, à l’heure actuelle, le Bitcoin a une scalabilité de 7 à 10 TPS, l’Ethereum de 30 TPS et le Solana de 2008 TPS.
L’autre grand critère est la sécurité. Cela correspond à la capacité d’une blockchain de continuer à fonctionner même dans le cas où une partie de son réseau est compromis.
Le dernier critère est la décentralisation et porte sur le nombre de nœuds du réseau. Plus un réseau est étendu et moins il est centralisé.
Une blockchain est développée autour de ces trois critères, autrement dit elle s’inscrit au sein du triangle : sécurité – scalabilité – décentralisation. Or, les développeurs blockchain vous le diront : ces trois critères sont impossibles à satisfaire simultanément. Pourquoi ? C’est là où il est nécessaire de parler du théorème CAP.
Le théorème CAP, précurseur du trilemme blockchain
On pourrait l’oublier, mais la blockchain est tout sauf un ovni technologique. La blockchain fait appel à des notions d’informatique, de programmation et de cryptographie. Aussi, certains problèmes rencontrés par la blockchains ne sont pas nouveaux et étaient déjà présents en informatique. En l’occurrence ce triangle de la blockchain évoqué ci-dessus est en réalité issu du théorème CAP.
Qu’est-ce que le théorème CAP ?
La théorie derrière ce théorème remonte à 1998. On la doit à Eric Brewer, informaticien scientifique à l’université de Berkeley (Californie). La théorie devint officiellement un théorème en 2022 après sa validation par Seth Gilbert et Nancy Lynch du MIT. Dans la littérature, on parle du théorème CAP comme du théorème Brewer également.
Alors que dit ce théorème ? CAP est un acronyme pour :
- Consistency (ou « cohérence ») : Cela désigne la capacité d’un réseau à renvoyer la même information pour une même requête même si celle-ci est adressée à différents nœuds. Autrement dit, tous les nœuds possèdent la dernière information en date.
- Availability (ou « disponibilité ») : Ce critère définit la capacité d’un réseau à rester disponible même si une partie est en panne.
- Partition Tolerance (ou « tolérance à la partition ») : Cette propriété concerne la capacité d’un réseau à continuer à fonctionner même si la communication entre certains nœuds est rompue.
Pour Brewer, un réseau distribué (exemple : une base de données) ne peut pas satisfaire pleinement ces 3 critères. Tout est une histoire de compromis. D’après ce théorème, un réseau ne peut que satisfaire que 2 critères et donc délaisser le troisième.
Illustration du théorème CAP
Prenons un exemple simplifié pour illustrer ce théorème.
Imaginons un réseau qui comporte deux nœuds (A et B). L’utilisateur écrit une valeur X au nœud A (dans notre exemple : 10) puis demande cette valeur au nœud B. Prenons le cas où il se produit une rupture de réseau entre le nœud A et B (voir illustration ci-dessus). Le réseau va continue de fonctionner, il assure donc la propriété « P », c’est-à-dire « Partition tolerance / tolérance à la partition ». Mais qu’en est-il des deux autres propriétés ?
C’est là où le réseau doit faire un choix. Les deux options suivantes s’offrent à lui :
- Il traite les deux requêtes (écriture et lecture) de l’utilisateur. Dans ce cas, on dit que le réseau assure la propriété de « A » ou « Availability / Disponibilité ». Par contre, l’utilisateur ne va pas lire la dernière valeur qu’il a écrite puisque le transfert des données entre le nœud A et B est rompu. Le réseau n’assure donc pas la propriété « C » ou « Consistency / Cohérence ».
- Le réseau ne traite pas les deux requêtes. Dans ce cas, la propriété « C » ou « Consistency / Cohérence » est assurée au détriment de « A » ou « Availability / Disponibilité ».
L’application du théorème CAP à la blockchain
Le triangle (ou trilemme) blockchain découle directement du théorème CAP. Rien de très étonnant lorsqu’on se rappelle qu’une blockchain n’est qu’un réseau distribué « décentralisé ». En fait, on peut considérer le trilemme blockchain comme l’application du théorème CAP à la blockchain.
Les trois propriétés considérées deviennent alors comme mentionné ci-dessus : sécurité – scalabilité – décentralisation. En revanche, le principe reste le même, à savoir qu’une blockchain ne peut satisfaire que deux de ces propriétés.
Pour illustrer, prenons quelques exemples de blockchains bien connues :
- L’Ethereum a clairement fait le choix de la décentralisation et de la sécurité. Par contre, la blockchain pèche par sa scalabilité (environ 30 TPS) comme en témoigne la flambée de ses frais de gas ;
- Le Solana, de son côté, est une blockchain décentralisée et très scalable. Au moment de la rédaction de cet article, la scalabilité est de 2008 TPS. En revanche, le Solana fait face à de nombreux problèmes de sécurité.
- Prenons un dernier exemple avec le Bitcoin Cash (BCH). Pour améliorer sa scalabilité et se démarquer de son grand frère le Bitcoin, la crypto BCH a choisi d’augmenter la taille de ses blocs. De ce fait, la blockchain était en mesure de traiter plus de transactions par bloc. Par contre, cela s’est fait au détriment de la sécurité.
Sur le même sujet :
- La mise à l’échelle de la technologie des chaînes de blocs et les compromis du trilemme
- Scalabilité Ethereum : Vitalik Buterin propose d’utiliser Bitcoin Cash
- Des craintes sur la décentralisation d’Ethereum ?
Partager
Kévin Comitogianni
Rédacteur
