Esta publicación blog comparte más sobre cómo estamos pensando la descentralización en OP Labs mientras apoyamos a los ingenieros del ecosistema que están construyendo un sistema a prueba de fallos para el OP Stack y el Optimism Collective mientras establece su primer consejo de seguridad.

Una discusión crítica sobre el camino hacia la madurez de la blockchain es cómo descentralizar, cuánto y cuándo hacerlo. Esta publicación de blog comparte un poco más sobre cómo estamos pensando sobre este proceso en OP Labs mientras apoyamos a los ingenieros del ecosistema que están desarrollando un sistema a prueba de fallos para el OP Stack y el Optimism Collective mientras establece su primer consejo de seguridad.

En un artículo perspicaz en el foro Ethereum Magicians, Vitalik Buterin presenta la hoja de ruta para lograr la Descentralización en la Etapa 2, un hito crítico para cualquier red de capa 2 que busque descentralizarse. Este post ha influido en gran medida en la conversación sobre la descentralización técnica en el Optimism Collective durante los últimos dos años. Creemos firmemente que todas las cadenas de bloques de Capa 2 deben priorizar alcanzar esta etapa de descentralización tan rápidamente (¡y de manera segura!) como sea posible, para garantizar un ecosistema más sólido, seguro y verdaderamente descentralizado.

Para recordar a todos lo que se requiere para que los rollups alcancen la Etapa 2, aquí están los criterios delineados en el post original de Vitalik Buterin:

Requisitos:

• En el caso de que el código no tenga errores, no debe haber ningún grupo de actores que pueda, incluso de manera unánime, publicar una raíz de estado diferente a la salida del código.

Esta redacción algo incómoda ("SI el código no tiene errores, ENTONCES nadie puede anularlo") tiene la intención de permitir el uso de consejos de seguridad de maneras claramente limitadas para adjudicar errores innegables, como los siguientes:

• El rollup utiliza dos o más implementaciones independientes de su función de transición de estado (por ejemplo, dos probadores de fraude distintos, dos probadores de validez distintos o uno de cada uno), y el consejo de seguridad puede adjudicar solo si no están de acuerdo, lo que solo sucedería si hay un error.

• Si alguien presenta una transacción o serie de transacciones que contiene dos pruebas válidas para dos raíces de estado distintas después de procesar los mismos datos (es decir, "el probador no está de acuerdo consigo mismo"), el control se entrega temporalmente al consejo de seguridad.

• Si no se presenta ninguna prueba válida durante >= 7 días (es decir, "el probador está atascado"), el control se entrega temporalmente al consejo de seguridad.

• Se permiten actualizaciones, pero deben tener un retraso de >= 30 días.

  En resumen, para quitar las "ruedas de entrenamiento" y lograr la descentralización en la Etapa 2, los rollups deben tener un sistema a prueba de fallos sin confianza, múltiples mecanismos de prueba funcionales y, en el caso de rollups que cuentan con un consejo de seguridad u entidad similar, deben cumplir con criterios específicos.

  Por qué es tan importante llegar a la Etapa 2?

  Lo que hace la Etapa 2 y que la Etapa 1 no hace es asegurar que no haya un grupo de actores que pueda "incluso de manera unánime, publicar una raíz de estado diferente a la salida del código". Las capas 2 en la Etapa 1 todavía tienen alguna versión de un multisig o consejo de seguridad que teóricamente (aunque no sin costos) podría alterar la raíz de estado de una cadena para censurar o iniciar retiros inválidos. No es completamente sin confianza. Eliminar esta capacidad descentraliza aún más las redes y garantiza que los usuarios posean la capacidad inalienable de salir del sistema.

  Este tipo de flexibilidad es crucial para la Superchain porque equilibra la interoperabilidad - todos los que utilizan el mismo sistema a prueba de fallos estarán en la misma versión de protocolo - sin sacrificar la libertad y protecciones del usuario. El derecho a salir siempre debe preservarse y no afectar el funcionamiento de una cadena o una aplicación.

  ¿Por qué está llevando tanto tiempo que Optimism alcance la descentralización en la Etapa 1?

  Los proyectos pueden adoptar un enfoque "primero en profundidad" mientras avanzan hacia la Etapa 2: llegar a la Etapa 1 con un solo sistema a prueba de fallos lo más rápido posible y luego descubrir cómo hacer un sistema a prueba de fallos multiprueba para alcanzar el estado de la Etapa 2. En cambio, Optimism adoptó un enfoque "primero en amplitud" que tiene como objetivo crear una red multiprueba funcional y de rápido crecimiento. Los ingenieros del ecosistema están construyendo la primera implementación del sistema a prueba de fallos de manera que permita ese enfoque. Mientras tanto, como todo esto se está construyendo de manera abierta, con un conjunto de código abierto, otros desarrolladores en el ecosistema pudieron comenzar a construir muchas otras implementaciones en paralelo con el trabajo en la primera implementación del sistema a prueba de fallos.

  Sabemos lo importante que es hacerlo bien desde el primer intento. Hoy, los ingenieros de OP Stack han sentado las bases para una rápida expansión multiprueba y están trabajando para alcanzar el estado de la Etapa 1 según las métricas de análisis de riesgos de L2Beat, un estándar respetado en la industria. Pero Bedrock se construyó desde cero teniendo en cuenta la descentralización en la Etapa 2. No nos interesa llegar a la Etapa 1 simplemente por decir que lo hicimos. Desde el primer día, ha sido solo una parte de nuestro plan pragmático para alcanzar la Etapa 2 tan rápido y seguramente como sea posible.

  La Etapa 2 es el juego final. Esto es lo que parece en la práctica:

  Primero llegó Bedrock y el OP Stack

  Para priorizar el logro de la Etapa 2, sabíamos que necesitábamos diseñar una base de código que facilitara llegar allí. Necesitábamos la modularidad introducida por la actualización de Bedrock para asegurarnos de que una vez que se diseñara un sistema a prueba de fallos funcional y sin confianza para el OP Stack, los desarrolladores del ecosistema pudieran aprovechar sus superpoderes modulares para ayudarnos a diseñar no solo uno o dos, sino muchos mecanismos de prueba alternativos.

  Al mismo tiempo, necesitábamos asegurarnos de que incluso los desarrollos tecnológicos imprevistos no volvieran obsoleto al OP Stack. El diseño actual del OP Stack asegura que los desarrolladores puedan intercambiar componentes de prueba para incluir la tecnología de conocimiento cero, algo que alguna vez amenazó el crecimiento de los rollups optimistas. Las cadenas en el ecosistema de Optimism no están obligadas para siempre a utilizar mecanismos de prueba optimistas. Esperamos que puedan aprovechar los avances en la tecnología ZK y el resurgimiento de Plasma, o una combinación de los tres mecanismos, en el sistema a prueba de fallos de su cadena.

  Llevó tiempo diseñar el OP Stack e implementar la actualización de Bedrock, pero el resultado de esta inversión ha colocado a todo el ecosistema en una posición para acelerar rápidamente nuestro progreso de desarrollo en los próximos meses y más allá. Esto significa que fue un tiempo bien invertido y estratégicamente utilizado.

  Luego viene un ecosistema multiprueba

  Hasta ahora, este enfoque ha dado resultados tremendos. La evidencia está en lo rápido que despegaron los clientes alternativos desde el lanzamiento de Bedrock y en la cantidad de equipos en el ecosistema que actualmente están trabajando en implementaciones alternativas de sistemas a prueba de fallos. Además de OP Labs y todos los mantenedores de clientes alternativos (Test in Prod, el equipo reth y Base, Nethermind, a16z crypto y Kai Chen y el equipo Hildr), que se utilizan como dependencias críticas en el OP Stack, los equipos que actualmente trabajan en pruebas de fallos alternativas incluyen al equipo de State Channels, RISCZero, O(1) Labs, AltLayer, Protolambda (en OP Labs), y los ingenieros Willem Olding y Eric Tu, junto con geohotz y su trabajo inicial en Cannon.

  Acá se encuentra la forma que está tomando:

El OP Stack es una triple amenaza. Es modular y de código abierto, lo que significa que todo el poder del Stack puede llegar a manos de la tercera "amenaza", su comunidad de desarrolladores tremendamente creativa y brillante. Llevaría años para que los ingenieros de OP Labs desarrollaran, probaran e implementaran los múltiples esquemas de prueba requeridos para la descentralización en la Etapa 2. Al poner las mejores herramientas en manos de los destacados desarrolladores y ingenieros principales en nuestro ecosistema, cualquier persona con interés en el éxito de Optimism puede diseñar los componentes que ayudarán a alcanzar nuestro objetivo.

Consejo de seguridad

Para llegar a la descentralización en la Etapa 1 y avanzar hacia la Etapa 2, las redes necesitan algo similar a un consejo de seguridad: un multisig con el cual gestionar actualizaciones de protocolo que esté mantenido por un mínimo de 8 personas independientes con un umbral de firma del 75% o superior.

En el otoño de 2023, comenzó en serio el despliegue para establecer el primer consejo de seguridad del ecosistema de Optimism, compuesto por individuos fuera de la Fundación. Los primeros 14 miembros del consejo de seguridad del ecosistema de Optimism fueron ratificados mediante una votación de gobernanza en diciembre de 2023, y otra votación de gobernanza sobre si compartir o no las claves de actualización con el consejo de seguridad en una 'Fase 0' interina también tuvo éxito.

Uno de los valores más apreciados de Optimism es la tecnología de código abierto. Así como los ingenieros del ecosistema están construyendo el OP Stack de código abierto con licencia MIT de manera abierta, el consejo de seguridad se construirá de manera abierta, como la carta pública, una implementación de código abierto y operaciones transparentes. Esto está en línea con dos de los tres principios rectores que han inspirado la estructura del consejo de seguridad: transparencia y comunidad.

El tercer principio, seguridad sobre vitalidad, informa el diseño del consejo de seguridad y de la seguridad en el ecosistema de Optimism en general. Priorizar la seguridad sobre la vitalidad significa que es más importante para el sistema evitar errores y estados inválidos, especialmente aquellos que resultarían en una pérdida de fondos, incluso si esto conlleva detener temporalmente las operaciones.

Todos los L2 deberían apuntar a la Etapa 2

Eso es todo. Ese es el meme.

No es suficiente que los L2 alcancen la Etapa 1 y limiten el uso de las ruedas de entrenamiento, mientras aún dependen de un solo mecanismo de prueba para asegurar un sistema a prueba de fallos incipiente. Además, un solo sistema a prueba de fallos es tan bueno como la fortaleza del consejo de seguridad que puede supervisarlo. Para la primera fase, un consejo de seguridad de 14 personas ha sido ratificado por la Gobernanza de Optimism para gobernar la seguridad de la Superchain, y un objetivo clave en 2024 es que este consejo de seguridad administre las claves de actualización del ecosistema bajo la dirección de la Gobernanza de Optimism, de manera independiente a la Fundación de Optimism.

Gran parte de la planificación y desarrollo en OP Labs durante el último año y medio ha sido poner a todo el ecosistema de Optimism en una posición en la que alcanzar la descentralización en la Etapa 2 no solo sea realista, sino alcanzable. ¡Estamos emocionados de emprender ese viaje el próximo año, junto con todos los demás en el Collective!