Introducción:

La actual escena de Bitcoin Layer2 está repleta de diversas soluciones tecnológicas que convergen en el crisol del ecosistema BTC. Dado el ritmo rápido de iteración en el campo de la cadena de bloques, donde el vocabulario y los estándares profesionales evolucionan continuamente a través de la investigación, la innovación y la implementación en ingeniería, muchos proyectos recurren a la 'creación de conceptos' o al 'hacer autostop en conceptos' para diferenciarse y llamar la atención, convirtiéndose en una regla no escrita dentro de la industria. Por ejemplo, varios proyectos de cadena de bloques modulares inicialmente activos dentro del ecosistema de Ethereum/Celestia se han subido al carro de 'Bitcoin Layer2', autodenominándose 'Rollups', a pesar de que a menudo sus soluciones técnicas no cumplen con los estándares de Rollup. Sin embargo, el término 'Rollup' tiene un reconocimiento significativo, lo que resulta ventajoso para fines promocionales. Muchos operadores de proyectos se etiquetan a sí mismos como Rollups de forma forzada o bifurcan el concepto principal de Rollup con calificativos vagos, como 'Sovereign Rollup'. Al descubrir las capas de estos 'XX Rollups', muchos proyectos se basan esencialmente en 'validación del lado del cliente' o 'sidechains', utilizando simplemente el eslogan 'XX Rollup' por conveniencia. Aunque esta estrategia promocional es común, tiende a ser engañosa, causando más daño que beneficio a aquellos que buscan la verdad.

(Este enfoque, resumido por el Ministro de Propaganda Nazi Goebbels como “propaganda basada en mentiras,” se observa con frecuencia entre los operadores de proyectos.) ¿Cómo podemos entonces discernir tal comportamiento de “autostop del concepto Rollup”? Quizás, comenzando con primeros principios, definiendo diferentes categorías de proyectos de Layer2 y sus niveles de seguridad y funcionalidades basados en estándares ampliamente aceptados en Occidente y en toda la industria, podría ofrecer claridad. No se trata necesariamente de la solución elegida; la clave radica en si el diseño del mecanismo del proyecto asegura la seguridad y confiabilidad de la red Layer2 y realmente potencia la mainnet de BTC.

Este artículo utilizará Chainway, un proyecto Bitcoin Layer2, como caso de estudio para analizar la naturaleza de la "validación del lado del cliente" oculta detrás de algunos eslóganes de proyectos "Rollup". Nuestro objetivo es distinguir claramente entre "Sovereign Rollup" y "validación del lado del cliente," y las diferencias significativas con respecto a los ZKRollups estándar de la industria o los OPRollups que dependen de contratos inteligentes. Esto no quiere decir que los Sovereign Rollups o las validaciones del lado del cliente sean inferiores a los ZK Rollups en seguridad y fiabilidad; todo depende de los detalles específicos de su implementación. Chainway, que suele ser una validación del lado del cliente Layer2, ha propuesto un esquema de transacción contra la censura desencadenado en BTC con validación fuera de la cadena, empleando Pruebas ZK recursivas similares a las utilizadas por la cadena pública MINA, lo que la sitúa por delante de muchos proyectos Bitcoin Layer2. Creemos que investigar la tecnología de Chainway es valioso, ofreciendo ideas significativas para los observadores de Bitcoin Layer2. (Las imágenes promocionales de Chainway lo posicionan como un ZK Rollup, pero su solución antigua era validación del lado del cliente, siendo ZKR otro proyecto suyo. Actualmente, no ha logrado un consenso del cliente fuera de la cadena o un intercambio de mensajes fiable).

