L’arrivée prochaine de la mise à jour The Merge de la blockchain Ethereum a relancé les discussions sur les différentes solutions possibles pour résoudre le trilemme des blockchains: Comment concilier décentralisation, scalabilité et sécurité. La congestion d’Ethereum et les performances des blockchains en Proof of Scale ont fait croire que ces dernières étaient le remède miracle. Pourtant, on s’aperçoit que même elles ont besoin de réseaux secondaires qui ont pour but de décharger le réseau principal. Les layers 2 s’imposent donc comme une nécessité. Mais si on ne pense pas simplement le problème pour une seule blockchain mais pour l’écosystème blockchain dans son ensemble, il faut ajouter aux trois exigences du trilemme celle de l’interopérabilité, ce qui a fait émerger la problèmatique des layers 0, ces couches qui permettraient une communication globale entre les blockchains. Avant d’examiner quelques solutions, il est sans doute nécessaire de redéfinir ces différentes couches de l’architecture blockchain.

• Ethereum: layer 1, smart-contract et layer 2
• La problématique des bridges
• Nervos: une réponse aux quatres exigences ?
• Milkomeda: des side-chains dediées aux EVM
• Polkadot, une verticalité repensée
• Cosmos, un écosystème sans layer
• Axelar

Ethereum, layer 1, smart-contract et Layer 2

La problématique des layers ne fait qu’un avec l’histoire d’Ethereum. L’arrivée des smart-contracts sur le réseau a en effet inauguré la superposition de couches dans l’architecture blockchain. En effet, sans smart-contract, une blockchain n’existe que sur un seul axe horizontal, chaque bloc indiquant l’état de chaque compte ouvert sur le réseau à un instant donné. Avec les smart-contracts, ces contrats intelligents automatisés, le réseau commence à gagner en verticalité. En effet, les dapps vont utiliser ces smart-contracts pour faire des transactions plus complexes sur le réseau et créer les tokens (qu’il faut distinguer des coins, les monnaies natives de chaque réseau). On peut par exemple indiquer dans un smart contract qu’on crée un token A qui a une supply de 1 milliards. Mais aussi que 1000 jetons de ce token seront brûlés pour acheter un NFT. Même si on ne parlait pas encore de layer lors de l’arrivée des smart-contracts, on peut déjà considérer que les dApps sont une couche supplémentaire qui doit communiquer avec le réseau par l’intermédiaire des nodes. Cependant, cette couche va devenir peu à peu un obstacle à la fluidité de la blockchain. Une fois qu’un smart-contract est déployé, il continue à fonctionner indéfiniment, et leur multiplication va donc peu à peu encombrer la blockchain. De plus, la complexité des transactions qu’ils mettent en œuvre peut congestionner la blockchain. La blockchain Ethereum a été la première victime de ce problème à partir de 2019, lors de la montée en puissance de la finance décentralisée. Peu à peu les transactions sont devenues moins rapides et les frais de transactions ont augmenté. 

On a cru dans un premier temps que l’utilisation d’un consensus en Proof of Work était responsable de cet état de fait. On avait la décentralisation et la sécurité au détriment de la scalabilité. C’est pourquoi d’autres layer 1 sont peu à peu apparus, ces fameux Ethereum killer qu’ont été en leur temps la Binance Smart Chain (devenues la BNB Chain), Solana ou Avalanche qui ont choisi le Proof of Stake et ses dérivés. Du côté de Ethereum, une autre solution apparaissait peu à peu, celle des layers 2. Cette deuxième couche avait pour but d’améliorer la scalabilité en se servant de la sécurité et de la décentralisation du layer 1. Le premier layer 2 qui a été développé a été Matic devenu Polygon en 2021. Sans entrer dans le détail de cette solution qui est elle-même composée de plusieurs niveaux, son but est de créer un système de validation qui permet de vérifier les transactions avant de les envoyer sur le layer 1 et d’avoir une couche d’exécution beaucoup plus rapide et moins chère. Même si les layer 2 vont adopter différentes solutions, ils reposent tous sur ce principe. Les applications d’Ethereum ont cependant continué à dominer la DeFi car le fait de rester sur le layer 1 offre une sécurité optimale qui est privilégiée par les fonds d’investissement et les institutions. De plus, même les blockchains en Proof of Stake qu’on a appelées l’une après l’autre les Ethereum killer se sont retrouvées congestionnées dès qu’il y a eu un pic des transactions et certaines d’entre elles envisagent maintenant de construire un layer 2 pour gagner en scalabilité.

