Interprétation du schéma technique Merlin : comment fonctionne-t-il exactement ?
TechFlow SélectionTechFlow Sélection
Interprétation du schéma technique Merlin : comment fonctionne-t-il exactement ?
Permettre à davantage de personnes de comprendre le flux de travail général de Merlin et d'avoir une perception plus claire de son modèle de sécurité.
Dédié à des analyses Web3 approfondiesRédaction : Faust, Geeks web3
Depuis l'été des inscriptions en 2023, les couches 2 (Layer2) de Bitcoin restent le cœur battant du monde Web3. Bien que ce domaine ait émergé bien plus tardivement que les Layer2 d'Ethereum, la puissance unique du mécanisme de preuve de travail (POW), combinée au succès du lancement des ETF physiques sur Bitcoin, ont permis à Bitcoin — sans avoir à s'inquiéter du risque de « titrisation » — d'attirer, en seulement six mois, l'attention de capitaux atteignant régulièrement des dizaines de milliards de dollars vers ce segment dérivé qu'est la couche 2.
Dans l'écosystème des Layer2 Bitcoin, Merlin, qui affiche déjà une TVL de plusieurs milliards de dollars, est sans conteste celle qui domine par sa taille et son nombre d'observateurs. Grâce à un système clair d'incitations par mise en jeu (staking) et à des rendements attractifs, Merlin a connu une croissance fulgurante en quelques mois, créant un écosystème encore plus impressionnant que celui de Blast. À mesure que l'intérêt pour Merlin grandit, les discussions autour de ses choix techniques deviennent elles aussi de plus en plus populaires.
Dans cet article, Geeks web3 se concentre sur la solution technique de Merlin Chain, en analysant ses documents publics et sa conception protocolaire. Nous visons à permettre à davantage de personnes de comprendre le fonctionnement général de Merlin, d'avoir une vision plus claire de son modèle de sécurité, et ainsi de saisir intuitivement comment fonctionne cette « première couche 2 de Bitcoin ».
Le réseau d'oracle décentralisé de Merlin : un comité DAC ouvert hors chaîne
Pour toutes les solutions Layer2, qu'il s'agisse d'Ethereum ou de Bitcoin, la disponibilité des données (DA) et le coût de publication des données constituent l'un des principaux défis à résoudre. En raison de nombreuses limitations inhérentes au réseau Bitcoin, notamment son incapacité native à supporter un fort débit de données, l'utilisation optimale de cet espace précieux de DA devient un véritable test d'imagination pour les projets Layer2.
Une conclusion est évidente : si la Layer2 publie « directement » les transactions brutes sur la blockchain Bitcoin, elle ne peut ni atteindre un haut débit, ni maintenir des frais faibles. La solution dominante consiste soit à compresser fortement les données avant de les envoyer sur Bitcoin, soit à publier directement les données hors chaîne.
Parmi les projets adoptant la première approche, Citrea est probablement le plus célèbre. Il prévoit de charger sur la blockchain Bitcoin les variations d'état (state diff) de la Layer2 sur une période donnée — c’est-à-dire les modifications d’état de plusieurs comptes — accompagnées de leur preuve ZK correspondante. Ainsi, n’importe qui peut télécharger depuis la chaîne principale de Bitcoin ces state diffs et les preuves ZKP, et surveiller les changements d’état de Citrea. Cette méthode permet de réduire la taille des données publiées de plus de 90 %.
Bien que cela compresse efficacement les données, le goulot d’étranglement reste évident. Si, sur une courte période, un grand nombre de comptes voient leur état modifié, la Layer2 doit regrouper et publier toutes ces modifications sur Bitcoin, ce qui fait grimper le coût de publication des données, une situation fréquemment observée chez de nombreux ZK Rollup Ethereum.
De nombreuses Layer2 Bitcoin choisissent donc la deuxième voie : utiliser des solutions de DA hors chaîne, soit en construisant leur propre couche DA, soit en utilisant des solutions comme Celestia ou EigenDA. B², BitLayer, ainsi que Merlin, le sujet principal de cet article, adoptent tous cette approche de scalabilité basée sur une DA hors chaîne.
Comme mentionné dans un précédent article de Geeks web3 — « Analyse de la nouvelle feuille de route technique de B² : la nécessité d'une couche DA et d'une couche de validation hors chaîne de Bitcoin » — B² imite directement Celestia en construisant hors chaîne un réseau DA doté d'une fonction d'échantillonnage de données, appelé B² Hub. Les données de transaction ou les state diffs — les « données DA » — sont stockées hors chaîne, tandis que seul le datahash / merkle root est publié sur la chaîne principale de Bitcoin.
Cela revient à utiliser Bitcoin comme un tableau d'affichage de confiance : n'importe qui peut lire le datahash sur la blockchain. Lorsque vous obtenez les données DA auprès d’un fournisseur hors chaîne, vous pouvez vérifier si elles correspondent au datahash présent sur la chaîne, c’est-à-dire : hash(données1) == datahash1 ? Si cette correspondance existe, cela signifie que les données fournies par le nœud hors chaîne sont correctes.
(Schéma de principe d’une Layer2 avec couche DA hors chaîne Bitcoin, source : Geeks web3)
Ce processus garantit que les données fournies par les nœuds hors chaîne sont liées à certaines « empreintes » présentes sur la couche 1, empêchant ainsi une couche DA malveillante de diffuser de fausses données. Toutefois, un scénario critique d'acte malveillant subsiste : que faire si la source des données — le Séquenceur (Sequencer) — n’a tout simplement pas diffusé les données correspondant au datahash, mais n’a publié que le datahash sur la blockchain Bitcoin, en retenant intentionnellement les données afin que personne ne puisse y accéder ?
Des cas similaires incluent notamment : ne publier que la preuve ZK (ZK-Proof) et le StateRoot, sans publier les données DA associées (state diff ou données de transaction). Bien que les utilisateurs puissent valider la preuve ZK et confirmer que le passage du StateRoot précédent au nouveau StateRoot est valide, ils ignorent complètement quels comptes ont vu leur état modifié. Dans ce cas, même si les actifs des utilisateurs sont sécurisés, personne ne peut déterminer l’état réel du réseau, ni savoir quelles transactions ont été incluses ou quels contrats ont été mis à jour. La Layer2 est alors, en pratique, hors service.
Il s'agit précisément du problème dit de « rétention de données » (data withholding). Dankrad, membre de la Fondation Ethereum, avait brièvement abordé ce sujet sur Twitter en août 2023, en se concentrant sur un concept appelé « DAC ».
De nombreuses Layer2 Ethereum utilisant une solution DA hors chaîne désignent généralement quelques nœuds aux droits spéciaux, formant un comité appelé Data Availability Committee (DAC). Ce comité agit comme garant, affirmant publiquement que le Séquenceur a effectivement publié intégralement les données DA (données de transaction ou state diff) hors chaîne. Les nœuds du DAC génèrent ensuite collectivement une signature multisignature ; dès que le seuil requis est atteint (par exemple 2 sur 4), le contrat sur la couche 1 considère que le Séquenceur a passé avec succès la vérification du comité DAC et a bien publié les données DA complètes hors chaîne.
Les comités DAC des Layer2 Ethereum suivent presque tous un modèle POA (Proof of Authority), limitant strictement l'accès aux membres KYC ou désignés officiellement. Cela fait du DAC un symbole de centralisation et de blockchain privée. Pire encore, dans certains cas, le Séquenceur envoie les données DA uniquement aux nœuds du comité DAC, sans diffusion ailleurs. Pour obtenir les données DA, toute personne doit obtenir l'autorisation du comité DAC, ce qui ne diffère guère d'une blockchain de consortium.
Sans aucun doute, le DAC doit être décentralisé. Une Layer2 peut choisir de ne pas publier directement les données DA sur la couche 1, mais l’accès au comité DAC doit être ouvert, afin d’éviter que quelques acteurs puissent conspirer pour commettre des actes malveillants. (Pour une analyse détaillée des scénarios de tricherie possibles avec un DAC, voir les tweets antérieurs de Dankrad.)
BlobStream, proposé par Celestia, remplace en réalité le DAC centralisé par Celestia elle-même : le Séquenceur de la Layer2 Ethereum peut publier les données DA sur la chaîne Celestia. Si 2/3 des nœuds Celestia signent ces données, le contrat dédié déployé sur Ethereum considère que le Séquenceur a bien publié les données DA. Ici, les nœuds Celestia jouent le rôle de garants. Étant donné que Celestia compte des centaines de validateurs, on peut considérer que ce « grand DAC » est relativement décentralisé.
La solution DA adoptée par Merlin est proche de BlobStream de Celestia : les deux ouvrent l’accès au DAC via un modèle POS, tendant ainsi vers une meilleure décentralisation. Toute personne pouvant mettre en jeu suffisamment d’actifs peut exécuter un nœud DAC. Dans les documents de Merlin, ces nœuds DAC sont appelés « Oracles », et il est indiqué que le système acceptera des mises en jeu en BTC, MERL, voire en jetons BRC-20, offrant un mécanisme de staking flexible, incluant également un staking par délégation similaire à Lido. (Le protocole de staking POS des oracles constitue l’un des récits clés futurs de Merlin, avec des taux d’intérêt élevés proposés.)
Voici un résumé du fonctionnement de Merlin (schéma ci-dessous) :
- Le Séquenceur (Sequencer), après avoir reçu de nombreuses demandes de transaction, les agrège en un lot de données (data batch) et les transmet aux nœuds Prover ainsi qu’aux nœuds Oracle (DAC décentralisé).
- Les nœuds Prover de Merlin sont décentralisés et utilisent le service « Prover as a Service » de Lumoz. Le pool de Prover, après avoir reçu plusieurs lots de données, génère les preuves de connaissance nulle (ZKP) correspondantes, puis envoie ces ZKP aux nœuds Oracle pour vérification.
- Les nœuds Oracle vérifient si les preuves ZK envoyées par le pool Lumoz correspondent bien au data batch envoyé par le Séquenceur. Si la correspondance est confirmée et qu’aucune erreur n’est détectée, la vérification est validée. Pendant ce processus, les nœuds Oracle décentralisés utilisent une signature seuil pour générer une signature multisignature, attestant publiquement que le Séquenceur a bien publié l’ensemble des données DA, et que les ZKP correspondants sont valides et ont passé la vérification des oracles.
- Le Séquenceur récupère les résultats de signature multisignature auprès des nœuds Oracle. Une fois le seuil de signatures atteint, il envoie ces informations sur la chaîne Bitcoin, accompagnées du datahash des données DA (data batch), permettant à l’extérieur de les lire et de les confirmer.
(Schéma de fonctionnement de Merlin, source : Geeks web3)
- Les nœuds Oracle appliquent un traitement particulier au processus de vérification des preuves ZK, générant un engagement (Commitment) qu’ils publient sur la blockchain Bitcoin, permettant à quiconque de contester cet engagement. Ce processus suit essentiellement le même protocole que les preuves de fraude de bitVM. En cas de contestation réussie, le nœud Oracle ayant publié l’engagement subit une sanction économique. Par ailleurs, les données que les Oracles publient sur Bitcoin incluent également le hash de l’état actuel de la Layer2 (StateRoot) et la preuve ZKP elle-même, accessibles à l’extérieur pour vérification.
Référence : « Explication simplifiée de BitVM : comment valider une preuve de fraude sur la chaîne BTC »
Quelques détails supplémentaires doivent être clarifiés. Merlin prévoit dans sa feuille de route de sauvegarder les données DA sur Celestia via les nœuds Oracle. Cela permettrait aux nœuds Oracle de purger périodiquement leurs données historiques locales sans besoin de stockage permanent. De plus, l’engagement (Commitment) généré par le réseau Oracle est en réalité la racine d’un arbre de Merkle. Rendre publique uniquement cette racine ne suffit pas : il faut divulguer l’intégralité du jeu de données correspondant. Pour cela, une plateforme tierce de DA est nécessaire — Celestia, EigenDA, ou toute autre couche DA.
Analyse du modèle de sécurité : un ZK-Rollup optimiste + service MPC de Cobo
Nous avons décrit précédemment le fonctionnement de Merlin. Vous devriez maintenant avoir une bonne compréhension de sa structure de base. On constate clairement que Merlin, tout comme B², BitLayer et Citrea, suit un modèle de sécurité commun : le ZK-Rollup optimiste.
À première lecture, ce terme peut sembler étrange aux amateurs d’Ethereum. Qu’est-ce qu’un « ZK-Rollup optimiste » ? Dans la communauté Ethereum, le modèle théorique du ZK Rollup repose entièrement sur la fiabilité des calculs cryptographiques, sans hypothèse de confiance. Or, le terme « optimiste » introduit justement une telle hypothèse : cela signifie que, dans la plupart des cas, on suppose « de façon optimiste » que le Rollup fonctionne correctement. S’il y a une erreur, on peut alors la contester via une preuve de fraude, d’où le nom « Optimistic Rollup » (ou OP Rollup).
Pour l’écosystème Ethereum, berceau des Rollups, un « ZK-Rollup optimiste » peut sembler contradictoire. Mais cela correspond parfaitement à la réalité des Layer2 Bitcoin. En raison de contraintes techniques, la blockchain Bitcoin ne peut pas valider intégralement une preuve ZK. Elle ne peut que vérifier certains pas du calcul dans des cas particuliers. Dans ce contexte, la chaîne Bitcoin ne supporte en pratique que les protocoles de preuve de fraude : on peut pointer une erreur dans une étape du calcul de la preuve ZK lors de la vérification hors chaîne, et la contester. Bien que cela ne soit pas aussi robuste qu’un ZK Rollup type Ethereum, c’est actuellement le modèle de sécurité le plus fiable et le plus solide que les Layer2 Bitcoin puissent atteindre.
Dans ce cadre de ZK-Rollup optimiste, supposons qu’il existe N entités habilitées à lancer une contestation. Tant que l’une de ces N entités est honnête et capable de détecter une erreur et de lancer une preuve de fraude, la transition d’état de la Layer2 reste sécurisée. Naturellement, un Optimistic Rollup mature doit aussi protéger son pont de retrait par un protocole de preuve de fraude. Or, actuellement, presque aucune Layer2 Bitcoin ne parvient à remplir cette condition et doit encore s’appuyer sur des systèmes multisignatures/MPC. Le choix du schéma multisig/MPC devient donc crucial pour la sécurité globale de la Layer2.
Merlin a choisi le service MPC de Cobo pour son pont. En mettant en œuvre des mesures telles que la séparation portefeuille chaud/portefeuille froid, les actifs du pont sont gérés conjointement par Cobo et Merlin Chain. Toute opération de retrait nécessite la participation conjointe des parties MPC de Cobo et de Merlin Chain. En somme, la fiabilité du pont repose ici sur la caution institutionnelle. Ce n’est toutefois qu’une solution temporaire. À mesure que le projet mûrira, le pont de retrait pourrait être remplacé par un « pont optimiste » reposant sur BitVM et les preuves de fraude, assurant ainsi une hypothèse de confiance 1/N. Toutefois, la mise en œuvre serait nettement plus complexe (la quasi-totalité des ponts officiels des Layer2 reposent aujourd’hui sur des multisigs).
Globalement, on peut résumer ainsi : Merlin intègre un DAC basé sur POS, un ZK-Rollup optimiste fondé sur BitVM, et une solution de custody d’actifs MPC fournie par Cobo. Il résout le problème de disponibilité des données (DA) en ouvrant l’accès au DAC ; assure la sécurité des transitions d’état via BitVM et les preuves de fraude ; et garantit la fiabilité du pont de retrait grâce au service MPC d’un acteur reconnu comme Cobo.
Un schéma de soumission ZKP en deux étapes basé sur Lumoz
Nous avons précédemment examiné le modèle de sécurité de Merlin et présenté le concept de ZK-Rollup optimiste. Dans sa feuille de route technique, Merlin mentionne également la décentralisation du Prover. Comme chacun le sait, le Prover est un rôle central dans l’architecture ZK-Rollup : il génère la preuve ZK (ZKProof) pour chaque lot publié par le Séquenceur. Or, la génération de preuves de connaissance nulle est extrêmement gourmande en ressources matérielles, ce qui pose un problème majeur.
Pour accélérer la génération des preuves ZK, découper la tâche en sous-tâches parallèles est une opération fondamentale. La parallélisation consiste à diviser la tâche de génération de preuve en plusieurs parties distinctes, assignées à différents Provers, puis à agréger les différentes preuves partielles en une preuve finale via un agrégateur (Aggregator).
Pour accélérer ce processus, Merlin adoptera la solution « Prover as a Service » de Lumoz, qui consiste à regrouper de nombreux équipements matériels en un pool minier, puis à distribuer les tâches de calcul entre différents dispositifs, accompagnées d’incitations appropriées — un modèle proche du minage POW.
Dans ce schéma de Prover décentralisé, un scénario d’attaque apparaît : l’attaque de frontrunning. Imaginons qu’un agrégateur (Aggregator) ait terminé la construction d’une preuve ZKP et s’apprête à la publier pour recevoir sa récompense. Un autre agrégateur intercepte cette preuve, la publie avant lui en prétendant l’avoir générée en premier. Comment éviter cela ?
Une solution intuitive serait d’attribuer des numéros de tâche uniques à chaque Aggregator. Par exemple, seule l’entité Aggregator A peut traiter la tâche 1. Même si d’autres la complètent, ils ne reçoivent aucune récompense. Mais cette méthode présente un inconvénient majeur : elle ne résiste pas aux pannes ponctuelles. Si Aggregator A tombe en panne ou se déconnecte, la tâche 1 reste bloquée. De plus, attribuer une tâche à une seule entité ne favorise pas une concurrence dynamique pour améliorer l’efficacité — ce n’est pas une bonne stratégie.
Polygon zkEVM a proposé dans un blog post une méthode appelée « Proof of Efficiency », suggérant d’instaurer une compétition entre agrégateurs, où la récompense va au plus rapide. Le premier à soumettre la preuve ZK sur chaîne reçoit la prime. Toutefois, ce modèle ne traite pas explicitement le problème du MEV lié au frontrunning.
Lumoz adopte une méthode en deux étapes pour la soumission de la preuve ZK. Après avoir généré la preuve, l’agrégateur ne publie pas immédiatement son contenu complet, mais seulement le hash de la preuve, c’est-à-dire hash(ZKP + adresse de l’Aggregator). Ainsi, même si d'autres voient ce hash, ils ignorent le contenu réel de la preuve et ne peuvent pas la copier directement.
Et si quelqu’un tentait de copier le hash et de le publier en premier ? Cela serait inutile, car le hash contient l’adresse de l’agrégateur X. Même si l’agrégateur A publie ce hash en premier, lorsque l’image originale sera révélée, on verra clairement que l’adresse contenue est celle de X, et non de A.
Grâce à ce mécanisme de soumission ZKP en deux étapes, Merlin (via Lumoz) résout efficacement le problème de frontrunning, instaurant ainsi un environnement hautement concurrentiel pour la génération de preuves ZK, ce qui augmente significativement la vitesse de production des preuves.
Merlin's Phantom : l'interopérabilité multi-chaînes
Selon la feuille de route technique de Merlin, il prévoit également de prendre en charge l’interopérabilité entre Merlin et d’autres chaînes EVM. Son approche est similaire à celle de Zetachain. Si l’on prend Merlin comme chaîne source et une autre chaîne EVM comme chaîne cible, lorsque les nœuds Merlin détectent une demande d’opération inter-chaînes de la part d’un utilisateur, ils déclenchent automatiquement le flux de travail sur la chaîne cible.
Par exemple, on pourrait déployer sur Polygon un compte EOA contrôlé par le réseau Merlin. Lorsqu’un utilisateur lance une instruction d’inter-opérabilité sur Merlin Chain, le réseau Merlin analyse d’abord la commande, génère les données de transaction à exécuter sur la chaîne cible, puis le réseau Oracle applique une signature MPC à cette transaction. Ensuite, le nœud Relayer de Merlin publie cette transaction sur Polygon, et utilise les actifs présents dans le compte EOA de Merlin sur la chaîne cible pour exécuter les opérations suivantes.
Une fois l’opération terminée, les actifs concernés sont transférés directement à l’adresse de l’utilisateur sur la chaîne cible. Théoriquement, ils pourraient aussi revenir directement vers Merlin Chain. Cette solution présente plusieurs avantages : elle évite les frais de friction typiques des ponts de cross-chain traditionnels, et la sécurité des opérations inter-chaînes est directement assurée par le réseau Oracle de Merlin, sans dépendre d’infrastructures externes. Tant que l’utilisateur fait confiance à Merlin Chain, il peut considérer que ces opérations inter-chaînes sont sûres.
Conclusion
Dans cet article, nous avons présenté une analyse concise de la solution technique de Merlin Chain, espérant aider davantage de lecteurs à comprendre son fonctionnement global et à mieux appréhender son modèle de sécurité. Étant donné l’effervescence actuelle de l’écosystème Bitcoin, nous pensons que ce type de vulgarisation technique est utile et largement attendu. Nous continuerons à suivre de près Merlin, ainsi que BitLayer, B² et d'autres projets, en approfondissant régulièrement l’analyse de leurs architectures techniques. 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
