De Sidechain à ZL Layer2, comment Merlin Chain en est-elle arrivée là ?

Un examen systématique de Messari de la transition progressive de Merlin de BTCSidechain à BTCZK layer2, après l’avoir lu, voici un résumé en combinant ma compréhension personnelle :

La naissance de Merlin Chain semble avoir suivi le courant, chaque étape étant inattendue. Avec le soutien d’une communauté solide telle que BRC-20, BRC-420, Blue Box, Bitmap Game, Merlin Chain a choisi une voie technique d’intégration et d’itération constante. En réalité, il n’y a pas d’autre choix.

En raison des défauts de « programmabilité » de base du réseau BTC natif en termes de disponibilité de ses propres données (DA) et d’exhaustivité de Turing (SC) des contrats intelligents, l’écosystème BTC bat son plein avec des projets innovants depuis plus d’un an, mais n’a pas encore été entièrement livré.

RGB++（Nervos）、BitVM（BitLayer）、zkVM（ ZKM）、AVM（Atomicals Protocol）、DA（B² Network、Nubit) L’approche de Merlin Chain est d’adopter les forces de tous, et d’améliorer constamment son propre cadre technologique.

2）Selon le rapport de Messari, la chaîne initiale de Merlin était une architecture pure de sidechain, construite par Lumoz sur le service CDK RaaS de Polygon, équivalant à une chaîne d’architecture Validium, ce qui signifie que les données de transaction de la chaîne sont entièrement stockées off-chain, seuls les preuves de validité sont publiées sur L1, et le réseau principal L1 ne peut pas vérifier l’exactitude des données L2. De plus, les données d’origine de cette architecture Validium sont toutes stockées dans une base de données locale, et le comité de disponibilité des données (DAC) est responsable de la collecte, du tri et de la vérification des données.

De toute évidence, cela nécessite la « confiance » de la chaîne elle-même comme prémisse, et il est difficile de la mettre à l’échelle à grande échelle, ce qui est également la raison pour laquelle Validium est remplacé par Rollup dans le système de couche 2 de l’ETH.

Pour remédier à cette lacune fondamentale, Merlin a renforcé ses itérations de deux manières:

1. En collaboration avec BTCOS pour améliorer les bridges cross-chain natifs et résoudre le problème de vérification des données L2 avec BTCMainnet, BitcoinOS a construit une Machine virtuelle vérifiable ProofMachine virtuelle-BitSNARK basée sur le framework ZK, combinée avec Grail Bridgebridges cross-chain pour mettre à jour les transferts d’actifs et les changements d’état de L2. Tout le processus utilise un réseau intermédiaire ZK pour synchroniser l’état entre L2 et Mainnet, et finalement, une interaction fiable est réalisée grâce à la verrouillage temporel des actifs sur Mainnet et le mécanisme de défi BitVM.

2、Collaboration avec Nubit pour construire la capacité de vérification de la disponibilité des données (DA), la logique générale est la suivante : déployer un nœud complet hors chaîne pour synchroniser les données d’état complet BTC et les preuves de changement d’état, et utiliser un nœud léger déployé sur le réseau principal BTC pour réaliser la vérification de l’état et la confirmation de la finalité, améliorant ainsi l’opacité et l’invérifiabilité précédentes du DAS hors chaîne, renforçant ainsi la capacité de DA nécessaire (en cours de développement).

En fin de compte, l’objectif de Merlin Chain est de devenir un réseau BTCZK-Rollup, composé de composants tels que Nœud, zkProver, Database, etc., puis de passer par un réseau Oracle Machine décentralisé, similaire à l’index du protocole d’ordre, pour en faire un EVM-Compatible BTClayer2 équilibré en termes de décentralisation (aucune permission de distribution de Nœud), transparence (accessibilité des données publiques) et vérifiabilité (Mainnet peut vérifier l’état des données L2 et un mécanisme de contestation est en place).