Uso de la teoría del barril para desmantelar los modelos de seguridad e indicadores de riesgo de capa 2 de Bitcoin y Ethereum

Una Capa 2 que pueda implementar un sistema de verificación de prueba de fraude/validez en la Capa 1 siempre será mucho mejor que un simple modelo de “verificación del cliente”.

Escrito por: Fausto y Wuyue, geek web3

Asesor: Kevin He (@0xKevinHe), vicepresidente de tecnología Xinhuo

Introducción: El científico de gestión estadounidense Lawrence Peter propuso una vez la “teoría del barril”, que cree que el rendimiento general de un sistema está limitado por su parte más débil. En otras palabras, la cantidad de agua que puede contener un barril está determinada por su tabla más corta. Aunque este principio es simple, a menudo se pasa por alto. **Los debates anteriores sobre la seguridad de la Capa 2 ignoraron en su mayoría la prioridad y la importancia de los diferentes componentes. Básicamente se centraron en la confiabilidad de la transición de estado y las cuestiones de DA, pero ignoraron los elementos de nivel inferior y más importantes. De esta manera, toda la base teórica probablemente ni siquiera sostenible. Por lo tanto, cuando analizamos un sistema complejo de múltiples módulos, primero debemos descubrir qué pieza es la “placa más corta”.

Inspirándonos en la teoría del barril, hicimos un análisis del sistema y descubrimos que existen dependencias obvias entre los diferentes componentes del modelo de seguridad de capa 2 de Bitcoin/Ethereum, o que algunos componentes son más seguros que otros. El sexo es más básico e importante, por lo que -llamado “más corto”.

En este sentido, inicialmente podemos priorizar la importancia/base de los diferentes componentes en el modelo de seguridad principal de Layer2 de la siguiente manera:**

1. Si la autoridad de control del contrato/puente oficial está razonablemente dispersa (¿qué tan concentrada está la autoridad de control de firmas múltiples)?
2. ¿Existe una función de retirada resistente a la censura (retirada forzada, trampilla de escape)?
3. Si la capa DA/el formulario de publicación de datos es confiable (si los datos DA se publican en Bitcoin o Ethereum)
4. Si se ha implementado un sistema confiable a prueba de fraude/validez en la Capa 1 (Bitcoin L2 requiere BitVM)

Deberíamos absorber moderadamente los resultados de la investigación de la Capa 2 de la comunidad Ethereum y evitar el lysenkoísmo

En comparación con el altamente ordenado sistema Ethereum Layer 2, Bitcoin Layer 2 es como un mundo completamente nuevo. Este nuevo concepto, que se ha vuelto cada vez más importante después de la locura de las inscripciones, está mostrando un impulso creciente, pero su ecosistema se está volviendo cada vez más caótico y caótico. En medio del caos, varios proyectos de Capa 2 surgieron como hongos después de una lluvia. Si bien traen esperanza al ecosistema de Bitcoin, ocultan deliberadamente sus propios riesgos de seguridad. Algunas personas incluso amenazaron con “negar la capa 2 de Ethereum y seguir el camino único del ecosistema de Bitcoin”. Tienen una fuerte tendencia a tomar una ruta extremista.

Teniendo en cuenta las diferencias en los atributos funcionales entre Bitcoin y Ethereum, ** La capa 2 de Bitcoin está destinada a no poder alinearse con la capa 2 de Ethereum en los primeros días, pero esto no significa que debamos negar por completo que Ethereum e incluso la industria de la cadena de bloques modular. Hace tiempo que la industria tiene sentido común** para llegar a una conclusión final (consulte el “incidente de Lysenko” en el que el ex biólogo soviético Lysenko utilizó cuestiones ideológicas para perseguir a los partidarios de la genética occidental).

Por el contrario, estos estándares de evaluación, que fueron obtenidos por los “predecesores” con grandes esfuerzos, ya han demostrado una gran capacidad de persuasión después de ser ampliamente reconocidos. Definitivamente no es una medida racional negar deliberadamente el valor de estos logros. **

