Nota del editor: Durante mucho tiempo, la discusión sobre las tres fases de la seguridad del rollup de Ethereum ha sido el foco de la comunidad ecológica de Ethereum, que no solo está relacionada con la estabilidad operativa de la red principal de Ethereum y la red L2, sino también con el desarrollo real de la red L2. Recientemente, Daniel Wang, miembro de la comunidad de Ethereum, propuso la etiqueta de nomenclatura #BattleTested para la fase de la Etapa 2 de la red L2 en la plataforma X, argumentando que solo las redes L2 con el código y la configuración actuales que han estado en línea en la red principal de Ethereum durante más de 6 meses y han mantenido un valor de bloqueo total (TVL) de más de USD 100 millones y al menos USD 50 millones en ETH y las principales stablecoins pueden obtener este título, y el título se evalúa dinámicamente para evitar "fantasmas en la cadena". 」。 El cofundador de Ethereum, Vitalik, dio una respuesta detallada a esta pregunta y compartió sus puntos de vista, recopilados por Odaily Planet Daily a continuación.
Las 3 grandes etapas de la red L2: de 0 a 1 y luego a 2, la seguridad se determina por la participación en la gobernanza.
Las tres etapas de la seguridad de rollup de Ethereum se pueden determinar según cuándo el comité de seguridad puede cubrir componentes sin confianza (es decir, puramente criptográficos o de teoría de juegos):
Fase 0: El Comité de Seguridad tiene control total. Puede haber un sistema de prueba en funcionamiento (modo Optimism o ZK), pero el Comité de Seguridad puede anularlo a través de un mecanismo de votación por mayoría simple. Por lo tanto, el sistema de prueba es solo de "naturaleza consultiva".
Fase 1: El comité de seguridad necesita la aprobación del 75% (al menos 6/8) para cubrir el sistema operativo. Debe haber un quórum que impida que un subconjunto (como ≥ 3) esté fuera de la organización principal. Por lo tanto, la dificultad para controlar el sistema de prueba es relativamente alta, pero no insuperable.
Fase 2: El comité de seguridad solo puede actuar en casos de errores demostrables. Por ejemplo, un error demostrable podría ser la contradicción entre dos sistemas de prueba redundantes (como OP y ZK). Si hay un error demostrable, solo puede elegir una de las respuestas propuestas: no puede responder arbitrariamente a un mecanismo.
Podemos usar el siguiente gráfico para representar la «cuota de votación» que tiene el comité de seguridad en diferentes etapas:
Estructura de votación de gobernanza en tres fases
Una pregunta importante es: ¿cuáles son los momentos óptimos para que las redes L2 pasen de la etapa 0 a la etapa 1 y de la etapa 1 a la etapa 2?
La única razón válida para no entrar inmediatamente en la fase 2 es que no puedes confiar plenamente en el sistema de pruebas; esta es una preocupación comprensible: el sistema está compuesto por un montón de código, y si hay vulnerabilidades en el código, un atacante podría robar los activos de todos los usuarios. Cuanto más fuerte sea tu confianza en el sistema de pruebas (o, por el contrario, cuanto más débil sea tu confianza en el comité de seguridad), más querrás impulsar toda la ecosistema de la red hacia la siguiente fase.
De hecho, podemos cuantificar esto utilizando un modelo matemático simplificado. Primero, enumeremos las suposiciones:
Cada miembro del comité de seguridad tiene un 10% de probabilidad de un "fallo individual";
Consideramos que las fallas de actividad (rechazo de firmar un contrato o clave no disponible) y las fallas de seguridad (firma de asuntos incorrectos o clave hackeada) son eventos de igual probabilidad. De hecho, solo asumimos una categoría de "fallo", en la que los miembros del consejo de seguridad que han "fallado" han firmado tanto asuntos incorrectos como no han logrado firmar los asuntos correctos.
En la etapa 0, el estándar de juicio del comité de seguridad es 4/7, en la etapa 1 es 6/8;
Supongamos que existe un único sistema de prueba integral (en contraste con el mecanismo de diseño de 2/3, donde un comité de seguridad puede romper el empate cuando hay desacuerdo entre ambas partes). Por lo tanto, en la fase 2, la existencia del comité de seguridad es completamente irrelevante.
Bajo estas suposiciones, considerando la probabilidad específica de que el sistema de prueba falle, deseamos minimizar la posibilidad de que la red L2 colapse.
Podemos usar la distribución binomial para completar este trabajo:
Si cada miembro del consejo de seguridad tiene un 10% de oportunidad de fallo independiente, entonces la probabilidad de que al menos 4 de 7 fallen es ∑𝑖= 47( 7 𝑖)∗ 0.1 𝑖∗ 0.97 −𝑖= 0.002728. Por lo tanto, el sistema integrado en la fase 0 tiene una probabilidad fija de fallo del 0.2728%.
La integración de la fase 1 también puede fallar si el sistema de certificación falla y el mecanismo de verificación del comité de seguridad falla ≥ 3 veces para realizar la superposición de cálculo de la red (probabilidad ∑i= 38( 8 i)∗ 0,1 i∗ 0,98 −i= 0,03809179 multiplicado por la tasa de fallos del sistema de certificación), o si el comité de seguridad tiene 6 o más fallos, Es posible forzarse a generar una respuesta calculada incorrecta (probabilidad fija ∑i= 68( 8 i)∗ 0,1 i∗ 0,98 −i= 0,00002341);
La probabilidad de fallo en la fusión de la Fase 2 es consistente con la probabilidad de fallo del sistema de pruebas.
Aquí se presenta en forma de gráfico:
Probabilidad de fallo del sistema de pruebas en diferentes etapas de la red L2
Como se ha deducido anteriormente, a medida que mejora la calidad del sistema de pruebas, la mejor etapa se traslada de la etapa 0 a la etapa 1, y luego de la etapa 1 a la etapa 2. Utilizar un sistema de pruebas de calidad de etapa 0 para la operación de red en la etapa 2 es el peor resultado.
Ahora, por favor, tenga en cuenta que las suposiciones en el modelo simplificado anterior no son perfectas:
En la realidad, los miembros del comité de seguridad no son completamente independientes; (puede haber) un "modo de fallo común" entre ellos: pueden coludirse o todos pueden estar bajo la misma coerción o ataque de hackers, etc. La exigencia de tener un quórum legal fuera de la organización principal para bloquear un subconjunto tiene como objetivo evitar que esto ocurra, pero aún no es perfecto.
El sistema de pruebas en sí puede estar compuesto por múltiples sistemas independientes (yo he promovido esto en mi blog anterior). En este caso, (i) la probabilidad de que el sistema de pruebas falle es muy baja, y (ii) incluso en la fase 2, el comité de seguridad es importante, ya que es clave para resolver disputas.
Ambos argumentos indican que las fases 1 y 2 son más atractivas en comparación con lo que muestra el gráfico.
Si crees en las matemáticas, la existencia de la etapa 1 casi nunca se demostrará como razonable: deberías avanzar directamente a la etapa 1. La principal objeción que he escuchado es que, si ocurre un error crítico, puede ser difícil obtener rápidamente las firmas de 6 de los 8 miembros del comité de seguridad para solucionarlo. Pero hay una solución simple: otorgar a cualquier miembro del comité de seguridad la autoridad para retrasar el retiro de 1 a 2 semanas, dando a los demás tiempo suficiente para tomar medidas (remediativas).
Al mismo tiempo, sin embargo, saltar prematuramente a la fase 2 también es un error, especialmente si el trabajo de transición a la fase 2 se realiza a expensas de reforzar el trabajo del sistema de prueba subyacente. Idealmente, proveedores de datos como L2Beat deberían mostrar auditorías del sistema de prueba e indicadores de madurez (preferiblemente indicadores de la implementación del sistema de prueba en lugar de indicadores de todo el resumen, para que podamos reutilizarlos), junto con una demostración de la fase.
El contenido es solo de referencia, no una solicitud u oferta. No se proporciona asesoramiento fiscal, legal ni de inversión. Consulte el Descargo de responsabilidad para obtener más información sobre los riesgos.
Artículo nuevo de Vitalik: Una breve discusión sobre los principios matemáticos para la división razonable de la etapa L2
Escrito por: Vitalik Buterin
Compilado por: Wenser, Odaily Planet Daily
Nota del editor: Durante mucho tiempo, la discusión sobre las tres fases de la seguridad del rollup de Ethereum ha sido el foco de la comunidad ecológica de Ethereum, que no solo está relacionada con la estabilidad operativa de la red principal de Ethereum y la red L2, sino también con el desarrollo real de la red L2. Recientemente, Daniel Wang, miembro de la comunidad de Ethereum, propuso la etiqueta de nomenclatura #BattleTested para la fase de la Etapa 2 de la red L2 en la plataforma X, argumentando que solo las redes L2 con el código y la configuración actuales que han estado en línea en la red principal de Ethereum durante más de 6 meses y han mantenido un valor de bloqueo total (TVL) de más de USD 100 millones y al menos USD 50 millones en ETH y las principales stablecoins pueden obtener este título, y el título se evalúa dinámicamente para evitar "fantasmas en la cadena". 」。 El cofundador de Ethereum, Vitalik, dio una respuesta detallada a esta pregunta y compartió sus puntos de vista, recopilados por Odaily Planet Daily a continuación.
Las 3 grandes etapas de la red L2: de 0 a 1 y luego a 2, la seguridad se determina por la participación en la gobernanza.
Las tres etapas de la seguridad de rollup de Ethereum se pueden determinar según cuándo el comité de seguridad puede cubrir componentes sin confianza (es decir, puramente criptográficos o de teoría de juegos):
Fase 0: El Comité de Seguridad tiene control total. Puede haber un sistema de prueba en funcionamiento (modo Optimism o ZK), pero el Comité de Seguridad puede anularlo a través de un mecanismo de votación por mayoría simple. Por lo tanto, el sistema de prueba es solo de "naturaleza consultiva".
Fase 1: El comité de seguridad necesita la aprobación del 75% (al menos 6/8) para cubrir el sistema operativo. Debe haber un quórum que impida que un subconjunto (como ≥ 3) esté fuera de la organización principal. Por lo tanto, la dificultad para controlar el sistema de prueba es relativamente alta, pero no insuperable.
Fase 2: El comité de seguridad solo puede actuar en casos de errores demostrables. Por ejemplo, un error demostrable podría ser la contradicción entre dos sistemas de prueba redundantes (como OP y ZK). Si hay un error demostrable, solo puede elegir una de las respuestas propuestas: no puede responder arbitrariamente a un mecanismo.
Podemos usar el siguiente gráfico para representar la «cuota de votación» que tiene el comité de seguridad en diferentes etapas:
Estructura de votación de gobernanza en tres fases
Una pregunta importante es: ¿cuáles son los momentos óptimos para que las redes L2 pasen de la etapa 0 a la etapa 1 y de la etapa 1 a la etapa 2?
La única razón válida para no entrar inmediatamente en la fase 2 es que no puedes confiar plenamente en el sistema de pruebas; esta es una preocupación comprensible: el sistema está compuesto por un montón de código, y si hay vulnerabilidades en el código, un atacante podría robar los activos de todos los usuarios. Cuanto más fuerte sea tu confianza en el sistema de pruebas (o, por el contrario, cuanto más débil sea tu confianza en el comité de seguridad), más querrás impulsar toda la ecosistema de la red hacia la siguiente fase.
De hecho, podemos cuantificar esto utilizando un modelo matemático simplificado. Primero, enumeremos las suposiciones:
Cada miembro del comité de seguridad tiene un 10% de probabilidad de un "fallo individual";
Consideramos que las fallas de actividad (rechazo de firmar un contrato o clave no disponible) y las fallas de seguridad (firma de asuntos incorrectos o clave hackeada) son eventos de igual probabilidad. De hecho, solo asumimos una categoría de "fallo", en la que los miembros del consejo de seguridad que han "fallado" han firmado tanto asuntos incorrectos como no han logrado firmar los asuntos correctos.
En la etapa 0, el estándar de juicio del comité de seguridad es 4/7, en la etapa 1 es 6/8;
Supongamos que existe un único sistema de prueba integral (en contraste con el mecanismo de diseño de 2/3, donde un comité de seguridad puede romper el empate cuando hay desacuerdo entre ambas partes). Por lo tanto, en la fase 2, la existencia del comité de seguridad es completamente irrelevante.
Bajo estas suposiciones, considerando la probabilidad específica de que el sistema de prueba falle, deseamos minimizar la posibilidad de que la red L2 colapse.
Podemos usar la distribución binomial para completar este trabajo:
Si cada miembro del consejo de seguridad tiene un 10% de oportunidad de fallo independiente, entonces la probabilidad de que al menos 4 de 7 fallen es ∑𝑖= 47( 7 𝑖)∗ 0.1 𝑖∗ 0.97 −𝑖= 0.002728. Por lo tanto, el sistema integrado en la fase 0 tiene una probabilidad fija de fallo del 0.2728%.
La integración de la fase 1 también puede fallar si el sistema de certificación falla y el mecanismo de verificación del comité de seguridad falla ≥ 3 veces para realizar la superposición de cálculo de la red (probabilidad ∑i= 38( 8 i)∗ 0,1 i∗ 0,98 −i= 0,03809179 multiplicado por la tasa de fallos del sistema de certificación), o si el comité de seguridad tiene 6 o más fallos, Es posible forzarse a generar una respuesta calculada incorrecta (probabilidad fija ∑i= 68( 8 i)∗ 0,1 i∗ 0,98 −i= 0,00002341);
La probabilidad de fallo en la fusión de la Fase 2 es consistente con la probabilidad de fallo del sistema de pruebas.
Aquí se presenta en forma de gráfico:
Probabilidad de fallo del sistema de pruebas en diferentes etapas de la red L2
Como se ha deducido anteriormente, a medida que mejora la calidad del sistema de pruebas, la mejor etapa se traslada de la etapa 0 a la etapa 1, y luego de la etapa 1 a la etapa 2. Utilizar un sistema de pruebas de calidad de etapa 0 para la operación de red en la etapa 2 es el peor resultado.
Ahora, por favor, tenga en cuenta que las suposiciones en el modelo simplificado anterior no son perfectas:
En la realidad, los miembros del comité de seguridad no son completamente independientes; (puede haber) un "modo de fallo común" entre ellos: pueden coludirse o todos pueden estar bajo la misma coerción o ataque de hackers, etc. La exigencia de tener un quórum legal fuera de la organización principal para bloquear un subconjunto tiene como objetivo evitar que esto ocurra, pero aún no es perfecto.
El sistema de pruebas en sí puede estar compuesto por múltiples sistemas independientes (yo he promovido esto en mi blog anterior). En este caso, (i) la probabilidad de que el sistema de pruebas falle es muy baja, y (ii) incluso en la fase 2, el comité de seguridad es importante, ya que es clave para resolver disputas.
Ambos argumentos indican que las fases 1 y 2 son más atractivas en comparación con lo que muestra el gráfico.
Si crees en las matemáticas, la existencia de la etapa 1 casi nunca se demostrará como razonable: deberías avanzar directamente a la etapa 1. La principal objeción que he escuchado es que, si ocurre un error crítico, puede ser difícil obtener rápidamente las firmas de 6 de los 8 miembros del comité de seguridad para solucionarlo. Pero hay una solución simple: otorgar a cualquier miembro del comité de seguridad la autoridad para retrasar el retiro de 1 a 2 semanas, dando a los demás tiempo suficiente para tomar medidas (remediativas).
Al mismo tiempo, sin embargo, saltar prematuramente a la fase 2 también es un error, especialmente si el trabajo de transición a la fase 2 se realiza a expensas de reforzar el trabajo del sistema de prueba subyacente. Idealmente, proveedores de datos como L2Beat deberían mostrar auditorías del sistema de prueba e indicadores de madurez (preferiblemente indicadores de la implementación del sistema de prueba en lugar de indicadores de todo el resumen, para que podamos reutilizarlos), junto con una demostración de la fase.