De l’été des inscriptions en 2023 à aujourd’hui, Bitcoin Layer 2 a toujours été le point culminant de tout le Web3. Bien que la hausse de ce domaine soit beaucoup plus tardive que celle de Layer 2 en Ethereum, avec le charme unique de POW et l’atterrissage en douceur de Spot ETF, le Bitcoin sans tenir compte du risque de « titrisation » a attiré l’attention de dizaines de milliards de dollars de capitaux pour la piste dérivée de Layer 2 en seulement six mois.
Dans la Bitcoin Layer 2 piste, Merlin, qui a des milliards de dollars en TVL, est sans aucun doute celui qui compte le plus de volume et le plus long d’adeptes. Avec des incitations claires au staking et un rendement décent, Merlin a vu le jour presque en quelques mois, créant un mythe écologique qui transcende Blast. Avec la popularité croissante de Merlin, la discussion de ses solutions techniques est devenue un sujet de plus en plus long.
Dans cet article, Geek Web3 se concentrera sur les solutions techniques de Merlin Chain, interprétera ses documents publiés et protocole idées de conception, et nous nous engageons à permettre à un plus grand nombre de personnes long 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é, afin que tout le monde puisse comprendre le fonctionnement de ce « Bitcoin Layer 2 de tête » de manière plus intuitive.
Le réseau oracle décentralisé de Merlin : un conseil DAC off-chain ouvert
Pour tous les Layer 2, qu’il s’agisse de Ethereum Layer 2 ou de Bitcoin Layer 2, les coûts de DA et de publication des données sont l’un des problèmes les plus importants à résoudre. En raison des problèmes les plus longs du réseau Bitcoin lui-même, qui ne support pas intrinsèquement un grand débit de données, la façon d’utiliser ce court DA est devenue un problème difficile pour tester l’imagination de Layer 2 projets.
Une conclusion s’impose : si Layer 2 publie « directement » des données de transaction non traitées sur le Bitcoin Bloc, il ne sera pas en mesure d’atteindre un débit élevé ou des frais peu élevés. La solution la plus populaire consiste soit à compresser la taille des données aussi petite que possible grâce à une compression élevée et à les télécharger sur le Bitcoin Bloc, soit à publier les données directement sur le Bitcoin off-chain. **
La plus connue des couches de Layer 2 qui adoptent la première approche est probablement Citrea, qui a l’intention de télécharger le différentiel d’état de Layer 2 sur une période de temps, c’est-à-dire les résultats du changement d’état sur long compte, ainsi que les preuves ZK correspondantes, sur le Bitcoin off-chain. Dans ce cas, n’importe qui peut télécharger le diff d’état et le ZKP à partir du Bitcoin Mainnet pour surveiller les résultats du changement d’état de Citrea. Cette méthode permet de réduire de plus de 90 % la taille des données sur la chaîne.
Bien que cela puisse réduire considérablement la taille des données, le goulot d’étranglement reste important. Si un grand nombre de changements d’état de compte se produisent au cours d’une période de temps short, Layer 2 doit résumer et télécharger toutes les modifications de ces compte dans le Bitcoin off-chain, et le coût final de publication des données ne peut pas être maintenu à un niveau très bas, ce qui peut être vu dans le tout long Ethereum ZK Rollup.
Il est très long Bitcoin Layer 2 d’emprunter simplement la deuxième voie : utiliser directement la solution DA Bitcoin off-chain, soit construire une couche DA par elle-même, soit utiliser Celestia, EigenDA, etc. B^Square, BitLayer et Merlin, le protagoniste de cet article, suivent tous ce schéma de mise à l’échelle DA off-chain.
Dans l’article précédent de Geek web3 - « Analyse de la nouvelle version de la feuille de route de la technologie B^2 : la nécessité de Bitcoin off-chain DA et de la couche de vérification », nous avons mentionné que **B^2 imite directement Celestia et construit un réseau DA qui prend en charge la fonction d’échantillonnage de données dans le off-chain, nommé B^2 Hub. Les « données DA » telles que les données de transaction ou les différences d’état sont stockées dans le Bitcoin off-chain, et seule la racine datahash/merkle est téléchargée sur le Bitcoin Mainnet. **
Il traite vraiment Bitcoin comme un tableau d’affichage Trustless : n’importe qui peut lire le datahash à partir de Bitcoin off-chain. Lorsque vous obtenez des données DA du fournisseur de données off-chain, vous pouvez vérifier si elles correspondent au datahash off-chain, c’est-à-dire hash(data1) == datahash1 ?. S’il y a une correspondance entre les deux, cela signifie que le fournisseur de données sous la off-chain vous a donné les bonnes données.
Le processus ci-dessus permet de s’assurer que les données qui vous sont fournies par off-chain Nœud sont associées à certains « indices » sur la couche 1, empêchant ainsi la couche DA de fournir de manière malveillante de fausses données. Mais il y a un scénario d’épingle très important ici : que se passe-t-il si la source des données, Sequencer, n’envoie pas du tout les données correspondantes du datahash, mais envoie uniquement le datahash au Bitcoin off-chain, mais cache délibérément les données correspondantes à quiconque peut les lire ?
Des scénarios similaires incluent, mais ne sont pas limités à, la publication uniquement de ZK-Proof et StateRoot, mais pas la publication des données DA correspondantes (différence d’état ou données de transaction), bien que les utilisateurs puissent vérifier que le processus de calcul ZKProof est valide et s’assurer que le processus de calcul de Prev_Stateroot à New_Stateroot est valide, mais ils ne savent pas quel état compte (état) a changé. Dans ce cas, bien que les actifs de l’utilisateur soient en sécurité, vous ne pouvez pas du tout déterminer l’état réel du réseau, et vous ne savez pas quelles transactions ont été empaquetées sur la chaîne et quels contrats ont été mis à jour.
Il s’agit en fait de "rétention de données », et Dankrad de la Fondation Ethereum a brièvement discuté d’un problème similaire sur Twitter en août 2023, bien sûr, il est principalement bougie à longue mèche pour quelque chose appelé « DAC ».
Longest Ethereum Layer2, qui adopte des solutions DA off-chain, met souvent en place plusieurs nœuds avec des autorisations spéciales pour former un comité, le nom complet de Comité de disponibilité des données (DAC). Ce comité DAC agit en tant que garant, affirmant que Sequencer publie les données DA complètes (données de transaction ou différence d’état) off-chain. Ensuite, le nœud DAC génère collectivement un plus long, aussi long que le plus long répond aux exigences de seuil (par exemple 2/4), le contrat concerné sur la couche 1 sera par défaut et Sequencer a passé l’inspection du comité DAC et a honnêtement publié les données DA complètes off-chain.
Le comité de Ethereum Layer 2 du DAC suit essentiellement le modèle du POA, n’autorisant que quelques nœuds KYC ou officiellement désignés à rejoindre le comité du DAC, ce qui fait du DAC un synonyme de « blockchain centralisée » et de « blockchain de consortium ». De plus, dans certains Ethereum Layer 2 qui adoptent le modèle DAC, le séquenceur n’envoie des données DA qu’aux nœuds membres du DAC, et ne télécharge presque jamais de données ailleurs, et quiconque souhaite obtenir des données DA doit obtenir l’autorisation du comité DAC, ce qui n’est pas fondamentalement différent du Consortium Blockchain.
Il ne fait aucun doute que le DAC devrait être Décentralisation, et Layer 2 ne pouvez pas télécharger les données du DA directement sur la couche 1, mais l’autorité d’accès du comité du DAC devrait être ouverte au monde extérieur pour empêcher quelques personnes de s’entendre pour faire le mal. (Pour une discussion sur le scénario des méfaits de la DAC, veuillez vous référer à la déclaration précédente de Dankrad sur Twitter)
**BlobStream, précédemment proposé par Celestia, consiste essentiellement à remplacer le DAC centralisé par Celestia, ** Le séquenceur Ethereum L2 peut publier des données DA sur le Celestia on-chain, si les 2/3 du nœud Celestia le signent, le contrat d’exclusivité Layer2 déployé sur Ethereum estime que le séquenceur libère honnêtement les données DA, ce qui est en fait de laisser le nœud Celestia agir en tant que garant. Si l’on considère que Celestia dispose de centaines de nœuds de validation, on peut considérer que ce grand DAC est relativement décentralisé.
**La solution DA utilisée par Merlin est en fait proche du BlobStream de Celestia, qui ouvre les droits d’accès au DAC sous forme de POS pour le faire tendre vers la décentralisation. N’importe qui peut exécuter un nœud DAC aussi long qu’il stake suffisamment d’actifs. Dans la documentation de Merlin, le nœud DAC ci-dessus est appelé Oracle, et il est souligné que le jalonnement d’actifs de BTC, MERL et même BRC-20 Tokens sera pris en charge, permettant un mécanisme de jalonnement flexible, ainsi que le jalonnement par proxy similaire à Lido. (Le POS stake protocole de Oracle Machine est essentiellement l’un des prochains récits de base de Merlin, et les stake Taux d'intérêt fournis sont relativement élevés)
Voici une brève description du flux de travail de Merlin (image ci-dessous):
Après avoir reçu un grand nombre de demandes de transaction, le séquenceur les agrège et génère un lot de données, qui est transmis au nœud Prover et au nœud Oracle (DAC de décentralisation).
Le nœud Prover de Merlin est la décentralisation, en utilisant le service Prover as a Service de lumoz. Après avoir reçu les lots de données les plus longs, le pool d’exploration de données Prover génère les zk-SNARKs correspondants, après quoi le ZKP est envoyé au nœud Oracle pour vérification.
Le Nœud Oracle vérifiera si la preuve ZK envoyée par le pool de minage ZK de Lmuoz correspond au lot de données envoyé par Sequencer. Si les deux peuvent correspondre et qu’il n’y a pas d’autres erreurs, c’est vérifié. Dans ce processus, les nœuds Oracle de décentralisation généreront des signatures plus longues via des signatures de seuil et déclareront en externe - le séquenceur a complètement émis des données DA et le ZKP correspondant est valide, qui a passé la vérification du nœud Oracle.
Le séquenceur collecte long résultats de signature à partir du Nœud Oracle, et lorsque le nombre de signatures répond aux exigences de seuil, il envoie les informations de signature au Bitcoin off-chain, avec un hachage de données DA par lot, et les transmet au monde extérieur pour qu’il les lise et les confirme.
Oracle Nœud traitement spécial de son processus de calcul pour vérifier ZK Proof, générer un engagement d’engagement, l’envoyer au Bitcoin off-chain et permettre à quiconque de contester l'« engagement », et le processus de ce processus est fondamentalement le même que le fraud proof protocole de bitVM. Si la contestation est couronnée de succès, le Nœud Oracle qui publie l’Engagement sera pénalisé financièrement. Bien entendu, les données qu’Oracle souhaite publier sur le Bitcoin off-chain, y compris le hash de l’état actuel du Layer 2 - StateRoot, et le ZKP lui-même, doivent être publiées sur le Bitcoin off-chain pour que le monde extérieur puisse les détecter.
Il y a encore quelques détails qui doivent être élaborés, tout d’abord, la feuille de route de Merlin mentionne qu’à l’avenir, Oracle sauvegardera les données DA à Celestia, afin qu’Oracle Nœud puisse éliminer correctement les données historiques locales et n’ait pas besoin de conserver les données localement pour toujours. Dans le même temps, l’engagement généré par Oracle Network est en fait la racine d’un arbre de Merkle, et il ne suffit pas de divulguer la racine au monde extérieur, mais pour divulguer tous les ensembles de données complets correspondant à l’engagement, il est nécessaire de trouver une plate-forme DA tierce, qui peut être Celestia, EigenDA ou d’autres couches DA.
Analyse du modèle de sécurité : le service MPC optimiste de ZKRollup+Cobo
Ci-dessus, nous avons brièvement décrit le flux de travail de Merlin, et je pense que vous avez déjà une bonne compréhension de sa structure de base. Il n’est pas difficile de voir que Merlin suit fondamentalement le même modèle de sécurité que B^Square, BitLayer et Citrea - l’optimiste ZK-Rollup.
La première lecture de ce mot peut faire se sentir bizarre de nombreux amateurs de long Ethereum, qu’est-ce que le « ZK-Rollup optimiste » ? Dans la cognition de la communauté Ethereum, le « modèle théorique » de ZK Rollup est entièrement basé sur la fiabilité des calculs de Cryptographie, et il n’est pas nécessaire d’introduire des hypothèses de confiance, et le mot optimisme introduit précisément des hypothèses de confiance, ce qui signifie que les gens devraient être optimistes sur le fait que les Rollups ne sont pas faux et fiables lorsqu’ils long un grand nombre de fois. Et une fois qu’il y a une erreur, l’opérateur Rollup peut être puni par fraud proof, qui est à l’origine du nom Optimistic Rollup, également connu sous le nom OP Rollup.
Pour l’écosystème Ethereum de la base de Rollup, l’optimisme ZK-Rollup est peut-être un peu inhabituel, mais cela correspond exactement à la situation actuelle de Bitcoin Layer 2. En raison de limitations techniques, Bitcoin off-chain ne pouvez pas vérifier entièrement ZK Proof, ne pouvez vérifier qu’une certaine étape du processus de calcul ZKP dans des circonstances particulières, dans cette prémisse, Bitcoin off-chain ne pouvez en fait que support fraud proof protocole, les gens peuvent souligner que ZKP dans le processus de vérification off-chain, une certaine étape de calcul a une erreur, et par le biais de la fraud proof manière de contester, bien sûr, cela ne peut pas être comparé au Ethereum ZK Rollup de style, mais c’est Bitcoin déjà le plus fiable et le plus fiable et le plus Le modèle de sécurité le plus robuste.
Dans le cadre du schéma optimiste ZK-Rollup ci-dessus, en supposant qu’il y ait N challengers autorisés dans le réseau de Layer 2, aussi long que 1 de ces N challengers est honnête et fiable, et peut détecter les erreurs et initier la fraud proof à tout moment, la transition d’état de Layer 2 est sûre. Bien sûr, les rollups optimistes avec un degré d’achèvement relativement élevé doivent s’assurer que leurs ponts de retrait sont également protégés par des fraud proof protocole, et à l’heure actuelle, presque tous les Bitcoin Layer 2 ne peuvent pas atteindre cette prémisse et doivent s’appuyer sur long signature/MPC, de sorte que le choix de la solution long signature/MPC est devenu un problème étroitement lié à la sécurité de Layer 2.
Merlin a choisi le service MPC de Cobo sur le système de bridge, en utilisant des mesures telles que l’isolation des portefeuilles froids et chauds, les actifs des ponts sont gérés conjointement par Cobo et Merlin Chain, et tout retrait doit être géré conjointement par les participants MPC de Cobo et Merlin Chain, garantissant essentiellement la fiabilité du bridge de retrait grâce à l’endossement de crédit de l’institution. Bien sûr, il ne s’agit que d’une mesure provisoire à ce stade, et avec l’amélioration progressive du projet, le bridge de retrait peut être remplacé par le « bridge optimiste » de l’hypothèse de confiance 1/N en introduisant BitVM et fraud proof protocole, mais il sera plus difficile d’atterrir (à l’heure actuelle, presque tous les ponts officiels de couche 2 reposent sur long signe).
Dans l’ensemble, nous pouvons déterminer que Merlin a introduit un DAC basé sur POS, un ZK-Rollup optimiste basé sur BitVM et une solution de conservation d’actifs MPC basée sur Cobo, a résolu le problème DA en ouvrant les autorisations DAC, a assuré la sécurité de la transition d’état en introduisant BitVM et fraud proof protocole, et a assuré la fiabilité du bridge de retrait en introduisant le service MPC de la célèbre plate-forme de conservation d’actifs Cobo.
Schéma de soumission ZKP de vérification en deux étapes basé sur Lumoz
Plus tôt, nous avons passé au peigne fin le modèle de sécurité de Merlin et introduit le concept de ZK-rollup optimiste. Dans la feuille de route technologique de Merlin, Decentralisation Prover est également discuté. Comme nous le savons tous, Prover est un rôle central dans l’architecture ZK-Rollup, qui est responsable de la génération de ZKProofs pour les lots publiés par Sequencer, et le processus de génération de zk-SNARKs est très gourmand en ressources matérielles et un problème très délicat.
Pour accélérer la génération des preuves ZK, la parallélisation de la tâche est l’une des opérations les plus élémentaires. **La soi-disant parallélisation consiste en fait à diviser la tâche de génération de preuve ZK en différentes parties, qui sont complétées séparément par différents prouveurs, et enfin l’agrégateur d’agrégateurs agrège la preuve la plus longue en un tout.
Dans le ordre d’accélérer le processus de génération de preuves ZK, Merlin utilisera la solution Prover as a service de Lumoz, qui consiste en fait à rassembler un grand nombre de périphériques matériels pour former un pool de minage, puis à attribuer des tâches informatiques à différents appareils et à attribuer des incitations correspondantes, similaires au minage POW.
Dans ce schéma de décentralisation Prover, il existe une classe de scénarios d’attaque, communément appelés attaques front-running : Supposons qu’un agrégateur Aggregator ait formé un ZKP et qu’il envoie le ZKP dans l’espoir de recevoir une récompense. Après que d’autres agrégateurs aient vu le contenu de ZKP, ils se sont précipités pour poster le même contenu devant lui, affirmant que ce ZKP avait été créé par leur propre mari, comment résoudre cette situation ?
L’une des solutions les plus instinctives qui peuvent venir à l’esprit est d’attribuer un numéro de tâche spécifique à chaque agrégateur, par exemple, seul l’agrégateur A peut prendre la tâche 1, et tous les autres n’obtiendront pas de récompense même s’ils terminent la tâche 1. Mais l’un des problèmes de cette approche est qu’elle ne protège pas contre un seul point de risque. Si l’agrégateur A subit une défaillance des performances ou se déconnecte, la tâche 1 est bloquée et ne peut pas se terminer. De plus, cette pratique consistant à attribuer des tâches à une seule entité n’est pas un bon moyen d’améliorer la productivité avec des incitations concurrentielles.
Polygon zkEVM a proposé une méthode appelée Preuve d’efficacité dans un article de blog, qui stipule que différents agrégateurs devraient être promus pour rivaliser les uns avec les autres de manière compétitive, et que les incitations devraient être distribuées sur la base du premier arrivé, premier servi, et que les premiers agrégateurs à soumettre ZK-Proof à la chaîne peuvent recevoir des récompenses. Bien sûr, il n’a pas mentionné comment résoudre le problème de la course frontale MEV.
Lumoz utilise une méthode de soumission de preuve ZK de vérification en deux étapes, après qu’un agrégateur ait généré une preuve ZK, il n’a pas besoin d’envoyer le contenu complet, mais publie uniquement le hash de ZKP, en d’autres termes, publie le hash (ZKP + adresse d’agrégation). De cette façon, même si d’autres personnes voient la valeur hash, elles ne connaissent pas le contenu ZKP correspondant et ne peuvent pas le précipiter directement ;
Si quelqu’un copie simplement le hash entier et le publie en premier, cela n’a aucun sens, car le hash contient l’adresse d’un agrégateur X spécifique, et même si l’agrégateur A publie le hash en premier, lorsque l’image originale du hash est révélée, tout le monde verra que l’adresse de l’agrégateur qu’il contient est X, pas A.
Grâce à ce système de soumission ZKP de vérification en deux étapes, Merlin (Lumoz) peut résoudre le problème de démarrage dans le processus de soumission ZKP, puis réaliser des incitations à la génération zk-SNARKs hautement compétitives, améliorant ainsi la vitesse de génération de ZKP.
Merlin’s Phantom : la plus longue interopérabilité des chaînes
Selon la feuille de route technique de Merlin, ils support également l’interopérabilité entre Merlin et d’autres chaînes EVM, et son chemin de mise en œuvre est fondamentalement le même que l’idée précédente de Zetachain, si Merlin est utilisé comme chaîne source et d’autres chaînes EVM sont utilisées comme chaîne cible, lorsque le nœud Merlin perçoit la demande d’interopérabilité cross-chain faite par l’utilisateur, il déclenchera le flux de travail suivant sur la cible on-chain.
Par exemple, un compte EOA contrôlé par le réseau Merlin peut être déployé sur Polygon, ** Lorsqu’un utilisateur publie une instruction d’interopérabilité cross-chain sur Merlin Chain, le réseau Merlin analyse d’abord son contenu et génère une donnée de transaction exécutée sur la cible on-chain, puis le traitement de signature Oracle Network MPC sur la transaction génère une signature numérique de la transaction. Le nœud de relais de Merlin libère ensuite la transaction ** sur Polygon, complétant les opérations ultérieures via les actifs de Merlin dans le compte EOA sur la cible on-chain.
Lorsque l’opération requise par l’utilisateur est terminée, l’actif correspondant sera transféré directement à l’adresse de l’utilisateur sur la cible off-chain, et théoriquement peut également traverser directement dans la chaîne Merlin. Cette solution présente des avantages évidents : elle peut éviter l’usure des frais générés par les contrats traditionnels de cross-chain et de bridges cross-chain, et elle est directement garantie par Oracle Network de Merlin pour assurer la sécurité des opérations cross-chain, et il n’est pas nécessaire de s’appuyer plus longtemps sur une infrastructure externe. Aussi longues que les utilisateurs fassent confiance à Merlin Chain, il n’y a aucun problème à utiliser par défaut une telle interopérabilité cross-chain.
Résumé
Dans cet article, nous donnons une brève explication de la solution technique générale de Merlin Chain, qui est censée aider plus de personnes longues à comprendre le flux de travail général de Merlin et à avoir une compréhension plus claire de son modèle de sécurité. Compte tenu de l’écologie actuelle de Bitcoin en plein essor, nous pensons que ce type de comportement de vulgarisation scientifique technique est précieux et nécessaire pour le grand public, ** Nous effectuerons un suivi à long terme sur Merlin et bitLayer, B ^ Square et d’autres projets à l’avenir **, et effectuerons une analyse plus approfondie de ses solutions techniques, alors restez à l’écoute !
Voir l'original
Cette page peut inclure du contenu de tiers fourni à des fins d'information uniquement. Gate ne garantit ni l'exactitude ni la validité de ces contenus, n’endosse pas les opinions exprimées, et ne fournit aucun conseil financier ou professionnel à travers ces informations. Voir la section Avertissement pour plus de détails.
Interprétation technique du mécanisme de fonctionnement de Merlin
Auteur : Faust, geek web3
De l’été des inscriptions en 2023 à aujourd’hui, Bitcoin Layer 2 a toujours été le point culminant de tout le Web3. Bien que la hausse de ce domaine soit beaucoup plus tardive que celle de Layer 2 en Ethereum, avec le charme unique de POW et l’atterrissage en douceur de Spot ETF, le Bitcoin sans tenir compte du risque de « titrisation » a attiré l’attention de dizaines de milliards de dollars de capitaux pour la piste dérivée de Layer 2 en seulement six mois.
Dans la Bitcoin Layer 2 piste, Merlin, qui a des milliards de dollars en TVL, est sans aucun doute celui qui compte le plus de volume et le plus long d’adeptes. Avec des incitations claires au staking et un rendement décent, Merlin a vu le jour presque en quelques mois, créant un mythe écologique qui transcende Blast. Avec la popularité croissante de Merlin, la discussion de ses solutions techniques est devenue un sujet de plus en plus long.
Dans cet article, Geek Web3 se concentrera sur les solutions techniques de Merlin Chain, interprétera ses documents publiés et protocole idées de conception, et nous nous engageons à permettre à un plus grand nombre de personnes long 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é, afin que tout le monde puisse comprendre le fonctionnement de ce « Bitcoin Layer 2 de tête » de manière plus intuitive.
Le réseau oracle décentralisé de Merlin : un conseil DAC off-chain ouvert
Pour tous les Layer 2, qu’il s’agisse de Ethereum Layer 2 ou de Bitcoin Layer 2, les coûts de DA et de publication des données sont l’un des problèmes les plus importants à résoudre. En raison des problèmes les plus longs du réseau Bitcoin lui-même, qui ne support pas intrinsèquement un grand débit de données, la façon d’utiliser ce court DA est devenue un problème difficile pour tester l’imagination de Layer 2 projets.
Une conclusion s’impose : si Layer 2 publie « directement » des données de transaction non traitées sur le Bitcoin Bloc, il ne sera pas en mesure d’atteindre un débit élevé ou des frais peu élevés. La solution la plus populaire consiste soit à compresser la taille des données aussi petite que possible grâce à une compression élevée et à les télécharger sur le Bitcoin Bloc, soit à publier les données directement sur le Bitcoin off-chain. **
La plus connue des couches de Layer 2 qui adoptent la première approche est probablement Citrea, qui a l’intention de télécharger le différentiel d’état de Layer 2 sur une période de temps, c’est-à-dire les résultats du changement d’état sur long compte, ainsi que les preuves ZK correspondantes, sur le Bitcoin off-chain. Dans ce cas, n’importe qui peut télécharger le diff d’état et le ZKP à partir du Bitcoin Mainnet pour surveiller les résultats du changement d’état de Citrea. Cette méthode permet de réduire de plus de 90 % la taille des données sur la chaîne.
Bien que cela puisse réduire considérablement la taille des données, le goulot d’étranglement reste important. Si un grand nombre de changements d’état de compte se produisent au cours d’une période de temps short, Layer 2 doit résumer et télécharger toutes les modifications de ces compte dans le Bitcoin off-chain, et le coût final de publication des données ne peut pas être maintenu à un niveau très bas, ce qui peut être vu dans le tout long Ethereum ZK Rollup.
Il est très long Bitcoin Layer 2 d’emprunter simplement la deuxième voie : utiliser directement la solution DA Bitcoin off-chain, soit construire une couche DA par elle-même, soit utiliser Celestia, EigenDA, etc. B^Square, BitLayer et Merlin, le protagoniste de cet article, suivent tous ce schéma de mise à l’échelle DA off-chain.
Dans l’article précédent de Geek web3 - « Analyse de la nouvelle version de la feuille de route de la technologie B^2 : la nécessité de Bitcoin off-chain DA et de la couche de vérification », nous avons mentionné que **B^2 imite directement Celestia et construit un réseau DA qui prend en charge la fonction d’échantillonnage de données dans le off-chain, nommé B^2 Hub. Les « données DA » telles que les données de transaction ou les différences d’état sont stockées dans le Bitcoin off-chain, et seule la racine datahash/merkle est téléchargée sur le Bitcoin Mainnet. **
Il traite vraiment Bitcoin comme un tableau d’affichage Trustless : n’importe qui peut lire le datahash à partir de Bitcoin off-chain. Lorsque vous obtenez des données DA du fournisseur de données off-chain, vous pouvez vérifier si elles correspondent au datahash off-chain, c’est-à-dire hash(data1) == datahash1 ?. S’il y a une correspondance entre les deux, cela signifie que le fournisseur de données sous la off-chain vous a donné les bonnes données.
Le processus ci-dessus permet de s’assurer que les données qui vous sont fournies par off-chain Nœud sont associées à certains « indices » sur la couche 1, empêchant ainsi la couche DA de fournir de manière malveillante de fausses données. Mais il y a un scénario d’épingle très important ici : que se passe-t-il si la source des données, Sequencer, n’envoie pas du tout les données correspondantes du datahash, mais envoie uniquement le datahash au Bitcoin off-chain, mais cache délibérément les données correspondantes à quiconque peut les lire ?
Des scénarios similaires incluent, mais ne sont pas limités à, la publication uniquement de ZK-Proof et StateRoot, mais pas la publication des données DA correspondantes (différence d’état ou données de transaction), bien que les utilisateurs puissent vérifier que le processus de calcul ZKProof est valide et s’assurer que le processus de calcul de Prev_Stateroot à New_Stateroot est valide, mais ils ne savent pas quel état compte (état) a changé. Dans ce cas, bien que les actifs de l’utilisateur soient en sécurité, vous ne pouvez pas du tout déterminer l’état réel du réseau, et vous ne savez pas quelles transactions ont été empaquetées sur la chaîne et quels contrats ont été mis à jour.
Il s’agit en fait de "rétention de données », et Dankrad de la Fondation Ethereum a brièvement discuté d’un problème similaire sur Twitter en août 2023, bien sûr, il est principalement bougie à longue mèche pour quelque chose appelé « DAC ».
Longest Ethereum Layer2, qui adopte des solutions DA off-chain, met souvent en place plusieurs nœuds avec des autorisations spéciales pour former un comité, le nom complet de Comité de disponibilité des données (DAC). Ce comité DAC agit en tant que garant, affirmant que Sequencer publie les données DA complètes (données de transaction ou différence d’état) off-chain. Ensuite, le nœud DAC génère collectivement un plus long, aussi long que le plus long répond aux exigences de seuil (par exemple 2/4), le contrat concerné sur la couche 1 sera par défaut et Sequencer a passé l’inspection du comité DAC et a honnêtement publié les données DA complètes off-chain.
Le comité de Ethereum Layer 2 du DAC suit essentiellement le modèle du POA, n’autorisant que quelques nœuds KYC ou officiellement désignés à rejoindre le comité du DAC, ce qui fait du DAC un synonyme de « blockchain centralisée » et de « blockchain de consortium ». De plus, dans certains Ethereum Layer 2 qui adoptent le modèle DAC, le séquenceur n’envoie des données DA qu’aux nœuds membres du DAC, et ne télécharge presque jamais de données ailleurs, et quiconque souhaite obtenir des données DA doit obtenir l’autorisation du comité DAC, ce qui n’est pas fondamentalement différent du Consortium Blockchain.
Il ne fait aucun doute que le DAC devrait être Décentralisation, et Layer 2 ne pouvez pas télécharger les données du DA directement sur la couche 1, mais l’autorité d’accès du comité du DAC devrait être ouverte au monde extérieur pour empêcher quelques personnes de s’entendre pour faire le mal. (Pour une discussion sur le scénario des méfaits de la DAC, veuillez vous référer à la déclaration précédente de Dankrad sur Twitter)
**BlobStream, précédemment proposé par Celestia, consiste essentiellement à remplacer le DAC centralisé par Celestia, ** Le séquenceur Ethereum L2 peut publier des données DA sur le Celestia on-chain, si les 2/3 du nœud Celestia le signent, le contrat d’exclusivité Layer2 déployé sur Ethereum estime que le séquenceur libère honnêtement les données DA, ce qui est en fait de laisser le nœud Celestia agir en tant que garant. Si l’on considère que Celestia dispose de centaines de nœuds de validation, on peut considérer que ce grand DAC est relativement décentralisé.
**La solution DA utilisée par Merlin est en fait proche du BlobStream de Celestia, qui ouvre les droits d’accès au DAC sous forme de POS pour le faire tendre vers la décentralisation. N’importe qui peut exécuter un nœud DAC aussi long qu’il stake suffisamment d’actifs. Dans la documentation de Merlin, le nœud DAC ci-dessus est appelé Oracle, et il est souligné que le jalonnement d’actifs de BTC, MERL et même BRC-20 Tokens sera pris en charge, permettant un mécanisme de jalonnement flexible, ainsi que le jalonnement par proxy similaire à Lido. (Le POS stake protocole de Oracle Machine est essentiellement l’un des prochains récits de base de Merlin, et les stake Taux d'intérêt fournis sont relativement élevés)
Voici une brève description du flux de travail de Merlin (image ci-dessous):
Oracle Nœud traitement spécial de son processus de calcul pour vérifier ZK Proof, générer un engagement d’engagement, l’envoyer au Bitcoin off-chain et permettre à quiconque de contester l'« engagement », et le processus de ce processus est fondamentalement le même que le fraud proof protocole de bitVM. Si la contestation est couronnée de succès, le Nœud Oracle qui publie l’Engagement sera pénalisé financièrement. Bien entendu, les données qu’Oracle souhaite publier sur le Bitcoin off-chain, y compris le hash de l’état actuel du Layer 2 - StateRoot, et le ZKP lui-même, doivent être publiées sur le Bitcoin off-chain pour que le monde extérieur puisse les détecter.
Il y a encore quelques détails qui doivent être élaborés, tout d’abord, la feuille de route de Merlin mentionne qu’à l’avenir, Oracle sauvegardera les données DA à Celestia, afin qu’Oracle Nœud puisse éliminer correctement les données historiques locales et n’ait pas besoin de conserver les données localement pour toujours. Dans le même temps, l’engagement généré par Oracle Network est en fait la racine d’un arbre de Merkle, et il ne suffit pas de divulguer la racine au monde extérieur, mais pour divulguer tous les ensembles de données complets correspondant à l’engagement, il est nécessaire de trouver une plate-forme DA tierce, qui peut être Celestia, EigenDA ou d’autres couches DA.
Analyse du modèle de sécurité : le service MPC optimiste de ZKRollup+Cobo
Ci-dessus, nous avons brièvement décrit le flux de travail de Merlin, et je pense que vous avez déjà une bonne compréhension de sa structure de base. Il n’est pas difficile de voir que Merlin suit fondamentalement le même modèle de sécurité que B^Square, BitLayer et Citrea - l’optimiste ZK-Rollup.
La première lecture de ce mot peut faire se sentir bizarre de nombreux amateurs de long Ethereum, qu’est-ce que le « ZK-Rollup optimiste » ? Dans la cognition de la communauté Ethereum, le « modèle théorique » de ZK Rollup est entièrement basé sur la fiabilité des calculs de Cryptographie, et il n’est pas nécessaire d’introduire des hypothèses de confiance, et le mot optimisme introduit précisément des hypothèses de confiance, ce qui signifie que les gens devraient être optimistes sur le fait que les Rollups ne sont pas faux et fiables lorsqu’ils long un grand nombre de fois. Et une fois qu’il y a une erreur, l’opérateur Rollup peut être puni par fraud proof, qui est à l’origine du nom Optimistic Rollup, également connu sous le nom OP Rollup.
Pour l’écosystème Ethereum de la base de Rollup, l’optimisme ZK-Rollup est peut-être un peu inhabituel, mais cela correspond exactement à la situation actuelle de Bitcoin Layer 2. En raison de limitations techniques, Bitcoin off-chain ne pouvez pas vérifier entièrement ZK Proof, ne pouvez vérifier qu’une certaine étape du processus de calcul ZKP dans des circonstances particulières, dans cette prémisse, Bitcoin off-chain ne pouvez en fait que support fraud proof protocole, les gens peuvent souligner que ZKP dans le processus de vérification off-chain, une certaine étape de calcul a une erreur, et par le biais de la fraud proof manière de contester, bien sûr, cela ne peut pas être comparé au Ethereum ZK Rollup de style, mais c’est Bitcoin déjà le plus fiable et le plus fiable et le plus Le modèle de sécurité le plus robuste.
Dans le cadre du schéma optimiste ZK-Rollup ci-dessus, en supposant qu’il y ait N challengers autorisés dans le réseau de Layer 2, aussi long que 1 de ces N challengers est honnête et fiable, et peut détecter les erreurs et initier la fraud proof à tout moment, la transition d’état de Layer 2 est sûre. Bien sûr, les rollups optimistes avec un degré d’achèvement relativement élevé doivent s’assurer que leurs ponts de retrait sont également protégés par des fraud proof protocole, et à l’heure actuelle, presque tous les Bitcoin Layer 2 ne peuvent pas atteindre cette prémisse et doivent s’appuyer sur long signature/MPC, de sorte que le choix de la solution long signature/MPC est devenu un problème étroitement lié à la sécurité de Layer 2.
Merlin a choisi le service MPC de Cobo sur le système de bridge, en utilisant des mesures telles que l’isolation des portefeuilles froids et chauds, les actifs des ponts sont gérés conjointement par Cobo et Merlin Chain, et tout retrait doit être géré conjointement par les participants MPC de Cobo et Merlin Chain, garantissant essentiellement la fiabilité du bridge de retrait grâce à l’endossement de crédit de l’institution. Bien sûr, il ne s’agit que d’une mesure provisoire à ce stade, et avec l’amélioration progressive du projet, le bridge de retrait peut être remplacé par le « bridge optimiste » de l’hypothèse de confiance 1/N en introduisant BitVM et fraud proof protocole, mais il sera plus difficile d’atterrir (à l’heure actuelle, presque tous les ponts officiels de couche 2 reposent sur long signe).
Dans l’ensemble, nous pouvons déterminer que Merlin a introduit un DAC basé sur POS, un ZK-Rollup optimiste basé sur BitVM et une solution de conservation d’actifs MPC basée sur Cobo, a résolu le problème DA en ouvrant les autorisations DAC, a assuré la sécurité de la transition d’état en introduisant BitVM et fraud proof protocole, et a assuré la fiabilité du bridge de retrait en introduisant le service MPC de la célèbre plate-forme de conservation d’actifs Cobo.
Schéma de soumission ZKP de vérification en deux étapes basé sur Lumoz
Plus tôt, nous avons passé au peigne fin le modèle de sécurité de Merlin et introduit le concept de ZK-rollup optimiste. Dans la feuille de route technologique de Merlin, Decentralisation Prover est également discuté. Comme nous le savons tous, Prover est un rôle central dans l’architecture ZK-Rollup, qui est responsable de la génération de ZKProofs pour les lots publiés par Sequencer, et le processus de génération de zk-SNARKs est très gourmand en ressources matérielles et un problème très délicat.
Pour accélérer la génération des preuves ZK, la parallélisation de la tâche est l’une des opérations les plus élémentaires. **La soi-disant parallélisation consiste en fait à diviser la tâche de génération de preuve ZK en différentes parties, qui sont complétées séparément par différents prouveurs, et enfin l’agrégateur d’agrégateurs agrège la preuve la plus longue en un tout.
Dans le ordre d’accélérer le processus de génération de preuves ZK, Merlin utilisera la solution Prover as a service de Lumoz, qui consiste en fait à rassembler un grand nombre de périphériques matériels pour former un pool de minage, puis à attribuer des tâches informatiques à différents appareils et à attribuer des incitations correspondantes, similaires au minage POW.
Dans ce schéma de décentralisation Prover, il existe une classe de scénarios d’attaque, communément appelés attaques front-running : Supposons qu’un agrégateur Aggregator ait formé un ZKP et qu’il envoie le ZKP dans l’espoir de recevoir une récompense. Après que d’autres agrégateurs aient vu le contenu de ZKP, ils se sont précipités pour poster le même contenu devant lui, affirmant que ce ZKP avait été créé par leur propre mari, comment résoudre cette situation ?
L’une des solutions les plus instinctives qui peuvent venir à l’esprit est d’attribuer un numéro de tâche spécifique à chaque agrégateur, par exemple, seul l’agrégateur A peut prendre la tâche 1, et tous les autres n’obtiendront pas de récompense même s’ils terminent la tâche 1. Mais l’un des problèmes de cette approche est qu’elle ne protège pas contre un seul point de risque. Si l’agrégateur A subit une défaillance des performances ou se déconnecte, la tâche 1 est bloquée et ne peut pas se terminer. De plus, cette pratique consistant à attribuer des tâches à une seule entité n’est pas un bon moyen d’améliorer la productivité avec des incitations concurrentielles.
Polygon zkEVM a proposé une méthode appelée Preuve d’efficacité dans un article de blog, qui stipule que différents agrégateurs devraient être promus pour rivaliser les uns avec les autres de manière compétitive, et que les incitations devraient être distribuées sur la base du premier arrivé, premier servi, et que les premiers agrégateurs à soumettre ZK-Proof à la chaîne peuvent recevoir des récompenses. Bien sûr, il n’a pas mentionné comment résoudre le problème de la course frontale MEV.
Lumoz utilise une méthode de soumission de preuve ZK de vérification en deux étapes, après qu’un agrégateur ait généré une preuve ZK, il n’a pas besoin d’envoyer le contenu complet, mais publie uniquement le hash de ZKP, en d’autres termes, publie le hash (ZKP + adresse d’agrégation). De cette façon, même si d’autres personnes voient la valeur hash, elles ne connaissent pas le contenu ZKP correspondant et ne peuvent pas le précipiter directement ;
Si quelqu’un copie simplement le hash entier et le publie en premier, cela n’a aucun sens, car le hash contient l’adresse d’un agrégateur X spécifique, et même si l’agrégateur A publie le hash en premier, lorsque l’image originale du hash est révélée, tout le monde verra que l’adresse de l’agrégateur qu’il contient est X, pas A.
Grâce à ce système de soumission ZKP de vérification en deux étapes, Merlin (Lumoz) peut résoudre le problème de démarrage dans le processus de soumission ZKP, puis réaliser des incitations à la génération zk-SNARKs hautement compétitives, améliorant ainsi la vitesse de génération de ZKP.
Merlin’s Phantom : la plus longue interopérabilité des chaînes
Selon la feuille de route technique de Merlin, ils support également l’interopérabilité entre Merlin et d’autres chaînes EVM, et son chemin de mise en œuvre est fondamentalement le même que l’idée précédente de Zetachain, si Merlin est utilisé comme chaîne source et d’autres chaînes EVM sont utilisées comme chaîne cible, lorsque le nœud Merlin perçoit la demande d’interopérabilité cross-chain faite par l’utilisateur, il déclenchera le flux de travail suivant sur la cible on-chain.
Par exemple, un compte EOA contrôlé par le réseau Merlin peut être déployé sur Polygon, ** Lorsqu’un utilisateur publie une instruction d’interopérabilité cross-chain sur Merlin Chain, le réseau Merlin analyse d’abord son contenu et génère une donnée de transaction exécutée sur la cible on-chain, puis le traitement de signature Oracle Network MPC sur la transaction génère une signature numérique de la transaction. Le nœud de relais de Merlin libère ensuite la transaction ** sur Polygon, complétant les opérations ultérieures via les actifs de Merlin dans le compte EOA sur la cible on-chain.
Lorsque l’opération requise par l’utilisateur est terminée, l’actif correspondant sera transféré directement à l’adresse de l’utilisateur sur la cible off-chain, et théoriquement peut également traverser directement dans la chaîne Merlin. Cette solution présente des avantages évidents : elle peut éviter l’usure des frais générés par les contrats traditionnels de cross-chain et de bridges cross-chain, et elle est directement garantie par Oracle Network de Merlin pour assurer la sécurité des opérations cross-chain, et il n’est pas nécessaire de s’appuyer plus longtemps sur une infrastructure externe. Aussi longues que les utilisateurs fassent confiance à Merlin Chain, il n’y a aucun problème à utiliser par défaut une telle interopérabilité cross-chain.
Résumé
Dans cet article, nous donnons une brève explication de la solution technique générale de Merlin Chain, qui est censée aider plus de personnes longues à comprendre le flux de travail général de Merlin et à avoir une compréhension plus claire de son modèle de sécurité. Compte tenu de l’écologie actuelle de Bitcoin en plein essor, nous pensons que ce type de comportement de vulgarisation scientifique technique est précieux et nécessaire pour le grand public, ** Nous effectuerons un suivi à long terme sur Merlin et bitLayer, B ^ Square et d’autres projets à l’avenir **, et effectuerons une analyse plus approfondie de ses solutions techniques, alors restez à l’écoute !