¿Cómo llegó Merlin Chain desde Sidechains hasta ZL Layer2?

Un informe sistemático de Messari sobre la solución de transición de Merlin de BTCCadena lateral a BTCZK layer2. Después de leerlo, resumiré mi comprensión personal aquí.

El nacimiento de Merlin Chain parece haber seguido naturalmente su curso, cada paso fue inesperado. Con el respaldo de una gran comunidad que incluye BRC-20, BRC-420, Blue BOX, Bitmap Game, Merlin Chain optó por un enfoque de desarrollo continuo e integrado. De hecho, no había otra opción.

Porque la red nativa de BTC tiene deficiencias en su propia disponibilidad de datos (DA), la Turing completeness de los contratos inteligentes (SC) y otros aspectos de la “programabilidad”, lo que ha llevado a un auge de proyectos innovadores en el ecosistema de BTC en el último año, pero que aún no se han entregado completamente.

La idea de RGB++ (Nervos), BitVM (BitLayer), zkVM (ZKM), AVM (Atomicals Protocol), DA (B² Network, Nubit) en la cadena Merlin es aprovechar las fortalezas de todos y mejorar continuamente su propio marco tecnológico.

2. Según el informe de Messari, la cadena original de Merlin Chain era puramente una arquitectura de cadena lateral, construida por Lumoz sobre el servicio CDK RaaS de Polygon, que es equivalente a una cadena de arquitectura Validium, lo que significa que los datos de transacción de la cadena se almacenan completamente fuera de la cadena (off-chain) y solo se publican las pruebas de validez en L1. Sin embargo, la red principal de L1 no puede verificar la precisión de los datos de L2. Además, los datos originales de esta arquitectura Validium se almacenan en una base de datos local y el Comité de Disponibilidad de Datos (DAC) es responsable de la obtención, clasificación y verificación de los datos, entre otras tareas.

Obviamente, esto requiere la “confianza” de la cadena en sí como premisa, lo que hace difícil escalar a gran escala. En el sistema de capa 2 de ETH, Rollup reemplaza a Validium por esta razón.

Para compensar esta deficiencia fundamental, Merlin ha realizado mejoras iterativas desde dos aspectos:

1、Colaborar con BTCOS para mejorar el puentes cross-chain nativo, y abordar el problema de verificación de datos L2 con BTCMainnet, BitcoinOS ha construido una prueba verificable basada en el marco ZK llamada ProofMáquina virtual-BitSNARK, combinada con Grail Bridgepuentes cross-chain para actualizar la transferencia de activos y cambios de estado en L2. Durante todo el proceso, la red ZK intermedia sincroniza el estado entre L2 y Mainnet, logrando una interacción confiable mediante el bloqueo temporal de activos en Mainnet y el mecanismo de desafío BitVM.

2、Colaborar con Nubit para construir la capacidad de verificación de la disponibilidad de datos (DA), la lógica general es: desplegar nodos completos off-chain para sincronizar los datos de estado completo de BTC y las pruebas de cambio de estado, y utilizar nodos ligeros desplegados en la red principal de BTC para realizar la verificación del estado y la confirmación de la finalidad, mejorando así la opacidad y la falta de verificabilidad que existían anteriormente en el DAS off-chain, lo que se considera un fortalecimiento de la capacidad de DA necesaria (actualmente en desarrollo).

Finalmente, el objetivo de Merlin Chain es convertirse en una red BTCZK-Rollup, compuesta por componentes como Nodo, zkProver, base de datos, etc., y luego a través de una red de Máquina de oráculo descentralizado similar a Ordinalsprotocolo, hacerlo un EVM-Compatible BTClayer2 equilibrado en Descentralización (Nodo distribuido sin permiso), transparencia (accesibilidad de datos públicos) y verificabilidad (Mainnet puede verificar el estado de los datos L2 y tiene un mecanismo de desafío garantizado).