Desde el “Verano de las Inscripciones” en 2023, las tecnologías Layer2 de Bitcoin han estado a la vanguardia de la revolución Web3. A pesar de ingresar al campo más tarde que las soluciones Layer2 de Ethereum, Bitcoin ha aprovechado el atractivo único de POW y el lanzamiento sin contratiempos de los ETF spot, que están libres de riesgos de “securitización”, para atraer miles de millones de dólares de inversión a este sector pujante en tan solo seis meses. Entre estos, Merlin destaca como la entidad más sustancial y seguida en el panorama de Bitcoin Layer2, comandando miles de millones en valor total bloqueado (TVL). Gracias a claros incentivos de participación y retornos impresionantes, Merlin rápidamente se destacó, superando incluso al conocido ecosistema Blast en cuestión de meses. Con el creciente revuelo en torno a Merlin, la exploración de su infraestructura técnica ha cautivado a una audiencia en aumento. En este artículo, Geek Web3 se centra en descifrar las estrategias técnicas detrás de Merlin Chain. Al desempaquetar los documentos disponibles públicamente y la lógica detrás de su diseño de protocolo, nuestro objetivo es desmitificar los procesos operativos de Merlin y mejorar la comprensión de su marco de seguridad, proporcionando una visión más clara de cómo funciona esta destacada solución Layer2 de Bitcoin.

Red de Oráculos Descentralizados de Merlín: Un Comité DAC Abierto Fuera de la Cadena

Para cada tecnología de Capa2, abordar la disponibilidad de datos (DA) y el costo de la publicación de datos sigue siendo un desafío crítico, ya sea para Capa2 de Ethereum o Capa2 de Bitcoin. Dadas las limitaciones inherentes de la red de Bitcoin, que lucha con un gran volumen de datos, la planificación del uso eficiente del valioso espacio de DA es una prueba significativa para la creatividad de los desarrolladores de Capa2.

Es evidente que si los proyectos de Capa 2 publicaran directamente datos de transacciones en bruto en la cadena de bloques de Bitcoin, no lograrían tanto alta capacidad como comisiones bajas. Las soluciones predominantes incluyen comprimir en gran medida los datos para reducir significativamente su tamaño antes de cargarlos en la cadena de bloques de Bitcoin, u optar por publicar los datos fuera de la cadena.

Entre quienes emplean la primera estrategia, Citrea se destaca. Su objetivo es cargar cambios en los estados de Layer2 en ciertos intervalos, lo que implica grabar los resultados de los cambios de estado en varias cuentas, junto con las pruebas de conocimiento cero (ZKPs) correspondientes, en la cadena de bloques de Bitcoin. Bajo este acuerdo, cualquiera puede acceder a las diferencias de estado y ZKPs desde la red principal de Bitcoin para hacer un seguimiento de los cambios de estado de Citrea. Este enfoque reduce efectivamente el tamaño de los datos cargados a la cadena de bloques en más del 90%.

Aunque esto puede comprimir considerablemente el tamaño de los datos, el cuello de botella sigue siendo obvio. Si un gran número de cuentas cambian su estado en un corto período de tiempo, la Capa 2 debe resumir y cargar todos los cambios en estas cuentas en la cadena de Bitcoin. El costo final de lanzamiento de datos no puede mantenerse muy bajo. Esto es cierto en muchos Ethereums. Esto se puede ver en ZK Rollup.

Muchas capas 2 de Bitcoin simplemente toman el segundo camino: utilizan directamente la solución DA bajo la cadena de Bitcoin, ya sea construyendo una capa DA por sí mismas, o utilizando Celestia, EigenDA, etc. B^Square, BitLayer y el protagonista de este artículo, Merlin, todos utilizan esta solución de expansión DA fuera de la cadena.

