Comprendre les sidechains avant de s'intéresser aux drivechains
Avant de se pencher sur les drivechains, une forme particulière de sidechain, il faut d'abord comprendre ce que sont les sidechains. Ce sont des blockchains qui se placent comme une infrastructure de seconde couche au-dessus d'une blockchain principale, dans le but de créer ou d'améliorer des fonctionnalités de la chaîne sous-jacente.
Les sidechains fonctionnent indépendamment de la chaîne principale. Techniquement, elles peuvent donc tourner sans avoir d'impact sur la blockchain parente et sans subir le sien. Une sidechain permet ainsi de créer des fonctionnalités absentes de la chaîne principale ou d'améliorer celles qui existent.
Mais comme pour Polygon (POL) vis-à-vis d'Ethereum (ETH), ces gains de performance se font souvent au détriment de la décentralisation du réseau.
De par la nature de ces sidechains, les actifs qui y circulent ne sont souvent que des représentations d'actifs de la chaîne principale.
Pour détenir de l'Ether (ETH) sur Polygon (POL), par exemple, il faut passer par un bridge, une passerelle entre les 2 chaînes, et faire confiance à un tiers. Ce dernier conserve l'actif sur la chaîne principale et émet sa représentation sur la chaîne secondaire, à parité 1:1, sous le nom de Wrapped Ether (WETH).
Cet actif « wrappé » peut aussi être « déwrappé » afin de récupérer l'actif natif sur la chaîne principale. Ce mécanisme porte le nom de « two-way peg », ou ancrage bidirectionnel.
Le two-way peg crée une passerelle presque indispensable à la vie de la sidechain. Sans ces représentations, les sidechains devraient créer leurs propres actifs, ce qui pourrait freiner l'adoption de cette seconde couche, même lorsqu'elle serait réellement utile.
À ce jour, les sidechains les plus connues de Bitcoin, que l'on retrouve en partie sur notre carte Bitcoin L2, sont Rootstock, Liquid et Stacks.
En quoi les drivechains diffèrent-elles des sidechains ?
Les drivechains sont des sidechains dont le two-way peg est contrôlé par les mineurs. Plus précisément, le concept de drivechain est souvent associé au merge mining (minage fusionné), une méthode d'incitation conçue pour encourager la participation des mineurs.
Sur des sidechains comme Liquid, la sécurité du réseau et les transactions dépendent d'une fédération d'entités qui possèdent chacune un nœud et un droit de vote. Les drivechains et leur merge mining fonctionnent au contraire grâce au consensus de Bitcoin lui-même.
Le merge mining permet aux mineurs de participer en même temps aux opérations de la blockchain Bitcoin et à celles d'une drivechain. Les drivechains peuvent ainsi profiter de la décentralisation de Bitcoin dès leur lancement.
Lorsqu'un mineur parvient à valider un bloc, il obtient un droit de vote. Une fois suffisamment de votes favorables réunis, le two-way peg peut être confirmé.
Le nombre de votes nécessaires pour valider le two-way peg dépend du nombre de blocs requis. Plus les votes « pour » sont nombreux, plus les transactions ont de chances d'être confirmées.
Indépendamment du vote des mineurs, le two-way peg peut aussi passer par un marché secondaire, où les échanges entre chaînes se font plus rapidement grâce aux atomic swaps, des échanges directs entre 2 chaînes sans intermédiaire.
L'émission de stablecoins comme l'USDT, par exemple, ne peut se faire que via les services de Tether, c'est le marché primaire. Il est en revanche possible d'acheter de l'USDT sur des plateformes d'échange comme Binance ou Uniswap, c'est le marché secondaire.
Pour le moment, aucune drivechain n'a été déployée sur Bitcoin, et c'est ce que les BIP-300 et BIP-301 cherchent à rendre possible.
Qu'apportent le BIP-300 et son Hashrate Escrow ?
Proposé par Paul Sztorc en 2017, le Bitcoin Improvement Proposal 300 (BIP-300) vise à introduire le concept de « Hashrate Escrow ».
Le Hashrate Escrow est au cœur du fonctionnement du two-way peg. Il ressemble à une adresse de dépôt Bitcoin multisignature, mais au lieu d'être sécurisé par plusieurs clés privées, il est sécurisé par la puissance de calcul sur une période définie.
Dans le cas du BIP-300, cette période va d'un minimum de 13 150 confirmations de blocs, soit environ 3 mois, à un maximum de 26 300 confirmations de blocs, soit environ 6 mois. Les demandes de peg-in et de peg-out sont donc exécutées si elles réunissent au moins 13 150 votes favorables.
Ce mécanisme vise à rendre le two-way peg plus sûr, mais malheureusement, les choses ne sont pas si simples.
Malgré ses avantages, le BIP-300 présente des inconvénients. Pour percevoir les frais générés par les drivechains, les mineurs doivent connaître leur registre, ce qui implique de faire tourner un nœud pour chaque drivechain.
Cette exigence pourrait représenter une charge financière importante pour ceux qui ne peuvent pas assumer les coûts d'infrastructure associés.
C'est là qu'intervient le BIP-301, pour éviter toute centralisation du consensus des drivechains.
Qu'apportent le BIP-301 et son Blind Merge Mining ?
Également proposé par Paul Sztorc en 2017, le Bitcoin Improvement Proposal 301 (BIP-301) vise à introduire le concept de « Blind Merge Mining ».
Le merge mining permet aux mineurs de travailler à la fois sur la blockchain principale de Bitcoin et sur une sidechain, sans avoir à valider les règles de cette dernière. Fusionner le minage du réseau Bitcoin avec le consensus des drivechains permet à celles-ci de profiter de sa sécurité, et donc de sa décentralisation et de sa résistance à la censure.
Le Blind Merge Mining est quant à lui censé être une forme plus équitable de merge mining. Il doit permettre aux mineurs de sécuriser les drivechains sans avoir à faire tourner un nœud complet pour chacune d'elles afin d'en percevoir les frais.
Sans Blind Merge Mining, les mineurs ne pourraient pas percevoir ces frais et perdraient en rentabilité. L'industrie du minage est très concurrentielle, et toute hausse de la puissance de calcul d'un mineur réduit la rentabilité de ses concurrents.
De plus, les mineurs qui disposent du plus de ressources pourraient faire tourner des nœuds pour chaque drivechain, percevoir davantage de frais et augmenter leurs revenus. Il leur serait alors plus facile de réinvestir dans des infrastructures plus puissantes, ce qui réduirait encore les revenus de leurs concurrents.
L'intégration du Blind Merge Mining n'est pas indispensable au fonctionnement des drivechains, mais le BIP-301 cherche à garantir un fonctionnement plus équitable du consensus du réseau.
Malheureusement, la situation est bien plus complexe. C'est justement parce que le Blind Merge Mining ne convainc pas toute la communauté de son efficacité que les drivechains font débat au sein de la communauté Bitcoin.
Sous la forme présentée par Paul Sztorc, les drivechains pourraient en effet fragiliser le consensus de Bitcoin.
Après la Blocksize War, la Drivechain War ?
Plusieurs années après la Blocksize War, la guerre de la taille des blocs, le débat sur les drivechains ravive les divisions au sein de la communauté Bitcoin.
D'un côté, on trouve des mineurs qui espèrent augmenter leurs revenus, soutenus par des passionnés de crypto qui voient dans les drivechains un moyen de créer des smart contracts sur Bitcoin et de concurrencer l'écosystème Ethereum (ETH).
De l'autre, certains s'interrogent sur la pertinence d'une telle mise à jour et s'inquiètent surtout du risque d'abîmer le consensus actuel du réseau Bitcoin.
Une drivechain pourrait en effet prendre en charge de nombreuses fonctionnalités différentes, chacune formant un fragment (shard) distinct de la blockchain Bitcoin chargé d'une tâche précise.
Mais comment être sûr que le format des drivechains suffira à attirer des utilisateurs, alors que des sidechains comme Liquid et Stacks sont relativement peu actives ?
Le principal problème que pourraient créer les drivechains est celui de la « Miner Extracted Value » (MEV).
Theo Pantamis, ingénieur R&D chez LN Markets, a abordé la question lors d'un épisode de Space Kek en août 2023. Nous l'avons contacté, et il a accepté de répondre à nos questions sur le sujet :
« La Miner Extracted Value, ou MEV, est un avantage économique qu'un mineur peut tirer de sa capacité à trancher une double dépense, puisqu'il peut choisir laquelle des transactions en conflit (qui dépensent par exemple les mêmes pièces) il va confirmer.
Certains protocoles permettent à un grand nombre de personnes de dépenser des pièces. Lorsque le mineur d'un bloc fait partie des personnes qui peuvent dépenser ces pièces, il peut profiter de ce choix pour créer et favoriser ses propres transactions en conflit, et ainsi réaliser un profit.
La MEV apparaît rapidement dans les protocoles ouverts qui nécessitent un consensus et dont les informations sont publiques, si elle n'est pas prise en compte dès leur conception.
Elle est parfois tolérée, comme c'est le cas pour la purge des anchor outputs dans les dernières versions des canaux de paiement du Lightning Network. Mais dans l'écrasante majorité des cas, on cherche à l'éviter autant que possible.
La MEV détourne en effet les mineurs de leur fonction initiale et idéalisée, qui consiste à confirmer les transactions Bitcoin valides par ordre de frais décroissants.
La MEV devient problématique lorsque la valeur extraite est élevée par rapport à celle que rapportent les frais de transaction. Le gain devenant significatif, les mineurs qui font l'effort de chercher et d'extraire de la MEV sont plus rentables que ceux qui ne le font pas et se contentent d'ordonner les transactions dans leur bloc.
Cela conduit naturellement à une situation où les seuls mineurs restants sont ceux qui courent après la MEV, comme ce fut le cas sur Ethereum avant son passage à la preuve d'enjeu.
Cela nous amène au problème de la MEV dans les drivechains. Une sidechain est un protocole très ouvert, et ses informations sont publiques. Les mineurs y sont explicitement placés en position privilégiée, puisqu'ils peuvent miner une sidechain et gérer les peg-outs tout en minant sur Bitcoin pour gagner davantage.
Mais pour cela, ils doivent s'assurer de respecter les règles de la sidechain. On se retrouve dans une situation où un mineur doit valider les règles de la sidechain en plus de celles de Bitcoin.
Le Blind Merge Mining a été proposé en complément du Hashrate Escrow pour répondre à cette critique. Il permet aux mineurs de collecter la MEV en laissant à d'autres utilisateurs la responsabilité de valider les règles de la sidechain. Mais ce n'est qu'une manière de déplacer le problème, car la MEV est toujours là et doit être collectée par le mineur pour qu'il reste rentable.
La condition pour l'obtenir n'est plus de valider soi-même les règles de toutes les drivechains (il peut y en avoir jusqu'à 256 dans la version actuelle des spécifications), mais de connaître des personnes capables de les valider pour vous et de négocier avec elles un tarif compétitif, ou bien de pouvoir le faire soi-même (ce qui reste toujours l'option la plus avantageuse).
La conséquence, c'est qu'il devient plus difficile d'être un mineur rentable et que la preuve de travail n'est plus le seul critère. C'est une forte incitation supplémentaire à la centralisation du minage, qui s'ajoute à celles qui peuvent déjà exister naturellement. »
Theo Pantamis nous a également alertés sur un risque rarement évoqué dans la communauté, celui d'un ralentissement de la propagation des blocs entre les nœuds du réseau :
« Au-delà du fait qu'elle modifie les incitations des mineurs, les développeurs Bitcoin cherchent à éviter la MEV parce qu'elle crée, dans certains cas, une incertitude sur le contenu du prochain bloc. Or les drivechains aggravent le problème à cause du Hashrate Escrow.
La sécurité du réseau Bitcoin repose sur le temps de propagation d'un nouveau bloc à tous les nœuds, qui doit rester court par rapport à la durée moyenne de minage. C'est pour cela que les blocs du réseau Bitcoin sont petits (pour réduire au minimum le temps de propagation) et peu fréquents (pour maximiser le temps moyen de minage).
Les développeurs Bitcoin ont beaucoup travaillé pour réduire le temps de propagation des blocs. L'une des principales améliorations vient du fait que les nœuds s'attendent à ne découvrir et à ne valider qu'une toute petite partie des transactions du bloc, puisqu'ils connaissent et ont déjà validé l'immense majorité des transactions qui paient le plus de frais dans la mempool.
Le Hashrate Escrow est géré par des transactions qui ne nécessitent pas de signature et que seul un mineur peut réaliser, exactement comme la transaction coinbase qui récompense le mineur d'un bloc.
De telles transactions ne peuvent raisonnablement pas être diffusées et validées par le réseau avant que le bloc soit miné (le faire ouvrirait un vecteur de spam). Les transactions liées au Hashrate Escrow seront donc forcément découvertes et validées pendant la propagation du bloc, ce qui ralentit cette propagation et réduit la sécurité du réseau.
Nous avons certainement assez de marge pour que le réseau reste sûr malgré les drivechains, mais il n'y a aucune raison d'être moins sévère avec les drivechains que nous ne le sommes déjà face à une éventuelle augmentation de la taille des blocs. À ce jour, je n'ai vu aucune quantification de l'impact maximal des drivechains sur cette donnée essentielle. »
Trop de risques pour Bitcoin ?
Pour beaucoup, le risque d'affaiblir le consensus de Bitcoin dans le seul but de créer un écosystème qui ressemble à celui d'Ethereum ne vaut pas la peine d'être pris, surtout alors que des infrastructures comme RGB, BitVM et Ark sont en cours de développement.
Le Dr Maxim Orlovsky, principal contributeur au développement de RGB, estime que la structure d'une blockchain n'est pas faite pour passer à l'échelle, et que construire une blockchain au-dessus d'une autre ne fait que repousser le problème.
Les blockchains de seconde couche d'Ethereum, comme Arbitrum (ARB) et Optimism (OP), sont souvent plus scalables que la chaîne principale, mais elles sont aussi plus centralisées.
Les drivechains sont par ailleurs plus vulnérables aux attaques sur le consensus que le réseau Bitcoin.
Sur Bitcoin, la seule façon de falsifier des transactions serait qu'un acteur ou un groupe d'acteurs détienne plus de 51 % de la puissance de calcul du réseau.
Dans ce cas, un acteur malveillant pourrait censurer les nouvelles transactions, réaliser des doubles dépenses de ses propres transactions et commencer à remonter la blockchain pour modifier des transactions passées.
Pour les drivechains, si un acteur malveillant parvenait à conserver 51 % de la puissance de calcul du réseau pendant 3 à 6 mois, il pourrait miner 51 % des nouveaux blocs, prendre le contrôle des votes des drivechains et récupérer l'ensemble des fonds détenus par les two-way pegs.
Une attaque à 26 % suffirait toutefois à fausser le vote et à geler le two-way peg. Dans le système de vote du BIP-300, un vote « oui » compte pour +1 et un vote « non » pour -1.
Même si 74 % des mineurs votent « oui », les 26 % restants peuvent voter « non » et ramener le score à 48 %, ce qui ne suffit pas pour confirmer le two-way peg. Il faudrait alors attendre les votes suivants, en espérant que le two-way peg finisse par être confirmé.
Maintenant que vous disposez des informations nécessaires pour comprendre le débat sur les drivechains de Bitcoin, qu'en pensez-vous ?
La communauté doit-elle prendre le risque d'abîmer le consensus de Bitcoin pour tenter d'introduire de nouvelles fonctionnalités qui ne sont pas forcément souhaitées ?
Cet article a d'abord été publié en français sur Cryptoast le 15 octobre 2023.
