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 está determinada por la participación en la gobernanza.
Las tres etapas de la seguridad de los rollups de Ethereum se pueden determinar según cuándo el comité de seguridad puede cubrir los componentes sin confianza (es decir, puramente criptográficos o de teoría de juegos):
Etapa 0: El comité de seguridad tiene el 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".
Etapa 1: El comité de seguridad necesita el 75% (al menos 6/8) de aprobación para poder 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.
Etapa 2: El comité de seguridad solo puede actuar en casos de errores demostrables. Por ejemplo, un error demostrable podría ser que dos sistemas de prueba redundantes (como OP y ZK) se contradigan entre sí. 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 votos» que posee el comité de seguridad en diferentes etapas:
Estructura de votación de gobernanza en tres etapas
Una pregunta importante es: ¿cuáles son los momentos óptimos para que las redes L2 pasen de la fase 0 a la fase 1, y de la fase 1 a la fase 2?
La única razón válida para no entrar inmediatamente en la fase 2 es que no puedes confiar completamente en el sistema de prueba, lo cual es una preocupación comprensible: el sistema consiste en 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 mayor sea tu confianza en el sistema de prueba (o, por el contrario, cuanto menor sea tu confianza en el comité de seguridad), más querrás impulsar todo el 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 "fallo individual";
Consideramos los fallos de actividad (rechazo a firmar contratos o claves no disponibles) y los fallos de seguridad (firmar asuntos incorrectos o claves comprometidas) como eventos de igual probabilidad. En realidad, solo asumimos una categoría de "fallo", en la que los miembros del consejo de seguridad fallido han firmado tanto asuntos incorrectos como han fallado en firmar asuntos correctos.
En la fase 0, el criterio de juicio del comité de seguridad es 4/7, en la fase 1 es 6/8;
Suponemos que existe un sistema de prueba único (en contraposición al mecanismo de diseño de 2/3, donde un comité de seguridad puede romper el empate cuando hay desacuerdos 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 colapse, queremos minimizar la posibilidad de colapso de la red L2.
Podemos usar la distribución binomial para completar este trabajo:
Si cada miembro del consejo de seguridad tiene un 10% de oportunidad de falla 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 de integración en la fase 0 tiene una probabilidad fija de falla 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 y no se puede realizar el cálculo de la cobertura 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 de la fusión en la Fase 2 es la misma que la probabilidad de fallo del sistema de prueba.
Aquí se presenta en forma de gráfico:
Probabilidad de fallos del sistema de prueba en diferentes etapas de la red L2
Como se ha inferido anteriormente, a medida que mejora la calidad del sistema de prueba, la mejor etapa pasa de la etapa 0 a la etapa 1, y luego de la etapa 1 a la etapa 2. Utilizar un sistema de prueba de calidad de etapa 0 para la operación de la 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 falla común": pueden coludirse o estar sujetos a la misma coerción o ataque hacker, entre otras cosas. La exigencia de tener un quórum fuera de la organización principal para bloquear subconjuntos tiene como objetivo evitar que esto ocurra, pero aún no es perfecto.
El sistema de pruebas en sí mismo puede estar compuesto por múltiples sistemas independientes combinados (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 etapa 2, el comité de seguridad es muy importante, ya que es clave para resolver disputas.
Ambos argumentos indican que, en comparación con lo que muestra el gráfico, la fase 1 y la fase 2 son más atractivas.
Si crees en las matemáticas, la existencia de la fase 1 casi nunca se probará como razonable: deberías pasar directamente a la fase 1. La principal objeción que he escuchado es: si ocurre un error clave, puede ser difícil obtener rápidamente la firma de 6 de los 8 miembros del comité de seguridad para solucionarlo. Pero hay una solución sencilla: otorgar a cualquier miembro del comité de seguridad la autoridad para retrasar la retirada de 1 a 2 semanas, dando a los demás tiempo suficiente para tomar acciones (correctivas).
Al mismo tiempo, sin embargo, saltar prematuramente a la etapa 2 también es un error, especialmente si el trabajo de transición a la etapa 2 se realiza a expensas de fortalecer el trabajo del sistema de prueba subyacente. Idealmente, proveedores de datos como L2Beat deberían mostrar auditorías del sistema de prueba y métricas de madurez (preferiblemente métricas de la implementación del sistema de prueba en lugar de métricas del total, para que podamos reutilizarlas), y acompañar con la presentación de la etapa.
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.
El modelo matemático revela la lógica de selección de la etapa L2: ¿por qué podría omitirse la etapa 1?
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 está determinada por la participación en la gobernanza.
Las tres etapas de la seguridad de los rollups de Ethereum se pueden determinar según cuándo el comité de seguridad puede cubrir los componentes sin confianza (es decir, puramente criptográficos o de teoría de juegos):
Podemos usar el siguiente gráfico para representar la «cuota de votos» que posee el comité de seguridad en diferentes etapas:
Una pregunta importante es: ¿cuáles son los momentos óptimos para que las redes L2 pasen de la fase 0 a la fase 1, y de la fase 1 a la fase 2?
La única razón válida para no entrar inmediatamente en la fase 2 es que no puedes confiar completamente en el sistema de prueba, lo cual es una preocupación comprensible: el sistema consiste en 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 mayor sea tu confianza en el sistema de prueba (o, por el contrario, cuanto menor sea tu confianza en el comité de seguridad), más querrás impulsar todo el ecosistema de la red hacia la siguiente fase.
De hecho, podemos cuantificar esto utilizando un modelo matemático simplificado. Primero, enumeremos las suposiciones:
Bajo estas suposiciones, considerando la probabilidad específica de que el sistema de prueba colapse, queremos minimizar la posibilidad de colapso de la red L2.
Podemos usar la distribución binomial para completar este trabajo:
Aquí se presenta en forma de gráfico:
Como se ha inferido anteriormente, a medida que mejora la calidad del sistema de prueba, la mejor etapa pasa de la etapa 0 a la etapa 1, y luego de la etapa 1 a la etapa 2. Utilizar un sistema de prueba de calidad de etapa 0 para la operación de la 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:
Ambos argumentos indican que, en comparación con lo que muestra el gráfico, la fase 1 y la fase 2 son más atractivas.
Si crees en las matemáticas, la existencia de la fase 1 casi nunca se probará como razonable: deberías pasar directamente a la fase 1. La principal objeción que he escuchado es: si ocurre un error clave, puede ser difícil obtener rápidamente la firma de 6 de los 8 miembros del comité de seguridad para solucionarlo. Pero hay una solución sencilla: otorgar a cualquier miembro del comité de seguridad la autoridad para retrasar la retirada de 1 a 2 semanas, dando a los demás tiempo suficiente para tomar acciones (correctivas).
Al mismo tiempo, sin embargo, saltar prematuramente a la etapa 2 también es un error, especialmente si el trabajo de transición a la etapa 2 se realiza a expensas de fortalecer el trabajo del sistema de prueba subyacente. Idealmente, proveedores de datos como L2Beat deberían mostrar auditorías del sistema de prueba y métricas de madurez (preferiblemente métricas de la implementación del sistema de prueba en lugar de métricas del total, para que podamos reutilizarlas), y acompañar con la presentación de la etapa.