Introduction:

La scène actuelle de Bitcoin Layer2 est animée par diverses solutions technologiques qui convergent vers le melting-pot de l’écosystème BTC. Compte tenu du rythme rapide de l’itération dans le domaine de la blockchain, où le vocabulaire et les normes professionnels évoluent continuellement grâce à la recherche, à l’innovation et à la mise en œuvre de l’ingénierie, de nombreux projets ont recours à la « création de concepts » ou à « l’auto-stop de concepts » pour se différencier et attirer l’attention, devenant une règle tacite au sein de l’industrie. Par exemple, plusieurs projets de blockchain modulaire initialement actifs au sein de l’écosystème Ethereum/Celestia ont sauté dans le train en marche de la « couche 2 de Bitcoin », se surnommant eux-mêmes « Rollups », bien que leurs solutions techniques ne répondent souvent pas aux normes Rollup. Cependant, le terme « Rollup » est très reconnu, ce qui le rend avantageux à des fins promotionnelles. De nombreux opérateurs de projet se qualifient eux-mêmes de manière forcée de Rollups ou de forker le concept de Rollup traditionnel avec des qualificatifs vagues, tels que « Sovereign Rollup ». Si l’on enlève les couches de ces « XX Rollups », de nombreux projets sont essentiellement basés sur la « validation côté client » ou les « sidechains », en utilisant simplement le slogan « XX Rollup » pour plus de commodité. Bien que cette stratégie promotionnelle soit courante, elle a tendance à être trompeuse, causant plus de mal que de bien à ceux qui cherchent la vérité.

(Cette approche, résumée par le ministre de la Propagande nazie Goebbels comme une "propagande basée sur le mensonge", est fréquemment observée chez les opérateurs de projets.) Comment alors pouvons-nous discerner un tel comportement de "covoiturage de concept Rollup"? Peut-être, en commençant par des principes fondamentaux, en définissant les différentes catégories de projets Layer2 et leurs niveaux de sécurité et fonctionnalités basés sur des normes largement acceptées en Occident et dans l'industrie, pourrait offrir de la clarté. Il ne s'agit pas nécessairement de la solution choisie; l'essentiel réside dans le fait que la conception mécanique du projet garantit la sécurité et la fiabilité du réseau Layer2 et renforce véritablement le mainnet BTC.

Cet article utilisera Chainway, un projet Layer2 Bitcoin, comme étude de cas pour disséquer la nature de la « validation côté client » cachée derrière certains slogans « Rollup » de projets. Nous visons à distinguer clairement entre le « Sovereign Rollup » et la « validation côté client », ainsi que les différences significatives par rapport aux ZKRollups ou OPRollups standard de l'industrie qui reposent sur des contrats intelligents. Cela ne signifie pas que les Sovereign Rollups ou les validations côté client sont inférieurs aux ZK Rollups en termes de sécurité et de fiabilité ; tout dépend de leurs détails d'implémentation spécifiques. Chainway, typiquement un Layer2 de validation côté client, a proposé un schéma de transaction anti-censure déclenché sur BTC avec une validation hors chaîne, utilisant des preuves ZK récursives similaires à celles utilisées par la chaîne publique MINA, le positionnant devant de nombreux projets Layer2 Bitcoin. Nous pensons que la recherche sur la technologie de Chainway est précieuse, offrant des insights significatifs aux observateurs de Layer2 Bitcoin. (Les images promotionnelles de Chainway le présentent comme un ZK Rollup, mais sa vieille solution était une validation côté client, ZKR étant un autre de leurs projets. Actuellement, il n'a pas atteint de consensus client hors chaîne ou d'échange de messages fiable.)