Artículo anterior en geek web3——"Análisis de la hoja de ruta de la nueva versión de la tecnología B^2: La necesidad de la capa de DA y verificación bajo la cadena de Bitcoin", mencionamos que B^2 imitó directamente a Celestia y construyó una red DA que admite la función de muestreo de datos bajo la cadena, llamada B^2 Hub. El '’ dato DA, como datos de transacción o diferencias de estado, se almacena bajo la cadena de Bitcoin, y solo se carga el datahash / raíz de Merkle en la red principal de Bitcoin.

Esto trata esencialmente a Bitcoin como un tablero de anuncios sin confianza: cualquiera puede leer el datahash de la cadena de Bitcoin. Después de obtener los datos de DA del proveedor de datos fuera de la cadena, puede verificar si corresponde al datahash en cadena, es decir, ¿hash(data1) == datahash1? Si hay correspondencia entre los dos, significa que los datos proporcionados por el proveedor de datos fuera de la cadena son correctos.

Capa DA explicada en Layer2 de Bitcoin:

(Fuente de la imagen: Geek web3)

Este sistema garantiza que los datos de los nodos fuera de la cadena se correlacionen con pistas específicas o pruebas en la Capa1, protegiéndose contra el posible problema de que la capa DA proporcione información falsa. Sin embargo, surge una preocupación importante si el originador de los datos, el Secuenciador, no distribuye los datos reales relacionados con un datahash. Supongamos que el Secuenciador solo transmite el datahash a la cadena de bloques de Bitcoin mientras retiene intencionalmente los datos correspondientes sin acceso público. ¿Qué sucede entonces?

Considera escenarios donde solo se hacen públicos el ZK-Proof y StateRoot, pero los datos DA acompañantes (como diferencias de estado o datos de transacciones) no se publican. Si bien es posible validar el ZK-Proof y garantizar que la transición de Prev_Stateroot a New_Stateroot es precisa, queda desconocido qué estados de cuentas han cambiado. En estas circunstancias, aunque los activos de los usuarios sigan seguros, la condición real de la red permanece incierta. Nadie sabe qué transacciones se han incorporado en la cadena de bloques o qué estados de contrato se han actualizado, lo que hace que Layer2 sea inoperativo, casi como si se hubiera desconectado.

Esta práctica se conoce como "retención de datos". En agosto de 2023, Dankrad de la Fundación Ethereum inició una discusión en Twitter sobre un concepto conocido como "DAC".

En muchos Ethereum Layer2 setups que utilizan soluciones de disponibilidad de datos fuera de la cadena (DA), a menudo hay algunos nodos con privilegios especiales que forman un comité conocido como el Comité de Disponibilidad de Datos (DAC). Este comité sirve como garante, asegurando que el Secuenciador haya liberado efectivamente datos DA completos (datos de transacciones o diferencias de estado) fuera de la cadena. Los miembros de DAC luego crean una firma múltiple colectiva. Si esta firma múltiple alcanza el umbral requerido (por ejemplo, 2 de 4), los contratos correspondientes en Layer1 están diseñados para asumir que el Secuenciador ha cumplido con los estándares de verificación de DAC y ha liberado genuinamente los datos DA completos fuera de la cadena.

Los comités DAC de Ethereum Layer2 se adhieren predominantemente al modelo de Prueba de Autoridad (POA), limitando la membresía a un grupo selecto de nodos que han pasado el KYC o han sido designados oficialmente. Este enfoque ha marcado efectivamente al DAC como un sello distintivo de "centralización" y "blockchain de consorcio". Además, en ciertos Ethereum Layer2 que utilizan el enfoque DAC, el secuenciador distribuye datos DA únicamente a los nodos miembros del DAC, con una difusión externa mínima. En consecuencia, cualquier persona que busque datos DA debe obtener la aprobación del DAC, al igual que operar dentro de un blockchain de consorcio.

Está claro que las DACs necesitan ser descentralizadas. Aunque es posible que no sea necesario cargar los datos de la DA directamente en la Capa 1 a través de la Capa 2, el acceso a la membresía de la DAC debería ser públicamente accesible para evitar la colusión y la mala conducta de unos pocos individuos. (Para obtener más información sobre este tema, consulte las discusiones anteriores de Dankrad en Twitter).

