Introducción:

El científico de la administración estadounidense Lawrence Peter propuso una vez la “teoría del barril”, que sostiene que el rendimiento general de un sistema está limitado por su parte más débil. En otras palabras, cuánta agua puede contener un barril está determinado por su tabla más corta. Aunque este principio es simple, a menudo se pasa por alto. En el pasado, los debates sobre la seguridad de Capa 2 en su mayoría ignoraron la prioridad e importancia de los diferentes componentes, y se enfocaron básicamente en la confiabilidad de la transición de estado y los problemas de DA, pero ignoraron los elementos de nivel inferior y más importantes. De esta manera, toda la base teórica puede ser insostenible. Por lo tanto, al discutir un sistema complejo de varios módulos, primero debemos averiguar cuál es la “tabla más corta”. Inspirados por la teoría del barril, hicimos un análisis del sistema y encontramos que existen dependencias evidentes entre los diferentes componentes en el modelo de seguridad de Capa 2 de Bitcoin/Ethereum, o que algunos componentes son más fundamentales e importantes para la seguridad que otros, lo que se puede considerar como “más corto”. En este sentido, podemos priorizar inicialmente la importancia/base de los diferentes componentes en el modelo de seguridad de Capa 2 predominante de la siguiente manera:

1. Si los derechos de control del puente del contrato/oficial están razonablemente dispersos (qué tan centralizados están los derechos de control de la multi-firma)

2. ¿Existe una función de retiro resistente a la censura (retiro forzado, salida de emergencia)?

3. ¿Es confiable el formulario de liberación de capa / datos de DA? (Ya sea que los datos de DA se publiquen en Bitcoin y Ethereum)

4. Si se implementa un sistema confiable de prueba de fraude/prueba de validez en Capa 1 (Bitcoin L2 requiere la ayuda de BitVM)

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