**Al construir la Capa 2 de Bitcoin, debemos comprender plenamente la importancia de “aprender de Occidente y aplicarlo en Oriente” y absorber y optimizar adecuadamente las numerosas conclusiones de la comunidad Ethereum. Pero al aprovechar perspectivas fuera del ecosistema de Bitcoin, debemos ser conscientes de las diferencias en sus puntos de partida y, en última instancia, buscar puntos en común reservando las diferencias. **

Esto es como discutir las similitudes y diferencias entre “occidentales” y “orientales”. Independientemente de si es occidental u oriental, el sufijo “人” expresa muchas características similares, pero cuando corresponde a diferentes prefijos como “occidental” y “oriental”, las características de subdivisión serán diferentes.

Pero en el análisis final, seguramente habrá una superposición entre “occidentales” y “orientales”, lo que significa que muchas cosas que se aplican a los occidentales también son aplicables a los orientales, y muchas cosas que se aplican a la “Capa 2 de Ethereum” también se aplica a “Bitcoin Layer2”. **Antes de distinguir las diferencias entre Bitcoin L2 y Ethereum L2, puede ser más importante y significativo aclarar la interoperabilidad entre los dos.

Siguiendo el propósito de “buscar puntos en común reservando las diferencias”, el autor de este artículo no tiene la intención de discutir “qué es Bitcoin Layer 2 y qué no”, ** porque este tema es demasiado controvertido, incluso la comunidad Ethereum tiene No se discute “qué es Ethereum Layer 2”, cuáles no son Layer 2” y se llega a una visión objetiva y consistente.

**Pero lo cierto es que si bien diferentes soluciones técnicas traen efectos de expansión a Bitcoin, también tienen diferentes riesgos de seguridad. Los supuestos de confianza existentes en sus modelos de seguridad serán el tema en el que pretende centrarse este artículo. **

Cómo entender los criterios de seguridad y evaluación de Layer2

De hecho, la seguridad de la Capa 2 no es un tema de discusión nuevo. Incluso la palabra seguridad es un concepto compuesto que incluye múltiples atributos subdivididos.

Anteriormente, el fundador de **EigenLayer simplemente había subdividido la “seguridad” en cuatro elementos que incluyen “irreversibilidad de las transacciones (anti-reversión), resistencia a la censura, confiabilidad de la publicación de datos/DA y validez de la transición de estado”. **

(El fundador de EigenLayer expresó una vez sus puntos de vista sobre cómo el esquema de verificación del lado del cliente/acumulación soberana puede heredar la seguridad de la red principal de Bitcoin)

L2BEAT y Ethereum Community OG han propuesto un modelo relativamente sistemático de evaluación de riesgos de Capa 2. Por supuesto, estas conclusiones están dirigidas a la Capa 2 de contrato inteligente, en lugar de la Capa 2 de contrato no inteligente típica, como la acumulación soberana y la verificación del cliente.

**Aunque esto no es 100% adecuado para Bitcoin L2, todavía contiene muchas conclusiones dignas de reconocimiento. La mayoría de sus puntos de vista han sido ampliamente reconocidos en la comunidad occidental, ** y también facilita nuestra evaluación objetiva de los riesgos de diferentes Bitcoin. L2.

(Vitalik dijo una vez que debido a que la solución Rollup no puede alcanzar la perfección teórica en su lanzamiento inicial, debe utilizar algunos medios auxiliares para mejorar la seguridad, y estos medios auxiliares se denominan “ruedas de entrenamiento” e introducirán suposiciones de confianza. Estas suposiciones de confianza son riesgos )

Entonces, ¿de dónde vienen los riesgos para la seguridad? Considerando la situación actual, ya sea Ethereum Layer 2 o Bitcoin Layer 2, muchos de ellos dependen de nodos centralizados para actuar como secuenciadores, o de un pequeño número de nodos que forman un “comité” en forma de cadena lateral. estar centralizado. Si el secuenciador/comité no está restringido, puede robar los activos del usuario y huir en cualquier momento. Puede rechazar las solicitudes de transacción de los usuarios, provocando que los activos queden congelados y sean inutilizables. **Esto implica la efectividad de la transición estatal y la resistencia a la censura mencionada anteriormente por el fundador de EigenLayer. **