La propuesta de BlobStream de Celestia tiene como objetivo fundamental reemplazar un DAC centralizado con Celestia. Bajo este modelo, un secuenciador de capa 2 de Ethereum publicaría datos DA en la cadena de bloques de Celestia. Si dos tercios de los nodos de Celestia validan estos datos, el contrato especializado de Capa 2 en Ethereum validaría que el secuenciador ha publicado con precisión los datos DA, posicionando así a los nodos de Celestia como garantes. Dado que Celestia opera con cientos de nodos validadores, esta configuración DAC más grande se considera relativamente descentralizada.

La solución DA adoptada por Merlín es en realidad relativamente cercana a BlobStream de Celestia, ambos abren acceso a DAC a través de POS, haciéndolo más descentralizado. Cualquiera puede ejecutar un nodo DAC siempre que apueste suficientes activos. En la documentación de Merlín, el nodo DAC mencionado anteriormente se llama Oráculo, y se señala que admitirá apuestas de activos de BTC, MERL e incluso tokens BRC-20 para implementar un mecanismo de apuesta flexible y también admitirá apuestas de proxy similares a Lido. (El acuerdo de apuesta POS de la máquina oráculo es básicamente una de las próximas narrativas principales de Merlín, y las tasas de interés de apuesta proporcionadas son relativamente altas)

Aquí describimos brevemente el flujo de trabajo de Merlin (imagen abajo):

1. Después de que el secuenciador recibe un gran número de solicitudes de transacción, las agrega y genera un lote de datos (lote de datos), que se pasa al nodo Probador y al nodo Oráculo (DAC descentralizado).

2. El nodo Prover de Merlin es descentralizado y utiliza el Prover como servicio de lumoz. Después de recibir múltiples lotes de datos, el grupo minero Prover generará las correspondientes pruebas de conocimiento cero. Posteriormente, las ZKP se enviarán al nodo Oracle para su verificación.

3. El nodo Oracle verificará si la Prueba ZK enviada por el grupo minero ZK de Lmuoz corresponde a los datos Batch enviados por el Secuenciador. Si los dos pueden coincidir y no contienen otros errores, la verificación se aprueba. Durante este proceso, los nodos oráculo descentralizados generarán multi-firmas a través de firmas de umbral y declararán al mundo exterior que el secuenciador ha enviado completamente los datos de DA, y el ZKP correspondiente es válido y ha pasado la verificación de los nodos oráculo.

4. El secuenciador recopila los resultados de multi-firma de los nodos de Oracle. Cuando el número de firmas cumple con los requisitos de umbral, la información de la firma se envía a la cadena de Bitcoin, junto con el datahash de los datos de DA (lote de datos), y se entrega al mundo exterior para su lectura y confirmación.

(Fuente del diagrama del principio de funcionamiento de Merlin: Geek web3)

1. Los nodos Oracle realizan un procesamiento especial en el proceso de cálculo para verificar la Prueba de Conocimiento Cero, generan compromisos de Compromiso y los envían a la cadena de Bitcoin, lo que permite a cualquier persona desafiar el 'compromiso'. El proceso aquí es básicamente el mismo que el protocolo de prueba de fraude de bitVM. Si el desafío tiene éxito, el nodo Oracle que emitió el Compromiso será sancionado financieramente. Por supuesto, los datos que Oracle desea publicar en la cadena de Bitcoin también incluyen el hash del estado actual de la Capa 2 - StateRoot, así como el ZKP en sí mismo, que debe publicarse en la cadena de Bitcoin para su detección externa.

Referencias:Una interpretación minimalista de BitVM: Cómo verificar las pruebas de fraude en la cadena BTC