Texto principal: Chainway es un proyecto bien conocido de Bitcoin Layer2 en la comunidad occidental, a menudo referido como un "ZK Rollup" por muchos KOLs, mientras que su documentación técnica lo posiciona como un "Sovereign Rollup". Recientemente, Chainway también anunció su nuevo proyecto, Citrea, afirmando que se trata de un ZK Rollup basado en BitVM. Sin embargo, dado que Citrea aún no ha detallado su solución de verificación ZK basada en BitVM, este artículo se centrará en la interpretación técnica de las soluciones anteriores de Chainway. En resumen, la solución técnica públicamente divulgada de Chainway implica publicar datos de DA a través del protocolo Ordinals, utilizando BTC como su capa DA, y publicar detalles de cambio de estado (diferencia de estado) + ZK Proof verificando la corrección de los cambios de estado en Layer1, equivalente a publicar datos de transacción completos y verificables. Sin embargo, debido a que Layer1 no verifica directamente las Pruebas ZK, con la verificación realizada por clientes/nodos independientes fuera de la cadena, y el código base actual de Chainway no ha logrado consenso entre los clientes fuera de la cadena, ni ha afirmado resolver este problema en las redes sociales, la solución técnica públicamente divulgada de Chainway pertenece esencialmente a la categoría de "validación del lado del cliente", incluso se asemeja a un protocolo indexado criptográficamente que admite el puenteo de activos. Las siguientes secciones presentarán la implementación técnica específica de Chainway y analizarán su modelo de seguridad.

Qué es un Sovereign Rollup: Publicación de la capa de disponibilidad de datos (DA) + Verificación fuera de la cadena

En la documentación técnica de Chainway, se utiliza el concepto de un Sovereign Rollup de Celestia. Un Sovereign Rollup es fundamentalmente diferente del concepto de Rollup convencional dentro de la comunidad de Ethereum y la industria en general (Rollup de contratos inteligentes). Entonces, ¿cuál es exactamente la estructura de un Sovereign Rollup?

En esencia, un Rollup soberano basado en Bitcoin es algo así como un "grupo de clientes fuera de la cadena / publicación de una cadena lateral de DA en la cadena de bloques BTC." Su característica principal es que no requiere contratos inteligentes en la Capa 1 para verificar transiciones de estado / acciones entre cadenas para la Capa 2. Básicamente, utiliza BTC como la capa de DA, y su modelo de seguridad es en gran medida similar a la "validación del lado del cliente". Por supuesto, algunas soluciones de Rollup soberano más seguras dependen de una capa de liquidación de terceros fuera de la cadena de Bitcoin (similar a una cadena lateral) para realizar verificaciones de transiciones de estado. Además, entre diferentes clientes/nodos completos independientes, existe un nivel de consenso o paso de mensajes confiable para llegar a un "acuerdo" sobre ciertas acciones conflictivas. Sin embargo, algunos proyectos de Rollup soberano se basan puramente en la "validación del lado del cliente", careciendo de cualquier paso de mensajes confiable entre clientes/nodos independientes.

Para comprender mejor el concepto único de "Sovereign Rollup", es útil compararlo con su homólogo, el smart contract Rollup. En Ethereum, las soluciones de Capa 2 son predominantemente smart contract Rollups, como Arbitrum y StarkNet. La estructura de un smart contract Rollup se puede visualizar en el siguiente diagrama:

(Imagine un diagrama aquí)

En el diagrama, podemos ver varios términos relacionados con la narrativa modular de la cadena de bloques, explicados de la siguiente manera:

• Capa de ejecución: Ejecuta las transacciones de los usuarios, actualiza el estado de la cadena de bloques y envía los datos a la capa DA y a la capa de liquidación.

• Capa de Liquidación: Verifica las transiciones de estado desde la capa de ejecución, resuelve disputas (como pruebas de fraude) y proporciona un módulo de puente para manejar activos de puente L1-L2.

• Capa de Disponibilidad de Datos (DA): Actúa como un gran tablón de anuncios, recibiendo datos de transición de estado enviados por la capa de ejecución y proporcionando estos datos de manera confiable a cualquier persona.

• Capa de Consenso: Garantiza la finalidad del orden de las transacciones. Su función parece ser algo cercana a la de la capa DA (el enfoque de la comunidad de Ethereum para la estratificación modular de blockchain no incluye una capa de consenso).
  
  Desde la arquitectura de los Rollups de contratos inteligentes, vemos que Ethereum asume el papel de las últimas tres capas, además de la capa de ejecución. Otro diagrama podría ofrecer una vista más detallada de los roles que Ethereum desempeña en los Rollups de contratos inteligentes.
  
  Por el contrario, los Sovereign Rollups difieren significativamente en que descentralizan algunas de estas responsabilidades lejos de una cadena de bloques monolítica como Ethereum. Específicamente, no se basan en contratos inteligentes en la capa base (Capa 1) para verificar las transiciones de estado o manejar disputas. En cambio, estas tareas son gestionadas por clientes fuera de la cadena o a través de una capa de liquidación de terceros, lo que hace hincapié en un enfoque diferente para lograr la escalabilidad y la seguridad en los sistemas blockchain.