La problématique des bridges

Depuis 2021, une quatrième exigence est peu à peu apparue avec la multiplication des blockchains. Jusqu’au printemps 2021, Ethereum, la Binance Smart Chain et Polygon formaient globalement le trio de la DeFi. Mais sont arrivées ensuite les blockchains Fantom, Avalanche, Solana et à partir de Septembre 2021 une multitude de blockchains. Cependant, chacun de ces réseaux forment un univers replié sur lui-même. Leur multiplication a donc peu à peu posé le problème du transfert de liquidité d’un réseau à l’autre. En effet, un token n’existe que sur la blockchain sur laquelle il a été créé. Il ne peut donc pas aller sur une autre blockchain. 

Il a donc fallu inventer des bridges pour aller d’une blockchain à une autre. En fait, ces ponts ne transportent pas les tokens mais sont l’équivalent de ce qui se passe lorsqu’on effectue un swap sur un DEX mais entre deux blockchains: on échange un token contre un autre. Lorsqu’on bridge un token d’une blockchain à une autre, on fait en réalité deux opérations. On envoie le token d’origine vers un smart-contract qui va le locker. Ensuite un smart-contract sur la blockchain de destination va copier votre token d’origine, qui aura ainsi la même valeur (il peut néanmoins exister des variations de valeur s’il n’y a pas assez de liquidité sur la blockchain de destination). Même si le procédés paraît simple en fait la copie des tokens peut poser des difficultés si les deux blockchains n’utilisent pas le même langage pour leur smart-contract. Par conséquent, les blockchains ne sont pas toutes aussi interopérables. Les bridges ont pu se développer dans un premier temps entre les blockchains qui utilisent le noyau de la machine virtuelle d’Ethereum et donc le langage Solidity pour l’écriture des smart-contracts. Xpollinate a été par exemple un des premiers bridges à proposer des transferts de tokens entre un grand nombre de blockchains avec une EVM (Ethereum Virtual Machine). L’arrivée de Solana, qui n’utilise pas une EVM, a conduit à la création d’autres bridges comme Worhole pour augmenter l’interopérabilité entre les blockchains. Wormhole a ainsi permis le transfert de liquidité entre les blockchains avec EVM, Solana et Cosmos.

Cependant, les bridges sont un des lieux les plus problématiques de l’environnement blockchain au niveau de la sécurité. Les hacks de Poly Network, une application crosschain, en août 2021 puis de Wormhole en février 2022 ont montré en effet la fragilité de ces outils devenus indispensables. Vitalik Buterin, le fondateur d’Ethereum, a plusieurs fois rappelé sa méfiance envers les manipulations cross-chain, lui préférant largement une superposition de layer. De plus, les bridges ne sont pas une solution scalable aux transferts cross-chains puisqu’il faut attendre à chaque fois la création du token wrappé sur la blockchain de destination. Il peut aussi y avoir des problèmes de différence de liquidité entre les deux blockchains qui rendent ainsi impossible le transfert.

Nervos: une réponse aux quatre exigences

Avant de continuer notre réflexion sur les layers, il faut s’arrêter sur une solution encore peu utilisée, celle de la blockchain Nervos. En effet, elle a le mérite de proposer une solution à ces quatres exigences: Sécurité, décentralisation, scalabilité et interopérabilité. Pour atteindre ce résultat, Nervos s’est doté d’une architecture à plusieurs niveaux. Le réseau Nervos en lui-même utilise le Proof of Work afin d’avoir la meilleure sécurité et décentralisation possible. Les smart-contracts quant à eux vont être déployés sur le layer 2. Si cette architecture est proche de celle d’Ethereum, elle s’en différencie sur plusieurs points. Ce qui est souvent considéré comme un palliatif pour Ethereum est pensé dès le départ comme une nécessité. De plus, le layer 1 de Nervos ne possède aucun smart-contract sur son réseau. Ceux-ci seront bien stockés sur le layer 1 mais déployés sur le layer 2. Mais les places pour le stockage des smart contracts ne sont pas définitives. Elles sont louées en échange de CKB, la cryptomonnaie de Nervos. Ainsi, il est possible d’éliminer d’anciens smart contracts qui ne sont plus utilisés afin d’éviter de congestionner la blockchain. Enfin la machine virtuelle de Nervos est blockchain agnostique, ce qui permettra à terme une interopérabilité totale. En un sens, ce premier niveau peut être en réalité considéré comme un layer 0 qui s’étendrait sous toutes les blockchains. Si pour l’instant seul Polyjuice/godwoken, un layer 2 avec EVM, est installé, on peut imaginer l’installation d’autres machines virtuelles dans le futur. De plus, il sera possible de transférer facilement les tokens de n’importe quelle blockchain. Pour l’instant, cette solution n’a trouvé ni un public d’utilisateurs ni assez de projets pour développer un écosystème mais elle est intéressante à suivre par sa cohérence.

