
Point de vue | Comment comprendre la notion de « chaîne latérale » ?
TechFlow SélectionTechFlow Sélection

Point de vue | Comment comprendre la notion de « chaîne latérale » ?
Autrefois, les sidechains étaient la seule solution disponible tout en conservant un certain niveau de composable et d'interopérabilité avec Ethereum. Aujourd'hui, avec la maturité d'autres solutions d'extension de couche 2 (Layer-2), il est temps de réfléchir à la manière dont les sidechains peuvent mieux s'intégrer avec ces autres approches.
Auteur : barryWhiteHat
Traduction : TechFlow
Introduction
L’importance croissante des solutions de couche 2 (Layer-2) pour Ethereum est désormais bien établie et largement acceptée.
Cependant, l’étiquette « Layer-2 » est imprécise.
Quand certaines personnes parlent de « Layer-2 », elles entendent simplement « tout ce qui n’est pas sur la couche 1 d’Ethereum ».
Or, la manière dont une solution interagit avec la couche 1 d’Ethereum est cruciale. Des systèmes très différents peuvent tomber sous le même terme générique de « Layer-2 », alors qu’ils ont des propriétés fondamentalement distinctes.
On peut discuter de savoir si « Layer-2 » devrait être réservé à certains types de solutions possédant des caractéristiques précises (par exemple, nous convenons tous qu’un service déployé sur AWS n’est pas un Layer-2, mais certains projets aux garanties de sécurité comparables sont néanmoins qualifiés ainsi). Ce n’est toutefois pas le sujet que je souhaite aborder ici.
Je veux plutôt discuter des propriétés des sidechains.
Qu’est-ce qu’une sidechain ?
La définition de base d’une sidechain est la suivante : un système où un ensemble de validateurs soumet régulièrement à un contrat intelligent sur la chaîne principale (mainchain) l’état le plus récent de la sidechain. Ces points de contrôle (checkpoints) peuvent ensuite être utilisés par un contrat de pont (bridge contract) pour permettre aux utilisateurs de déposer et retirer leurs fonds.
Généralement, les validateurs mettent également en place un processus d’élection d’un leader afin de décider à chaque instant qui crée le prochain bloc de la sidechain ; par exemple via un algorithme PoA (Proof of Authority) ou PoS (Proof of Stake).
(Note du traducteur : selon cette définition, l’auteur traite ici des sidechains qui ne disposent pas sur la chaîne principale d’un mécanisme de vérification d’validité. Selon la définition large actuelle du terme « sidechain », il s’agit donc d’un sous-ensemble des sidechains au sens large. Toutefois, la notion originelle de « sidechain », c’est-à-dire au sens strict, correspond exactement à ce que l’auteur expose ici. Le choix appartient à chacun de considérer « sidechain » comme un terme technique précis ou comme un concept étendu.)
Les sidechains jouent un rôle important dans l’écosystème Ethereum. Elles ont servi de solutions temporaires à la scalabilité et à l’utilisabilité avant que les chercheurs ne développent de meilleures alternatives. Des produits comme xDai ont mis en lumière la demande d’une meilleure expérience utilisateur et contribué à sa diffusion.
Mais les sidechains ne fournissent pas la sécurité attendue par la grande majorité de la communauté Ethereum. Cela ne signifie pas qu’il ne faudrait jamais utiliser de telles solutions.
Si les utilisateurs sont pleinement informés et choisissent volontairement d’en user, c’est leur décision — et cela peut être justifié.
En revanche, si les utilisateurs agissent sans en connaître les risques, cela devient dangereux.
Cet article vise à fournir des informations. S’il ne fait que confirmer ce que tout le monde sait déjà, inutile de s’en inquiéter. Mais s’il aide certains à corriger leurs malentendus, alors il aura accompli son but.
Quelles propriétés de sécurité manquent donc aux sidechains ? Presque toutes les sidechains ne garantissent pas :
-
La résistance à la censure
-
La finalité (finality)
-
La garantie de propriété des fonds
Si vous exigez ces trois propriétés, vous devriez probablement chercher une alternative aux sidechains. Bien sûr, il est possible d’améliorer certains aspects de ces solutions tout en conservant leur architecture de base. Une discussion ouverte sur ces sujets serait bénéfique pour tous.
Résistance à la censure
Il est évident que la résistance à la censure des sidechains est inférieure à celle des blockchains bien conçues — sinon, on n’aurait pas besoin de blockchain du tout. Allons plus loin. Supposons qu’une sidechain compte N validateurs, et que M validateurs suffisent à bloquer toute transaction. Alors, seulement (N-M) validateurs peuvent s’entendre pour valider un bloc arbitraire. Cela conduit à un dilemme intéressant : rendre la censure de transaction plus difficile rend automatiquement la censure de bloc plus facile. Puisque les deux sont indésirables, les sidechains ne peuvent fondamentalement pas offrir une résistance solide à la censure. (Note du traducteur : la logique est la suivante : si M validateurs peuvent empêcher la création d’un bloc, ils peuvent aussi bloquer une transaction spécifique ; mais inversement, si seuls (N-M) validateurs peuvent créer un bloc, ils peuvent choisir de produire n’importe quel bloc, voire ignorer totalement certaines transactions ou disparaître collectivement.) Cette vulnérabilité persiste même avec un mécanisme PoS, et elle peut même empirer si la pondération des blocs est basée sur les enjeux (stakes), car le nombre d’entités indépendantes nécessaires pour atteindre le seuil requis peut être encore plus faible (même dans le meilleur des cas, où les stakes sont parfaitement répartis, on n’obtient pas de gain par rapport à un système sans PoS).
Garantie de disponibilité des données
Supposons que (N-M) validateurs puissent créer un bloc, et que tous les autres validateurs aient besoin des données complètes de l’état pour vérifier le nouvel état. Alors, si (N-M) validateurs sont malveillants, ils peuvent :
-
créer un nouveau bloc ;
-
refuser de partager les données du bloc avec les validateurs honnêtes ;
-
en pratique, exclure ainsi les M validateurs honnêtes du processus de consensus, prenant ainsi le contrôle total du système.
Quelle est la probabilité que cela se produise ? Cela dépend de nombreux facteurs spécifiques, mais on peut commencer par se demander : quelle incitation un validateur rationnel a-t-il à partager les données avec les autres ? Dans un modèle classique de Proof of Authority, cela pourrait nuire à sa réputation. Mais en réalité, les mécanismes de réputation sont peu efficaces, car il est difficile de prouver qu’un validateur retient sciemment les données, sauf si toutes les données sont publiées sur la chaîne. Cette solution vous rappelle-t-elle quelque chose comme un optimistic rollup ? Exactement. Cela signifie que toute sidechain dotée d’une meilleure sécurité tend naturellement à « dégénérer » en un optimistic rollup. Dans la plupart des sidechains, les validateurs reçoivent une récompense pour leur travail. Pour les validateurs honnêtes, cette récompense est partagée entre les N validateurs. Pour les validateurs malhonnêtes, la même somme est partagée entre seulement M = N-(N-M) validateurs, ce qui donne une forte incitation à ne pas partager les données d’état mises à jour. Ici, on rencontre un problème fondamental : il est très difficile de détecter une attaque par non-disponibilité des données. Pour un validateur honnête, il est ardu de distinguer entre une véritable attaque et un simple problème de synchronisation. (Note du traducteur : le calcul original semble comporter une erreur.)
Finalité
Supposons que la transition d’état se fasse ainsi : state1 => state2 => state3, chaque étape nécessitant l’exécution de certaines transactions sur l’état existant. La finalité signifie qu’une fois qu’une transaction est validée, elle ne peut plus être annulée. Les points de contrôle des sidechains, après consensus entre les validateurs de la sidechain, sont envoyés sur la blockchain Ethereum et consolidés grâce au mécanisme de consensus d’Ethereum. Certains pensent donc que la finalité d’une sidechain équivaut à celle d’Ethereum : pour revenir en arrière sur un bloc de sidechain, il faudrait aussi revenir en arrière sur un bloc d’Ethereum. Mais c’est une erreur complète. Car la finalité concerne l’irréversibilité des transactions, pas celle des états. Dès que (N-M) validateurs sont d’accord, ils peuvent effectuer la transition suivante : state1 => state2 => state1, c’est-à-dire remplacer state3 par state1, ce qui revient à annuler state2 — bien que cela ne nécessite aucun retraitement de la chaîne principale d’Ethereum.
Garantie de propriété des fonds sur sidechain
Imaginons que l’état actuel soit state1={Alice:1000, Bob:0}, autrement dit Alice possède 1000 unités et Bob rien. Si Bob est malveillant et contrôle (ou peut corrompre efficacement) la majorité des validateurs PoA, que peut-il faire ? Il peut exécuter une transition d’état : state1 => state2, où state2={Alice:0, Bob:1000}, volant ainsi tout l’argent d’Alice. Ainsi, la sécurité de la sidechain se réduit à l’hypothèse qu’aucun groupe de (N-M) validateurs ne consentira à une telle transition illégale. C’est un fait connu (du moins je l’espère), mais il est bon de le rappeler. Votre confiance dans une sidechain repose uniquement sur la croyance que la majorité des validateurs ne feront pas une chose pareille. Toute analyse de sécurité d’une sidechain devrait se concentrer sur ce point. Il peut exister des entités que vous êtes prêt à confier partiellement, tout comme beaucoup d’entre nous font confiance à des fournisseurs centralisés (pour diverses raisons). Parfois, ce compromis vaut la peine. L’essentiel est d’en être conscient.
Problèmes liés à l’utilisation de la gouvernance comme mécanisme de défense
Certains affirment : « Nous pouvons utiliser un processus de gouvernance pour résoudre tous les problèmes mentionnés ci-dessus ». Cette approche est imparfaite, car elle réduit tout le système à un simple processus de gouvernance. Ce qui m’inquiète particulièrement, c’est que cela impliquerait que les autres propriétés de la sidechain ne sont qu’un théâtre (alors, pourquoi et quand avons-nous besoin de ces attributs ?). Par exemple, si la gouvernance est la dernière ligne de défense contre les attaques, alors PoS, PoA, etc., deviennent insignifiants. En réalité, c’est le processus de gouvernance lui-même qui devient le vrai PoA. Et clairement, ce processus de gouvernance peut lui aussi subir exactement les mêmes attaques.
Où les caractéristiques des sidechains peuvent-elles être utiles ?
Outre certains avantages annexes des sidechains, comme des temps de bloc plus rapides (donc une meilleure expérience utilisateur), il existe certains cas d’usage où leurs particularités sont justement avantageuses :
-
Vous souhaitez justement qu’un groupe de (N-M) validateurs puisse effectuer n’importe quelle transition d’état. Un exemple typique est une application d’entreprise nécessitant un contrôle administratif élevé.
-
Le cas où M=0, et donc où N validateurs peuvent effectuer n’importe quelle transition. Par exemple, un jeu à quatre participants. Problème : un seul validateur peut bloquer la chaîne.
Conclusion
Autrefois, les sidechains étaient la seule solution disponible pour maintenir un certain niveau de composable et d’interopérabilité avec Ethereum.
Aujourd’hui, avec la maturation d’autres solutions d’extension de couche 2, il est temps de réfléchir à la manière dont les sidechains peuvent mieux s’intégrer avec ces nouvelles approches. Certaines améliorations seraient particulièrement pertinentes :
-
Permettre des transferts massifs sans frais, garantissant que les utilisateurs ne soient pas bloqués à cause des coûts de sortie.
-
Remplacer le mécanisme d’élection du leader par un autre offrant une meilleure résistance à la censure (le PoS pourrait être une mauvaise direction. Voir ce fil).
-
Utiliser un coordinateur pour gérer les divergences entre deux états sur la chaîne.
-
Introduire des preuves d’erreur (fault proofs) pour empêcher les transitions d’état illégales.
À mesure que les technologies d’optimistic rollup et de machine virtuelle optimiste matures, les compromis disponibles pour les projets évoluent. C’est donc le moment idéal pour reconsidérer les propriétés des sidechains et les arbitrages qu’elles impliquent.
Bienvenue dans la communauté officielle TechFlow
Groupe Telegram :https://t.me/TechFlowDaily
Compte Twitter officiel :https://x.com/TechFlowPost
Compte Twitter anglais :https://x.com/BlockFlow_News