Los contratos Rollup en Ethereum reciben pruebas de validez o pruebas de fraude para verificar la validez de las transiciones de estado de Capa 2. Vale la pena mencionar que los contratos inteligentes Rollup actúan como entidades de capa de liquidación en la arquitectura modular de la cadena de bloques. Los contratos de capa de liquidación a menudo incluyen módulos de puente para manejar activos puenteados desde Ethereum a la Capa 2. Para la Disponibilidad de Datos (DA), los contratos de capa de liquidación pueden obligar al Secuenciador a publicar los últimos datos de transacciones / detalles de cambios de estado en la cadena. Sin publicar DA en la cadena, es imposible actualizar con éxito el estado L2 registrado en los contratos Rollup.

(ZK Rollup o Optimistic Rollup puede hacer cumplir que los datos de DA se publiquen en cadena; sin ello, el estado registrado en la capa de liquidación no se puede actualizar.) Al analizar el modelo de seguridad e indicadores de riesgo de las soluciones de Capa 2 de Bitcoin/Ethereum con la teoría del barril, queda claro que los Rollups de contratos inteligentes dependen en gran medida de los contratos inteligentes de Capa 1. Para una Capa 1 como BTC, que lucha por soportar lógica empresarial compleja, construir una Capa 2 que se alinee con los Rollups de Ethereum es esencialmente imposible. Por otro lado, las soluciones de Sovereign Rollup no requieren contratos en la Capa 1 para la verificación/puente de estado. Su arquitectura es la siguiente: (Aquí falta la descripción de la arquitectura, lo que implica que se pretendía incluir una ilustración o más detalles pero no se proporcionan en el texto.)

En los Rollups soberanos, los nodos fuera de la capa de Disponibilidad de Datos (DA) actúan como las entidades para la ejecución de transacciones y operaciones de liquidación, ofreciendo un mayor grado de libertad. El flujo de trabajo es el siguiente:

Los nodos de la capa de ejecución del Rollup soberano envían los datos de la transacción/detalles de cambio de estado a la capa DA, mientras que la capa de liquidación/clientes se esfuerzan por obtener y verificar los datos. Es importante tener en cuenta que, dado que el módulo de capa de asentamiento no se encuentra en la Capa 1, los Rollups soberanos, en teoría, no pueden lograr puentes con una seguridad equivalente a la Capa 1. A menudo confían en puentes notariales o soluciones puente de terceros. Actualmente, la implementación de esquemas soberanos de Rollup/verificación de clientes es relativamente simple, requiriendo solo la publicación de datos sobre la cadena Bitcoin (BTC) utilizando un protocolo similar a Ordinals. En cuanto a la verificación y el consenso fuera de la cadena, existe una gran flexibilidad. De hecho, muchas cadenas laterales simplemente publican datos de DA en la cadena BTC, convirtiéndose esencialmente en "Rollups soberanos basados en BTC", aunque la seguridad específica es cuestionable. Sin embargo, el problema es que el rendimiento de datos de Bitcoin es extremadamente bajo, con un máximo de 4 MB por bloque y un tiempo medio de bloque de 10 minutos, lo que se traduce en un rendimiento de datos de sólo 6 KB/s. Es posible que las soluciones de capa 2 que afirman ser Rollups soberanos no puedan publicar todos los datos de DA en la cadena de BTC, por lo que pueden optar por métodos alternativos, como publicar datos de DA fuera de la cadena y almacenar el hash de datos en la cadena de BTC como una forma de "compromiso", o encontrar una manera de comprimir en gran medida los datos de DA (p. ej., usando State diff + ZK Proof como afirma Chainway). Claramente, este modo no se ajusta a la definición de "Rollup soberano" o a un Rollup propiamente dicho, representando una variante cuya seguridad es cuestionable. Predecimos que la mayoría de los proyectos de capa 2 que llevan el banner "Rollup" finalmente no publicarán todos los datos de DA en la cadena BTC, por lo que es probable que sus soluciones prácticas no coincidan con las afirmaciones de "ZK Rollup" u "OP Rollup" hechas en sus documentos técnicos.