Texte principal: Chainway est un projet Bitcoin Layer2 bien connu dans la communauté occidentale, souvent désigné comme un "ZK Rollup" par de nombreux KOLs, tandis que sa documentation technique le positionne comme un "Sovereign Rollup." Récemment, Chainway a également annoncé son nouveau projet, Citrea, affirmant qu'il s'agit d'un ZK Rollup basé sur BitVM. Cependant, comme Citrea n'a pas encore détaillé sa solution de vérification ZK basée sur BitVM, cet article se concentrera sur l'interprétation technique des solutions précédentes de Chainway. En résumé, la solution technique publiquement divulguée par Chainway implique la publication de données DA via le protocole Ordinals, en utilisant BTC comme couche DA, et la publication de détails de changement d'état (différence d'état) + Preuve ZK vérifiant la correction des changements d'état sur Layer1, équivalent à la publication de données de transaction complètes et vérifiables. Cependant, comme Layer1 ne vérifie pas directement les Preuves ZK, la vérification est effectuée par des clients/nœuds indépendants hors chaîne, et le codebase actuel de Chainway n'a pas atteint un consensus parmi les clients hors chaîne, ni prétendu résoudre ce problème sur les réseaux sociaux, la solution technique publiquement divulguée de Chainway appartient essentiellement à la catégorie de la "validation côté client", ressemblant même à un protocole cryptographiquement indexé prenant en charge le pontage d'actifs. Les sections suivantes présenteront la mise en œuvre technique spécifique de Chainway et analyseront son modèle de sécurité.

Qu'est-ce qu'un Sovereign Rollup : Publication de la couche de disponibilité des données (DA) + Vérification hors chaîne

Dans la documentation technique de Chainway, le concept d'un Rouleau Souverain de Celestia est utilisé. Un Rouleau Souverain est fondamentalement différent du concept de Rollup traditionnel au sein de la communauté Ethereum et de l'industrie plus large (Rollup de contrat intelligent). Alors, quelle est exactement la structure d'un Rouleau Souverain ?

En substance, un Sovereign Rollup basé sur Bitcoin est quelque peu semblable à une "publication hors chaîne d'un groupe de clients/sidechain de données sur la blockchain BTC." Sa principale caractéristique est qu'il ne nécessite pas de contrats intelligents sur la Couche 1 pour vérifier les transitions d'état/actions inter-chaînes pour la Couche 2. Fondamentalement, il utilise le BTC comme couche DA, et son modèle de sécurité est largement similaire à une "validation côté client." Bien sûr, certaines solutions Sovereign Rollup plus sécurisées s'appuient sur une couche de règlement tierce hors de la chaîne Bitcoin (similaire à une sidechain) pour effectuer des vérifications de transition d'état. De plus, parmi les différents clients complets/nœuds indépendants, il existe un niveau de consensus ou de transmission de messages fiable pour parvenir à un "accord" sur certaines actions litigieuses. Cependant, certains projets Sovereign Rollup sont purement basés sur une "validation côté client," sans aucun passage de messages fiable entre les clients/nœuds indépendants.

Pour mieux comprendre le concept unique de "Sovereign Rollup", il est utile de le comparer à son homologue, le Rollup de contrat intelligent. Sur Ethereum, les solutions de couche 2 sont principalement des Rollups de contrats intelligents, tels que Arbitrum et StarkNet. La structure d'un Rollup de contrat intelligent peut être visualisée dans le diagramme suivant:

(Imaginez un diagramme ici)

Sur le schéma, nous pouvons voir plusieurs termes liés au récit modulaire de la blockchain, expliqués comme suit:

• Couche d'exécution: Exécute les transactions des utilisateurs, met à jour l'état de la blockchain et soumet les données à la couche DA et à la couche de règlement.

• Couche de RèglementVérifie les transitions d'état de la couche d'exécution, résout les litiges (comme les preuves de fraude) et fournit un module de pont pour gérer les actifs de pont L1-L2.

• Couche de Disponibilité des Données (DA): Agit comme un grand tableau d'affichage, recevant les données de transition d'état soumises par la couche d'exécution et fournissant ces données de manière impartiale à quiconque.

• Couche de consensus: Assure la finalité de l'ordonnancement des transactions. Sa fonction semble quelque peu proche de celle de la couche DA (l'approche de la communauté Ethereum en matière de superposition modulaire de la blockchain n'inclut pas de couche de consensus).
  
  De l'architecture des Rollups de contrats intelligents, nous voyons qu'Ethereum assume le rôle des trois dernières couches, en plus de la couche d'exécution. Un autre diagramme pourrait fournir une vue plus détaillée des rôles qu'Ethereum joue dans les Rollups de contrats intelligents.
  
  En revanche, les Rollups souverains se distinguent de manière significative en ce qu'ils décentralisent certaines de ces responsabilités loin d'une blockchain monolithique comme Ethereum. Plus précisément, ils ne dépendent pas des contrats intelligents sur la couche de base (couche 1) pour vérifier les transitions d'état ou gérer les conflits. Au lieu de cela, ces tâches sont gérées par des clients hors chaîne ou via une couche de règlement tierce, mettant en avant une approche différente pour atteindre la scalabilité et la sécurité dans les systèmes blockchain.

Les contrats Rollup sur Ethereum reçoivent soit des preuves de validité, soit des preuves de fraude pour vérifier la validité des transitions d'état de la couche 2. Il convient de mentionner que les contrats intelligents Rollup agissent en tant qu'entités de couche de règlement dans l'architecture modulaire de la blockchain. Les contrats de couche de règlement incluent souvent des modules de pont pour gérer les actifs pontés d'Ethereum vers la couche 2. Pour la Disponibilité des Données (DA), les contrats de couche de règlement peuvent obliger le Séquenceur à publier les derniers détails de transaction/d'état de changement sur la chaîne. Sans publication de la DA sur la chaîne, il est impossible de mettre à jour avec succès l'état L2 enregistré dans les contrats Rollup.

(ZK Rollup ou Optimistic Rollup peuvent contraindre les données DA à être publiées on-chain ; sans cela, l'état enregistré dans la couche de règlement ne peut pas être mis à jour.) En analysant le modèle de sécurité et les indicateurs de risque des solutions de couche 2 de Bitcoin/Ethereum avec la théorie du tonneau, il est clair que les Rollups de contrats intelligents reposent fortement sur les contrats intelligents de la couche 1. Pour une couche 1 comme BTC, qui peine à prendre en charge une logique commerciale complexe, la construction d'une couche 2 qui soit en phase avec les Rollups d'Ethereum est essentiellement impossible. D'autre part, les solutions Sovereign Rollup ne nécessitent pas de contrats sur la couche 1 pour la vérification/l'articulation des états. Leur architecture est la suivante : (Ici, la description de l'architecture est manquante, ce qui laisse entendre qu'une illustration ou des détails supplémentaires étaient censés être inclus mais ne sont pas fournis dans le texte.)

Dans les Rollups souverains, les nœuds en dehors de la couche de disponibilité des données (DA) servent d'entités pour l'exécution des transactions et des opérations de règlement, offrant un degré de liberté plus élevé. Le flux de travail est le suivant :

Les nœuds de la couche d’exécution du correctif souverain envoient les données de transaction/les détails de changement d’état à la couche DA, tandis que la couche de règlement/les clients s’efforcent d’obtenir et de vérifier les données. Il est important de noter qu’étant donné que le module de la couche de règlement n’est pas situé sur la couche 1, les rollups souverains, en théorie, ne peuvent pas atteindre des ponts avec une sécurité équivalente à la couche 1. Ils s’appuient souvent sur des ponts notariaux ou des solutions de transition tierces. À l’heure actuelle, la mise en œuvre des systèmes souverains de vérification des clients est relativement simple, ne nécessitant que la publication de données sur la chaîne Bitcoin (BTC) à l’aide d’un protocole similaire à Ordinals. En ce qui concerne la vérification et le consensus hors chaîne, il y a beaucoup de flexibilité. En fait, de nombreuses sidechains publient simplement des données DA sur la chaîne BTC, devenant essentiellement des « rollups souverains basés sur BTC », bien que la sécurité spécifique soit discutable. Cependant, le problème est que le débit de données de Bitcoin est extrêmement faible, avec un maximum de 4 Mo par bloc et un temps de bloc moyen de 10 minutes, ce qui se traduit par un débit de données de seulement 6 Ko/s. Les solutions de couche 2 prétendant être des Rollups souverains peuvent ne pas être en mesure de publier toutes les données DA sur la chaîne BTC, elles peuvent donc opter pour des méthodes alternatives, telles que la publication de données DA hors chaîne et le stockage du datahash sur la chaîne BTC comme une forme d'« engagement », ou la recherche d’un moyen de compresser fortement les données DA (par exemple, en utilisant State diff + ZK Proof comme le prétend Chainway). De toute évidence, ce mode n’est pas conforme à la définition de « Rollup souverain » ou d’un Rollup à proprement parler, représentant une variante dont la sécurité est discutable. Nous prévoyons que la plupart des projets de couche 2 portant la bannière « Rollup » ne publieront finalement pas toutes les données DA sur la chaîne BTC, de sorte que leurs solutions pratiques ne correspondront probablement pas aux affirmations « ZK Rollup » ou « OP Rollup » faites dans leurs livres blancs.

Enfin, résumons brièvement les différences entre les Rollups souverains et les Rollups de contrats intelligents :

1. Capacité de mise à niveau :Les itérations de mise à jour des Rollups de contrat intelligent impliquent la mise à jour des contrats intelligents, ce qui nécessite que l'équipe de développement utilise des contrats évolutifs. Ce type d'autorisation de mise à niveau de contrat intelligent est généralement contrôlé par l'équipe de développement Rollup via une signature multiple. En revanche, les règles de mise à jour des Rollups souverains sont similaires aux fourches logicielles et matérielles des chaînes de blocs conventionnelles, où les nœuds peuvent choisir de mettre à jour les versions de manière indépendante, et les clients peuvent choisir d'accepter ou non la mise à jour. De ce point de vue, les Rollups souverains sont supérieurs aux Rollups de contrat intelligent en termes de capacité de mise à niveau.

2. Ponts :Dans des conditions ideéales, les ponts pour les Rollups de contrats intelligents respectent un niveau minimal de confiance, mais la possibilité de mettre à niveau les contrats peut affecter leur sécurité. Dans le schéma Rollup souverain, les développeurs doivent construire eux-mêmes les composants de pontage sous la chaîne de couche 1, et les ponts construits sont susceptibles d'avoir moins confiance que les ponts de contrats intelligents.

Structure DA de BTC

Dans le texte ci-dessus, nous avons mentionné que pour mettre en œuvre un Rollup souverain basé sur BTC, le cœur réside dans l’utilisation du protocole Ordinals pour faire en sorte que BTC serve de couche de disponibilité des données (DA). Chainway a adopté cette solution.

Nous pouvons examiner une soumission de données DA du séquenceur Chainway, avec le hachage de transaction étant :

24add7cdcbffcda8d43509c8e27c5a72f4d39df1731be84bdba727cd83ae0000, illustré comme suit:

Ce script de transaction s'inspire de l'approche du Protocole des Ordinaux qui utilise OP_0 OP_IF pour l'écriture de données afin d'écrire les données de disponibilité des données (DA) de Rollup sur la chaîne BTC. Cela implique la publication des changements d'état et des preuves ZK, ce qui équivaut en termes de sécurité à la publication des données de transaction originales mais permet une réduction significative de la taille des données. En plus des données DA, le séquenceur écrit également certaines données d'authentification dans la transaction, la plus cruciale étant que le séquenceur de Rollup signe les données DA avec sa clé privée pour garantir que la soumission provient du séquenceur. Il est important de noter que toute transaction impliquant la soumission de données DA comporte 16 zéros binaires à la fin du hachage de la transaction (c'est-à-dire que deux octets consécutifs sont nuls). Cette restriction peut être observée dans le code:

Dans le graphe de transaction d'exemple mentionné précédemment, le nombre aléatoire "b715" est utilisé pour ajuster la valeur de hash de la transaction afin que sa queue porte 16 zéros spécifiques. Ce principe est similaire au minage de Bitcoin, où un nombre aléatoire nonce est ajouté pour que les N bits de tête du hash soient tous des zéros, répondant à des conditions de contrainte spécifiques. Cette conception vise à simplifier la difficulté d'obtenir des données DA (Disponibilité des Données). Lorsqu'un nœud de couche 2 souhaite accéder aux données DA, il lui suffit de scanner le bloc BTC (Bitcoin) pour toutes les transactions définies pour se terminer par 16 zéros, ce qui permet de distinguer efficacement les transactions initiées par le trieur Chainway lors de la soumission de données des autres transactions sur la blockchain Bitcoin. Dans le texte suivant, de telles transactions contenant des données DA et répondant à l'exigence de se terminer par 16 zéros sont appelées "transactions standard Chainway." L'accent de cet article est mis sur la manière dont Chainway réalise la résistance à la censure. Étant donné qu'un trieur de couche 2 pourrait refuser délibérément une demande de transaction d'un utilisateur spécifique, un schéma spécial doit être utilisé pour permettre aux utilisateurs d'initier des transactions résistantes à la censure. En réponse à ce problème, Chainway permet aux utilisateurs de lancer des "Transactions Forcées." Une fois qu'un utilisateur soumet cette déclaration de transaction dans un bloc BTC, le trieur Chainway doit traiter cette demande de transaction sur la couche 2 ; sinon, il ne pourra pas produire normalement un bloc, ou le bloc produit ne sera pas reconnu par les clients hors chaîne. La structure des paramètres de la transaction forcée est la suivante :

Cette transaction sera soumise à la blockchain Bitcoin en tant que « Transaction de spécification de la voie de chaîne », avec le hachage de transaction se terminant par 16 zéros. Le trieur ChainWay, lors de la génération des blocs L2, doit inclure des « Transactions de spécification de la couche 2 » qui ont été divulguées sur la blockchain BTC mais pas encore enregistrées dans le grand livre L2, et les agréger dans un arbre de Merkle, écrivant sa racine de Merkle dans l'en-tête du bloc L2. Une fois qu'un utilisateur initie une transaction forcée directement sur la blockchain BTC, le trieur doit la traiter; sinon, il ne peut pas générer le bloc valide suivant. Le client Chainway hors de la chaîne BTC peut d'abord vérifier la preuve ZK pour déterminer la validité du bloc L2 soumis par le trieur, vérifier la racine de Merkle de l'en-tête du bloc L2, et juger si le trieur a inclus de manière véridique la demande de transaction forcée. Le flux de travail peut être consulté dans le diagramme suivant. Veuillez noter que, en raison de contraintes d'espace, le diagramme ci-dessous manque un jugement de condition dans verify_relevant_tx_list :

En résumé, le client/node Chainway se synchronise avec les blocs du réseau principal BTC et recherche les “données DA” publiées par le trieur Chainway à partir de ceux-ci. Il vérifie que ces données sont publiées par le trieur désigné et contiennent effectivement toutes les “transactions standard Chainway” soumises à la chaîne BTC. Il est évident que tant que les utilisateurs peuvent construire une transaction qui répond aux critères spécifiés en tant que “transaction standard” et la soumettre à la chaîne BTC, cette transaction sera finalement incluse dans le grand livre local L2 du client Chainway. Sinon, le bloc L2 publié par le trieur Chainway sera rejeté par le client. Associé à une transmission fiable de messages de consensus/alerte hors chaîne, le schéma de transaction anti-censure de Chainway se rapproche de la méthode anti-censure idéale des Rollups souverains. Par exemple, certaines solutions de Rollup souverains ont explicitement déclaré que en cas de bloc invalide, des messages d'alerte seraient diffusés parmi les clients hors chaîne pour renforcer la sécurité, en particulier en informant les clients légers qui ne peuvent pas synchroniser des données DA complètes des anomalies du réseau. Si un bloc n'inclut pas de manière véridique des “transactions obligatoires”, il déclenchera évidemment une diffusion d'alerte hors chaîne. Cependant, Chainway n'a pas encore mis en œuvre cet aspect (du moins les documents et dépôts de code actuellement publiés montrent qu'il n'a pas entrepris la mise en œuvre technique de cette partie).

Matériel de référence : les chercheurs de Celestia analysent 6 types de variantes de Rollup : Séquenceur = Agrégateur + Générateur d'en-têtes. Même avec le consensus obtenu entre les clients/nœuds hors chaîne, l'efficacité anti-censure des "transactions forcées" de Chainway n'est pas aussi robuste que celle des Rollups de contrats intelligents comme Arbitrum, car Arbitrum One garantira finalement que les "transactions forcées" sont incluses dans le registre de la Couche2 grâce à des contrats sur la Couche1, héritant pleinement des propriétés anti-censure de la Couche1. Les Rollups souverains ne peuvent clairement pas rivaliser avec les Rollups de contrats intelligents dans ce domaine, car leur efficacité anti-censure dépend finalement des composants hors chaîne. Cela détermine également que l'approche des "Rollups souverains" et des schémas de "vérification des clients" ne peuvent fondamentalement pas hériter pleinement des propriétés anti-censure de la Couche1, comme Arbitrum One, Loopring, dydx et Degate, car la possibilité d'inclure en douceur les transactions forcées dans le registre de la Couche2 dépend des décisions des entités hors chaîne de la Couche2, sans rapport avec la Couche1 elle-même. De toute évidence, l'approche de Chainway, qui repose uniquement sur la discrétion des clients hors chaîne, n'hérite que de la fiabilité de la DA de la Couche1, pas de ses pleines propriétés anti-censure. Similaire aux preuves ZK récursives de MINA.

Dans cette section, nous présenterons plus en détail les autres composants de Chainway, qui, en plus d'utiliser BTC comme couche DA, ont également mis en œuvre des preuves ZK récursives similaires à MINA. Sa structure globale est illustrée dans le diagramme suivant :

Le trieur du réseau Chainway, après avoir traité les transactions des utilisateurs, génère la preuve finale ZK (Zero-Knowledge) ainsi que les détails des changements d’état (différence d’état) pour différents comptes et les publie sur la blockchain Bitcoin (BTC). Les nœuds complets synchroniseront toutes les données historiques de Chainway publiées sur la blockchain BTC. Chaque preuve ZK doit non seulement prouver le processus de transition d’état du bloc actuel, mais aussi assurer la validité de la preuve ZK du bloc précédent. Sur la base de ce schéma, nous pouvons voir que chaque fois qu’une nouvelle preuve est générée, elle confirme essentiellement la preuve précédente de manière récursive, et la dernière preuve ZK peut garantir la validité de toutes les preuves ZK à partir du bloc de genèse. Cette conception est similaire à celle de MINA. Lorsqu’un « client léger » qui ne synchronise que les en-têtes de bloc, également connu sous le nom de nœud léger, rejoint le réseau, il lui suffit de vérifier la validité de la dernière preuve ZK divulguée sur la blockchain BTC pour confirmer que les données historiques de l’ensemble de la chaîne et toutes les transitions d’état sont valides. Si le trieur agit de manière malveillante, en refusant intentionnellement d’accepter les transactions obligatoires ou en omettant d’utiliser la preuve ZK précédente pour la preuve récursive, la preuve ZK nouvellement générée ne peut pas être acceptée par le client (même si elle est générée, elle n’est pas reconnue), comme le montre le schéma ci-dessous :

Résumé

Comme résumé au début de cet article, Chainway est fondamentalement un schéma de vérification Rollup/client souverain qui utilise BTC comme couche de disponibilité des données (DA). Pour renforcer la résistance à la censure du Rollup, Chainway introduit le concept de transactions forcées. D'autre part, Chainway utilise la technologie de preuve ZK récursive, permettant aux nouveaux nœuds de faire confiance à la sortie du séquenceur et de vérifier l'exactitude des données historiques de la chaîne entière à tout moment. Le problème actuel avec Chainway réside dans le mécanisme de confiance de son pont inter-chaînes. Étant donné qu'il adopte une approche Rollup souveraine sans détailler comment il prévoit de traiter les spécificités techniques dans sa solution de pont inter-chaînes, il est difficile de juger de sa sécurité ultime.

Aujourd'hui, en examinant la solution technique de Chainway, nous avons découvert que le type de technologie promu par la communauté du projet n'est pas un Rollup au sens traditionnel. Étant donné qu'il existe déjà des dizaines de projets Bitcoin Layer2 (qui pourraient atteindre des centaines en six mois), pour réduire le coût cognitif des termes techniques, nous continuerons à mener des recherches approfondies sur la classification des solutions Layer2 et les normes en matière de sécurité, de complétude fonctionnelle et d'évaluation. Restez à l'écoute!

Avertissement：

1. Cet article est repris de [ 极客 Web3]. Tous les droits d’auteur appartiennent à l’auteur original [Shew & Faust, web3 geek]. Si des objections sont soulevées concernant cette reproduction, veuillez contacter le Porte Apprendreéquipe, et ils s'en occuperont rapidement.
2. Clause de non-responsabilité : Les points de vue et opinions exprimés dans cet article sont uniquement ceux de l'auteur et ne constituent aucun conseil en investissement.
3. Les traductions de l'article dans d'autres langues sont effectuées par l'équipe Gate Learn. Sauf mention contraire, la copie, la distribution ou le plagiat des articles traduits est interdite.