De 0 a 2: Explorando la evolución de la seguridad de la red L2 de Ethereum
En el ecosistema de Ethereum, las tres etapas de la seguridad de la red L2 han sido un foco de atención para la comunidad. Esto no solo se relaciona con la estabilidad operativa de la red principal de Ethereum y la red L2, sino que también está estrechamente relacionado con el proceso de desarrollo real de la red L2. Recientemente, los miembros de la comunidad propusieron la etiqueta de nombramiento #BattleTested para la etapa 2 de la red L2, lo que ha generado una amplia discusión.
La seguridad de la red L2 de Ethereum se puede definir en tres etapas según el grado de control del comité de seguridad sobre los componentes sin confianza:
Fase 0: El comité de seguridad tiene el control absoluto. Aunque puede existir un sistema de prueba, este solo es de referencia.
Fase 1: Se requiere la aprobación de más del 75% de los miembros del comité de seguridad para cubrir el sistema operativo, y debe haber un número legal de personas fuera de la organización principal para bloquear el subconjunto.
Fase 2: El comité de seguridad solo puede intervenir en caso de errores claros y únicamente para seleccionar las soluciones propuestas.
Estas tres etapas se pueden representar visualmente con la "cuota de voto" del Comité de Seguridad. La cuestión clave es: ¿cuál es el mejor momento para que la red L2 pase de la etapa 0 a la 1, y luego de la 1 a la 2?
La única razón razonable para no entrar directamente en la fase 2 es la falta de confianza total en el sistema de prueba. El sistema de prueba está compuesto por una gran cantidad de código, y las vulnerabilidades potenciales pueden llevar al robo de los activos de los usuarios. Cuanto mayor sea la confianza en el sistema de prueba, o menor la confianza en el comité de seguridad, más se debería impulsar a la red hacia un desarrollo en fases superiores.
A través de un modelo matemático simplificado, podemos cuantificar este problema. Supongamos que cada miembro del comité de seguridad tiene un 10% de probabilidad de fallo independiente, y la probabilidad de fallo de actividad es igual a la de fallo de seguridad. En la etapa 0, el criterio de decisión del comité de seguridad es de 4/7, y en la etapa 1 es de 6/8. Suponemos que existe un único sistema de prueba global.
Basado en estas suposiciones, podemos calcular la probabilidad de colapso de las redes L2 en diferentes probabilidades de fallo del sistema de prueba. Los resultados muestran que, a medida que mejora la calidad del sistema de prueba, la fase óptima se traslada de 0 a 1 y luego a 2. Utilizar un sistema de prueba de calidad de fase 0 para operar en la fase 2 es la peor opción.
Sin embargo, la situación real es más compleja que el modelo. Los miembros del comité de seguridad no son completamente independientes y pueden existir modos de falla comunes. El sistema de prueba en sí mismo puede estar compuesto por múltiples sistemas independientes, lo que reduce la probabilidad de colapso general, al mismo tiempo que se mantiene la importancia del comité de seguridad en la fase 2.
Desde un punto de vista matemático, la existencia de la fase 1 parece difícil de justificar: teóricamente debería saltarse directamente de la fase 0 a la fase 2. Sin embargo, considerando que en situaciones de emergencia puede ser difícil obtener rápidamente las firmas de suficientes miembros del comité de seguridad, una solución es otorgar a cualquier miembro el poder de retrasar temporalmente los retiros, para que los otros miembros tengan tiempo para actuar.
Al mismo tiempo, ingresar a la fase 2 demasiado pronto no es sabio, especialmente si hacerlo sacrifica el trabajo de fortalecimiento del sistema de pruebas subyacente. En un escenario ideal, los proveedores de datos deberían mostrar la auditoría del sistema de pruebas y los indicadores de madurez, y al mismo tiempo mostrar la fase actual. Esto ayudará a los participantes del ecosistema a evaluar y comprender mejor el estado de seguridad de la red L2.
Esta página puede contener contenido de terceros, que se proporciona únicamente con fines informativos (sin garantías ni declaraciones) y no debe considerarse como un respaldo por parte de Gate a las opiniones expresadas ni como asesoramiento financiero o profesional. Consulte el Descargo de responsabilidad para obtener más detalles.
19 me gusta
Recompensa
19
7
Republicar
Compartir
Comentar
0/400
WalletInspector
· hace12h
L2 quiere volar, pero debe caminar con firmeza.
Ver originalesResponder0
GateUser-40edb63b
· 08-11 10:45
Finalmente puedo jugar bien L2.
Ver originalesResponder0
WealthCoffee
· 08-10 06:11
¿Quién no está hablando de qué etapa y de las dos etapas?
Ver originalesResponder0
ser_we_are_early
· 08-09 21:12
Frío asesinato, alta cognición, shorting y luego correr.
Ver originalesResponder0
GasFeeCrybaby
· 08-09 21:10
¿No se dijo que subiría 0.2 de inmediato? ¿Por qué todavía se está hablando tonterías en el nivel 3?
Ver originalesResponder0
WalletsWatcher
· 08-09 21:08
Espero que L2 derribe a ETH.
Ver originalesResponder0
GateUser-c799715c
· 08-09 21:03
La primera fila de L2 ha estado disfrutando del espectáculo.
Evolución de la seguridad de la red L2 de Ethereum: de control centralizado a Descentralización
De 0 a 2: Explorando la evolución de la seguridad de la red L2 de Ethereum
En el ecosistema de Ethereum, las tres etapas de la seguridad de la red L2 han sido un foco de atención para la comunidad. Esto no solo se relaciona con la estabilidad operativa de la red principal de Ethereum y la red L2, sino que también está estrechamente relacionado con el proceso de desarrollo real de la red L2. Recientemente, los miembros de la comunidad propusieron la etiqueta de nombramiento #BattleTested para la etapa 2 de la red L2, lo que ha generado una amplia discusión.
La seguridad de la red L2 de Ethereum se puede definir en tres etapas según el grado de control del comité de seguridad sobre los componentes sin confianza:
Estas tres etapas se pueden representar visualmente con la "cuota de voto" del Comité de Seguridad. La cuestión clave es: ¿cuál es el mejor momento para que la red L2 pase de la etapa 0 a la 1, y luego de la 1 a la 2?
La única razón razonable para no entrar directamente en la fase 2 es la falta de confianza total en el sistema de prueba. El sistema de prueba está compuesto por una gran cantidad de código, y las vulnerabilidades potenciales pueden llevar al robo de los activos de los usuarios. Cuanto mayor sea la confianza en el sistema de prueba, o menor la confianza en el comité de seguridad, más se debería impulsar a la red hacia un desarrollo en fases superiores.
A través de un modelo matemático simplificado, podemos cuantificar este problema. Supongamos que cada miembro del comité de seguridad tiene un 10% de probabilidad de fallo independiente, y la probabilidad de fallo de actividad es igual a la de fallo de seguridad. En la etapa 0, el criterio de decisión del comité de seguridad es de 4/7, y en la etapa 1 es de 6/8. Suponemos que existe un único sistema de prueba global.
Basado en estas suposiciones, podemos calcular la probabilidad de colapso de las redes L2 en diferentes probabilidades de fallo del sistema de prueba. Los resultados muestran que, a medida que mejora la calidad del sistema de prueba, la fase óptima se traslada de 0 a 1 y luego a 2. Utilizar un sistema de prueba de calidad de fase 0 para operar en la fase 2 es la peor opción.
Sin embargo, la situación real es más compleja que el modelo. Los miembros del comité de seguridad no son completamente independientes y pueden existir modos de falla comunes. El sistema de prueba en sí mismo puede estar compuesto por múltiples sistemas independientes, lo que reduce la probabilidad de colapso general, al mismo tiempo que se mantiene la importancia del comité de seguridad en la fase 2.
Desde un punto de vista matemático, la existencia de la fase 1 parece difícil de justificar: teóricamente debería saltarse directamente de la fase 0 a la fase 2. Sin embargo, considerando que en situaciones de emergencia puede ser difícil obtener rápidamente las firmas de suficientes miembros del comité de seguridad, una solución es otorgar a cualquier miembro el poder de retrasar temporalmente los retiros, para que los otros miembros tengan tiempo para actuar.
Al mismo tiempo, ingresar a la fase 2 demasiado pronto no es sabio, especialmente si hacerlo sacrifica el trabajo de fortalecimiento del sistema de pruebas subyacente. En un escenario ideal, los proveedores de datos deberían mostrar la auditoría del sistema de pruebas y los indicadores de madurez, y al mismo tiempo mostrar la fase actual. Esto ayudará a los participantes del ecosistema a evaluar y comprender mejor el estado de seguridad de la red L2.