Las tres etapas de la evolución de la seguridad en la red L2: del control total a la intervención limitada

La evolución de la seguridad de la red L2 de Ethereum se puede dividir en tres etapas, que dependen principalmente de la capacidad del comité de seguridad para intervenir en componentes sin confianza:

• Etapa 0: El Comité de Seguridad tiene el control total. Incluso en presencia de un sistema de prueba, el Comité de Seguridad puede anular su resultado mediante una votación de simple mayoría.

• Fase 1: Se requiere la aprobación de más del 75% de los miembros del comité de seguridad para anular los resultados del sistema de prueba. Al mismo tiempo, se requiere que al menos 3 miembros provengan de fuera de la organización principal para aumentar la dificultad de control.

• Etapa 2: El comité de seguridad solo puede actuar en caso de errores comprobables, como cuando los resultados de dos sistemas de prueba redundantes son contradictorios. Además, solo puede elegir una de las respuestas propuestas, no puede responder de manera arbitraria.

Estas tres etapas reflejan el proceso de disminución gradual de la "participación de voto" del comité de seguridad. La cuestión clave es cómo determinar el mejor momento para pasar de una etapa a la siguiente.

La única razón razonable para no pasar directamente a la fase 2 es la insuficiencia de confianza en el sistema de pruebas. El sistema de pruebas 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 pruebas, o menor sea la confianza en el comité de seguridad, más se debería impulsar el desarrollo de la red hacia la siguiente fase.

A través de un modelo matemático simplificado, podemos cuantificar este proceso de decisión. Supongamos que cada miembro del comité de seguridad tiene un 10% de probabilidad de fallo independiente, y las probabilidades de fallo de actividad y de seguridad son iguales. En la fase 0, el criterio de decisión del comité de seguridad es 4/7; en la fase 1 es 6/8. La fase 2 depende completamente del sistema de prueba.

Según estas suposiciones, podemos calcular la probabilidad de colapso de la red L2 en diferentes etapas. Los resultados muestran que, a medida que mejora la calidad del sistema de pruebas, la mejor opción pasa gradualmente de la etapa 0 a la etapa 1 y luego a la etapa 2. Entrar directamente en la etapa 2 con un sistema de pruebas de baja calidad es la peor opción.

Sin embargo, la situación real es más compleja que el modelo. Los miembros del comité de seguridad pueden tener fallos de patrón comunes, como colusión o estar bajo la misma amenaza. Además, el sistema de prueba en sí puede estar compuesto por múltiples sistemas independientes, lo que reduce la probabilidad de colapso y permite que, incluso en la fase 2, el comité de seguridad siga desempeñando un papel importante en la resolución de disputas.

Teniendo en cuenta estos factores, la Fase 1 y la Fase 2 son, de hecho, más atractivas de lo que predice el modelo. Hay opiniones que sugieren que podría ser más razonable saltar directamente de la Fase 0 a la Fase 2, ya que en situaciones de emergencia es difícil obtener rápidamente la firma de 6/8 miembros del Consejo de Seguridad. Pero esto se puede resolver otorgando a cualquiera de los miembros el poder de retrasar el retiro de 1 a 2 semanas, dando a los demás tiempo suficiente para actuar.

Sin embargo, entrar en la fase 2 demasiado pronto, especialmente a costa de sacrificar el fortalecimiento del sistema de prueba subyacente, no es sabio. En un escenario ideal, los proveedores de datos deberían mostrar los indicadores de auditoría y madurez del sistema de prueba, al mismo tiempo que muestran la fase actual en la que se encuentran. Esto ayudaría a los participantes del ecosistema a evaluar y gestionar mejor los riesgos de seguridad de la red L2.