Depuis le "Summer of Inscriptions" en 2023, les technologies de couche2 de Bitcoin sont à l'avant-garde de la révolution Web3. Malgré leur entrée tardive sur le marché par rapport aux solutions de couche2 d'Ethereum, Bitcoin a su tirer parti de l'attrait unique de POW et du lancement en douceur des ETF en spot, qui sont exempts de risques de "titrisation", pour attirer des milliards de dollars d'investissements vers ce secteur en pleine croissance en seulement six mois. Parmi ceux-ci, Merlin se distingue comme l'entité la plus importante et la plus suivie dans le paysage de Bitcoin Layer2, avec des milliards de dollars de valeur totale bloquée (TVL). Grâce à des incitations claires à la mise en jeu et des rendements impressionnants, Merlin a rapidement acquis une notoriété, surpassant même l'écosystème bien connu de Blast en quelques mois seulement. Avec l'engouement croissant autour de Merlin, l'exploration de son infrastructure technique captive un public de plus en plus vaste. Dans cet article, Geek Web3 se concentre sur le décryptage des stratégies techniques derrière Merlin Chain. En déballant les documents disponibles publiquement et la logique derrière la conception de son protocole, nous visons à démystifier les processus opérationnels de Merlin et à améliorer la compréhension de son cadre de sécurité, offrant une vue plus claire du fonctionnement de cette solution phare de Bitcoin Layer2.

Réseau Oracle Décentralisé de Merlin : Un Comité DAC Hors Chaîne Ouvert

Pour chaque technologie de couche 2, l'adresse de disponibilité des données (DA) et le coût de la publication des données restent un défi critique, que ce soit pour la couche 2 d'Ethereum ou la couche 2 de Bitcoin. Compte tenu des limites inhérentes du réseau Bitcoin, qui lutte avec un débit important de données, la stratégie de l'utilisation efficace de l'espace DA précieux est un test significatif pour la créativité des développeurs de la couche 2.

Il est évident que si les projets de couche 2 devaient publier directement des données de transaction brutes sur la blockchain Bitcoin, ils échoueraient à atteindre à la fois un débit élevé et des frais réduits. Les solutions prédominantes consistent à compresser fortement les données pour réduire significativement leur taille avant de les téléverser sur la blockchain Bitcoin, ou à choisir de publier les données hors chaîne.

Parmi ceux qui utilisent la première stratégie, Citrea se démarque. Ils visent à télécharger les changements d'états de la couche 2 à intervalles réguliers, ce qui implique d'enregistrer les résultats des changements d'état sur plusieurs comptes, ainsi que les preuves de connaissance nulle (ZKP) correspondantes, sur la blockchain Bitcoin. Dans le cadre de cet arrangement, n'importe qui peut accéder aux différences d'état et aux ZKP depuis le réseau principal de Bitcoin pour suivre les changements d'état de Citrea. Cette approche réduit efficacement la taille des données téléchargées sur la blockchain de plus de 90%.

Bien que cela puisse considérablement compresser la taille des données, le goulot d'étranglement reste évident. Si un grand nombre de comptes changent de statut en peu de temps, la Couche 2 doit résumer et télécharger tous les changements de ces comptes sur la chaîne Bitcoin. Le coût final de la publication des données ne peut pas être maintenu très bas. Cela est vrai pour de nombreux Ethereums. On peut le voir dans ZK Rollup.

De nombreuses solutions Bitcoin Layer 2 empruntent simplement le deuxième chemin : utiliser directement la solution DA sous la chaîne Bitcoin, construire une couche DA par elles-mêmes, ou utiliser Celestia, EigenDA, etc. B^Square, BitLayer et le protagoniste de cet article, Merlin, utilisent tous cette solution d'expansion DA hors chaîne.

Article précédent dans geek web3——“Analyse de la feuille de route de la technologie de la nouvelle version B^2 : La nécessité de la couche DA et de vérification sous la chaîne Bitcoin”, nous avons mentionné que B^2 a directement imité Celestia et a construit un réseau DA qui prend en charge la fonction d'échantillonnage de données sous la chaîne, appelé B^2 Hub. Les données 'DA' telles que les données de transaction ou state diff sont stockées sous la chaîne Bitcoin, et seuls les datahash / merkle root sont téléchargés sur le réseau principal de Bitcoin.