Milkomeda: des side-chains dédiées aux EVM

Pour l’instant, nous avons parlé des layers 2 par rapport au problème de scalabilité. Cependant, l’usage d’un réseau annexe peut aussi avoir pour fonction d’amener une machine virtuelle sur un réseau. C’est le cas de la solution développée par Milkomeda. Milkomeda est une solution qui propose une série de sidechain avec EVM pour les réseaux qui n’en disposent pas. Sa première sidechain a été lancée pour Cardano cet hiver. En même temps est proposé un utilitaire pour déplacer la liquidité entre le réseau principal et la sidechain. Milkomeda considère ainsi que la voie de l’interopérabilité se fera via des machines virtuelles similaires. Après Cardano, Milkomeda lancera des sidechains sur Algorand puis Solana dans les prochains mois.

Polkadot, une verticalité repensée

Si j’apprécie beaucoup l’écosystème Polkadot, c’est parce que je trouve qu’il reprend tous les aspects précédemment évoqués. Même s’il peut paraître peu intuitif pour les utilisateurs pour l’instant, il répond aux exigences de la sécurité, de la décentralisation, de la scalabilité et bien sûr de l’interopérabilité.

La décentralisation du réseau Polkadot est assuré par les validateurs et les collateurs qui vont avoir pour fonction à la fois d’assurer la production des blocks des relaychain (donc Polkadot et Kusama) et des parachains (c’est la fonction précise des collators). On peut considérer Polkadot et Kusama comme des layer 0 car ces blockchains n’ont pas de smart-contract développé sur elles. Elles servent uniquement à la sécurité, à la décentralisation et à l’interopérabilité. La décentralisation est assurée techniquement par les validateurs et collateurs mais aussi par tout un système de votes auxquels peuvent participer ceux qui stakent leur DOT et KSM. Il ne faut pas oublier non plus les crowdloans que l’on peut comparer à des prêts participatifs pour choisir à qui reviendra les places de parachains.

En effet, l’originalité de Polkadot est proposer un certain nombre de places pour des blockchains spécialisées appelées parachains et dont la sécurité sera assurée par la relaychain. Cette spécialisation permet d’optimiser la scalabilité. De plus, les relaychains vont assurer l’interopérabilité du système. Le XCM (Cross-Consensus Message Format) permet aux parachains de communiquer entre elles et en particulier de s’envoyer des tokens sans avoir besoin de bridges. Cela ne signifie pas pour autant que le système Polkadot fermé sur lui-même. Plusieurs parachains sont dotées d’une EVM (Astar/Shiden et Moonbeam/Moonriver par exemple) et peuvent donc facilement bridger leur token avec les autres blockchains EVM. De plus, la présence d’une EVM permet à de petits projets de commencer à se déployer dans l’univers Polkadot quitte à chercher plus tard à avoir leur propre parachain.

Enfin, tout l’intérêt de cette architecture duelle Kusama/Polkadot est d’assurer une sécurité maximale du système. Toute nouveauté de l’écosystème doit être essayée dans un premier temps sur le réseau canari qui va servir de crash-test grandeur nature avant d’aller sur Polkadot. Par conséquent, les fonds institutionnels ont vocation à aller avant tout sur Polkadot, puisque la sécurité y est alors optimale.

Cosmos, un écosystème sans layer ?