Al mismo tiempo, dado que Ethereum Layer2 se basa en contratos en la cadena ETH para la verificación de la transición de estado y la verificación del comportamiento de depósito y retiro, si el controlador del contrato (en realidad el Layer2 oficial) puede actualizar rápidamente la lógica del contrato, agregar segmentos de código malicioso (por ejemplo (Al permitir que una dirección específica transfiera todos los tokens bloqueados en el contrato de depósito y retiro L1-L2), puede robar directamente los activos bajo custodia.

** Esto se atribuye al “problema de distribución de firmas múltiples del contrato”, y el problema de distribución de firmas múltiples también se aplica a la Capa 2 de Bitcoin, ** porque la Capa 2 de Bitcoin a menudo depende del “Puente de Notario” y requiere múltiples nodos para liberarse. A través de solicitudes de cadena cruzada de firmas múltiples, por lo que Bitcoin Layer 2 también tiene el problema de cómo distribuir razonablemente firmas múltiples, incluso podemos considerarlo como la “rueda auxiliar” más básica de Bitcoin Layer 2. **

**Además, la cuestión del DA es extremadamente importante. **Si Layer2 no carga datos en Layer1, pero elige algunos lugares de publicación de DA no confiables, si esta capa de DA fuera de la cadena (comúnmente conocida como Comité de Disponibilidad de Datos de DAC) se confabula y se niega a publicar los datos de transacciones más recientes al mundo exterior, Los ataques de retención de datos harán que la red se vuelva obsoleta y pueden impedir que los usuarios retiren fondos sin problemas.

L2BEAT resumió los problemas anteriores y resumió varios elementos centrales en el modelo de seguridad Layer2:

1. Validación del estado/Demostrar si el sistema es confiable (Validación del estado)
2. ¿Es confiable el método de publicación de datos de DA? (Disponibilidad de datos)
3. Si la red Layer2 rechaza deliberadamente su transacción/se cierra, ¿puede forzar que los activos se retiren de Layer2 (falla del secuenciador, falla del proponente)?
4. Contratos relacionados con Layer2: si el control del puente oficial entre cadenas está suficientemente descentralizado. Si la energía está relativamente concentrada, ¿los usuarios tendrán tiempo suficiente para responder cuando ocurra un “robo de vigilancia” (Ventana de salida)?

(“Visualización del factor de riesgo” configurada para diferentes proyectos Layer2 en L2BEAT)

De todos modos, cuando analizamos los riesgos de seguridad de la Capa 2, en realidad estamos discutiendo cuántos escenarios existen en la red de la Capa 2 que pueden causar daños a los activos del usuario y si el sistema de la Capa 2 puede restringir efectivamente estas situaciones peligrosas a través del diseño del mecanismo. ** Si ciertos comportamientos maliciosos no se pueden eliminar, ¿cuánta “confianza” debemos introducir, en cuántas personas de un grupo debemos confiar y en cuántas “ruedas auxiliares” debemos confiar?

A continuación analizaremos los factores de riesgo en el modelo general Ethereum Layer2/Bitcoin Layer2** (Los objetos mencionados en este artículo no incluyen “canal estatal” ni “canal de pago”, ni incluye el protocolo de índice de inscripción, porque son especial). **Y trataremos de explorar qué factores son más básicos, de menor nivel y más importantes en el modelo de seguridad de Capa 2. Estas deficiencias más básicas serán riesgos de confianza que merecen nuestra atención más que otras deficiencias.

El efecto barril de Layer2: ¿cuáles son sus deficiencias?

La tabla más corta: contrato/derechos oficiales de gestión de puentes

Aquí, también podríamos usar el “efecto barril” para analizar los problemas de seguridad de la Capa 2. Es fácil ver que la tabla más corta es la “capacidad de actualización del contrato” mencionada anteriormente (principalmente para la Capa 2 de Ethereum), o Además, es la “derecho de gestión del puente oficial entre cadenas” (aplicable tanto a Bitcoin como a Ethereum Layer 2). **

Para Ethereum Layer 2, siempre que el funcionario de Layer 2 pueda actualizar rápidamente el contrato en la cadena de Layer 1, el token bloqueado en la dirección de depósito y retiro del puente oficial L2 puede, en teoría, ser robado, sin importar cuán confiable sea su capa DA o su sistema de certificación. es.

Se puede decir que la autoridad de control del contrato puente está relacionada con la seguridad de todo el sistema, es la parte más básica y crítica de toda la Capa 2 e incluso de la pila modular de blockchain. ** Si el componente/contrato del puente se puede actualizar e iterar bajo el control de firmas múltiples, entonces debemos introducir aquí una “suposición de confianza”, suponiendo que el controlador del contrato/puente oficial de Capa 2 no hará el mal. **

(Los retrasos en la actualización del contrato de diferentes proyectos Layer2 están marcados en L2BEAT. La mayoría de los contratos L2 pueden ser actualizados inmediatamente por el controlador. Si el controlador del contrato quiere robar activos, o su clave privada es robada por un pirata informático, los activos del usuario alojados por L2 definitivamente sufrirá)

A diferencia de la Capa 2 de Ethereum, el puente de la Capa 2 de Bitcoin básicamente no está controlado por el contrato de la Capa 1, porque Bitcoin originalmente no admite contratos inteligentes. En términos relativos, todo el flujo de trabajo de Ethereum Layer2 depende en gran medida del contrato de Layer1, mientras que Bitcoin Layer2 no puede hacer esto.

(Esquema de Starknet)

**Este es un problema inevitable para Bitcoin Layer 2. Se puede decir que tiene ventajas y desventajas. En la actualidad, parece que el “puente sin confianza” implementado por Ethereum Layer 2 basándose en contratos no se puede implementar en Bitcoin L2. ** Este “puente sin confianza” requiere el despliegue de un contrato dedicado en Layer1 y la cooperación del sistema a prueba de fraude DA+/ZK. Es esencialmente similar al “puente optimista” como Orbiter o puentes ZK como Polyhedra.

La opinión generalizada actual en la industria es que si no se consideran posibles errores en la práctica y solo se consideran los modelos teóricos, el nivel de seguridad de Optimistic Bridge y ZK Bridge es básicamente el nivel más alto, siempre que el código del contrato no contenga errores o no se puede actualizar maliciosamente, básicamente no es confiable.

(El Puente Optimista solo necesita garantizar que 1 de cada N observadores sea honesto para garantizar la seguridad. El modelo de confianza es 1/N)

Dado que Bitcoin Layer 2 no puede implementar componentes de contrato en Layer 1 (aquí no estamos hablando de Lightning Network), sus puentes oficiales son básicamente “** Notary Bridges” compuestos por una pequeña cantidad de nodos, o “Multi-Signature Bridges”. Este tipo de puente La seguridad depende de cómo se establezcan las firmas de firmas múltiples/umbrales, lo que requiere la introducción de supuestos de confianza sólidos: se supone que estos notarios no se confabularán ni les robarán sus claves privadas. **

En la actualidad, la mayoría de los puentes basados en firmas de notario/umbral no se pueden comparar con el “puente sin confianza” oficial de Ethereum Layer 2 en términos de seguridad (la premisa es que el contrato de Ethereum Layer 2 no se actualizará maliciosamente). Obviamente, la seguridad de los activos de la custodia de la red ** Bitcoin Layer 2 estará limitada por la seguridad de su puente oficial o por la descentralización del poder del puente de firmas múltiples, que es su primera “rueda auxiliar”. **

Dado que los “derechos de actualización” de los contratos oficiales relacionados con el puente de Ethereum Layer 2 a menudo se concentran en manos de unos pocos controladores de firmas múltiples, ** si los controladores de firmas múltiples se confabulan, el puente de Ethereum Layer 2 también tendrá problemas, a menos que it El contrato no se puede actualizar o está sujeto a un gran retraso** (actualmente solo Degate y Fuel V1).

(Cada vez que se actualice el contrato de Degate, se reservará un período de escape seguro de 30 días para los usuarios. Durante este período, siempre que todos descubran que la nueva versión del código del contrato tiene una lógica maliciosa, pueden escapar de forma segura mediante el retiro forzado. /función de cabina de escape)

En cuanto a la parte del “puente oficial”, **Los modelos de confianza de Ethereum Layer 2 y Bitcoin Layer 2 son básicamente los mismos: los controladores que necesitan confiar en la firma múltiple no se confabularán para hacer el mal. **Este grupo de multi-firmas las firmas pueden controlar el puente oficial L2 o cambiarlo. La lógica del código es liberar directamente las solicitudes de retiro no válidas y el resultado final es: los activos del usuario pueden ser robados.

La única diferencia entre los dos es que El puente oficial de Ethereum Layer 2 no es confiable siempre que el contrato no se actualice maliciosamente/la ventana de actualización sea lo suficientemente larga, pero Bitcoin Layer 2 no puede lograr este efecto de todos modos.

La segunda tabla más corta: retirada forzada resistente a la censura

Si asumimos que la cuestión de los contratos de firmas múltiples/control de puentes oficiales mencionada anteriormente puede ignorarse, es decir, que no hay ningún problema con esta capa, entonces la siguiente capa más importante debe ser la resistencia a la censura de los retiros.

Con respecto a la importancia de la función de retiro forzado/cabina de escape resistente a la censura, Vitalik enfatizó en su artículo “Diferentes tipos de capa 2” de hace unos meses que si los usuarios pueden retirar activos con éxito de la Capa 2 a la Capa 1 es un factor clave. La seguridad es muy importante indicador. **

Si el secuenciador de la Capa 2 sigue rechazando sus solicitudes de transacción, o falla/está inactivo durante mucho tiempo, sus activos se “congelarán” y no podrá hacer nada. **Incluso si se dispone de sistemas DA y a prueba de fraude/ZK, sin una solución anticensura, dicha Capa 2 no es lo suficientemente segura y sus activos pueden ser detenidos en cualquier momento. **

Es más, la solución Plasma, que alguna vez fue muy popular en el ecosistema Ethereum, permite a cualquiera retirar activos de forma segura a la Capa 1 cuando falla el DA o falla la prueba de fraude. En este momento, toda la red de Capa 2 está básicamente desechada, pero todavía hay una manera de que sus activos salgan ilesos. **Obviamente, la función de retiro resistente a la censura es más básica y de nivel inferior que el DA y los sistemas de prueba. **

(Dankrad de la Fundación Ethereum dijo que Plasma aún puede permitir que los activos de los usuarios sean evacuados de forma segura cuando DA falla o los usuarios no pueden sincronizar los datos más recientes)

Algunos Ethereum Layer 2, como Loopring, StarkEx, dYdX, Degate, etc., configurarán una función de activación de cabina de escape/retiro forzado resistente a la censura en la Capa 1. Tomando Starknet como ejemplo, si el usuario envía Forzado en la Capa 1 Si la solicitud de retiro no recibe una respuesta del secuenciador Layer2 al final del período de ventana de 7 días, la función de solicitud de congelación se puede llamar manualmente para poner L2 en el estado congelado y activar el modo de cabina de escape.

En este momento, el clasificador no puede enviar datos al contrato acumulativo en L1 y toda la Capa 2 se congelará durante un año. Luego, ** los usuarios pueden enviar una prueba merkle para demostrar el estado de sus activos en la Capa 2 y retirar dinero directamente en la Capa 1 (en realidad, retiran su propia cantidad igual de fondos de la dirección oficial de depósito y retiro del puente). **

Obviamente, el modo de trampilla de escape solo se puede implementar en una cadena como Ethereum que admita contratos inteligentes, y Bitcoin no puede ejecutar una lógica tan compleja. ** En otras palabras, la función de trampilla de escape es básicamente una patente de Ethereum Layer 2. Bitcoin Layer 2 debe utilizar algunos medios auxiliares adicionales para imitar al gato y al tigre: esta es la segunda “rueda auxiliar”. **

Pero simplemente indicar una “solicitud de retiro forzoso” es mucho más conveniente que activar directamente la trampilla de escape. ** El primero solo requiere que el usuario envíe una transacción a la dirección especificada en la Capa 1 y, en los datos adicionales de la transacción, declare los datos que desea enviar a todos los nodos de la Capa 2 ( Esto puede omitir directamente el clasificador y envía datos a otros nodos de Layer2 (el nodo comunica la solicitud). ** Si el “retiro forzado” no recibe respuesta durante mucho tiempo, es más razonable que el usuario active el modo de cabina de escape.

(Referencia: ¿Qué importancia tienen las funciones de retirada forzada y cabina de escape para Layer2?)

**Actualmente, ya existen equipos de Bitcoin Layer 2 que planean imitar la implementación de transacciones forzadas de Arbitrum y permitir a los usuarios emitir declaraciones de transacciones forzadas (Sobres de Transacciones Forzadas) en la cadena de Bitcoin. **Bajo esta solución, los usuarios pueden omitir el secuenciador y “transmitir sus voces” directamente a otros nodos de Layer2. Si el secuenciador aún rechaza la solicitud del usuario después de ver la declaración de transacción forzada del usuario, otros nodos de Capa 2 lo notarán y pueden ser castigados.

**Pero el problema es que la función de transacción forzada de Arbitrum, beneficiándose de su sistema a prueba de fraude, puede castigar al Secuenciador/Proponente que ha estado ignorando las transacciones de los usuarios. Sin embargo, la Capa 2 de Bitcoin, que es difícil de verificar a prueba de fraude en la Capa 1, encontrará ciertos desafíos a este respecto. (No hablemos de BitVM por ahora) **Si se trata de una solución como el Rollup soberano, donde el nivel de seguridad no es muy diferente de la verificación del cliente, es difícil para nosotros evaluar seriamente su confiabilidad y es posible que necesitemos evaluar la Detalles de implementación de diferentes proyectos.

Por supuesto, dado que muchos Bitcoin Layer 2 actualmente operan en forma similar a las cadenas laterales, es equivalente a implementar un ** secuenciador descentralizado, que puede resolver el problema anti-censura hasta cierto punto. Pero esto es sólo un medio auxiliar eficaz, ciertamente no es la solución definitiva. **

PD: Algunas soluciones actuales de Capa 2, como Validium, etc., no son perfectas en el diseño del mecanismo de la cabina de escape. Cuando el secuenciador lanza un ataque de retención de datos/DA no está disponible, el usuario no puede retirar dinero. Pero esto se debe al diseño imperfecto de la cabina de escape de Capa 2. En teoría, la retirada óptima de la cabina de escape solo puede depender de datos históricos y no necesita depender de la disponibilidad de DA/datos nuevos)

** El tercer tablero más corto: la confiabilidad de la publicación de datos de la capa DA **

**Aunque DA se llama disponibilidad de datos, este término en realidad se refiere a la publicación de datos. **Solo porque Vitalik y Mustafa no pensaron detenidamente cuando nombraron originalmente este concepto, el nombre DA/disponibilidad de datos no coincide. Nombre real.

**La publicación de datos, como sugiere el nombre, se refiere a si quienes los necesitan pueden recibir con éxito los últimos bloques/datos de transacción/parámetros de transición de estado. **La publicación de datos en diferentes cadenas tiene diferente confiabilidad.

(Referencia: Malentendido sobre la disponibilidad de datos: DA=publicación de datos ≠ recuperación de datos históricos)

Las comunidades occidentales generalmente creen que las cadenas públicas establecidas como Bitcoin y Ethereum son las capas DA más confiables. Si el clasificador Layer2 publica nuevos datos en Ethereum, cualquiera que ejecute el cliente geth de Ethereum puede descargar los datos y sincronizarlos sin ningún obstáculo. **Esto se debe a que esto se logra gracias a la enorme escala de la red Ethereum y la amplia variedad de fuentes de datos públicos.

**Vale la pena mencionar que Ethereum Rollup obligará al secuenciador a publicar datos de transacción/parámetros de transición de estado en la Capa 1, lo cual se garantiza mediante prueba de validez/prueba de fraude. **

Por ejemplo, después de que el secuenciador de ZK Rollup publique datos de transacciones en la Capa 1, activará la lógica del contrato para generar un hash de datos, y el contrato del validador debe confirmar que el certificado de validez enviado por el Proponente tiene una relación correspondiente con el hash de datos.

Esto equivale a: confirmar que la prueba zk y Stateroot enviados por el Proponente están asociados con los datos Tx enviados por el Secuenciador, es decir, New Stateroot=STF(Old Stateroot, Txdata). STF es la función de transición de estado.

**Esto garantiza que los datos de transición de estado/DA se carguen por la fuerza en la cadena. Si solo envía la raíz del estado y el certificado de validez, no podrá pasar la verificación del contrato del validador. **

En cuanto a si la publicación de datos de DA o el sistema de verificación de prueba es más básico, la comunidad Ethereum/Celestia ya ha tenido una discusión completa. La conclusión general es: **La confiabilidad de la capa DA es más importante que la integridad de la prueba de fraude/ sistema de prueba de validez. **Por ejemplo, soluciones como Plasma, Validium y Optimium, donde la capa DA está debajo de la cadena Ethereum y la capa de liquidación está en la cadena Ethereum, son propensas a "ataques de retención de datos", lo que significa:

**El secuenciador/proponente puede conspirar con los nodos de la capa DA bajo la cadena ETH para actualizar el stateroot en la Capa1, pero los parámetros de entrada correspondientes a la transición de estado se retienen y no se envían, lo que hace imposible que los externos juzguen si el nuevo stateroot es correcto, lo que se convierte en “ojos abiertos” ciegos". **

**Si esto sucede, toda la red de Capa 2 equivale a ser descartada, **porque en este momento, no tienes idea de en qué se ha convertido el libro mayor de Capa 2. Si es la Capa 2 (Plasma y Optimium) basada en prueba de fraude, el clasificador puede reescribir los datos/activos bajo cualquier cuenta a voluntad; si es la Capa 2 (Validium) basada en prueba de validez, aunque el clasificador no puede reescribir su cuenta en voluntad, esto En ese momento, toda la red de Capa 2 se convirtió en una caja negra, nadie sabía lo que sucedió dentro y no fue diferente de ser desguazado. Debido a esto, las soluciones ortodoxas de Capa 2 en el ecosistema Ethereum son básicamente Rollup, mientras que Validium y Optimium a menudo no son reconocidas por la Fundación Ethereum.

(Referencia: Retención de datos y prueba de fraude: por qué Plasma no admite contratos inteligentes)

Por lo tanto, la confiabilidad de la capa DA/disponibilidad de los parámetros de transición de estado es más importante y fundamental que la integridad del sistema a prueba de fraude/validez. **Para la Capa 2 de Bitcoin, especialmente la Capa 2 basada en el modelo de verificación del cliente, incluso si el sistema de verificación a prueba de fraude/validez no está configurado en la Capa 1, siempre que la capa DA funcione como de costumbre, todos pueden saber si hay un error en la transición del estado de la red L2.

En la actualidad, es difícil para la red principal de Bitcoin verificar la prueba de fraude/validez (BitVM no se discutirá aquí). Primero supongamos que Bitcoin L2 no tiene un sistema de verificación de prueba. Idealmente, si el clasificador L2 realmente hace el mal y publica un stateroot que no está relacionado con los datos DA en la capa de liquidación/BTC, todavía no puede robar realmente los activos del usuario porque envió unilateralmente el stateroot/el resultado del estado. La transición no será reconocida por los nodos honestos y, al final, puede ser solo por placer personal.

*(**En este momento, siempre que los nodos administrados por los proveedores de instalaciones periféricas del ecosistema, como los intercambios y los puentes entre cadenas, no coludan con el secuenciador, el secuenciador no puede darse cuenta rápidamente de los activos robados mediante la publicación de datos incorrectos. *** Después de eso, siempre que un nodo honesto descubra que algo anda mal y emita una alarma en un momento crítico, el error se puede corregir mediante el consenso social, pero el costo del consenso social en sí es muy alto y no puede surtir efecto. inmediatamente)

Si se trata de un modelo similar a una cadena lateral, donde la mayoría de los nodos conspiran para realizar cambios de estado maliciosos, las personas pueden descubrir rápidamente el problema. Mientras las instalaciones de terceros, como puentes e intercambios entre cadenas, no reconozcan datos erróneos, el controlador malicioso de la capa 2/cadena lateral no podrá retirar dinero exitosamente, a menos que convenza a otros para que lo hagan directamente. OTC con él en la cadena.

(Viatlik señaló una vez en el artículo que la verificación del cliente es la base real para garantizar la seguridad de la red blockchain. Verifíquelo usted mismo)

Hay un punto muy interesante aquí: de hecho, tanto Ethereum Layer 2 como Bitcoin Layer 2 pueden lograr la “verificación del cliente”. Sin embargo, sobre la base de la “verificación del cliente”, la Capa 2 de Ethereum se basa en la Capa 1 y el sistema de verificación de prueba para garantizar la validez de las transiciones de estado y básicamente no necesita depender del consenso social (siempre que exista una prueba/validez de fraude madura). sistema de prueba).