En comparación con el sistema de capa 2 de Ethereum, altamente ordenado, la capa 2 de Bitcoin es como un mundo completamente nuevo. Este nuevo concepto, que se ha vuelto cada vez más importante después de la moda de las inscripciones, está mostrando un impulso creciente, pero su ecosistema se está volviendo cada vez más caótico. Del caos, varios proyectos de la Capa 2 brotaron 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 han amenazado con "negar la capa 2 de Ethereum y seguir el camino único del ecosistema Bitcoin", mostrando 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 ser incapaz de alinearse con la capa 2 de Ethereum en las primeras etapas, pero esto no significa que debamos negar por completo el sentido común industrial que se ha establecido durante mucho tiempo en Ethereum e incluso en la industria de la cadena de bloques modular. (Refiérase al "incidente 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 alcanzados por los "predecesores" con grandes esfuerzos, ya han mostrado una fuerte capacidad de persuasión después de haber sido ampliamente reconocidos. Definitivamente no es un movimiento racional negar deliberadamente el valor de estos logros.

Al construir Bitcoin Capa 2, debemos comprender completamente la importancia de "aprender del Oeste y aplicarlo en el Este" y absorber y optimizar adecuadamente las muchas conclusiones de la comunidad de Ethereum. Pero al recurrir a 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 mientras se reservan las diferencias.

Esto es como discutir las similitudes y diferencias entre los “occidentales” y los “orientales”. Independientemente de si es occidental u oriental, el sufijo “-er (人)” expresa muchas características similares, pero al corresponder a diferentes prefijos como “occidental” y “oriental”, las características de subdivisión serán diferentes. Pero en última instancia, inevitablemente habrá superposición entre los “occidentales” y los “orientales”, lo que significa que muchas cosas que se aplican a los occidentales también se aplican a los orientales. Muchas cosas que se aplican a “Capa 2 de Ethereum” también se aplican a “Capa 2 de Bitcoin”. Antes de distinguir las diferencias entre Bitcoin L2 y Ethereum L2, puede ser más importante y significativo aclarar la interoperabilidad entre los dos.

Adherirse al propósito de "buscar puntos en común mientras se reservan diferencias", el autor de este artículo no tiene la intención de discutir "qué es la Capa 2 de Bitcoin y qué no lo es", porque este tema es tan controvertido que incluso la comunidad de Ethereum no ha discutido "cuál es la Capa 2 de Ethereum y cuál no es Capa 2" y llegar a una visión objetiva y consistente. Pero lo que es seguro 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 foco de este artículo.

Cómo entender los criterios de seguridad y evaluación de Capa 2

De hecho, la seguridad de Capa 2 no es un nuevo punto de discusión. Incluso la palabra seguridad es un concepto compuesto que incluye múltiples atributos subdivididos. Anteriormente, el fundador de EigenLayer simplemente subdividió "seguridad" en cuatro elementos: "irreversibilidad de transacción (resistencia a reorganizaciones), resistencia a la censura, fiabilidad de liberación de datos/DA y validez de transición de estado."

(El fundador de EigenLayer una vez expresó sus opiniones sobre cómo el esquema de verificación/rollup soberano del lado del cliente puede heredar la seguridad de la red principal de Bitcoin) L2BEAT y la OG de la Comunidad Ethereum han propuesto un modelo de evaluación de riesgos de Capa 2 más sistemático. Por supuesto, estas conclusiones están dirigidas a la Capa 2 de contratos inteligentes, en lugar de la Capa 2 no típica como rollup soberano y verificación del cliente. Aunque esto no es 100% adecuado para Bitcoin L2, todavía contiene muchas conclusiones dignas de reconocimiento, y la mayoría de sus puntos de vista han sido ampliamente reconocidos en la comunidad occidental. También nos facilita evaluar objetivamente los riesgos de diferentes Bitcoin L2.

(Vitalik una vez dijo que dado que la solución Rollup no puede alcanzar la perfección teórica en su lanzamiento inicial, debe usar algunos medios auxiliares para mejorar la seguridad, y estos medios auxiliares se llaman "ruedas de entrenamiento" e introducirán suposiciones de confianza. Estas medidas auxiliares se llaman "ruedas de entrenamiento" e introducirán suposiciones de confianza. Las suposiciones de confianza son riesgos.)

Entonces, ¿de dónde vienen los riesgos de seguridad? Teniendo en cuenta la situación actual, ya sea la capa 2 de Ethereum o la capa 2 de Bitcoin, muchos de ellos dependen de nodos centralizados para actuar como secuenciadores, o de un "comité" en forma de cadena lateral compuesta por un pequeño número de nodos. Si estos ordenadores/comités centralizados no están restringidos, pueden robar los activos de los usuarios y huir en cualquier momento. Pueden rechazar las solicitudes de transacción de los usuarios, lo que hace que los activos se congelen y queden inutilizables. Esto implica la efectividad y la resistencia a la censura de las transiciones de estado mencionadas anteriormente por el fundador de EigenLayer. Al mismo tiempo, dado que la capa 2 de Ethereum 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 la capa 2 oficial) puede actualizar rápidamente la lógica del contrato, agregue segmentos de código malicioso (por ejemplo, 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 asignación de múltiples firmas de contratos", y el problema de asignación de múltiples firmas también se aplica a la capa 2 de Bitcoin. Debido a que la capa 2 de Bitcoin a menudo se basa en el "puente notarial" y requiere múltiples nodos para liberar solicitudes de cadena cruzada a través de firmas múltiples, la capa 2 de Bitcoin también tiene el problema de cómo distribuir razonablemente las firmas múltiples. Incluso podemos pensar en ello como las "ruedas de entrenamiento" más básicas de la capa 2 de Bitcoin.

Además, el problema de DA es extremadamente importante. Si Layer2 no carga datos en Layer1, sino que elige algunos lugares de publicación de DA no confiables, si esta capa de DA fuera de la cadena (comúnmente conocida como el Comité de Disponibilidad de Datos DAC) colude y se niega a liberar los últimos datos de transacciones al mundo exterior, ocurrirá un ataque de retención de datos. Esto hará que la red se vuelva obsoleta y puede evitar que los usuarios retiren fondos con fluidez.

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

1. Verificación del estado/comprobar si el sistema es confiable (Validación del estado)

2. Si el método de liberación de datos DA es confiable (Disponibilidad de Datos)

3. Si la red de Capa 2 rechaza deliberadamente su transacción/se apaga, ¿puede forzar la retirada de los activos de la Capa 2 (Fallo del secuenciador, Fallo del proponente)

4. Con respecto a los contratos relacionados con Capa 2, ¿el control del puente oficial entre cadenas es suficientemente descentralizado? Si el poder es relativamente centralizado, en caso de que los 'insiders actúen maliciosamente', ¿los usuarios tienen suficiente tiempo para responder en caso de emergencia? (Ventana de salida)

(“Gráfico de visualización de factores de riesgo” establecido para diferentes proyectos de Capa 2 en L2BEAT)

De todos modos, al analizar los riesgos de seguridad de Capa 2, en realidad estamos discutiendo cuántos escenarios existen en la red de Capa 2 que pueden causar daño a los activos de los usuarios, y si el sistema de Capa 2 puede restringir eficazmente estas situaciones peligrosas a través del diseño de mecanismos. Si ciertos comportamientos maliciosos no pueden ser eliminados, ¿cuánta "confianza" necesitamos introducir, cuántos individuos en un grupo necesitan ser confiables y cuántas "ruedas de entrenamiento" necesitamos utilizar? A continuación, analizaremos los factores de riesgo presentes en el modelo general de Capa 2 de Ethereum/Bitcoin. (Los objetos discutidos en este artículo no incluyen los "canales de estado" o "canales de pago", ni incluyen protocolos de índice de inscripción, porque son especiales. Y trataremos de explorar qué factores son más básicos, de nivel más bajo 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 más atención que otras deficiencias.)

El efecto barril de Capa 2, ¿cuáles son sus deficiencias?

La tabla más corta - los derechos de gestión del contrato/puente oficial

Aquí, bien 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 “actualización de contrato” mencionada anteriormente (principalmente para Ethereum Capa 2), o más aún, los “derechos de gestión del puente oficial entre cadenas” (aplicable tanto a Bitcoin como a Ethereum Capa 2).

Para Ethereum Capa 2, siempre que los funcionarios de la Capa 2 puedan actualizar rápidamente los contratos en la cadena de Capa 1, teóricamente, pueden robar los tokens bloqueados en la dirección de depósito y retiro del puente oficial de la Capa 2, independientemente de cuán confiable sea su capa de Disponibilidad de Datos (DA) o sistema de pruebas. Se puede decir que la autoridad de control del contrato del puente concierne a la seguridad de todo el sistema. Es la parte más fundamental y crítica de toda la Capa 2 e incluso del conjunto de bloques modular. Si el componente/contrato del puente puede actualizarse e iterarse bajo control de firma múltiple, entonces necesitamos introducir una “suposición de confianza” aquí, asumiendo que el controlador del contrato/puente oficial de la Capa 2 no hará el mal.

(Los retrasos en la actualización de contratos de diferentes proyectos de Capa 2 están marcados en L2BEAT. La mayoría de los contratos de Capa 2 pueden actualizarse de inmediato por el controlador. Si el controlador del contrato quiere robar activos, o si su clave privada es robada por un hacker, los activos del usuario alojados en Capa 2 deben sufrir)

A diferencia de Ethereum Capa 2, el puente de Bitcoin Capa 2 básicamente no está controlado por el contrato en la Capa 1, porque Bitcoin no soporta contratos inteligentes. En comparación, todo el flujo de trabajo de Ethereum Capa 2 depende en gran medida del contrato en la Capa 1, mientras que Bitcoin Capa 2 no puede hacer esto.

(Diagrama esquemático de Starknet)

Este es un problema inevitable para Bitcoin Capa 2. Se puede decir que tiene tanto ventajas como desventajas. En la actualidad, parece que el “puente sin confianza” implementado por Ethereum Capa 2 que se basa en contratos no se puede realizar en Bitcoin L2. Este “Puente sin Confianza” requiere la implementación de un contrato dedicado en la Capa 1 y la cooperación del sistema DA+ prueba de fraude/prueba de ZK. Es esencialmente similar al “puente optimista” como Orbiter o puentes ZK como Polyhedra. La opinión predominante en la industria actual es que si no se consideran posibles errores en la práctica y solo se consideran modelos teóricos, el nivel de seguridad del Puente Optimista y del Puente ZK es básicamente el más alto. Siempre que el código del contrato no contenga errores o no pueda actualizarse maliciosamente, es básicamente sin confianza.

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

Dado que la capa 2 de Bitcoin no puede implementar componentes de contrato en la capa 1 (no estamos hablando de la Lightning Network aquí), sus puentes oficiales son básicamente "puentes notariales" compuestos por un pequeño número de nodos, o "puentes multifirma". La seguridad de este tipo de puentes La fiabilidad depende de cómo se configuren las firmas multifirma/umbral, lo que requiere la introducción de supuestos de confianza sólidos: asumir que estos notarios no se confabulan ni les roban sus claves privadas.

En la actualidad, la mayoría de los puentes basados en firmas de notario/umbral no pueden compararse con el “puente sin confianza” oficial de Capa 2 de Ethereum en cuanto a seguridad (siempre y cuando el contrato de Capa 2 de Ethereum no se actualice maliciosamente). Obviamente, la seguridad de los activos de la custodia de la red de Capa 2 de Bitcoin estará limitada por la seguridad de su puente oficial, o por la descentralización del poder del puente de firma múltiple, que es su primera “rueda auxiliar”. Dado que los “derechos de actualización” de los contratos relacionados con el puente oficial de Capa 2 de Ethereum a menudo están concentrados en manos de algunos controladores de firma múltiple, si los controladores de firma múltiple coluden, también habrá problemas con el puente de Capa 2 de Ethereum, a menos que su contrato no pueda actualizarse, o esté sujeto a un límite de retraso prolongado (actualmente solo Degate y Fuel V1).

(Cada vez que los contratos de Degate se actualizan, se reservará un período de escape seguro de 30 días para los usuarios. Durante este período, siempre y cuando todos encuentren que la nueva versión del código del contrato tiene lógica maliciosa, pueden escapar de forma segura a través de la función de retiro/escape forzado de la cabina)

En cuanto a la parte del "puente oficial", los modelos de confianza de la Capa 2 de Ethereum y la Capa 2 de Bitcoin son básicamente iguales: debes confiar en que el controlador de firma múltiple no coludirá para hacer el mal. Este grupo de firmas múltiples puede controlar el puente oficial de L2 y cambiar su lógica de código o liberar directamente solicitudes de retiro inválidas. El resultado final es: los activos del usuario pueden ser robados. La única diferencia entre los dos es que siempre que el contrato de la Capa 2 de Ethereum no se actualice maliciosamente/el período de actualización sea lo suficientemente largo, su puente oficial será sin confianza, pero la Capa 2 de Bitcoin de todos modos no puede lograr este efecto.

El segundo enlace más corto - retiros forzados resistentes a la censura

Si asumimos que el problema de contratos de firma múltiple/control de puente oficial mencionado anteriormente puede ser ignorado, es decir, no hay problema en esta capa, entonces la siguiente capa más importante debe ser la resistencia a la censura de retiros. Respecto a la importancia de la funcionalidad de retiro resistente a la censura/salida de emergencia, Vitalik enfatizó en su artículo 'Diferentes tipos de capas 2' hace unos meses que si el usuario puede retirar con éxito activos de Capa 2 a Capa 1 es un indicador de seguridad muy importante.

Si el secuenciador de la Capa 2 sigue rechazando sus solicitudes de transacción, o falla/está inactivo durante mucho tiempo, sus activos serán "congelados" y no se podrá hacer nada. Incluso si los sistemas de prueba de DA y fraude/prueba de ZK están disponibles, sin una solución anti-censura, dicha Capa 2 no es lo suficientemente segura y sus activos pueden ser retenidos en cualquier momento. Además, la solución Plasma, que una vez fue muy popular en el ecosistema de Ethereum, permite a cualquier persona retirar sus activos de manera segura a la Capa 1 cuando el DA falla o la prueba de fraude falla. En este momento, toda la red de la Capa 2 es básicamente desechada, pero aún hay una forma de que sus activos escapen ilesos. Obviamente, la función de retiro resistente a la censura es más básica y de un nivel más bajo que los sistemas de DA y prueba.

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

Algunos Ethereum Capa 2, como Loopring y StarkEx, dYdX, Degate, etc., establecerán una función de activación de cabina de escape resistente a la censura en la Capa 1. Tomando Starknet como ejemplo, si la solicitud de Retiro Forzoso presentada por el usuario en la Capa 1 no recibe respuesta del secuenciador de la Capa 2 al final del período de ventana de 7 días, la función de solicitud de congelación puede ser llamada manualmente para poner la L2 en un estado congelado y activar el modo de cabina de escape. En este momento, el secuenciador no puede enviar datos al contrato de Rollup en L1, y toda la Capa 2 quedará congelada durante un año. Luego, los usuarios pueden presentar una prueba de Merkle para demostrar el estado de sus activos en la Capa 2, y retirar dinero directamente en la Capa 1 (en realidad, toman su propia cantidad igual de fondos de la dirección de depósito y retiro del puente oficial).

Obviamente, el modo de escape solo se puede implementar en una cadena como Ethereum que admite contratos inteligentes. Bitcoin no puede ejecutar una lógica tan compleja. En otras palabras, la función de escape es básicamente una patente de Ethereum Capa 2. Bitcoin Capa 2 debe usar algunos medios auxiliares adicionales para imitar al gato y al tigre. Este es el segundo "rueda auxiliar". Sin embargo, es mucho más conveniente simplemente declarar una "solicitud de retiro forzoso" que activar directamente el modo de escape. Lo 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 desean enviar a todos los nodos de la Capa 2 (esto puede sortear directamente al secuenciador y comunicar solicitudes a otros nodos de la Capa 2). Si la "retirada forzosa" no recibe respuesta durante mucho tiempo, es un diseño más razonable que el usuario active el modo de cabina de escape.

(Referencia: ¿Qué tan importantes son la retirada forzada y las funciones de cabina de escape para Capa 2）

Actualmente, ya hay equipos de Capa 2 de Bitcoin que planean imitar el método de 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 evitar al secuenciador y “transmitir sus voces” directamente a otros nodos de Capa 2. Si el secuenciador sigue rechazando la solicitud del usuario después de ver la declaración de transacción forzada del usuario, será notado por otros nodos de Capa 2 y podría ser castigado.

Pero el problema es que la función de transacción forzada de Arbitrum, que se beneficia de su sistema a prueba de fraudes, puede castigar a los Secuenciadores/Proponentes que han estado ignorando las transacciones de los usuarios. Sin embargo, Capa 2 de Bitcoin, que es difícil de verificar a prueba de fraudes en Capa 1, encontrará ciertos desafíos al respecto. (No discutamos BitVM por ahora) Si se trata de una solución como Rollup soberano, donde el nivel de seguridad no difiere mucho de la verificación del cliente, nos resulta difícil evaluar seriamente su confiabilidad, y es posible que necesitemos evaluar los detalles de implementación de diferentes proyectos.

Por supuesto, dado que muchos Bitcoin Capa 2 operan actualmente en una forma similar a las side chains, es equivalente darse cuenta de que el secuenciador descentralizado puede resolver el problema de la censura hasta cierto punto. Pero esto es solo un medio auxiliar efectivo, ciertamente no 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, los usuarios no pueden retirar dinero. Pero esto se debe al diseño imperfecto de la cabina de escape de la Capa 2. Teóricamente, la retirada óptima de la escotilla de escape puede depender solo de datos históricos y no necesita depender de la disponibilidad de DA/nuevos datos.

La tercera tabla más corta: la fiabilidad de la liberación de datos de la capa DA

Aunque DA se llama disponibilidad de datos, el término en realidad se refiere a la liberación de datos. Solo es porque Vitalik y Mustafa no pensaron cuidadosamente cuando originalmente nombraron este concepto que el nombre DA/disponibilidad de datos resultó ser falso.

La liberación de datos, como su nombre indica, se refiere a si los últimos bloques/datos de transacción/parámetros de transición de estado pueden ser recibidos con éxito por aquellos que lo necesitan. Los datos publicados en diferentes cadenas tienen diferentes niveles de confiabilidad.

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

Generalmente se cree en la comunidad occidental que las cadenas públicas establecidas como Bitcoin y Ethereum son las capas DA más confiables. Si el clasificador de Capa 2 publica nuevos datos en Ethereum, cualquier persona que ejecute el cliente geth de Ethereum puede descargar estos datos y sincronizarlos sin ningún impedimento. Esto se logra aprovechando la gran escala de la red de Ethereum y la amplia variedad de fuentes de datos públicas. Cabe mencionar que Ethereum Rollup obligará al secuenciador a publicar datos de transacciones/parámetros de transición de estado en Capa 1, lo que está garantizado a través de pruebas de validez/pruebas de fraude.

Por ejemplo, después de que el secuenciador de ZK Rollup publique los datos de la transacción 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 es equivalente 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 a la fuerza en la cadena. Si solo envías el stateroot y el certificado de validez, no podrás pasar la verificación del contrato de validador. En cuanto a si la liberación de datos de DA o el sistema de verificación de pruebas es más básico, la comunidad Ethereum/Celestia ya ha tenido una discusión completa. La conclusión general es que la fiabilidad de la capa DA es más importante que la exhaustividad del sistema a prueba de fraude/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 encontrar problemas de "ataque 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 la raíz del estado en la capa 1, pero retienen los parámetros de entrada correspondientes a la transición de estado y no los envían, lo que hace imposible que los extraños juzguen si el nuevo stateroot es correcto y se vuelvan "ciegos".

Si esto sucede, toda la red de Capa 2 será descartada. Porque en este momento, no tienes idea de lo que se ha convertido el libro mayor de Capa 2. Si se trata de Capa 2 (Plasma y Optimium) basada en prueba de fraude, el clasificador puede reescribir los datos/activos bajo cualquier cuenta a voluntad; si se trata de Capa 2 (Validium) basada en prueba de validez, aunque el clasificador no puede reescribir tu cuenta a voluntad, en ese momento, toda la red de Capa 2 se convirtió en una caja negra. Nadie sabía lo que sucedía dentro, y no era diferente de ser descartado. Por eso, las soluciones ortodoxas de Capa 2 en el ecosistema de Ethereum son básicamente Rollup, mientras que Validium y Optimium a menudo no son reconocidos por la Fundación Ethereum.

(Referencia: Prueba de retención de datos y fraude: Por qué Plasma no soporta contratos inteligentes）

Por lo tanto, la fiabilidad de la capa DA/disponibilidad de parámetros de transición de estado es más importante y fundamental que la completitud del sistema de prueba de fraude/prueba de validez. Para Bitcoin Capa 2, especialmente Capa 2 basada en el modelo de verificación del cliente, incluso si no hay un sistema de verificación de prueba de fraude/prueba de validez en la Capa 1, siempre que la capa DA funcione como de costumbre, todos pueden saber si hay un error en la red L2. En la actualidad, la red principal de Bitcoin es difícil de verificar la prueba de fraude/prueba de validez (aquí no se discute BitVM). Supongamos primero que Bitcoin L2 no tiene un sistema de verificación de prueba. Idealmente, si el clasificador de L2 realmente hace el mal y publica una raíz de estado que no está relacionada con los datos de DA en la capa de liquidación/BTC, aún así no puede robar realmente los activos de los usuarios porque las raíces de estado/resultado de transición de estado que presenta unilateralmente no serán reconocidas por los nodos honestos, pero al final solo puede ser autocomplacencia. (En este momento, siempre que los nodos ejecutados por proveedores de instalaciones periféricas en el ecosistema como intercambios y puentes entre cadenas no colaboren con el secuenciador, el secuenciador no puede darse cuenta rápidamente de los activos robados al publicar datos erróneos. Después, siempre que un nodo honesto descubra que algo está mal y emita una alarma en un momento crítico, el error puede corregirse a través del consenso social. Sin embargo, el costo del consenso social en sí mismo es muy alto y no puede surtir efecto de inmediato)

Si se trata de un modelo similar a una cadena lateral, y la mayoría de los nodos conspiran para realizar cambios de estado maliciosos, las personas pueden descubrir rápidamente el problema. Siempre y cuando las instalaciones de terceros como puentes entre cadenas e intercambios no reconozcan datos erróneos, los controladores malintencionados de Capa 2/cadenas laterales no podrán retirar fondos con éxito. A menos que convenza a otros de realizar una operación fuera de la cadena directamente con él.

(Viatlik señaló una vez en el artículo que la verificación del cliente es la verdadera base para garantizar la seguridad de la red blockchain, Verifica por ti mismo)

Aquí hay un punto muy interesante. De hecho, tanto la capa 2 de Ethereum como la capa 2 de Bitcoin 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 en el sistema de verificación de pruebas para garantizar la validez de las transiciones de estado y, básicamente, no tiene que depender del consenso social (siempre que exista un sistema maduro a prueba de fraude/prueba de validez). La solución de "verificación del cliente" de la capa 2 de Bitcoin a menudo se basa en gran medida en el "consenso social" y traerá los riesgos correspondientes. (Para la capa 2 de Bitcoin, este riesgo de seguridad es básicamente controlable, pero aún así puede hacer que algunas personas pierdan activos. Para la capa 2 de Ethereum, debido a que su puente oficial necesita demostrar la cooperación del sistema, si el sistema de prueba no es perfecto, el orden El servidor puede robar los activos del usuario y huir en L1. Por supuesto, los detalles dependen de cómo esté diseñado el componente del puente entre cadenas). Por lo tanto, una capa 2 que pueda implementar un sistema de verificación a 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 las capas 2 de Bitcoin que utilizan sistemas a prueba de fraude/prueba de validez no pueden permitir que la capa 1 participe directamente en el proceso de verificación de pruebas, su esencia sigue siendo tratar a Bitcoin como una capa DA, y el modelo de seguridad es equivalente a la "verificación del cliente". Teóricamente, 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 se enfrentará a grandes desafíos. Dado que la comunidad de 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".

Conclusión

Después de un análisis del modelo de barriles simple, podemos sacar una conclusión inicial: En el modelo de seguridad de Capa 2 principal, según el grado de importancia/nivel básico, se puede clasificar de la siguiente manera:

1. Si los derechos de control del contrato/puente oficial están razonablemente dispersos

2. Si existe una función de retiro resistente a la censura

3. Si el formulario de liberación de datos de la capa DA es confiable

4. Si se implementa un sistema confiable de prueba de fraude/prueba de validez en Capa 1

Por supuesto, no analizamos la Red Lightning/Canales de Estado y el ecosistema de ICP's ckBTC, Protocolo de Índice de Inscripción y otras soluciones, porque son bastante diferentes de las soluciones típicas de Rollup, Plasma, Validium o verificación de cliente. Debido a limitaciones de tiempo, nos resulta difícil realizar una evaluación prudente de su seguridad y factores de riesgo, pero considerando su importancia, se llevará a cabo el trabajo de evaluación relevante según lo programado en el futuro. Al mismo tiempo, existen serias diferencias entre muchas partes del proyecto en cuanto a si se debe considerar al Protocolo de Índice de Inscripción como Capa 2. Sin embargo, independientemente de la definición de Capa 2, nuevas cosas como el Protocolo de Índice de Inscripción han aportado suficiente innovación tecnológica al ecosistema de Bitcoin. Y eventualmente estallarán con gran vitalidad.

Descargo de responsabilidad：

1. Este artículo es reimpreso de [极客web3]. Todos los derechos de autor pertenecen al autor original [Faust & 雾月, web3 de geek]. If there are objections to this reprint, please contact the Gate Learnequipo, y ellos lo manejarán rápidamente.
2. Descargo de responsabilidad por responsabilidad: Las opiniones expresadas en este artículo son únicamente las del autor y no constituyen asesoramiento 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.