La combinación de gobierno humano y mecanismos hace que la segunda fase de L2 sea más antifrágil.
Escrito por: Vitalik Buterin
Compilado por: Wenser, Odaily Diario de las Estrellas
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 rollup 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 control total. Puede haber un sistema de prueba en funcionamiento (modo Optimism o ZK), pero el comité de seguridad puede anularlo mediante un simple mecanismo de votación mayoritaria. Por lo tanto, el sistema de prueba es solo de "naturaleza consultiva".
Etapa 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 un subconjunto (como ≥ 3) 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 caso de errores demostrables. Por ejemplo, un error demostrable podría ser que dos sistemas de prueba redundantes (como OP y ZK) se contradicen entre sí. Si hay un error demostrable, solo puede elegir una de las respuestas propuestas: no puede responder arbitrariamente a un mecanismo.
Podemos utilizar el siguiente gráfico para representar la "cuota de voto" que tiene 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 la red L2 pase 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 pruebas—es una preocupación comprensible: el sistema está compuesto por un montón de código, y si hay vulnerabilidades en el código, los atacantes podrían robar los activos de todos los usuarios. Cuanto mayor sea tu confianza en el sistema de pruebas (o, por el contrario, menor tu confianza en el comité de seguridad), más querrás impulsar toda la ecología 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 posibilidad de "fallo individual";
Consideramos que las fallas de activación (rechazo a firmar contratos o claves no disponibles) y las fallas de seguridad (firma de asuntos incorrectos o claves hackeadas) son eventos de igual probabilidad. En realidad, solo asumimos una categoría de "fallo", donde los miembros del consejo de seguridad de "fallo" han firmado tanto asuntos incorrectos como han fallado en firmar asuntos correctos.
En la fase 0, el criterio de evaluación del comité de seguridad es 4/7, en la fase 1 es 6/8;
Supongamos que existe un sistema de prueba único y completo (en contraste con el mecanismo de diseño de 2/3, donde el comité de seguridad puede romper el empate en caso de opiniones contradictorias). Por lo tanto, en la etapa 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, 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 probabilidad 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 de integración en la fase 0 tiene una probabilidad de fallo fija del 0.2728%.
La integración de la fase 1 también puede fallar si el sistema de prueba falla y el mecanismo de verificación del comité de seguridad falla ≥ 3 veces, lo que impide la cobertura del cálculo de la red (probabilidad ∑𝑖= 38( 8 𝑖)∗ 0.1 𝑖∗ 0.98 −𝑖= 0.03809179 multiplicado por la tasa de fallo del sistema de prueba), o si el comité de seguridad ha fallado 6 veces o más, puede forzar la generación de una respuesta de cálculo errónea por sí mismo (fijo ∑𝑖= 68( 8 𝑖)∗ 0.1 𝑖∗ 0.98 −𝑖= 0.00002341 probabilidad);
La probabilidad de fallo de la fusión en la fase 2 es consistente con 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 deduce de los resultados anteriores, a medida que mejora la calidad del sistema de pruebas, la mejor fase se traslada de la fase 0 a la fase 1, y luego de la fase 1 a la fase 2. Utilizar un sistema de pruebas de calidad de fase 0 para la operación de red de fase 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) "fallos de modo común" entre ellos: pueden conspirar entre sí, o pueden estar sujetos a las mismas coacciones o ataques de hackers, etc. La exigencia de tener un quórum legal fuera de la organización principal para prevenir 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 (lo he propuesto en mi blog anterior). En este caso, (i) la probabilidad de que el sistema de pruebas colapse 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, en comparación con lo que se muestra en el gráfico, la etapa 1 y la etapa 2 son más atractivas.
Si crees en las matemáticas, la existencia de la etapa 1 casi nunca se probará como razonable: deberías pasar directamente a la etapa 1. La principal objeción que escuché 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 corregirlo. 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 (remediar).
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 fortalecer el trabajo del sistema de prueba subyacente. En un mundo ideal, proveedores de datos como L2Beat deberían mostrar auditorías del sistema de prueba y métricas de madurez (preferiblemente métricas de implementación del sistema de prueba en lugar de métricas de toda la agregación, de esta manera podemos reutilizar), y acompañar la presentació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.
Obra reciente de Vitalik: Reflexiones sobre los principios matemáticos para una división razonable de las etapas L2
Escrito por: Vitalik Buterin
Compilado por: Wenser, Odaily Diario de las Estrellas
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 rollup 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 utilizar el siguiente gráfico para representar la "cuota de voto" que tiene 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 la red L2 pase 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 pruebas—es una preocupación comprensible: el sistema está compuesto por un montón de código, y si hay vulnerabilidades en el código, los atacantes podrían robar los activos de todos los usuarios. Cuanto mayor sea tu confianza en el sistema de pruebas (o, por el contrario, menor tu confianza en el comité de seguridad), más querrás impulsar toda la ecología 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, deseamos minimizar la posibilidad de que la red L2 colapse.
Podemos usar la distribución binomial para completar este trabajo:
Aquí se presenta en forma de gráfico:
Probabilidad de fallos del sistema de prueba en diferentes etapas de la red L2
Como se deduce de los resultados anteriores, a medida que mejora la calidad del sistema de pruebas, la mejor fase se traslada de la fase 0 a la fase 1, y luego de la fase 1 a la fase 2. Utilizar un sistema de pruebas de calidad de fase 0 para la operación de red de fase 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 se muestra en el gráfico, la etapa 1 y la etapa 2 son más atractivas.
Si crees en las matemáticas, la existencia de la etapa 1 casi nunca se probará como razonable: deberías pasar directamente a la etapa 1. La principal objeción que escuché 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 corregirlo. 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 (remediar).
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 fortalecer el trabajo del sistema de prueba subyacente. En un mundo ideal, proveedores de datos como L2Beat deberían mostrar auditorías del sistema de prueba y métricas de madurez (preferiblemente métricas de implementación del sistema de prueba en lugar de métricas de toda la agregación, de esta manera podemos reutilizar), y acompañar la presentación de la fase.