Hay varios detalles que necesitan ser elaborados aquí. En primer lugar, se menciona en la hoja de ruta de Merlin que Oracle respaldará los datos de DA en Celestia en el futuro. De esta manera, los nodos de Oracle pueden eliminar adecuadamente los datos históricos locales sin la necesidad de que los datos persistan localmente. Al mismo tiempo, el Compromiso generado por la Red de Oracle es en realidad la raíz de un Árbol de Merkle. No es suficiente revelar la raíz al mundo exterior. El conjunto de datos completo correspondiente al Compromiso debe hacerse público. Esto requiere encontrar una plataforma de DA de terceros. Esta plataforma puede ser Celestia o EigenDA, u otras capas de DA.

Referencias:"Análisis de la hoja de ruta de la tecnología de la nueva versión B^2: La necesidad de la capa de DA y verificación bajo la cadena de Bitcoin"

Análisis del modelo de seguridad: servicio MPC optimista de ZKRollup+Cobo

Arriba hemos descrito brevemente el flujo de trabajo de Merlin, y creo que ya has dominado su estructura básica. No es difícil ver que Merlin, B^Square, BitLayer y Citrea básicamente siguen el mismo modelo de seguridad: ZK-Rollup optimista.

Al leer esta palabra por primera vez, muchos entusiastas de Ethereum pueden sentirse extraños. ¿Qué es “ZK-Rollup optimista”? En la comprensión de la comunidad de Ethereum, el “modelo teórico” de ZK Rollup se basa completamente en la confiabilidad de cálculos criptográficos y no requiere la introducción de suposiciones de confianza. La palabra “optimista” introduce precisamente la suposición de confianza, lo que significa que la mayoría de las veces, se debe ser optimista de que Rollup no tiene errores y es confiable. Una vez que ocurre un error, el operador de Rollup puede ser castigado a través de una prueba de fraude. Esta es el origen del nombre Optimistic Rollup, también conocido como OP Rollup.

Para el ecosistema de Ethereum en la base de Rollup, el ZK-Rollup optimista puede ser un poco poco descriptivo, pero encaja perfectamente con la situación actual de la Capa 2 de Bitcoin. Debido a limitaciones técnicas, la cadena de Bitcoin no puede verificar completamente la Prueba ZK. Solo puede verificar cierto paso del proceso de cálculo de ZKP bajo circunstancias especiales. Bajo esta premisa, la cadena de Bitcoin solo puede admitir el protocolo de prueba de fraude. Se puede señalar que hay un error en un cierto paso de cálculo de ZKP durante el proceso de verificación fuera de la cadena, y desafiado a través de una prueba de fraude. Por supuesto, esto no se puede comparar con el ZK Rollup al estilo de Ethereum, pero es lo mejor que la Capa 2 de Bitcoin puede lograr actualmente. Modelo de seguridad confiable y más seguro.

Bajo el esquema optimista de ZK-Rollup anterior, suponga que hay N personas en la red de Capa 2 que tienen la autoridad para iniciar desafíos. Siempre que uno de los N desafiantes sea honesto y confiable y pueda detectar errores e iniciar pruebas de fraude en cualquier momento, la transición de estado de la Capa 2 es segura. Por supuesto, el Rollup optimista con un grado de finalización relativamente alto necesita garantizar que su puente de retiro también esté protegido por el protocolo de prueba de fraude. Sin embargo, casi todos los Bitcoin de Capa 2 actualmente no pueden lograr esta premisa y necesitan depender de la firma múltiple/MPC. Entonces, ¿cómo elegir la firma múltiple? Firmar la solución de MPC se ha convertido en un problema estrechamente relacionado con la seguridad de la Capa 2.