El esquema de “verificación del cliente” de Bitcoin Layer 2 a menudo depende en gran medida del “consenso social” y traerá los riesgos correspondientes (Para Bitcoin Layer 2, este riesgo de seguridad es básicamente controlable, pero aún así puede causar algunos personas pierdan activos. Para Ethereum Layer 2, debido a que su puente oficial necesita demostrar la cooperación del sistema, si se demuestra que el sistema es imperfecto, el secuenciador puede robar los activos del usuario y huir en L1. Por supuesto, los requisitos específicos Vea cómo diseñar el componente del puente de cadenas cruzadas).

Por lo tanto, una Capa 2 que pueda implementar un sistema de verificación de prueba de fraude/validez en la Capa 1 siempre será mucho mejor que un simple modelo de “verificación del cliente”. **

**PD: Dado que la mayoría de la Capa 2 de Bitcoin que adopta el sistema de prueba de fraude/validez no puede permitir que la Capa 1 participe directamente en el proceso de verificación de prueba, su esencia sigue siendo tratar a Bitcoin como la capa DA, y el modelo de seguridad es equivalente a “verificación final del cliente”. **

En teoría, la prueba de fraude se puede verificar en la cadena Bitcoin a través de la solución BitVM en la Capa 1. Sin embargo, la implementación de esta solución es muy difícil y enfrentará grandes desafíos. Dado que la comunidad Ethereum ya ha discutido mucho sobre el sistema de prueba y verificación basado en Layer1, que ya es bien conocido, este artículo no tiene la intención de entrar en detalles sobre el “sistema de prueba y verificación basado en Layer1”.

