Analyse technique de Chainway : comment un projet de couche 2 sur Bitcoin surf-il sur les concepts à la mode ? (1)
TechFlow SélectionTechFlow Sélection
Analyse technique de Chainway : comment un projet de couche 2 sur Bitcoin surf-il sur les concepts à la mode ? (1)
Chainway est essentiellement une solution de rollup souverain / vérification par client utilisant BTC comme couche DA.
Dédié à des analyses Web3 approfondiesRédaction : Shew & Faust, Geek web3
Le secteur des Layer2 Bitcoin est actuellement en pleine effervescence, avec une grande diversité de solutions techniques regroupées au sein de l'écosystème BTC. En raison de la vitesse élevée d'innovation dans le domaine blockchain, les termes techniques ou standards évoluent constamment durant la recherche et la mise en œuvre pratique. Dans ce contexte, de nombreux projets adoptent une stratégie consistant à « créer » ou « s'approprier » des concepts pour se différencier et attirer l'attention, devenant ainsi une règle implicite du secteur.
Par exemple, plusieurs projets modulaires initialement actifs sur Ethereum ou Celestia profitent de cette vague pour embarquer sur le train express des « Layer2 Bitcoin », s'autoproclamant eux-mêmes « Rollup », bien que leurs solutions techniques ne respectent souvent pas les critères classiques d’un Rollup.
Or, le terme « Rollup » bénéficie d'une reconnaissance élevée, et revendiquer ce statut facilite grandement la communication. De nombreux projets utilisent donc soit un rattachement forcé (se proclamer Rollup), soit dérivent des concepts dominants comme le « Rollup souverain » en ajoutant un qualificatif ambigu.
Mais une fois retiré leur habit de « XX Rollup », on découvre que le fonctionnement réel de beaucoup de ces projets repose simplement sur une « validation côté client » ou une « sidechain », utilisant uniquement le slogan « XX Rollup » pour bénéficier d’une image flatteuse. Cette méthode de communication, bien qu’assez répandue, est souvent trompeuse, nuisant plus qu’autrement aux utilisateurs sincères cherchant à comprendre la vérité.
(Résumé par Goebbels, ministre de la propagande nazie, sur la « propagande mensongère », une pratique fréquemment observée chez de nombreux projets)
Comment alors identifier ces cas de « détournement du concept de Rollup » ?
Peut-être faut-il revenir aux principes fondamentaux, définir selon les standards largement reconnus en Occident et dans l'industrie les catégories de solutions Layer2, leurs niveaux de sécurité ainsi que leur complétude fonctionnelle, afin d’acquérir cette « vision clarifiante » face aux illusions. Autrement dit, la solution technique choisie importe moins que la capacité du projet, dans sa conception mécanique, à assurer la sécurité fiable du réseau Layer2 et à véritablement renforcer le réseau principal BTC.
Nous allons ici analyser le projet Chainway, un Layer2 Bitcoin développé par un étranger, afin d'exposer, derrière le slogan « Rollup », la réalité sous-jacente d’une simple « validation côté client ». Nous pourrons ainsi mieux percevoir les différences marquées entre « Rollup souverain », « validation côté client » et les solutions authentiques de Rollup comme ZKRollup ou OPRollup qui reposent sur des contrats intelligents.
Bien entendu, cela ne signifie pas que les approches « Rollup souverain » ou « validation côté client » soient nécessairement moins sûres que ZK Rollup — tout dépend des détails concrets de mise en œuvre. Chainway, bien qu’étant typiquement un Layer2 basé sur la validation côté client, propose un schéma de transaction résistant à la censure via « déclenchement sur BTC + vérification hors chaîne », et utilise une preuve ZK récursive similaire à celle de la blockchain MINA, ce qui le place en avance par rapport à la majorité des autres Layer2 Bitcoin.
Nous considérons que l'étude technique de Chainway est particulièrement pertinente, offrant une référence importante aux observateurs de l’écosystème Bitcoin Layer2.
(Illustration promotionnelle de Chainway se présentant comme un ZK Rollup, alors que sa solution réelle repose sur la validation côté client ; il n’a actuellement ni consensus entre clients hors chaîne, ni échange fiable de messages)
Contenu principal : Chainway est un projet Layer2 Bitcoin bien connu dans les communautés occidentales. De nombreux influenceurs le désignent directement comme un « ZK Rollup », tandis que dans sa documentation technique, Chainway s’auto-définit comme un « Rollup souverain ». Récemment, Chainway a annoncé un nouveau projet, Citrea, affirmant qu’il s’agit d’un ZK Rollup basé sur BitVM. Étant donné que Citrea n’a pas encore détaillé comment il implémentera la vérification ZK via BitVM, cet article se concentrera sur l’analyse technique des solutions existantes de Chainway.
On peut résumer en une phrase la solution technique actuellement publiée par Chainway : publier des données DA via le protocole Ordinals, utilisant BTC comme couche DA, en publiant sur Layer1 les différences d’état (state diff) ainsi que la preuve ZK attestant de la validité de ces changements, ce qui revient efficacement à publier des données de transaction complètes et vérifiables.
(Un state diff correspond à la variation d’état d’un compte)
Toutefois, comme Layer1 ne valide pas directement la preuve ZK, cette tâche étant effectuée par des clients/nœuds indépendants hors chaîne, et que le dépôt de code de Chainway n’implémente actuellement aucun consensus entre ces clients hors chaîne, sans que l’équipe ait non plus annoncé publiquement avoir résolu ce problème, la solution actuelle de Chainway relève essentiellement du type « validation côté client », ressemblant davantage à un protocole d’indexation d’inscriptions permettant le pontage d’actifs.
La suite présentera en détail la mise en œuvre technique de Chainway et analysera son modèle de sécurité.
Qu’est-ce qu’un Rollup souverain : publication de données sur la couche DA + validation hors chaîne
Dans sa documentation technique, Chainway emploie le concept de « Rollup souverain » provenant de Celestia. Or, le Rollup souverain diffère fondamentalement du concept dominant de Rollup dans les communautés Ethereum et industrielles (le Rollup par contrat intelligent). Alors, quelle est la structure concrète d’un Rollup souverain ?
En réalité, un Rollup souverain basé sur Bitcoin ressemble à un « groupe de clients hors chaîne / sidechain publiant des données DA sur la chaîne BTC », dont la caractéristique majeure est de ne pas nécessiter qu’un contrat intelligent sur Layer1 valide les transitions d’état ou opérations inter-chaînes du Layer2. Il utilise BTC uniquement comme couche DA, et son modèle de sécurité se rapproche fortement de la « validation côté client » (client side validation).
Certes, certains Rollups souverains plus sécurisés peuvent s’appuyer sur une couche de règlement tierce hors chaîne BTC (similaire à une sidechain) pour valider les transitions d’état, et prévoient un niveau de consensus ou un échange fiable de messages entre différents clients/nœuds indépendants afin d’aboutir à un « accord » sur les actions litigieuses. Mais certains projets de Rollup souverain sont franchement de simples « validations côté client », sans aucun mécanisme fiable d’échange de messages entre clients/nœuds indépendants.
Pour mieux comprendre ce concept singulier de « Rollup souverain », nous pouvons le comparer à son homologue par contrat intelligent. Les Layer2 d’Ethereum sont presque tous des Rollups par contrat intelligent, comme Arbitrum ou StarkNet. La structure d’un tel Rollup est illustrée ci-dessous :
Sur ce schéma, on retrouve plusieurs termes issus du récit des blockchains modulaires, expliqués ci-après :
Couche d’exécution (Execution) : exécute les transactions utilisateur, met à jour l’état de la blockchain, et soumet les données aux couches DA et de règlement
Couche de règlement (Settlement) : vérifie les transitions d’état de la couche d’exécution, résout les litiges (ex. preuves de fraude), et fournit un module de pont pour gérer les actifs L1-L2
Couche DA : une grande affiche publique recevant les données de transition d’état depuis la couche d’exécution, et les rendant accessibles de manière fiable à tous
Couche de consensus : assure la finalité de l’ordre des transactions, fonction proche de celle de la couche DA (note : la communauté Ethereum exclut généralement la couche de consensus de sa modélisation des blockchains modulaires)
Depuis l’architecture d’un Rollup par contrat intelligent, on observe que toutes les fonctions autres que l’exécution sont assumées par Ethereum. Le schéma suivant illustre plus précisément les rôles tenus par Ethereum dans un tel Rollup.
Les contrats Rollup sur Ethereum reçoivent des preuves de validité (validity proof) ou des preuves de fraude (fraud proof) afin de valider la validité des transitions d’état Layer2. À noter que le contrat Rollup joue ici exactement le rôle de la couche de règlement dans la blockchain modulaire. Ces contrats intègrent souvent un module de pont pour gérer les actifs transférés d’Ethereum vers Layer2.
Pour la couche DA, le contrat Rollup peut exiger impérativement que le séquenceur (Sequencer) publie les dernières données de transaction / détails de changement d’état sur la chaîne ; si ces données DA ne sont pas publiées, l’état L2 enregistré dans le contrat ne peut être mis à jour.
(ZK Rollup ou OP Rollup peuvent exiger impérativement la publication des données DA ; sans cela, impossible de mettre à jour l’état enregistré dans la couche de règlement)
On constate ainsi que les Rollups par contrat intelligent dépendent fortement des contrats intelligents sur Layer1, ce qui rend pratiquement impossible la construction d’un Layer2 « aligné » sur Ethereum pour une blockchain comme BTC, incapable de supporter des logiques complexes.
Inversement, les solutions de Rollup souverain n’ont aucun besoin de contrat sur Layer1 pour valider l’état ou gérer les ponts. Leur architecture est illustrée ci-dessous :
On voit que dans un Rollup souverain, un groupe de nœuds extérieurs à la couche DA assurent à la fois l’exécution et le règlement, offrant ainsi une plus grande liberté. Le processus fonctionne comme suit :
Les nœuds d’exécution du Rollup souverain envoient les données de transaction / détails de changement d’état vers la couche DA, tandis que la couche de règlement / les clients récupèrent ces données et effectuent la vérification. À noter que comme le module de règlement n’est pas sur Layer1, le Rollup souverain ne peut théoriquement atteindre la même sécurité que Layer1 pour ses ponts, et doit souvent s’appuyer sur des ponts notariés ou tiers.
Actuellement, la mise en œuvre du Rollup souverain / validation côté client est relativement simple : il suffit de publier des données sur la chaîne BTC, via un protocole semblable à Ordinals. Pour les parties de validation et consensus hors chaîne, il existe une grande marge de manœuvre, au point que toute sidechain publiant des données DA sur BTC peut prétendre être un « Rollup souverain basé sur BTC », même si sa sécurité reste douteuse.
Cependant, le débit de données de Bitcoin est extrêmement faible : 4 Mo maximum par bloc, intervalle moyen de 10 minutes, ce qui donne environ 6 Ko/s. Les solutions Layer2 se proclamant aujourd’hui Rollups souverains risquent de ne pas pouvoir publier toutes leurs données DA sur BTC, recourant à des compromis : par exemple, publier les données DA hors chaîne et inscrire seulement le hachage (datahash) sur BTC comme « engagement », ou compresser fortement les données (comme Chainway avec State diff + ZK Proof).
Clairement, cette approche ne correspond plus à la définition d’un « Rollup souverain » ou d’un vrai Rollup, mais constitue une variante dont la sécurité reste incertaine. Nous prédisons que la plupart des projets Layer2 brandissant le label « Rollup » finiront par ne pas publier intégralement leurs données DA sur BTC, s’écartant ainsi largement des slogans promotionnels « ZK Rollup » ou « OP Rollup » figurant dans leurs livres blancs.
Enfin, synthétisons brièvement les différences entre Rollup souverain et Rollup par contrat intelligent :
Premièrement, l’extensibilité. La mise à jour d’un Rollup par contrat intelligent nécessite une mise à jour du contrat, impliquant l’utilisation de contrats upgradables, dont les droits sont généralement contrôlés par l’équipe développeuse via un multisig. En revanche, les mises à jour d’un Rollup souverain suivent des règles comparables aux forks (doux ou durs) des blockchains traditionnelles : chaque nœud peut choisir d’accepter ou non la mise à jour. Sous cet aspect, le Rollup souverain est supérieur au Rollup par contrat intelligent.
Deuxièmement, le pont. Le pont d’un Rollup par contrat intelligent est idéalement minimisant la confiance, bien que la possibilité de mise à jour du contrat puisse affecter sa sécurité. En revanche, dans un Rollup souverain, les développeurs doivent construire eux-mêmes le composant de pont hors chaîne, aboutissant très probablement à un pont nécessitant davantage de confiance qu’un pont par contrat intelligent.
Construction de la couche DA sur BTC
Comme mentionné précédemment, la clé pour construire un Rollup souverain sur BTC réside dans l'utilisation du protocole Ordinals pour faire de BTC une couche DA. C'est exactement ce que fait Chainway.
Observons une transaction de soumission de données DA émise par le séquenceur de Chainway, dont le hash est :
24add7cdcbffcda8d43509c8e27c5a72f4d39df1731be84bdba727cd83ae0000, illustration ci-dessous :
Cette transaction exploite le code script d’Ordinals Protocol utilisant OP_0 OP_IF pour écrire des données, inscrivant ainsi les données DA du Rollup sur la chaîne BTC (publication des changements d’état + preuve ZK, équivalente en sécurité à la publication des données brutes de transaction, mais avec une compression massive de taille).
Outre les données DA, le séquenceur inclut aussi des données d’authentification, notamment la signature des données DA avec sa propre clé privée, garantissant que la soumission provient bien du séquenceur.
Notons également qu’une transaction quelconque de soumission de données DA comporte systématiquement 16 zéros binaires à la fin de son hash (soit deux octets consécutifs à zéro). Ce seuil apparaît dans le code :
La valeur aléatoire b715 dans l’exemple précédent sert à ajuster le hash de la transaction pour qu’il se termine par 16 zéros, un peu comme le nonce dans le minage Bitcoin, qui permet d’obtenir un hash avec N bits initiaux à zéro, satisfaisant une condition précise.
Cette conception simplifie l’extraction des données DA : lorsqu’un nœud Layer2 veut récupérer les données DA, il scanne simplement les transactions des blocs BTC dont le hash se termine par 16 zéros, permettant ainsi de distinguer clairement les transactions envoyées par le séquenceur Chainway des autres transactions BTC. Par la suite, nous appellerons « transaction conforme Chainway » toute transaction contenant des données DA et respectant la condition des 16 zéros finaux.
Nous arrivons maintenant au cœur du sujet évoqué dans le titre : comment Chainway assure-t-il la résistance à la censure ? Puisqu’un séquenceur Layer2 pourrait refuser intentionnellement certaines transactions, une solution spécifique est nécessaire pour permettre aux utilisateurs d’envoyer des transactions anti-censure.
Face à ce problème, Chainway autorise les utilisateurs à envoyer une « transaction forcée » (Forced Transaction). Dès qu’un utilisateur soumet cette déclaration sur un bloc BTC, le séquenceur Chainway doit traiter la requête sur Layer2, sinon il ne pourra pas produire de bloc valide, ou ses blocs seront rejetés par les clients hors chaîne.
Structure des paramètres d’une transaction forcée :
Cette transaction est envoyée comme une « transaction conforme Chainway » sur la chaîne Bitcoin, avec un hash se terminant par 16 zéros. Lorsque le séquenceur Chainway génère un bloc L2, il doit inclure toutes les « transactions conformes Layer2 » déjà divulguées sur BTC mais non encore intégrées au registre L2, les regrouper dans un arbre de Merkle, et inscrire la racine dans l’en-tête du bloc L2.
Dès qu’un utilisateur lance directement une transaction forcée sur BTC, le séquenceur doit la traiter, sinon il ne peut produire le prochain bloc valide. Les clients Chainway hors chaîne peuvent d’abord vérifier la preuve ZK, confirmer la validité du bloc L2 soumis, puis vérifier la racine de Merkle dans l’en-tête pour juger si le séquenceur a bien inclus la demande de transaction forcée.
Le flux de travail est illustré ci-dessous. Notez que, par souci de concision, la condition de vérification verify_relevant_tx_list est incomplète sur le schéma :
En résumé, les clients/nœuds Chainway synchronisent les blocs BTC, y extraient les « données DA » publiées par le séquenceur, vérifient qu’elles proviennent bien du séquenceur désigné et qu’elles incluent effectivement toutes les « transactions conformes Chainway » soumises sur BTC.
Il est clair que tant qu’un utilisateur peut construire une « transaction conforme » répondant aux conditions et la soumettre sur BTC, cette transaction sera in fine intégrée au registre L2 local du client Chainway ; sinon, les blocs L2 publiés par le séquenceur seront rejetés par les clients.
Avec un consensus hors chaîne / transmission d’alertes fiable, la solution de transaction anti-censure de Chainway s’approcherait du modèle idéal du Rollup souverain. Certains projets ont par exemple annoncé qu’en cas de bloc invalide, ils diffuseraient un signal d’alerte entre clients hors chaîne pour renforcer la sécurité, surtout pour informer les clients légers incapables de synchroniser toutes les données DA.
Si un bloc omet une « transaction forcée », un signal d’alerte devrait être déclenché, mais pour l’instant, Chainway n’a pas encore implémenté cette fonctionnalité (du moins, ni ses documents publiés ni son code ne montrent qu’il ait travaillé là-dessus).
Ressource : Analyse par un chercheur Celestia de 6 variantes de Rollup : Séquenceur = agrégateur + générateur d’en-têtes
Même avec un consensus entre clients/nœuds hors chaîne, l’efficacité anti-censure de la « transaction forcée » de Chainway reste inférieure à celle d’un Rollup par contrat intelligent comme Arbitrum, car Arbitrum One garantit finalement via un contrat sur Layer1 que la transaction forcée est incluse dans le registre L2, héritant pleinement de la résistance à la censure de Layer1. Le Rollup souverain ne peut rivaliser sur ce point, sa résistance à la censure dépendant ultimement de la partie hors chaîne.
Cela implique que les approches « Rollup souverain » ou « validation côté client » ne peuvent pas comme Arbitrum One, Loopring, dydx ou Degate, hériter entièrement de la résistance à la censure de Layer1, car l'inclusion des transactions forcées dans le registre L2 dépend des décisions des entités hors chaîne de Layer2, indépendamment de Layer1.
Il est donc évident que Chainway, avec une solution reposant uniquement sur la décision libre des clients hors chaîne, n’hérite que de la fiabilité DA de Layer1, sans en transmettre pleinement la résistance à la censure.
Preuve ZK récursive similaire à MINA
Dans cette section, nous détaillons d'autres composants de Chainway. Outre l'utilisation de BTC comme couche DA, il implémente une preuve ZK récursive similaire à celle de MINA. Sa structure globale est illustrée ci-dessous :
Après traitement des transactions utilisateur, le séquenceur Chainway génère une preuve ZK finale, accompagnée des différences d’état (state diff), et les publie sur BTC. Les nœuds complets synchronisent toutes les données historiques Chainway publiées sur BTC. Chaque preuve ZK doit non seulement prouver la transition d’état du bloc courant, mais aussi garantir la validité de la preuve ZK du bloc précédent.
Grâce à ce système, chaque nouvelle preuve confirme récursivement la précédente, de sorte que la dernière preuve ZK garantit la validité de toutes les preuves antérieures depuis le bloc genesis. Cette conception rappelle MINA.
Lorsqu’un « client léger » synchronisant uniquement les en-têtes de blocs rejoint le réseau, il lui suffit de vérifier la validité de la dernière preuve ZK publiée sur BTC pour confirmer que l’historique complet de la chaîne et toutes les transitions d’état sont valides.
Si le séquenceur agit malicieusement en ignorant une transaction forcée ou en ne réutilisant pas la preuve ZK précédente, la nouvelle preuve générée ne sera pas acceptée par les clients (même si elle est produite, elle ne sera pas reconnue), comme illustré ci-dessous :
Conclusion
Comme résumé au début de cet article, Chainway est fondamentalement une solution de Rollup souverain/validation côté client utilisant BTC comme couche DA. Pour renforcer la résistance à la censure, Chainway introduit le concept de transaction forcée. D’autre part, il utilise la technologie de preuve ZK récursive, permettant aux nouveaux nœuds de faire davantage confiance aux résultats produits par le séquenceur et de vérifier instantanément l’intégrité historique complète de la chaîne.
Le principal problème actuel de Chainway concerne la fiabilité de son pont inter-chaînes. Du fait de son choix pour un Rollup souverain, il n’a pas encore précisé les détails techniques de son pont, rendant difficile l’évaluation de sa sécurité finale.
Aujourd’hui, notre analyse approfondie de la solution technique de Chainway révèle que le type de technologie promu par la communauté du projet ne correspond pas à la définition classique d’un Rollup. Compte tenu que l’écosystème Bitcoin Layer2 compte déjà des dizaines de projets (probablement plus d’une centaine dans six mois), afin de réduire le coût cognitif lié aux termes techniques, nous poursuivrons nos recherches approfondies sur la classification des solutions Layer2, les standards de sécurité et de complétude fonctionnelle. Restez à l’écoute !
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
@godrealmx