Merlin eligió el servicio MPC de Cobo para la solución del puente. Utilizando medidas como el aislamiento de billeteras calientes y frías, los activos del puente son gestionados conjuntamente por Cobo y Merlin Chain. Cualquier comportamiento de retiro debe ser manejado conjuntamente por los participantes de MPC de Cobo y Merlin Chain. Esencialmente, la fiabilidad del puente de retiro está garantizada a través del respaldo crediticio de la institución. . Por supuesto, esta es solo una medida provisional en esta etapa. A medida que el proyecto mejora gradualmente, el puente de retiro puede ser reemplazado por el “puente optimista” con una suposición de confianza de 1/N mediante la introducción de BitVM y el protocolo de prueba de fraude. Sin embargo, la implementación de esto será más difícil. Los puentes oficiales de capa 2 actuales dependen casi en su totalidad de la firma múltiple.

En general, podemos ordenarlo,Merlin introdujo DAC basado en POS, ZK-Rollup optimista basado en BitVM, y una solución de custodia de activos basada en MPC de Cobo, resolviendo el problema DA abriendo permisos DAC; asegurando la seguridad de las transiciones de estado mediante la introducción de BitVM y protocolos de prueba de fraude; asegurando la fiabilidad del puente de retiro mediante la introducción del servicio MPC de la conocida plataforma de custodia de activos Cobo.

Estrategia de presentación ZKP de verificación de dos pasos de Lumoz

En nuestras discusiones anteriores, profundizamos en el marco de seguridad de Merlin y exploramos el innovador concepto de ZK-rollups optimistas. Un elemento clave en la trayectoria tecnológica de Merlin es el Prover descentralizado. Este papel es fundamental dentro de la arquitectura ZK-Rollup, encargado de generar Pruebas ZK para lotes liberados por el Secuenciador. La creación de pruebas de conocimiento cero es notablemente intensiva en recursos, lo que supone un desafío considerable.

Una estrategia básica para acelerar la generación de pruebas ZK es dividir y paralelizar las tareas. Este proceso, conocido como paralelización, implica descomponer la generación de pruebas ZK en partes distintas. Cada parte es manejada por un Prover diferente, y finalmente, un Agregador fusiona estas pruebas individuales en un todo unificado. Este enfoque no solo acelera el proceso sino que también distribuye la carga computacional de manera efectiva.

Para acelerar el proceso de generación de la prueba ZK, Merlin adoptará la solución Prover de Lumoz como un servicio, de hecho, es reunir un gran número de dispositivos de hardware para formar un grupo de minería, y luego asignar tareas de computación a diferentes dispositivos y asignar incentivos correspondientes, lo que es algo similar a la minería POW.

En esta solución Prover descentralizada, hay un tipo de escenario de ataque, comúnmente conocido como un ataque de front-running: Supongamos que un Agregador ha establecido ZKP y envía ZKP para obtener recompensas. Después de que otros agregadores ven el contenido de ZKP, publican el mismo contenido antes que él, afirmando que él generó el ZKP primero. ¿Cómo resolver esta situación?

Quizás la solución más instintiva que todos piensan es asignar un número de tarea designado a cada Agregador. Por ejemplo, solo el Agregador A puede tomar la tarea 1, y otros no recibirán recompensas incluso si completan la tarea 1. Pero hay un problema con este enfoque, que es que no puede resistir los riesgos de un solo punto. Si el Agregador A tiene un fallo de rendimiento o está desconectado, la tarea 1 quedará atascada y no podrá completarse. Además, este método de asignar tareas a una única entidad no puede mejorar la eficiencia de producción a través de un mecanismo de incentivos competitivo, y no es un buen enfoque.

Polygon zkEVM una vez propuso un método llamado Prueba de eficiencia en un blog, que señaló que se deben usar medios competitivos para promover la competencia entre diferentes Aggregators, y los incentivos deben asignarse por orden de llegada. El Aggregator que envíe ZK-Proof a la cadena primero puede recibir recompensas. Por supuesto, no mencionó cómo resolver el problema de front-running de MEV.

