Évolution des sidechains Bitcoin vers le Layer 2 ZK : Analyse du chemin technique de Merlin Chain
Le développement de Merlin Chain peut être considéré comme en phase avec les tendances du moment. Sur la base de l'énorme communauté apportée par des projets tels que BRC-20 et BRC-420, Merlin Chain a choisi une voie technique d'intégration et d'itération continues. Ce choix est en réalité déterminé par les limitations fondamentales de "programmabilité" présentes dans le réseau Bitcoin natif en termes de disponibilité des données et de la complétude de Turing des contrats intelligents.
Au cours de l'année écoulée, l'écosystème Bitcoin a vu l'émergence de nombreux projets innovants, tels que RGB++, BitVM, zkVM, AVM, etc., mais la plupart n'ont pas encore été pleinement réalisés. La stratégie de Merlin Chain consiste à absorber les avantages de ces projets et à améliorer constamment son cadre technique.
Selon un rapport d'analyse, Merlin Chain était à l'origine une architecture de sidechains pure, construite sur le service CDK RaaS d'une certaine entreprise, utilisant l'architecture Validium. Cela signifie que les données de transaction de la chaîne sont entièrement stockées hors chaîne, seules les preuves de validité étant publiées sur L1, tandis que le réseau principal L1 ne peut pas vérifier l'exactitude des données L2. De plus, les données originales de l'architecture Validium sont conservées dans une base de données locale, et un comité de disponibilité des données est responsable de l'acquisition, du tri et de la vérification des données.
Cette architecture nécessite une grande confiance dans la chaîne elle-même, ce qui rend difficile l'expansion à grande échelle. Pour résoudre ce problème, Merlin a apporté des améliorations sur deux aspects :
Collaborer avec BTCOS pour améliorer la vérifiabilité des données L2 sur le réseau principal Bitcoin via le pont inter-chaînes Native. BTCOS a construit une machine virtuelle Proof vérifiable BitSNARK basée sur le cadre ZK, combinée avec le pont inter-chaînes Grail Bridge pour mettre à jour le transfert d'actifs et les changements d'état de L2. L'ensemble du processus synchronise l'état entre L2 et le réseau principal via un réseau intermédiaire ZK, réalisant finalement une interaction de confiance grâce à un verrouillage temporel des actifs du réseau principal et au mécanisme de défi BitVM.
Collaborer avec un projet pour construire des capacités de disponibilité des données vérifiables. La logique de base est de déployer hors chaîne des nœuds complets synchronisant toutes les données d'état BTC et les preuves de changement d'état, et de réaliser la validation d'état et la confirmation finale via des nœuds légers déployés sur le réseau principal BTC, améliorant ainsi le problème d'opacité et d'invérifiabilité précédemment rencontré par le DAS hors chaîne, et renforçant les capacités de DA requises.
L'objectif final de Merlin Chain est de devenir un réseau de ZK-Rollup pour Bitcoin, composé de composants tels que Node, zkProver, Database, etc. Grâce à un réseau oracle décentralisé indexé de manière similaire au protocole Ordinals, Merlin Chain devrait connaître une amélioration équilibrée en matière de décentralisation, de transparence et de vérifiabilité, devenant ainsi une solution de Layer 2 compatible avec EVM pour Bitcoin.
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.
15 J'aime
Récompense
15
5
Partager
Commentaire
0/400
MEVHunterZhang
· Il y a 9h
Il suffit de frémir !
Voir l'originalRépondre0
ChainWallflower
· Il y a 18h
Cette stratégie technique est un vrai piège bull.
Voir l'originalRépondre0
Layer2Arbitrageur
· Il y a 19h
je viens de faire les calculs... l'optimisation du gaz de merlin pourrait offrir des opportunités d'arbitrage d'environ 400 bps si elle est bien codée *smirks*
Voir l'originalRépondre0
SerumSquirter
· Il y a 19h
Tout le monde parle de complétude, il suffit de faire les choses avec de l'argent.
Voir l'originalRépondre0
CryptoWageSlave
· Il y a 19h
Prends ton temps, regardons d'abord le BTC se mettre en marche.
Merlin Chain : l'évolution technologique de Bitcoin sidechains vers ZK Layer 2
Évolution des sidechains Bitcoin vers le Layer 2 ZK : Analyse du chemin technique de Merlin Chain
Le développement de Merlin Chain peut être considéré comme en phase avec les tendances du moment. Sur la base de l'énorme communauté apportée par des projets tels que BRC-20 et BRC-420, Merlin Chain a choisi une voie technique d'intégration et d'itération continues. Ce choix est en réalité déterminé par les limitations fondamentales de "programmabilité" présentes dans le réseau Bitcoin natif en termes de disponibilité des données et de la complétude de Turing des contrats intelligents.
Au cours de l'année écoulée, l'écosystème Bitcoin a vu l'émergence de nombreux projets innovants, tels que RGB++, BitVM, zkVM, AVM, etc., mais la plupart n'ont pas encore été pleinement réalisés. La stratégie de Merlin Chain consiste à absorber les avantages de ces projets et à améliorer constamment son cadre technique.
Selon un rapport d'analyse, Merlin Chain était à l'origine une architecture de sidechains pure, construite sur le service CDK RaaS d'une certaine entreprise, utilisant l'architecture Validium. Cela signifie que les données de transaction de la chaîne sont entièrement stockées hors chaîne, seules les preuves de validité étant publiées sur L1, tandis que le réseau principal L1 ne peut pas vérifier l'exactitude des données L2. De plus, les données originales de l'architecture Validium sont conservées dans une base de données locale, et un comité de disponibilité des données est responsable de l'acquisition, du tri et de la vérification des données.
Cette architecture nécessite une grande confiance dans la chaîne elle-même, ce qui rend difficile l'expansion à grande échelle. Pour résoudre ce problème, Merlin a apporté des améliorations sur deux aspects :
Collaborer avec BTCOS pour améliorer la vérifiabilité des données L2 sur le réseau principal Bitcoin via le pont inter-chaînes Native. BTCOS a construit une machine virtuelle Proof vérifiable BitSNARK basée sur le cadre ZK, combinée avec le pont inter-chaînes Grail Bridge pour mettre à jour le transfert d'actifs et les changements d'état de L2. L'ensemble du processus synchronise l'état entre L2 et le réseau principal via un réseau intermédiaire ZK, réalisant finalement une interaction de confiance grâce à un verrouillage temporel des actifs du réseau principal et au mécanisme de défi BitVM.
Collaborer avec un projet pour construire des capacités de disponibilité des données vérifiables. La logique de base est de déployer hors chaîne des nœuds complets synchronisant toutes les données d'état BTC et les preuves de changement d'état, et de réaliser la validation d'état et la confirmation finale via des nœuds légers déployés sur le réseau principal BTC, améliorant ainsi le problème d'opacité et d'invérifiabilité précédemment rencontré par le DAS hors chaîne, et renforçant les capacités de DA requises.
L'objectif final de Merlin Chain est de devenir un réseau de ZK-Rollup pour Bitcoin, composé de composants tels que Node, zkProver, Database, etc. Grâce à un réseau oracle décentralisé indexé de manière similaire au protocole Ordinals, Merlin Chain devrait connaître une amélioration équilibrée en matière de décentralisation, de transparence et de vérifiabilité, devenant ainsi une solution de Layer 2 compatible avec EVM pour Bitcoin.