Finalmente, vamos a resumir brevemente las diferencias entre Rollups soberanos y Rollups de contratos inteligentes:

1. Capacidad de actualización:Las iteraciones de actualización de los contratos inteligentes Rollups implican actualizar los contratos inteligentes, lo que requiere que el equipo de desarrollo utilice contratos actualizables. Este tipo de autoridad de actualización del contrato inteligente suele ser controlada por el equipo de desarrollo de Rollup a través de firmas múltiples. En contraste, las reglas de actualización para los Rollups soberanos son similares a las bifurcaciones suaves y duras de las blockchains convencionales, donde los nodos pueden optar por actualizar las versiones de forma independiente, y los diferentes clientes pueden elegir si aceptar la actualización. Desde esta perspectiva, los Rollups soberanos son superiores a los Rollups de contratos inteligentes en cuanto a capacidad de actualización.

2. Puentes:En condiciones ideales, los puentes para Rollups de contratos inteligentes se adhieren a una confianza mínima, pero la capacidad de actualización de los contratos puede afectar su seguridad. Bajo el esquema de Rollup soberano, los desarrolladores necesitan construir componentes de puente bajo la propia cadena de Capa 1, y es probable que los puentes construidos confíen menos que los puentes de contratos inteligentes.

Estructura DA de BTC

En el texto anterior, mencionamos que para implementar un Rollup soberano basado en BTC, la clave radica en utilizar el protocolo Ordinals para hacer que BTC sirva como capa de Disponibilidad de Datos (DA). Chainway ha adoptado esta solución.

Podemos examinar una presentación de datos de DA del secuenciador de Chainway, con el hash de transacción siendo:

24add7cdcbffcda8d43509c8e27c5a72f4d39df1731be84bdba727cd83ae0000, ilustrado como sigue:

Este script de transacción toma prestado el enfoque del Protocolo de Ordinales de usar OP_0 OP_IF para la escritura de datos para escribir los datos de Disponibilidad de Datos (DA) de Rollup en la cadena BTC. Esto implica publicar cambios de estado y Pruebas de Conocimiento Cero (ZK), lo que es equivalente en seguridad a publicar los datos de transacción originales pero permite una reducción significativa del tamaño de los datos. Además de los datos de DA, el secuenciador también escribe algunos datos de autenticación en la transacción, siendo el más crucial la firma del secuenciador de Rollup de los datos de DA con su clave privada para garantizar que la presentación provenga del secuenciador. Es importante tener en cuenta que cualquier transacción que implique la presentación de datos de DA tiene 16 ceros binarios al final del hash de la transacción (es decir, dos bytes consecutivos son cero). Esta restricción se puede ver en el código:

En el gráfico de transacción de ejemplo mencionado anteriormente, el número aleatorio "b715" se utiliza para ajustar el valor hash de la transacción de modo que su cola lleve 16 ceros específicos. Este principio es similar a la minería de Bitcoin, donde se agrega un número aleatorio nonce para hacer que los N bits iniciales del hash sean ceros, cumpliendo con condiciones de restricción específicas. Este diseño tiene como objetivo simplificar la dificultad de obtener datos de DA (disponibilidad de datos). Cuando cualquier nodo de capa 2 quiere acceder a los datos de DA, solo necesita escanear el bloque BTC (Bitcoin) para todas las transacciones configuradas para terminar con 16 ceros, distinguiendo efectivamente las transacciones iniciadas por el clasificador de Chainway al enviar datos de otras transacciones en la cadena de bloques de Bitcoin. En el siguiente texto, las transacciones que contienen datos de DA y cumplen con el requisito de terminar con 16 ceros se denominan "transacciones estándar de Chainway". El enfoque de este artículo está en cómo Chainway logra la resistencia a la censura. Dado que un clasificador de capa 2 puede rechazar deliberadamente una solicitud de transacción de un usuario específico, se debe emplear un esquema especial para permitir que los usuarios inicien transacciones que resistan la censura. En respuesta a este problema, Chainway permite a los usuarios iniciar "Transacciones forzadas". Una vez que un usuario envía esta declaración de transacción dentro de un bloque BTC, el clasificador de Chainway debe procesar esta solicitud de transacción en la capa 2; De lo contrario, no podrá producir normalmente un bloque, o el bloque producido no será reconocido por los clientes fuera de la cadena. La estructura de parámetros de la transacción forzada es la siguiente:

