Raphael Thys
Par Fabrice Le Fessant & Thomas Sibut-Pinote, OcamlPro
Dans cet article, après avoir rappelé ce qu’est une blockchain, nous affirmons l’importance que prendra la performance dans les prochaines années dans ce domaine, en particulier le débit et la latence de la blockchain, au travers de mécanismes assez peu répandus que sont finality immédiate, garantissant le caractère immédiatement irréversible de l’ajout d’un bloc, et le state sharding, permettant de diviser la gestion de la blockchain entre tous ses validateurs. Nous présentons aussi Free TON, une jeune blockchain qui est l’une des seules à présenter ces deux mécanismes dans une plateforme fonctionnelle et mature. La communauté Dune Network, un fork de Tezos[1], a fait le choix de s’allier avec cette blockchain pour associer à la performance hors-normes de Free TON leurs compétences en vérification et en outillage.
Introduction
Lors d’un récent séminaire en ligne sur la blockchain, organisé par le GT Blockchain du pôle Systematic, les discussions ont dévié sur l’importance pour une blockchain publique du nombre de validateurs qu’elle utilise. Ainsi, une blockchain comme Tezos affiche près de 400 validateurs, quand d’autres ne disposent que de quelques dizaines. On pourrait en déduire, à tort, que plus le nombre de validateurs est important, plus la blockchain est puissante et efficace. C’est en fait presque le contraire : s’il faut un nombre important de validateurs pour garantir la résistance de la blockchain à certaines attaques, leur nombre est par contre une entrave à l’efficacité, tant qu’il n’existe pas un mécanisme, appelé sharding, pour lui en faire bénéficier. Peu de blockchains disposent aujourd’hui de ce mécanisme, qui, d’après l’analyse que nous faisons dans cet article, est pourtant indispensable pour garantir l’utilisabilité de la blockchain dans le temps et donc la pérennité des applications qui l’utilisent. C’est aussi un mécanisme qui est presque impossible à ajouter a posteriori : au moment où beaucoup d’entreprises font le choix d’une blockchain pour déployer leurs futures applications, c’est un critère qu’il faut mettre au premier niveau. Nous présentons, en fin d’article, quelques blockchains qui proposent ce mécanisme, comme Free TON, la version open-source de la blockchain de Telegram.
Cette métrique du nombre de validateurs est historiquement liée au critère de décentralisation, cher à Satoshi Nakamoto, l’inventeur du Bitcoin. La décennie passée a connu une sorte d’explosion cambrienne de blockchains et d’algorithmes de consensus décentralisés qui, pour beaucoup, ont fait leurs preuves. En parallèle du raffinement de ces algorithmes, des efforts conséquents ont été consacrés à repousser les limites pratiques des applications des blockchains.
Chez OCamlPro, nous avons acquis une expérience conséquente dans le développement d’applications pour Tezos et Dune Network[2] ces dernières années. Comme on peut s’y attendre étant donnés les développements de l’informatique ces dernières décennies, nous soulignons l’importance de deux critères : d’une part la performance (puissance de calcul, stockage et débit pour pouvoir supporter un maximum d’utilisateurs), et la latence (la vitesse à laquelle une transaction est garantie, cruciale pour l’interactivité en temps réel de l’application). À ces enjeux attendus s’en ajoute un autre, spécifique aux blockchains, la finalité, terme que nous définirons plus loin.
Après un rappel de l’historique et du fonctionnement d’origine d’une blockchain, nous examinerons, à travers quelques propositions de blockchains actuelles, comment se matérialisent ces enjeux de performance, notamment à travers la notion de sharding. Nous verrons que le sharding suppose de repenser complètement l’architecture des contrats et de leurs interactions ; que si l’on souhaite passer à l’échelle, il ne suffit pas d’adapter des smart contracts existants ; en somme, qu’il faut choisir en amont la bonne infrastructure.
Rappels sur la blockchain : Bitcoin et les bases de la blockchain
Une blockchain peut être décrite comme une base de données distribuée.
Comme toute base de données, sa spécificité est que, à tout moment, son état peut être recalculé en exécutant toutes les opérations émises depuis sa création : ces opérations, ou transactions, sont stockées dans des blocs, chaînés cryptographiquement les uns aux autres depuis un bloc initial, dit bloc genesis. Cet enchaînement cryptographique entre les blocs garantit l’immuabilité de la blockchain, i.e. que ces blocs ne seront jamais altérés dans le futur.
Les nouveaux blocs sont produits à intervalles réguliers par des serveurs, les nœuds validateurs, qui doivent se mettre d’accord pour n’élire qu’un seul bloc à la suite du précédent, utilisant pour cela un protocole de consensus. Selon les blockchains, la puissance requise pour être un validateur varie entre celle d’un simple ordinateur de bureau, celle d’un serveur évolué ou encore celle d’un réseau de processeurs spécialisés. Ainsi les premiers blocs de Bitcoin étaient vraisemblablement “minés” (c’est le terme consacré pour la production de blocs) sur un ordinateur portable en 2009 par Satoshi Nakamoto, le mystérieux inventeur de cette cryptomonnaie ; aujourd’hui, des hangars entiers remplis de machines (ASIC) spécialisées, consommant en cumulé dans le monde l’équivalent en électricité de pays entiers, sont nécessaires à toute entreprise rentable de minage sur le réseau Bitcoin.
L’usage du terme de “transaction” pour les opérations n’est pas anodin, alors que ce terme coexiste dans les domaines des bases de données et de l’économie. En économie, accomplir une transaction, c’est transférer de l’argent d’une partie à une autre ; vu autrement, c’est opérer une modification dans un livre de compte (celui d’une banque par exemple) qui retranche au solde de l’acheteur ce qu’elle crédite à celui du vendeur. Une transaction de base de données est une généralisation de cette opération particulière qu’est une transaction financière : c’est la modification du livre de compte généralisé qu’est la base de données. Dans Bitcoin donc, les deux sens du mot “transaction” sont essentiellement confondus dans la mesure où les blocs ne contiennent que des transactions financières. Ces transactions sont libellées en bitcoins, la (crypto) monnaie associée, qui est inséparablement le but et le carburant de la blockchain.
La blockchain est aussi complètement distribuée. Le graal poursuivi et atteint par Satoshi Nakamoto consistait à produire une monnaie numérique décentralisée, c’est-à-dire ne dépendant d’aucune entité singulière pour son fonctionnement, ce qui excluait que la base de données de ses transactions soit stockée sur un serveur en particulier. Aussi décida-t-il que la blockchain serait répliquée, sur tous les nœuds du réseau Bitcoin. Cela signifie, c’est important pour la suite, que tous les nœuds stockent toutes les transactions du réseau Bitcoin depuis sa création en janvier 2009. On parle bien ici de plusieurs centaines de gigaoctets, rien qu’au format brut; cela ne signifie pas nécessairement que Bitcoin ne passe pas à l’échelle, mais il est certain que certaines applications des blockchains doivent trouver d’autres solutions.
Il est évidemment crucial que tous les nœuds possèdent, éventuellement après une courte période de discussion, des copies rigoureusement identiques de la blockchain: tout désaccord entre les nœuds sur l’existence ou les paramètres d’une transaction serait fatal à la confiance en Bitcoin. Il faut donc un protocole pour mettre d’accord entre eux les nœuds qui peuvent être en nombre arbitraire, qui en règle générale ne se connaissent pas, et ne se font pas confiance.
La solution proposée par Satoshi Nakamoto, souvent dénommée “consensus de Nakamoto” ou à l’origine “proof-of-work”, preuve de travail, consiste à mettre en compétition les producteurs de blocs — les “mineurs” — pour résoudre des problèmes mathématiques volontairement inutiles et coûteux: toutes les dix minutes en moyenne, le vainqueur de cette course obtient le droit de produire le prochain bloc et touche une récompense, la première transaction du bloc en question, pour son effort. Cette récompense constitue donc une incitation, pour les mineurs, à contribuer à la production des blocs de Bitcoin, en dépensant, si c’est rentable, de l’électricité et du matériel de minage.
Or la régularité en moyenne de la production des blocs, toutes les dix minutes, se fait au prix d’un ajustement permanent de la difficulté de minage (c’est-à-dire, étant donnée une machine de puissance fixe, la difficulté à trouver une solution au problème mathématique du moment pour miner un bloc): lorsque la blockchain “voit” que les blocs sont produits trop rapidement — par exemple en raison de l’augmentation de la puissance des derniers circuits spécialisés –, elle augmente cette difficulté. Il s’agit d’une course à l’armement permanente, consommant aujourd’hui plus d’électricité que toute l’Argentine.
Par ailleurs, le matériel nécessaire au minage est de moins en moins à portée des petites structures. Par conséquent, le réseau Bitcoin se centralise depuis des années autour de quelques énormes “fermes” de minage qui en contrôlent de fait sa gouvernance, nom que l’on donne au processus d’amendement du fonctionnement de Bitcoin, régi collectivement par le logiciel que choisissent d’utiliser la majorité (pondérée par leur puissance de calcul) des mineurs.
La finality des transactions (nous faisons le choix d’utiliser le terme anglais dans cet article, le terme finalité étant un faux ami puisqu’il indique le but, et non le caractère final), c’est-à-dire leur caractère permanent, immuable, après leur introduction dans la blockchain, est un critère important, puisqu’un vendeur ne souhaite pas s’exposer à voir son paiement annulé après le transfert d’un bien et le départ du client. Or la finality, dans le proof-of-work, n’est que probable: elle repose sur la quantité de “travail”, c’est-à-dire de puissance de calcul (donc de matériel et d’électricité) qu’il faudrait pour produire une blockchain alternative susceptible de convaincre les validateurs, soit ici l’ensemble des nœuds. Cette quantité de travail, si la blockchain est correctement décentralisée, c’est-à-dire si aucun acteur ne dispose d’une quantité critique de puissance de calcul, est en général dissuasive: la finality d’une transaction Bitcoin donnée est extrêmement probable, mais l’existence de contre-exemples est suffisante pour poser problème en pratique. La plupart des applications attendent que plusieurs blocs soient construits au-dessus de la transaction pour la considérer définitive, ce qui peut prendre plusieurs dizaines de minutes, voire plusieurs heures. Cela n’a pas empêché, dans le passé, des blockchains de plus petites tailles de subir des attaques, dites à 51%, où le caractère définitif d’une transaction était remis en cause, permettant à l’attaquant de récupérer sa mise malgré toutes les précautions de l’application. Nous verrons dans la suite qu’il existe des blockchains qui fournissent une finality immédiate et s’affranchissent ainsi de telles attaques.
Ethereum et les smart contracts
Vitalik Buterin et Gavin Wood semblent être les premiers à avoir réalisé pleinement le caractère contingent de la coïncidence, dans Bitcoin, entre “transaction” au sens des bases de données et “transaction” au sens de l’économie. Ils ont proposé que le “livre de compte” qu’est la blockchain ne rende pas seulement compte des soldes des utilisateurs, mais d’un état arbitrairement compliqué, dont le solde ne serait plus qu’un élément parmi d’autres, et qui puisse être modifié par les transactions selon les règles d’un programme informatique appelé smart contract, lui-même stocké sur la blockchain, donc immuable dans le temps. Il s’agissait donc d’utiliser la structure de données décentralisée qu’est la blockchain pour construire un “ordinateur mondial”, accessible à n’importe qui, en payant pour le calcul et pour le stockage.
La première version d’Ethereum, en 2015, reproduit les ingrédients principaux de Bitcoin: la preuve de travail (proof of work) et le stockage uniforme de toutes les transactions par tous les nœuds. La preuve d’enjeu (proof of stake) est rapidement proposée comme horizon pour y remplacer la preuve de travail, même s’il faudra attendre mars 2021 pour que son adoption dans Ethereum débute. Cette preuve d’enjeu consiste à transformer la validation de la blockchain (i.e. la production de blocs), d’une compétition fondée sur la puissance de calcul qu’est le minage, en une répartition du travail de validation selon les fonds bloqués par chaque validateur sur la blockchain. Comme dans la preuve de travail, cette compétition est encouragée par la perspective d’une récompense. Ces fonds sont alors sujets à confiscation en cas de comportement “déloyal” (celui qui consisterait à valider deux chaînes en parallèle).
Ethereum connaît un grand succès et donne lieu à des centaines de projets d’applications décentralisées (ou Dapps), mais, comme c’est souvent le cas à la première tentative, il révèle de nombreux écueils, parmi lesquels le manque de sécurité pour des programmes qui manipulent parfois jusqu’à des centaines de millions de dollars. Simultanément, les problèmes de passage à l’échelle de Bitcoin, dont explose le nombre de transactions puis, par ricochet, le prix moyen de la commission de transaction, conduisent à une crise de la gouvernance, centrée symboliquement sur la question de la taille des blocs. Ethereum n’est pas en reste, des applications comme les Cryptokitties[4] font s’effondrer le réseau, montrant la difficulté de concevoir une blockchain qui passe à l’échelle, puisque ces problèmes sont toujours d’actualité.
Les blockchains et la performance
Pour une application, la performance d’une blockchain va s’exprimer suivant deux critères principaux : son débit, le nombre de transactions par seconde qu’elle peut traiter, et sa latence, le temps qu’il faut pour qu’une transaction soit confirmée à l’utilisateur. En effet, le débit limite à la fois le nombre d’utilisateurs, le nombre d’opérations, mais aussi la complexité des traitements que requièrent ces opérations. La blockchain étant partagée entre toutes ses applications, ces nombres se cumulent entre elles : plus une blockchain a d’applications, plus son débit sera limitant pour celles-ci. La latence limite, elle, l’utilisabilité de l’application : si certaines applications peuvent s’accommoder d’une latence de plusieurs minutes ou heures, beaucoup d’applications requièrent une confirmation après quelques secondes ou minutes, au maximum, sous peine de pertes de clients et de chiffre d’affaires.
Si on observe les débits de Bitcoin et Ethereum, les blockchains de loin les plus utilisées, on voit que Bitcoin est limité à environ 5 transactions par seconde, tandis qu’Ethereum en permet un peu plus de 16 par seconde, soit 1,4 million par jour. Pour les latences, le plus simple est d’examiner les latences imposées par les échanges, tels que Binance, sur les imports/exports pour la plupart des cryptomonnaies : il faut ainsi souvent attendre une heure pour une transaction Bitcoin, une demi-heure sur Ethereum.
Il est important de remarquer, à ce stade, que la latence est bien la durée pour qu’une opération soit confirmée, définitivement, sans possibilité que le réseau décide ensuite de modifier la blockchain pour supprimer cette opération. C’est une durée bien différente de la mesure plus habituelle de l’écart entre les blocs, qui mesure lui uniquement le temps qu’une opération met pour apparaître sur la blockchain. Ainsi, si cet écart est seulement d’une minute entre blocs pour Tezos, Binance impose d’attendre 30 blocs après l’opération pour que celle-ci soit suffisamment confirmée, soit une latence de 30 minutes, toujours pour Tezos.
Débit et latence ont aussi un autre effet pervers sur la blockchain: parce qu’elles engendrent un temps d’attente avant qu’une transaction soit incluse sur la blockchain, elles créent une compétition entre les transactions, qui impose aux utilisateurs de payer plus cher le carburant, le “gas” en tokens, pour que les validateurs privilégient leur transaction plutôt que d’autres. Au moment où beaucoup de blockchains assez peu utilisées mettent en avant le faible coût de leur carburant (souvent une combinaison du faible cours du token et du faible coût qu’imposent temporairement les validateurs), il faut avoir conscience que cet argument s’effondrera dès que la blockchain sera utilisée par de vraies applications, sauf pour les quelques blockchains disposant des mécanismes de finality immédiate et de sharding que nous décrivons dans la suite, et qui permettent de s’affranchir de ces limitations.
Latence et finality immédiate
Intéressons-nous donc aux solutions qui existent pour résoudre le problème de la latence. La première solution, quand une blockchain ne résout pas elle-même ce problème, est de le résoudre au niveau de l’application. Dans la vie de tous les jours, la latence est aussi un problème, un transfert entre banques ou un paiement par carte bancaire ne sont pas immédiats, mais il existe des mécanismes de compensation, qui permettent de donner aux commerçants une illusion proche. De tels mécanismes peuvent être adaptés aux applications de blockchains, permettant à celles-ci de prendre le temps d’attendre une confirmation, même si un retour est fait immédiatement à l’utilisateur. Il y a bien évidemment une prise de risque, qui devra être compensée économiquement. Il existe aussi des protocoles permettant de fournir des garanties identiques, mais sans prise de risque : ces “protocoles de niveau 2” (layer-2 protocols) permettent des transactions hors blockchain, donc beaucoup plus rapides, mais s’appuyant sur la cryptographie de la blockchain, qui sont ensuite insérées sur la blockchain, souvent dans un format condensé (une seule opération sur la blockchain peut alors représenter de multiples échanges hors blockchain). Néanmoins, tous ces mécanismes (chambres de compensation aussi bien que protocoles de niveau 2) restent limités à des opérations relativement simples, souvent de simples transferts de tokens, et peuvent difficilement être adaptés à des traitements plus complexes, pourtant permis par les smarts contracts.
Heureusement, il existe des protocoles blockchain qui permettent de diminuer considérablement la latence en fournissant une garantie immédiate de non-retour en arrière, une fois un bloc accepté. Ces protocoles fournissent une finality immédiate. Pour cela, ces blockchains utilisent des algorithmes de consensus de type PBFT (Practical Byzantine Fault Tolerance), qui, au prix d’exigences plus fortes sur la puissance des noeuds validateurs, permettent de garantir qu’un bloc validé ne sera jamais invalidé par la suite. Les blockchains Cosmos et Free TON[3] utilisent de tels protocoles, tels Tendermint pour Cosmos. Ainsi, un import ou export de tokens pour ces blockchains sur un échange est confirmé en à peine quelques secondes, quand la plupart des autres blockchains laisseront l’utilisateur attendre une heure. D’autres blockchains ont choisi de garder un protocole plus classique, certes en le modifiant pour cela, et d’ajouter une extension, un “gadget”, qui fournit séparément une forme de finality, pas forcément immédiate, mais quasi. C’est le cas du futur Ethereum 2.0, qui utilisera un gadget appelé “Casper FFT”[8], ou de Polkadot[9], qui utilise déjà le gadget GRANDPA. Dans les deux cas, seule la sortie du gadget est garantie ne pas pouvoir être invalidée, mais celle-ci peut être légèrement en retard sur l’avancement de la blockchain elle-même.
Tous ces protocoles ou gadgets fonctionnent de la même façon, autour d’un algorithme de PBFT[10] exécuté de façon répétitive sur chaque bloc ou groupe de blocs : un sous-ensemble des validateurs est sélectionné pour participer à chaque itération, car le coût d’inclure l’ensemble des validateurs serait prohibitif (quadratique dans leur nombre), cette sélection est effectuée en fonction de cautions (“deposits”) que font ces validateurs et change régulièrement ; durant l’itération, les validateurs vont ensuite alterner des phases, proposant des blocs, sélectionnant souvent un leader, votant pour les blocs, et, quand une majorité des deux tiers est atteinte, considérant le vote terminé. La littérature autour des ces algorithmes est très fournie, ancienne et toujours très active, et les variations sont souvent assez subtiles pour ne pas pouvoir être décrites ici.
Il faut noter aussi que la finality immédiate ne résout pas totalement le problème de la latence : une blockchain dont le débit est limitée, soit par l’écart entre les blocs, soit par le nombre de transactions par bloc, soit par sa capacité à traiter les blocs, imposera forcément une autre forme de latence, liée à la compétition entre les opérations pour être incluses dans les futurs blocs. Ainsi, certaines opérations sur Bitcoin et Ethereum peuvent attendre plusieurs dizaines de minutes avant même d’être considérées pour être incluses, voire même ne jamais l’être.
Résoudre le problème de la finality sans résoudre celui du débit n’est donc pas une solution au problème plus général de la latence.
Débit et sharding
Puisque la latence ne peut être totalement résolue sans résoudre le problème du débit aussi, nous pouvons considérer les solutions proposées pour celui-ci.
D’une façon générale, le débit d’une blockchain, le nombre de transactions par seconde qu’elle est capable de traiter et de mémoriser, est limité par trois principaux facteurs :
– Le temps de transmission sur le réseau des données liées aux transactions entre les validateurs. Pour que tous les validateurs soient capables d’accepter un bloc, ils doivent vérifier les transactions qui le composent, et doivent donc être en possession, non seulement des données de la transaction elle-même, mais aussi de l’ensemble de l’état de la base de données sur lequel se base la transaction, souvent des centaines de gigaoctets de données. Il y a quelques années, Bitcoin a ainsi été au centre d’une véritable guerre entre utilisateurs et validateurs, entre autres parce que ces derniers, pour la plupart basés en Chine, préféraient garder un débit limité pour pallier le faible débit de leur connection avec le reste du monde;
– Le temps pour atteindre un consensus entre validateurs. En fonction du protocole de consensus choisi et de la puissance exigée des validateurs, ce temps peut varier énormément. Ainsi, il est de 10 minutes sur Bitcoin et d’une quinzaine de secondes sur Ethereum, tous deux fonctionnant en preuve de travail (PoW). Coté preuve d’enjeu (PoS), le protocole Emmy+ de Tezos fournit au mieux un bloc par minute, tandis que Tendermint, pour Cosmos[5], en fournit un toutes les 5 secondes, avec finality immédiate, et 3 secondes pour Free TON.
– Le temps de traitement d’une transaction. Ce temps varie considérablement en fonction de l’expressivité de la blockchain : ainsi, Bitcoin ne supporte que des transactions extrêmement simples, ce qui permet aux nœuds un traitement très rapide, tandis que la plupart des autres blockchains mettent en avant des langages de smart contracts très riches et expressifs (Solidity, Michelson, Wasm, etc.), mais souvent coûteux et lents à exécuter. Pour cette raison, certaines blockchains mettent en avant les performances de leurs nœuds, comme Solana[11] qui déporte les calculs sur GPUs, ou Ethereum et Free TON qui déploient des nœuds en Rust, beaucoup plus performants et bénéficiant mieux du multicœur.
A priori, la plupart de ces temps ne peuvent être que modérément diminués. Ce n’est pourtant pas la première fois dans l’histoire de l’informatique que les temps d’exécution paraissent incompressibles: l’exécution concurrente a permis de franchir cette barrière, par le calcul distribué et le parallélisme/multi-cœur. Dans le cas de la blockchain, ou des bases de données distribuées, cela s’appelle le sharding, une technique que tous les grands sites web utilisent pour pouvoir gérer leurs millions d’utilisateurs.
Dans le cas d’une base de données classique, le sharding consiste à découper chaque table de la base de données, pour ne stocker qu’une sous-partie dans chaque shard. Chaque shard est lui-même constitué d’un petit nombre de machines, le plus souvent en lecture seule, tandis qu’un serveur primaire gère les écritures. Lorsqu’un utilisateur se connecte au site web, il est immédiatement redirigé de façon transparente vers le shard qui contient ses données. La croissance du site web s’effectue alors tout simplement et de manière adaptative, en ajoutant de nouveaux shards à chaque fois que les shards précédents sont saturés.
Le cas de la blockchain est un peu plus complexe : d’une part, même si l’on veut découper la blockchain en une multitude de petites blockchains, il faut maintenir l’apparence d’une seule blockchain, en particulier concernant la garantie d’immutabilité des blocs passés (garantie d’infalsifiabilité de l’historique); d’autre part, la plupart des transactions n’affectent pas un seul utilisateur (comme c’est souvent le cas sur les sites web), mais plusieurs. En effet, la transaction la plus simple contient un compte créditeur et un compte débiteur, tandis qu’une transaction sur un smart contract peut déclencher un enchaînement d’appels d’une multitude de smart contracts. Il devient ainsi beaucoup plus difficile d’allouer une transaction à un seul shard.
Il existe plusieurs niveaux de sharding, que nous allons présenter dans la suite. Bien sûr, le premier niveau est tout simplement l’absence de sharding, c’est le cas le plus courant aujourd’hui, avec une blockchain unique : ainsi, Bitcoin, Ethereum, Cardano, Solana, Tezos, Algorand et tous leurs forks ne proposent aujourd’hui aucun mécanisme de sharding. Ethereum 2.0[7] est le seul à avoir inclus le sharding dans sa roadmap, prévoyant de fournir un tel mécanisme en 2021-2022, mais extrêmement limité, avec un nombre de shards très limités et dont l’utilisation se limitera dans un premier temps aux simples paiements. Au contraire, Tezos s’est affiché officiellement contre l’utilisation du sharding[15].
Le niveau suivant est le sharding statique, proposé par Cosmos et Polkadot : ces deux blockchains permettent de créer une multitude de blockchains au sein de leur écosystème, toutes ces blockchains étant liées par une blockchain principale qui enregistre l’avancement de chacune des blockchains secondaires (c’est le Cosmos Hub pour Cosmos, et la Relay Chain pour Polkadot). Néanmoins, dans les deux cas, la création d’une nouvelle blockchain est un événement très coûteux, cette nouvelle blockchain manipule un token indépendant et doit être validée par ses propres validateurs. L’idée est donc qu’une application, pour obtenir une garantie de débit, doit créer sa propre blockchain secondaire, ou en partager une avec un nombre raisonnable d’autres applications. Dans un tel système, il devient alors très compliqué de faire interagir toutes les applications entre elles, si elles sont sur des blockchains secondaires différentes. Il est aussi difficile pour les développeurs de savoir dès le départ où héberger leur application, sans savoir à l’avance le débit qu’elle nécessitera. Au final, cette forme de sharding fournit une amélioration du débit, mais qui reste limitée et pas toujours vraiment exploitable.
Zilliqa[12] fournit un sharding plus dynamique, appelé transaction sharding. Chaque nœud continue d’y stocker l’ensemble de l’état de la blockchain, mais ne traite qu’un sous-ensemble des transactions. Le shard qui va traiter une transaction est choisi en fonction de l’adresse du débiteur de la transaction, mais uniquement pour des transactions simples (paiement d’un débiteur vers un autre compte ou vers un smart contract). Toutes les autres transactions, en particulier impliquant plusieurs comptes ou smart contracts, sont exécutées par des nœuds particuliers, chargés en plus de collecter les résultats de tous les shards. Finalement, ce système offre un débit important pour des transactions simples, mais ne pourra pas abriter d’applications faisant un usage avancé des smarts contracts, sans saturer les nœuds collecteurs. Par contre, la nécessité pour chaque nœud de stocker l’ensemble de la blockchain est aussi un facteur limitant, car il impose des coûts en stockage et en communication élevés, qui limiteront tôt ou tard la capacité de la blockchain.
Enfin, le sharding ultime s’appelle le state sharding. Le state sharding consiste à découper l’état de la blockchain entre les shards, c’est à dire qu’un nœud d’un shard ne stocke qu’une petite partie de l’état de la blockchain, et ne traite que les transactions opérant sur la partie qu’il stocke. Ce sharding peut être statique, le nombre de shard est fixe et ne varie pas dans le temps, ou dynamique, si la blockchain a la capacité d’adapter le nombre de shards en fonction de l’utilisation, découpant un shard en plusieurs quand il est saturé, ou réunissant plusieurs shards quand ils sont sous-utilisés.
Peu de blockchain implantent le state sharding, nous nous sommes principalement intéressés à Free TON, auquel nous consacrons une plus longue présentation en fin d’article, et à Elrond[13], qui fournissent tous deux du sharding dynamique, tandis que NEAR[14] ne propose que la version statique du state sharding. L’approche de Free TON pousse d’ailleurs le sharding à l’extrême, en considérant les smart contracts comme de véritables agents s’échangeant des messages asynchrones comme dans un système distribué, ce qui permet d’obtenir des débits considérables, difficilement atteignables par ses concurrents.
Avec le state sharding dynamique, un shard peut se découper pour tenir la charge, telle une mitose cellulaire
Free TON, de Telegram à l’indépendance
Free TON est l’une des rares blockchains en fonctionnement qui proposent déjà la sharding dynamique et la finality immédiate. Dune Network, le fork de Tezos lancé en 2019 par Origin Labs, a récemment fait le choix de fusionner dans Free TON pour que les deux communautés puissent contribuer au succès de cette solution.
Free TON est né du projet TON, Telegram Open Network. En 2017, Pavel Durov, le fondateur de Telegram, la messagerie sécurisée qui compte à l’époque près de 180 millions d’utilisateurs, s’intéresse aux blockchains et aux crypto-monnaies. Il décide de lancer un énorme projet pour financer une plateforme de crypto-monnaies adossée à Telegram. Dès 2018, une ICO privée (Initial Coin Offering) recueille de très nombreuses offres de participation, et lève près de 1.7 milliards de dollars en deux tours, auprès d’investisseurs institutionnels. Plusieurs dizaines de développeurs sont impliqués dans le développement de la plateforme, dont le code est publié en open-source. La plateforme est construite avec l’importance de la performance en tête, pour permettre aux millions d’utilisateurs de Telegram de pouvoir l’utiliser en permanence. Un réseau de test est lancé dès 2019, mais la SEC, le gendarme de la bourse américain, attaque le projet, au prétexte que la vente des jetons, les Grams, aux résidents américains, était illégale. Après une courte bataille judiciaire, Telegram décide d’abandonner le projet début 2020 et de rembourser les investisseurs.
La communauté et une partie des développeurs décident cependant de reprendre le code, open-source, et de relancer le projet indépendamment de Telegram, sous le nom Free TON. Le token s’appelle maintenant TON Crystal. La blockchain présente toutes les qualités du projet initial de Pavel Durov, avec une capacité de passage à l’échelle peu commune, grâce au sharding dynamique, et l’utilisation de la preuve d’enjeu (Proof-of-Stake) pour limiter l’empreinte énergétique.
Faute d’ICO, le projet s’appuie pour se financer sur un système “méritocratique” : des compétitions sont lancées par les validateurs pour améliorer l’écosystème, contribuer aux logiciels et à l’adoption de la plateforme, et les gagnants de ces compétitions reçoivent des tokens, puisé dans un fond initial de 5 milliards de tokens, donc moins d’un milliard sont déjà distribués. Cette gouvernance a déjà permis de financer de nombreux projets : plateformes de swap avec Ethereum et Polkadot, vérification formelle de nombreux smart contracts, associations avec des média pour la promotion et la publicité, etc.
OCamlPro, qui avait développé le prototype de la blockchain Tezos et dont plusieurs ingénieurs avaient fondé Origin Labs et le fork Dune Network de Tezos, s’est lancé dans l’aventure Free TON, et participe aujourd’hui à plusieurs de ses projets. Notre analyse est que la plupart des choix techniques faits par Free TON donnent au projet un potentiel de passage à l’échelle qu’on ne trouve pas aujourd’hui dans les autres blockchains actuelles. Ainsi, alors que presque toutes les blockchains proposent un modèle d’exécution séquentiel pour les smart contracts, Free TON est la seule à proposer un modèle d’exécution distribuée (les smart contracts s’envoient des messages sans synchronisation), seul compatible pour obtenir un haut débit de transactions.
Choisir une blockchain sans sharding et attendre ?
Au moment où beaucoup d’entreprises s’interrogent sur la blockchain à choisir pour développer leur application, il peut être tentant de mettre le critère de la performance de côté, et de choisir en fonction d’autres critères plus simples, tels que sa célébrité (Ethereum dans le monde, Tezos en France), le prix du carburant/gas, ou encore la disponibilité de développeurs (Solidity), en espérant voir le problème de la performance se résoudre tout seul dans les versions suivantes de la blockchain.
Nous estimons que c’est un calcul risqué.
D’abord, pour faire une analogie, un logiciel conçu pour un ordinateur de bureau va-t-il automatiquement s’accélérer quand on le fait s’exécuter sur un réseau d’ordinateurs multicoeurs avec ses données réparties entre eux ? La réponse est non, un logiciel a besoin d’être conçu dès le départ pour bénéficier du multi-cœur et de la distribution. Il en va de même du sharding. Pour en bénéficier, un ensemble de smart contracts doivent être pensés pour communiquer de façon asynchrone, pour n’accéder qu’aux données locales à un shard, afin de ne pas déclencher des mécanismes coûteux de communication et de synchronisation entre les shards.
D’autre part, la capacité d’une blockchain a migré ses applications vers la finality immédiate et le sharding dynamique est loin d’être prouvée. Le projet ambitieux d’Ethereum de passer au sharding dans sa version 2.0 est un projet long (au moins 4 années), risqué (aucune solution pour le sharding des smart contracts n’est encore proposée alors que nous sommes déjà à mi-chemin) et que exclut déjà de ses plans les applications qui auront déjà été déployées (la chaîne Ethereum 1.0 sera incluse comme un unique shard dans le système). Si l’écosystème le plus actif se montre aussi prudent, il est très probable que la plupart des autres blockchains qui n’ont pas pris le sharding en compte aujourd’hui soient incapables de passer ce cap.
A propos d’Ocamlpro
OCamlPro SAS est une spin-off de l’Inria créée en 2011, son équipe d’ingénieurs-chercheurs conçoit, crée et met en oeuvre des logiciels sur-mesure pour ses clients, dans les domaines les plus variés, mais avec un accent important sur la fiabilité, la sécurité et la performance. Elle utilise pour cela une expertise poussée des langages OCaml et Rust, ainsi que des méthodes formelles, et diffuse cette expertise au travers de formations avancées. Dans le domaine de la finance, OCamlPro a conçu et implémenté le prototype de la blockchain Tezos de 2014 à 2017, et travaille avec des entreprises telles que Jane Street (HFT), Bloomberg et LexiFi. Vous trouverez plus d’informations sur : http://www.ocamlpro.com
- **
Liens: [1] Tezos. https://tezos.com/ [2] Dune Network. https://dune.network [3] Free TON Community. https://freeton.org [4] CryptoKitties craze slows down transactions on Ethereum. https://www.bbc.com/news/technology-42237162 [5] Cosmos, the Internet of Blockchains. https://cosmos.network/ [6] Terdermint. https://tendermint.com/core/ [7] Ethereum 2.0. https://ethereum.org/fr/learn/#eth-2-0 [8] Casper FFG. https://arxiv.org/abs/1710.09437 [9] Polkadot Network. https://polkadot.network/ [10] Practical Byzantine Fault Tolerance (PBFT). https://en.bitcoinwiki.org/wiki/PBFT [11] Solana. https://solana.com/ [12] Zilliqa. https://www.zilliqa.com/ [13] Elrond. https://elrond.com/ [14] NEAR. https://near.org/ [15] Scaling Tezos. https://medium.com/hackernoon/scaling-tezo-8de241dd91bd