En una nueva publicación en el foro, proponemos actualizar los requisitos de la Etapa 1 introduciendo una nueva "prueba de abandono del Consejo de Seguridad" que intenta responder a la pregunta: ¿Pueden los usuarios salir, en presencia de operadores maliciosos, incluso si el Consejo de Seguridad desaparece?

El requisito actual de la Etapa 1 permite el uso activo de la minoría del Consejo de Seguridad para proporcionar resistencia a la censura, garantías de disponibilidad o garantías de seguridad, sin necesidad de implementar mecanismos adecuados sin permisos.

Si bien en su momento decidimos no abordar esta posible laguna, notamos un interés creciente por parte de los proyectos en utilizar tales estrategias para alcanzar la Etapa 1 y un interés decreciente en fortalecer los sistemas de prueba o implementar transacciones forzadas.

Discutimos tres proyectos de la Etapa 1 que actualmente no superan la prueba de abandono: @Starknet, @KintoXYZ (ahora cerrado) y @Scroll_ZKP. Aunque proporcionamos un breve resumen aquí, invitamos a las personas a leer los detalles en la publicación.

Hoy, Starknet satisface el requisito actual de la Etapa 1 utilizando a la minoría del Consejo de Seguridad como un probador con permiso. Si los usuarios son censurados, se supone que deben contactar a los miembros del Consejo de Seguridad, quienes a su vez deben ejecutar la infraestructura del probador de manera oportuna.

Nunca se ha definido un mecanismo exacto sobre cómo contactar al Consejo de Seguridad en términos de censura. De manera equivalente, si el Consejo de Seguridad no puede ejecutar el comprobador a tiempo, o simplemente desaparece, los fondos pueden verse comprometidos.

Una forma más robusta de satisfacer el principio de la Etapa 1 sería implementar transacciones forzadas y un mecanismo de recuperación de actividad para el probador. Starknet actualmente carece de ambos mecanismos.

.@KintoXYZ utilizó a los miembros del Consejo de Seguridad como los únicos retadores con permiso en el protocolo. Si el Consejo de Seguridad "se aleja", o no puede proporcionar el servicio de manera oportuna, los fondos pueden verse comprometidos. Una solución más robusta sería abrir desafíos sin permiso.

Finalmente, mientras que @Scroll_ZKP ya implementa transacciones forzadas y un mecanismo de recuperación de actividad para el probador con permiso, solo el Consejo de Seguridad puede recuperarse de una pausa maliciosa. Una pausa que expire automáticamente sería suficiente para satisfacer la prueba.

Cabe destacar que muchas de las principales cadenas ya satisfacen las pruebas de abandono del Consejo de Seguridad y no necesitarían cambios para mantener la designación de Etapa 1: @arbitrum, @Optimism, @inkonchain y @unichain. Todos ellos ya implementan transacciones forzadas y pruebas sin permisos.

@Scroll_ZKP Notablemente, muchas de las principales cadenas ya satisfacen las pruebas de abandono del Consejo de Seguridad y no necesitarían cambios para mantener la designación de Etapa 1: @arbitrum, @Optimism, @base, @inkonchain y @unichain. Todos ellos ya implementan transacciones forzadas y pruebas sin permisos.