Esta transacción se enviará a la cadena de bloques de Bitcoin como una "Transacción de Especificación de Chainway," con el hash de transacción que termina en 16 ceros. El clasificador ChainWay, al generar bloques L2, debe incluir "Transacciones de Especificación de Capa2" que se hayan revelado en la cadena de bloques BTC pero aún no se hayan registrado en el libro mayor L2, y agregarlas en un Árbol de Merkle, escribiendo su raíz de Merkle en el encabezado del bloque L2. Una vez que un usuario inicia una transacción forzosa directamente en la cadena de bloques BTC, el clasificador debe procesarla; de lo contrario, no puede generar el siguiente bloque válido. El cliente Chainway fuera de la cadena BTC puede verificar primero la prueba ZK para determinar la validez del bloque L2 enviado por el clasificador, verificar la raíz de Merkle del encabezado del bloque L2 y juzgar si el clasificador ha incluido verazmente la solicitud de transacción forzosa. El flujo de trabajo se puede consultar en el siguiente diagrama de flujo. Tenga en cuenta que, debido a limitaciones de espacio, el diagrama a continuación no incluye una condición de juicio en verify_relevant_tx_list:

En resumen, el cliente/nodo de Chainway se sincroniza con los bloques de la red principal de BTC y busca "datos DA" publicados por el clasificador de Chainway a partir de ellos. Verifica que estos datos sean publicados por el clasificador designado y, de hecho, contengan todas las "transacciones estándar de Chainway" enviadas a la cadena BTC. Es evidente que mientras los usuarios puedan construir una transacción que cumpla con los criterios especificados como una "transacción estándar" y enviarla a la cadena BTC, esta transacción eventualmente se incluirá en el libro mayor L2 local del cliente de Chainway. De lo contrario, el cliente rechazará el bloque L2 liberado por el clasificador de Chainway. Si se combina con una transmisión confiable de mensajes de alerta / consenso fuera de la cadena, el esquema de transacciones anticensura de Chainway se acerca al método anticensura ideal de Rollups soberanos. Por ejemplo, algunas soluciones Rollup soberanas han declarado explícitamente que, en caso de un bloqueo no válido, los mensajes de advertencia de alerta se transmitirían entre los clientes fuera de la cadena para mejorar la seguridad, especialmente para informar a los clientes ligeros que no pueden sincronizar los datos completos de DA sobre las anomalías de la red. Si un bloque no incluye verazmente "transacciones obligatorias", obviamente activará una transmisión de alerta fuera de la cadena. Sin embargo, Chainway aún no ha implementado este aspecto (al menos los materiales y repositorios de código publicados actualmente muestran que no ha emprendido la implementación técnica de esta parte).

Material de referencia: Los investigadores de Celestia analizan 6 tipos de variantes de Rollup: Secuenciador = Agregador + Generador de encabezados. Incluso con el consenso alcanzado entre los clientes/nodos fuera de la cadena, la eficacia anticensura de las "transacciones forzadas" de Chainway no es tan robusta como la de los Rollups de contratos inteligentes como Arbitrum, porque Arbitrum One acabará garantizando que las "transacciones forzadas" se incluyan en el libro mayor de la Capa 2 a través de contratos en la Capa 1, heredando plenamente las propiedades anticensura de la Capa 1. Está claro que los Rollups soberanos no pueden igualar a los Rollups de contratos inteligentes en este aspecto, ya que su eficacia contra la censura depende en última instancia de los componentes fuera de la cadena. Esto también determina que el enfoque de los esquemas de "Sovereign Rollups" y "verificación de clientes" fundamentalmente no puede heredar las propiedades anticensura de Layer1 en su totalidad, como Arbitrum One, Loopring, dydx y Degate, porque si las transacciones forzadas se pueden incluir sin problemas en el libro mayor de Layer2 depende de las decisiones de las entidades fuera de la cadena de Layer2, no relacionadas con la propia Layer1. Evidentemente, el enfoque de Chainway, que se basa únicamente en la discreción de los clientes fuera de la cadena, solo hereda la confiabilidad de DA de Layer 1, no sus propiedades anticensura completas. Similar a las pruebas ZK recursivas de MINA.