Cela traite essentiellement Bitcoin comme un tableau d'affichage sans confiance : n'importe qui peut lire le datahash à partir de la chaîne Bitcoin. Après avoir obtenu les données DA du fournisseur de données hors chaîne, vous pouvez vérifier si elles correspondent au datahash sur chaîne, c'est-à-dire hash(data1) == datahash1 ? S'il y a une correspondance entre les deux, cela signifie que les données fournies par le fournisseur de données hors chaîne sont correctes.

La couche DA dans la couche 2 de Bitcoin expliquée :

(Source de l'image : Geek web3)

Ce système garantit que les données des nœuds hors chaîne correspondent à des « indices » spécifiques ou des preuves sur la couche 1, se protégeant ainsi contre le risque potentiel que la couche DA fournisse de fausses informations. Cependant, une préoccupation majeure survient si l'initiateur des données - le Séquenceur - omet de distribuer les données réelles liées à un hachage de données. Supposons que le Séquenceur transmette uniquement le hachage de données à la blockchain Bitcoin tout en retenant intentionnellement les données correspondantes de l'accès public. Que se passe-t-il alors?

Considérez des scénarios où seuls la Preuve-ZK et le StateRoot sont rendus publics, mais les données DA accompagnantes (comme les différences d'état ou les données de transaction) ne sont pas publiées. Bien qu'il soit possible de valider la Preuve-ZK et de s'assurer que la transition de Prev_Stateroot à New_Stateroot est précise, on ne sait pas quels états de comptes ont changé. Dans ces circonstances, même si les actifs des utilisateurs restent sécurisés, la condition réelle du réseau reste incertaine. Personne ne sait quelles transactions ont été incorporées dans la blockchain ou quels états de contrat ont été mis à jour, rendant effectivement Layer2 inopérant, presque comme s'il était hors ligne.

Cette pratique est appelée "retenue de données". En août 2023, Dankrad de la Fondation Ethereum a lancé une discussion sur Twitter à propos d'un concept connu sous le nom de "DAC".

Dans de nombreuses configurations Ethereum Layer2 qui utilisent des solutions de disponibilité des données hors chaîne (DA), il y a souvent quelques nœuds avec des privilèges spéciaux qui forment un comité appelé Data Availability Committee (DAC). Ce comité sert de garant, assurant que le Séquenceur a effectivement publié des données DA complètes (données de transaction ou différence d'état) hors chaîne. Les membres du DAC créent ensuite une signature multiple collective. Si cette signature multiple atteint le seuil requis (par exemple, 2 sur 4), les contrats correspondants sur Layer1 sont conçus pour supposer que le Séquenceur a satisfait aux normes de vérification du DAC et a véritablement publié l'ensemble des données DA hors chaîne.

Les comités DAC de la couche 2 d'Ethereum adhèrent principalement au modèle de Preuve d'Autorité (POA), limitant l'adhésion à un groupe restreint de nœuds ayant réussi le KYC ou ayant été officiellement désignés. Cette approche a effectivement qualifié le DAC de "centralisation" et de "blockchain de consortium". De plus, dans certains Ethereum Layer2 utilisant l'approche DAC, le séquenceur distribue des données DA uniquement aux nœuds membres du DAC, avec une diffusion externe minimale. Par conséquent, toute personne cherchant des données DA doit obtenir l'approbation du DAC, similaire à l'exploitation au sein d'une blockchain de consortium.

Il est clair que les DAC doivent être décentralisés. Bien que Layer2 ne soit peut-être pas nécessaire pour télécharger directement des données DA sur Layer1, l'accès des membres du DAC devrait être publiquement accessible pour éviter la collusion et les malversations de quelques individus. (Pour en savoir plus sur ce problème, veuillez vous référer aux discussions précédentes de Dankrad sur Twitter.)

La proposition de BlobStream de Celestia vise fondamentalement à remplacer un DAC centralisé par Celestia. Dans ce modèle, un séquenceur Ethereum L2 publierait des données DA sur la blockchain de Celestia. Si les deux tiers des nœuds de Celestia valident ces données, le contrat Layer2 spécialisé sur Ethereum validerait que le séquenceur a correctement publié les données DA, positionnant ainsi les nœuds de Celestia en tant que garants. Étant donné que Celestia fonctionne avec des centaines de nœuds validateurs, cette configuration de DAC plus grande est considérée comme relativement décentralisée.

La solution DA adoptée par Merlin est en fait relativement proche de BlobStream de Celestia, tous deux ouvrant l'accès à DAC via POS, le rendant plus décentralisé. N'importe qui peut exécuter un nœud DAC tant qu'il bloque suffisamment d'actifs. Dans la documentation de Merlin, le nœud DAC mentionné ci-dessus est appelé Oracle, et il est noté qu'il prendra en charge les engagements d'actifs en BTC, MERL et même des jetons BRC-20 pour mettre en œuvre un mécanisme d'engagement flexible et prendra également en charge des engagements de proxy similaires à Lido. (L'accord d'engagement POS de la machine oracle est essentiellement l'un des prochains récits principaux de Merlin, et les taux d'intérêt sur les engagements fournis sont relativement élevés)

Ici, nous décrivons brièvement le workflow de Merlin (image ci-dessous) :

1. Après que le séquenceur reçoit un grand nombre de demandes de transaction, il les agrège et génère un lot de données (lot de données), qui est transmis au nœud Prover et au nœud Oracle (DAC décentralisé).

2. Le nœud de vérificateur de Merlin est décentralisé et utilise le service Prover en tant que service de lumoz. Après avoir reçu plusieurs lots de données, le pool de minage du vérificateur générera des preuves de connaissance nulle correspondantes. Ensuite, ZKP sera envoyé au nœud Oracle pour vérification.

3. Le nœud Oracle vérifiera si la preuve ZK envoyée par le pool de minage ZK de Lmuoz correspond aux données Batch envoyées par le Séquenceur. Si les deux peuvent être appariés et ne contiennent pas d'autres erreurs, la vérification est réussie. Au cours de ce processus, les nœuds Oracle décentralisés généreront des signatures multiples grâce à des signatures seuils et déclareront au monde extérieur que le séquenceur a complètement envoyé les données DA, et que le ZKP correspondant est valide et a passé la vérification des nœuds Oracle.

4. Le séquenceur collecte les résultats de signatures multiples des nœuds Oracle. Lorsque le nombre de signatures atteint les exigences du seuil, les informations de signature sont envoyées à la chaîne Bitcoin, avec le datahash des données DA (lot de données), et sont remises au monde extérieur pour lecture et confirmation.

(Schéma de principe de fonctionnement de Merlin source : Geek web3)

1. Les nœuds oracle effectuent un traitement spécial sur le processus de calcul de vérification de la preuve ZK, génèrent des engagements de Commitment, et les envoient à la chaîne Bitcoin, permettant à quiconque de contester le "commitment". Le processus ici est essentiellement le même que le protocole de preuve de fraude de bitVM. Si le défi est réussi, le nœud Oracle qui a émis le Commitment sera financièrement sanctionné. Bien sûr, les données que Oracle souhaite publier sur la chaîne Bitcoin incluent également le hash de l'état actuel de la couche 2 - StateRoot, ainsi que ZKP lui-même, qui doit être publié sur la chaîne Bitcoin pour une détection externe.

Références:Une interprétation minimaliste de BitVM : Comment vérifier les preuves de fraude sur la chaîne BTC

Il y a plusieurs détails qui doivent être élaborés ici. Tout d'abord, il est mentionné dans la feuille de route de Merlin que Oracle sauvegardera les données DA vers Celestia à l'avenir. De cette façon, les nœuds Oracle peuvent éliminer correctement les données historiques locales sans avoir besoin que les données persistent localement. En même temps, l'engagement généré par le réseau Oracle est en fait la racine d'un arbre de Merkle. Il ne suffit pas de divulguer la racine au monde extérieur. L'ensemble de données complet correspondant à l'engagement doit être rendu public. Cela nécessite de trouver une plateforme DA tierce. Cette plateforme peut être Celestia ou EigenDA, ou d'autres couches DA.

Références :"Analyse de la feuille de route technologique de la nouvelle version B^2 : La nécessité de la couche DA et de vérification sous la chaîne Bitcoin"

Analyse du modèle de sécurité : Optimistic ZKRollup+Service MPC de Cobo

Ci-dessus, nous avons brièvement décrit le flux de Merlin, et je pense que vous avez déjà maîtrisé sa structure de base. Il n'est pas difficile de voir que Merlin, B^Square, BitLayer et Citrea suivent essentiellement le même modèle de sécurité - Optimistic ZK-Rollup.

Lors de la première lecture de ce mot, de nombreux enthousiastes d'Ethereum peuvent se sentir étranges. Qu'est-ce que le «ZK-Rollup optimiste»? Dans la compréhension de la communauté Ethereum, le «modèle théorique» de ZK Rollup est entièrement basé sur la fiabilité des calculs cryptographiques et ne nécessite pas l'introduction d'hypothèses de confiance. Le mot «optimiste» introduit précisément l'hypothèse de confiance, ce qui signifie que la plupart du temps, les gens sont optimistes quant au fait que Rollup ne comporte pas d'erreurs et est fiable. Une fois qu'une erreur se produit, l'opérateur Rollup peut être puni par le biais d'une preuve de fraude. C'est l'origine du nom Optimistic Rollup, également connu sous le nom de Rollup OP.

Pour l'écosystème Ethereum à la base de Rollup, l'optimiste ZK-Rollup peut sembler un peu indescriptible, mais il correspond exactement à la situation actuelle de Bitcoin Layer 2. En raison de limitations techniques, la chaîne Bitcoin ne peut pas vérifier complètement la Preuve ZK. Elle ne peut vérifier qu'une certaine étape du processus de calcul de ZKP dans des circonstances spéciales. Dans cette hypothèse, la chaîne Bitcoin ne peut en réalité prendre en charge que le protocole de preuve de fraude. Les gens peuvent signaler une erreur dans une certaine étape de calcul de ZKP lors du processus de vérification hors chaîne, et contester via une preuve de fraude. Bien sûr, cela ne peut être comparé au ZK Rollup de style Ethereum, mais c'est actuellement le meilleur que Bitcoin Layer 2 peut réaliser. Modèle de sécurité fiable et le plus sécurisé.

Sous le schéma optimiste ZK-Rollup ci-dessus, Supposons qu'il y ait N personnes dans le réseau de la couche 2 qui ont l'autorité d'initier des défis. Dès lors qu'un des N challengers est honnête et fiable et peut détecter les erreurs et lancer une preuve de fraude à tout moment, la transition d'état de la couche 2 est sécurisée. Bien sûr, le Rollup optimiste avec un degré de réalisation relativement élevé doit également garantir que son pont de retrait est également protégé par le protocole de preuve de fraude. Cependant, presque tous les réseaux de la couche 2 du Bitcoin actuels ne peuvent pas atteindre cette prémisse et doivent s'appuyer sur une solution multi-signature/MPC. Alors comment choisir la multi-signature ? La signature de la solution MPC est devenue une question étroitement liée à la sécurité de la couche 2.

Merlin a choisi le service MPC de Cobo pour la solution de pont. En utilisant des mesures telles que l'isolation des portefeuilles chauds et froids, les actifs du pont sont gérés conjointement par Cobo et Merlin Chain. Tout comportement de retrait doit être géré conjointement par les participants MPC de Cobo et Merlin Chain. Fondamentalement, la fiabilité du pont de retrait est garantie par le biais de l'approbation de crédit de l'institution. Bien sûr, il ne s'agit que d'une mesure provisoire à ce stade. À mesure que le projet s'améliore progressivement, le pont de retrait pourra être remplacé par le "pont optimiste" avec une hypothèse de confiance 1/N en introduisant BitVM et le protocole de preuve de fraude. Cependant, la mise en œuvre de cela sera plus difficile. Les grands (presque tous les ponts officiels de couche 2 actuels reposent actuellement sur une signature multiple).

Dans l'ensemble, nous pouvons le trier, Merlin a introduit DAC basé sur POS, ZK-Rollup optimiste basé sur BitVM, et une solution de garde d'actifs basée sur MPC de Cobo, résolvant le problème DA en ouvrant les autorisations DAC; assurant la sécurité des transitions d'état en introduisant BitVM et des protocoles de preuve de fraude; garantissant la fiabilité du pont de retrait en introduisant le service MPC de la plateforme de garde d'actifs bien connue Cobo.

La stratégie de soumission ZKP à deux étapes de Lumoz

Lors de nos discussions précédentes, nous avons plongé dans le cadre de sécurité de Merlin et exploré le concept innovant des ZK-rollups optimistes. Un élément clé de la trajectoire technologique de Merlin est le Prover décentralisé. Ce rôle est essentiel au sein de l'architecture ZK-Rollup, chargé de générer des preuves ZK pour les lots publiés par le Séquenceur. La création de preuves à divulgation nulle est notamment gourmande en ressources, posant un défi considérable.

Une stratégie de base pour accélérer la génération des preuves ZK est de diviser et paralléliser les tâches. Ce processus, connu sous le nom de parallélisation, implique de découper la génération de preuves ZK en parties distinctes. Chaque partie est gérée par un Prover différent, et enfin, un Agrégateur fusionne ces preuves individuelles en un tout unifié. Cette approche permet non seulement d'accélérer le processus, mais également de répartir efficacement la charge de calcul.

Afin d'accélérer le processus de génération de la preuve ZK, Merlin adoptera la solution Prover en tant que service de Lumoz, en fait, il s'agit de rassembler un grand nombre de dispositifs matériels pour former un pool de minage, puis allouer des tâches de calcul à différents dispositifs et allouer des incitations correspondantes, ce qui est quelque peu similaire au minage POW.

Dans cette solution Prover décentralisée, il existe un type de scénario d'attaque, communément appelé une attaque de front-running : Supposons qu'un agrégateur ait établi ZKP, et qu'il envoie ZKP afin d'obtenir des récompenses. Après que d'autres agrégateurs voient le contenu de ZKP, ils publient le même contenu avant lui, affirmant qu'il a généré le ZKP en premier. Comment résoudre cette situation ?

Peut-être la solution la plus instinctive à laquelle tout le monde pense est d'attribuer un numéro de tâche désigné à chaque Agrégateur. Par exemple, seul l'Agrégateur A peut prendre la tâche 1, et les autres ne recevront pas de récompense même s'ils accomplissent la tâche 1. Mais il y a un problème avec cette approche, qui est qu'elle ne peut pas résister aux risques ponctuels. Si l'Agrégateur A rencontre une défaillance de performance ou est déconnecté, la tâche 1 restera bloquée et ne pourra pas être complétée. De plus, cette méthode d'attribution des tâches à une entité unique ne peut pas améliorer l'efficacité de production grâce à un mécanisme d'incitation concurrentielle, et ce n'est pas une bonne approche.

Polygon zkEVM a autrefois proposé une méthode appelée Preuve d'efficacité dans un blog, qui a souligné que des moyens compétitifs devraient être utilisés pour promouvoir la concurrence entre différents agrégateurs, et les incitations devraient être allouées sur la base du premier arrivé, premier servi. L'agrégateur qui soumet la Preuve ZK à la chaîne en premier peut recevoir des récompenses. Bien sûr, il n'a pas mentionné comment résoudre le problème de front-running de la MEV.

Lumoz adopte une méthode de soumission de certificat ZK à vérification en deux étapes. Après qu'un agrégateur ait généré un certificat ZK, il n'a pas besoin d'envoyer le contenu complet en premier lieu, mais publie uniquement le hachage ZKP. En d'autres termes, il publie le hachage (ZKP+Adresse de l'agrégateur). De cette manière, même si d'autres voient la valeur de hachage, ils ne connaissent pas le contenu ZKP correspondant et ne peuvent pas sauter directement en avant;

Si quelqu'un se contente de copier l'intégralité du hachage et de le publier en premier, cela n'a aucun intérêt, car le hachage contient l'adresse d'un agrégateur spécifique X. Même si l'agrégateur A publie le hachage en premier, lorsque l'image originale du hachage est révélée, tout le monde verra également que l'adresse de l'agrégateur contenue en elle est celle de X, pas celle d'A.

Grâce à ce schéma de soumission ZKP à vérification en deux étapes, Merlin (Lumoz) peut résoudre le problème de front-running existant dans le processus de soumission ZKP, ce qui permet d'obtenir des incitations à la génération de preuves de connaissance nulle hautement compétitives, et ainsi d'augmenter la vitesse de génération de ZKP.

Le fantôme de Merlin : Interopérabilité multi-chaînes

Selon la feuille de route technologique de Merlin, ils soutiendront également l'interopérabilité entre Merlin et d'autres chaînes EVM, son parcours de mise en œuvre est essentiellement le même que l'idée précédente de Zetachain. Si Merlin est utilisé comme chaîne source et que d'autres chaînes EVM sont utilisées comme chaîne cible, lorsque le nœud Merlin détecte la demande d'interopérabilité entre chaînes émises par l'utilisateur, il déclenchera des travaux ultérieurs sur la chaîne cible.

Par exemple, un compte EOA contrôlé par le réseau Merlin peut être déployé sur Polygon, Lorsqu'un utilisateur émet une instruction d'interopérabilité inter-chaîne sur la chaîne Merlin, le réseau Merlin analyse d'abord son contenu et génère des données de transaction à exécuter sur la chaîne cible, puis le réseau Oracle effectue un traitement de signature MPC sur la transaction pour générer la signature. Le nœud Relayer de Merlin publie ensuite la transaction sur Polygon, effectue les opérations ultérieures grâce aux actifs de Merlin dans le compte EOA sur la chaîne cible, telles que.

Lorsque l'opération demandée par l'utilisateur est terminée, les actifs correspondants seront directement transférés à l'adresse de l'utilisateur sur la chaîne cible. En théorie, ils peuvent également être directement transférés à la chaîne Merlin. Cette solution présente certains avantages évidents : elle peut éviter les frais de traitement et l'usure causés par les contrats de pont inter-chaînes lors du transfert des actifs traditionnels d'une chaîne à l'autre, et la sécurité des opérations inter-chaînes est directement garantie par le réseau Oracle de Merlin, sans avoir besoin de faire appel à des infrastructures externes. Tant que les utilisateurs font confiance à Merlin Chain, de tels comportements d'interopérabilité inter-chaînes peuvent être considérés comme sans problème.

Résumé

Dans cet article, nous interprétons brièvement la solution technique générale de Merlin Chain, qui, selon nous, permettra à un plus grand nombre de personnes de comprendre le flux de travail général de Merlin et d'avoir une compréhension plus claire de son modèle de sécurité. Étant donné que l'écosystème actuel de Bitcoin est en plein essor, nous pensons que ce type d'activités de vulgarisation technologique est précieux et nécessaire pour le grand public. Nous suivrons de près Merlin, bitLayer, B^Square et d'autres projets à l'avenir, pour une analyse plus approfondie de leurs solutions techniques, alors restez à l'écoute !

Clause de non-responsabilité :

1. Cet article est reproduit à partir de [ geek web3] , le droit d'auteur appartient à l'auteur original [Faust], si vous avez des objections à la réimpression, veuillez contacter Gate Learn ÉquipeL'équipe s'en occupera dès que possible selon les procédures pertinentes.

2. Les points de vue et les opinions exprimés dans cet article ne représentent que les points de vue personnels de l'auteur et ne constituent aucun conseil en investissement.

3. Les autres versions linguistiques de l'article sont traduites par l'équipe Gate Learn. Sans référence Gate.io, copier, distribuer ou plagier les articles traduits est interdit.