Lumoz adopta un método de presentación de certificado ZK de verificación de dos pasos. Después de que un Agregador genere un certificado ZK, no necesita enviar todo el contenido primero, sino que solo publica el hash de ZKP. En otras palabras, publica el hash (ZKP + Dirección del Agregador). De esta manera, incluso si otros ven el valor hash, no conocen el contenido ZKP correspondiente y no pueden saltar directamente hacia adelante;

Si alguien simplemente copia todo el hash y lo publica primero, no tiene sentido, porque el hash contiene la dirección de un agregador específico X. Incluso si el agregador A publica el hash primero, cuando se revele la imagen original del hash, todos verán que la dirección del agregador contenida en él es la de X, no la de A.

A través de este esquema de presentación de ZKP de verificación de dos pasos, Merlin (Lumoz) puede resolver el problema de front-running existente en el proceso de presentación de ZKP, logrando así incentivos de generación de prueba de conocimiento cero altamente competitivos, aumentando la velocidad de generación de ZKP.

Merlin’s Fantasma: Interoperabilidad entre múltiples cadenas

Según la hoja de ruta tecnológica de Merlin, también admitirán la interoperabilidad entre Merlin y otras cadenas EVM, su camino de implementación es básicamente el mismo que la idea anterior de Zetachain. Si Merlin se utiliza como cadena de origen y otras cadenas EVM se utilizan como cadena de destino, cuando el nodo de Merlin percibe la solicitud de interoperabilidad entre cadenas emitida por el usuario, desencadenará el trabajo posterior en la cadena de destino.

Por ejemplo, una cuenta EOA controlada por la red Merlin puede ser implementada en Polygon, Cuando un usuario emite una instrucción de interoperabilidad entre cadenas en la Cadena de Merlin, la Red de Merlin primero analiza su contenido y genera datos de transacción para ser ejecutados en la cadena objetivo, y luego la Red Oracle realiza un procesamiento de firma MPC en la transacción para generar la firma del número de transacción. El nodo de Relayer de Merlin luego libera la transacción en Polygon, completando operaciones posteriores a través de los activos de Merlin en la cuenta EOA en la cadena objetivo, como.

Cuando se complete la operación solicitada por el usuario, los activos correspondientes se enviarán directamente a la dirección del usuario en la cadena de destino. En teoría, también se pueden transferir directamente a Gate Chain. Esta solución tiene algunos beneficios obvios: puede evitar las tarifas de gestión y el desgaste causado por los contratos de puente entre cadenas cuando los activos tradicionales cruzan las cadenas, y la seguridad de las operaciones entre cadenas está garantizada directamente por la Red de Oráculos de Gate, y no es necesario depender de partes externas. infraestructura. Si los usuarios confían en Gate Chain, se puede asumir que este comportamiento de interoperabilidad entre cadenas no tiene problemas.

Resumir

En este artículo, interpretamos brevemente la solución técnica general de Merlin Chain, que creemos permitirá que más personas comprendan el flujo de trabajo general de Merlin y tengan una comprensión más clara de su modelo de seguridad. Teniendo en cuenta que el ecosistema actual de Bitcoin está en pleno apogeo, creemos que este tipo de actividades de popularización tecnológica son valiosas y necesarias para el público en general. En el futuro, realizaremos un seguimiento a largo plazo de Merlin, bitLayer, B^Square y otros proyectos, para un análisis más profundo de sus soluciones técnicas, ¡así que manténganse atentos!

Descargo de responsabilidad:

1. Este artículo es reproducido de [Gategeek web3], the copyright belongs to the original author [Faust], if you have any objection to the reprint, please contactEquipo Gate Learn, el equipo lo gestionará lo antes posible de acuerdo con los procedimientos pertinentes.

2. Las opiniones expresadas en este artículo representan únicamente las opiniones personales del autor y no constituyen ningún consejo de inversión.

3. Otras versiones del artículo en otros idiomas son traducidas por el equipo de Gate Learn. Sin hacer referenciaGate.io, copiar, distribuir o plagiar los artículos traducidos está prohibido.