En esta sección, presentaremos otros componentes de Gate.io, que, además de utilizar BTC como la capa DA, también implementaron pruebas ZK recursivas similares a MINA. Su estructura general se ilustra en el siguiente diagrama:

El clasificador de la red Chainway, después de procesar las transacciones de los usuarios, genera la prueba final de ZK (Zero-Knowledge) junto con los detalles de los cambios de estado (diferencia de estado) para diferentes cuentas y los publica en la cadena de bloques de Bitcoin (BTC). Los nodos completos sincronizarán todos los datos históricos de Chainway publicados en la cadena de bloques de BTC. Cada prueba de ZK no solo tiene que demostrar el proceso de transición de estado del bloque actual, sino que también debe garantizar la validez de la prueba de ZK del bloque anterior. Basándonos en este esquema, podemos ver que cada vez que se genera una nueva prueba, esencialmente confirma la prueba anterior de manera recursiva, y la última prueba de ZK puede garantizar la validez de todas las pruebas de ZK a partir del bloque génesis. Este diseño es similar al de MINA. Cuando un "cliente ligero" que solo sincroniza encabezados de bloque, también conocido como nodo ligero, se une a la red, solo necesita verificar la validez de la última prueba ZK divulgada en la cadena de bloques BTC para confirmar que los datos históricos de toda la cadena y todas las transiciones de estado son válidas. Si el clasificador actúa de forma maliciosa, negándose intencionadamente a aceptar transacciones obligatorias o no utilizando la prueba de ZK anterior para la prueba recursiva, el cliente no puede aceptar la prueba de ZK recién generada (incluso si se genera, no se reconoce), como se muestra en el siguiente diagrama:

Resumen

Como se resume al principio de este artículo, Chainway es fundamentalmente un esquema de verificación de Rollup/cliente soberano que utiliza BTC como su capa de Disponibilidad de Datos (DA). Para mejorar la resistencia a la censura del Rollup, Chainway introduce el concepto de transacciones forzadas. Por otro lado, Chainway emplea la tecnología de prueba ZK recursiva, lo que permite a los nuevos nodos confiar más en la salida del secuenciador y verificar la precisión de los datos históricos de toda la cadena en cualquier momento. El problema actual con Chainway radica en el mecanismo de confianza de su puente cruzado. Dado que adopta un enfoque de Rollup soberano sin detallar cómo planea abordar aspectos técnicos en su solución de puente cruzado, es difícil juzgar su seguridad final.

Hoy, al profundizar en la solución técnica de Chainway, descubrimos que el tipo de tecnología promovida por la comunidad del proyecto no es un Rollup en el sentido mainstream. Teniendo en cuenta que ya hay docenas de proyectos de Bitcoin Layer2 (que podrían llegar a cientos en medio año), para reducir el costo cognitivo de la terminología técnica, continuaremos realizando investigaciones en profundidad sobre la clasificación de las soluciones y estándares de Layer2 para la seguridad, la integridad de la funcionalidad y la evaluación. ¡Manténgase atento!

Descargo de responsabilidad:

1. Este artículo ha sido reimpreso de [ Web3 Geek]. Todos los derechos de autor pertenecen al autor original [Shew & Faust, web3 de los geeks]. If there are objections to this reprint, please contact the Gate Learnequipo y lo resolverán rápidamente.
2. Responsabilidad de descargo: Las vistas y opiniones expresadas en este artículo son únicamente las del autor y no constituyen ningún consejo de inversión.
3. Las traducciones del artículo a otros idiomas son realizadas por el equipo de Gate Learn. A menos que se mencione, está prohibido copiar, distribuir o plagiar los artículos traducidos.