Cosmos est l’autre grand écosystème de l’interopérabilité avec Polkadot. Encore méconnu jusqu’au début 2021, cet écosystème a gagné en visibilité par l’ajout de l’Inter Blockchain Communication (IBC) qui permet tout comme le XCM de Polkadot de transférer directement des tokens d’une blockchain (appelées ici “zones”) à une autre. Le nombre de zones augmentant régulièrement depuis l’automne dernier, les usages se sont multipliés.

Cosmos a la particularité de faire au maximum le pari de l’horizontalité la plus complète. Chaque zone est souveraine et assure sa propre sécurité. Il n’y a pas de sélection pour utiliser l’IBC. La décentralisation est assurée par un ensemble de validateurs et par des votes réguliers pour la gouvernance de chaque zone. De plus, chaque nouvelle zone fait un airdrop de ses tokens aux stakers de Atom (avec la possibilité d’ajouter d’autres règles d’airdrop) afin de distribuer ou plutôt de disperser les tokens.

Tout comme les parachains de Polkadot, les zones de Cosmos sont des blockchains spécialisées afin d’optimiser la scalabilité. Cependant quelques zones proposent aussi le développement d’applications. Secret Network et Juno utilisent la machine virtuelle CosmWasm et Evmos dispose d’une EVM.

Cependant, cette horizontalité ne pourra sans doute pas perdurer. En effet, il peut être difficile pour une zone peu capitalisée d’assurer sa sécurité. En effet, l’usage du Proof of Stake peut facilement permettre à une entité malveillante d’acheter 51% des tokens. Dans ce cas, par l’intermédiaire de l’IBC, elle pourrait devenir aussi un danger pour l’écosystème. Les prochaines mises à jour vont donc permettre d’avoir des zones (en particulier Atom)  d’assurer la sécurité d’une zone “cliente”, mise à jour appelée l’interchain security. Sans parler véritablement de layer, Atom aura bien une place à part dans l’écosystème Cosmos.

Axelar

Il était difficile de développer toute cette problématique des layers sans évoquer l’arrivée de Axelar que certains présentent comme le layer 0 absolu, celui qui va permettre l’interopérabilité de toutes les blockchains. L’ambition de Axelar peut paraître démesuré. Cette zone de Cosmos veut proposer un ensemble d’outils qui doivent aider les développeurs à se connecter le plus facilement possible à n’importe quelle blockchain, à disposer d’un routage cross-chain facilité et d’un langage de programmation unifié. À terme, Axelar veut rendre possible un AMM (Automated Market Maker, ce qui est à la base de tout échange décentralisé) universel ou la possibilité de poser un NFT en collatéral pour emprunter sur une autre blockchain. Les développeurs n’auront qu’à se connecter sur l’API d’Axelar pour développer leurs applications. Du coté d’Axelar, les validateurs du réseau vont aussi enregistrer l’état de chaque blockchain connectées afin que cet état soit enregistré. Sachant qu’il sera une cible pour les hackers, Axelar a poussé au maximum la sécurité. Il y a ainsi un seuil de 90% de la sécurité, ce qui signifie que quasiment tous les validateurs doivent se mettre d’accord pour falsifier les preuves d’état ou retirer des fonds bloqués sur le réseau. Il y a de plus un mécanisme de repli qui permet aux utilisateurs de récupérer leurs fonds en cas de blocage du réseau. Si Axelar réussit à finaliser sa solution sans que cela soit au détriment de la scalabilité, on peut s’attendre à une montée en puissance de cette solution dans les prochaines années. Un nouveau projet, Teleport Network, développe aussi une solution cross-chain et il faudra suivre avec attention ce concurrent.

Vous l’avez compris, il est impossible de séparer la problématique des layers des quatre exigences auxquels doivent répondre les blockchains: décentralisation, scalabilité, sécurité et interopérabilité. Si les trois premières exigences ont porté dans un premier le débat sur la différence entre Proof of Work et Proof of Stake (même si la notion de décentralisation n’a pas le même sens pour ces deux systèmes de consensus), l’augmentation des transactions sur toutes les blockchains a montré la nécessité de construire des layers 2 pour gagner en scalabilité. Le problème de l’interopérabilité étant de plus en plus mis en avant, la nécessité d’ajouter des layers 0 se fait de plus en plus sentir. En résumé (puisque cet article est beaucoup trop long): layer 0: interopérabilité; layer 1: sécurité et décentralisation: layer 2: scalabilité.