Resumir

Después de un simple análisis del modelo de barril, inicialmente podemos sacar una conclusión**: en el modelo de seguridad de Capa 2 convencional, según el grado de importancia/grado básico, se puede ordenar de la siguiente manera:**

1. Si la autoridad de control del contrato/puente oficial está razonablemente dispersa
2. ¿Existe una función de retirada resistente a la censura?
3. ¿Es confiable la capa DA/el formulario de publicación de datos?
4. Si se implementa un sistema confiable a prueba de fraude/validez en la Capa 1

Por supuesto, no analizamos el ckBTC, el protocolo de índice de inscripción y otras soluciones de Lightning Network/State Channel y del ecosistema ICP, porque son bastante diferentes de las típicas soluciones Rollup, Plasma, Validium o de verificación de clientes. Debido a limitaciones de tiempo, nos resulta difícil realizar una evaluación prudente de sus factores de seguridad y riesgo, pero considerando su importancia, se llevarán a cabo trabajos de evaluación relevantes según lo programado en el futuro.

Al mismo tiempo, existen serias diferencias entre muchas partes del proyecto en cuanto a si el Protocolo de índice de inscripción debe considerarse como Capa 2. Sin embargo, independientemente de la definición de Capa 2, cosas nuevas como el Protocolo de índice de inscripción han traído suficiente innovación tecnológica. al ecosistema Bitcoin y eventualmente estallará con gran vitalidad.