Entrevista con los desarrolladores de Optimism y Redstone: El modo Plasma redefine la Capa 2

En esta edición de entrevistas especiales, invitamos a tdot(, el desarrollador del protocolo central de Plasma Mode, quien también es desarrollador de Redstone ), y a Ben Jones, cofundador de Optimism. Optimism es el principal impulsor de OP Stack. Plasma Mode permite a los desarrolladores construir sobre OP Stack, pero no necesita publicar datos en L1, sino que puede cambiar de manera flexible a proveedores de datos fuera de la cadena, ahorrando costos y mejorando la escalabilidad. En esta conversación, exploraron los orígenes de la colaboración entre Redstone y Optimism, la importancia de revivir Plasma, la necesidad de introducir protocolos experimentales en entornos de producción, la hoja de ruta futura de Plasma Mode y OP Stack, así como su entusiasmo por el desarrollo en el campo de los juegos de cadena completa.

01. Cómo mejorar la OP Stack utilizando el modo Plasma

Ben: ¿Cómo es el proceso de mejora de OP Stack?

tdot: Hace aproximadamente un año que me uní a Lattice, encargándome específicamente del Modo Plasma. El objetivo es muy claro: tenemos muchas aplicaciones MUD que consumen una gran cantidad de gas, mientras intentamos poner grandes cantidades de datos en la cadena, por lo que necesitamos una solución que apoye estas demandas y sea económica. El equipo de Lattice ya ha realizado algunas pruebas en OP Stack, como la creación de prototipos de algunos mundos en cadena y su implementación en OP Stack. Hemos descubierto que OP Stack ya es muy útil.

Entonces nos preguntamos: "¿Cómo podemos hacerlo más barato?" La suposición básica es: "Creemos que OP Stack es el marco que más se ajusta a la filosofía de Ethereum y es completamente compatible con EVM." Lo que funciona en la red principal puede funcionar igualmente en OP Stack, esta es la solución ideal. Pero queremos que sea más barato.

En ese momento, calldata seguía siendo la fuente de disponibilidad de datos de la cadena OP Stack (DA), lo cual era muy costoso. Por lo tanto, claramente no podíamos usar calldata para lanzar un L2, ya que nuestro juego completo en cadena y el mundo MUD requieren un mayor rendimiento. Por ello, decidimos comenzar a explorar otras soluciones de disponibilidad de datos (Alt DA). De hecho, en los documentos iniciales de OP Stack ya se mencionó la necesidad de explorar Alt DA.

Entonces nos preguntamos: "¿Qué pasaría si comenzamos desde DA fuera de la cadena?" Esperamos que todo el modelo de seguridad y todo lo demás pueda depender de Ethereum L1. Por lo tanto, evitamos otras soluciones de Alt DA y decidimos almacenar los datos en un almacenamiento DA centralizado, y luego encontrar un modelo de seguridad eficaz en L1.

Esta es la razón por la que queremos reutilizar algunos conceptos antiguos de Plasma y colocarlos sobre la Capa 2. Aquí hay algunas diferencias. La mayor pregunta es, ¿cómo implementar la DA fuera de la cadena y los desafíos de datos en la cadena sobre la pila OP existente? Nuestro objetivo es hacer el mínimo cambio posible a la pila OP, sin afectar el camino del rollup, ya que no queremos impactar la seguridad de otras cadenas de rollup que utilizan la pila OP.

Al diseñar un rollup, no piensas: "¿Qué pasaría si alguien cambiara el proceso de generación de datos para almacenar datos desde otro lugar?" Incluso con estos cambios, OP Stack sigue siendo muy poderoso y funciona muy bien listo para usar. Este es el primer cambio que hicimos.

Después, necesitamos escribir contratos para crear estos desafíos. Hay desafíos de DA que obligan a llevar los datos a la cadena. Este es el segundo paso, integrar los contratos en el proceso. Debemos construir todo el sistema de integración en el proceso de derivación, de modo que puedas derivar datos de una fuente de DA fuera de la cadena y de un contrato de desafío de DA de L1, en caso de que los datos se envíen a la cadena durante el proceso de resolución del desafío.

Este es el punto clave. Es complicado, porque queremos mantener las cosas elegantes y sólidas. Al mismo tiempo, es un concepto relativamente simple. No hemos intentado reinventar todo ni cambiar toda la OP Stack, sino que intentamos mantener las cosas simples en un entorno complejo. Así que, en general, este es un viaje de ingeniería muy genial.

Ben: Puedo hablar desde la perspectiva de OP. Mencionaste algunos trabajos tempranos de Lattice. Justo al mismo tiempo, nosotros en Optimism hicimos una reescritura completa de toda la Capa 2 de OP, a esta publicación la llamamos Bedrock.

Básicamente, después de construir un rollup durante dos años, dimos un paso atrás y reflexionamos: "Bueno, si vamos a llevar al máximo toda la experiencia que hemos aprendido, ¿cómo sería eso?" Esto evolucionó al que finalmente se llamó la biblioteca de código Bedrock, que es nuestra mayor actualización a la red.

En ese momento, colaboramos con ustedes en un proyecto llamado OPCraft, creo que Biomes es su sucesor espiritual, fue la vez que más nos divertimos jugando en la cadena. Al mismo tiempo, también suspiramos aliviados, porque otras personas también pueden desarrollar usando OP Stack. Creo que otro punto de inflexión importante en la escalabilidad en los últimos años es que muchas personas pueden ejecutar la cadena.

No son solo aquellos que han desarrollado grandes y complejas bibliotecas de código quienes pueden lograr esto. Cuando comenzamos a colaborar, ver a otros capaces de hacerse cargo de esta biblioteca de código y hacer cosas realmente increíbles es una gran validación. Luego, ver cómo esta situación se expande en aplicaciones reales a Capa 2 es realmente genial. Incluso puedo hablar un poco sobre esa historia.

Antes de que Optimism se convirtiera en Optimism, en realidad estábamos investigando una tecnología llamada Plasma. En ese momento, la tarea que asumimos superaba con creces la capacidad de la comunidad de escalabilidad de entonces. El diseño que ves en los primeros diseños de Plasma puede no tener una relación directa con el Plasma de hoy.

Hoy en día, Plasma es mucho más simple. Vamos a separar la prueba y el desafío de la verificación de estado del desafío de los datos. Al final, hace unos años nos dimos cuenta de que los Rollups son mucho más simples que Plasma. Creo que la conclusión de la comunidad en ese momento fue "Plasma está muerto". Este es un meme de la historia de la escalabilidad de Ethereum de esa época.

Pero siempre hemos creído que "Plasma no ha muerto, solo que podemos intentar una tarea más simple primero". Ahora usamos términos diferentes. Por ejemplo, en ese momento había conceptos como salidas (exits), ahora puedes mirar hacia atrás y decir "oh, eso era un desafío de disponibilidad de datos con algunos pasos adicionales". Así que es asombroso ver que no solo el OP Stack está siendo utilizado por otros, sino que también ha evolucionado en algo que intentamos originalmente, pero de una manera muy confusa e inmadura. Hemos completado un ciclo completo, ustedes han hecho abstracciones increíbles alrededor de ello, y lo han hecho funcionar de una manera razonable y sensata. Eso es realmente genial.

02. Lo más importante es entrar en el entorno de producción lo antes posible

tdot: El modo Plasma todavía presenta algunos desafíos y problemas no resueltos, en los que seguimos trabajando. La clave es cómo evitar gastar hasta diez años en ello. ¿Sabes a lo que me refiero? Necesitamos alcanzar lo más pronto posible una etapa en la que podamos entregar resultados.

Esta es nuestra idea. Ya tenemos muchas aplicaciones basadas en MUD que queremos lanzar en la mainnet de inmediato. Necesitamos preparar una mainnet para estos juegos lo antes posible. La gente ya está esperando y está lista. Necesitas una cadena que se lance rápidamente y que pueda funcionar, para ejecutar todas estas aplicaciones, de modo que estas aplicaciones puedan desarrollarse en paralelo y mejorar mientras nosotros resolvemos problemas. Desde la investigación y desarrollo hasta lograr la estabilidad en producción lleva mucho tiempo.

Para lanzar algo en la mainnet, hacerlo sin permisos, robusto y seguro, se requiere mucho tiempo. Ver todo el proceso que hemos llevado a cabo para lograr este objetivo ha sido realmente asombroso. Por eso necesitamos mantener una alta agilidad, porque hay demasiadas cosas. Todo el ecosistema se está desarrollando muy rápido. Creo que todos están entregando una gran cantidad de innovaciones. Por eso debes mantenerte al día, pero tampoco puedes comprometer la seguridad y el rendimiento, de lo contrario el sistema no podrá funcionar.

Ben: O se podría decir que es una carga técnica. El principio de mínima modificación que mencionaste es una de las ideas centrales en nuestra reescritura de Bedrock. Hablé sobre la reescritura completa de extremo a extremo, pero lo más importante es que redujimos aproximadamente 50,000 líneas de código, lo cual es muy poderoso en sí mismo. Porque tienes razón, estas cosas son realmente difíciles.

Cada línea de código que se agrega te aleja más del entorno de producción, dificultando que las cosas pasen por pruebas en la vida real y introduciendo más oportunidades de error. Por lo tanto, agradecemos enormemente todos sus esfuerzos en impulsar este proceso, especialmente las contribuciones al nuevo modo de operación de OP Stack.

tdot: OP Stack realmente ha creado una manera de avanzar rápidamente en este tipo de cosas. Coordinar a todos es muy difícil, porque claramente somos dos empresas diferentes. En Lattice, estamos construyendo un juego, un motor de juego y una cadena.

Y ustedes están construyendo cientos y miles de cosas, y entregando todos estos productos de manera regular. Desde el punto de vista de la coordinación, esto no es nada fácil.

Ben: Sí, definitivamente aún hay un largo camino por recorrer. Pero esa es precisamente la esencia del atractivo de la modularidad. Para mí, desde la perspectiva de OP Stack, esta es una de las cosas más emocionantes, sin mencionar los increíbles juegos y mundos virtuales que se están construyendo ahora en Redstone. Desde una perspectiva puramente de OP Stack, es un ejemplo muy poderoso que demuestra que muchos excelentes desarrolladores principales se han unido y han mejorado este stack, lo cual es impresionante.

Esta es la primera vez, puedes cambiar significativamente las propiedades del sistema a través de un valor booleano clave. Poder lograr esto completamente, como tú dijiste, todavía queda un largo camino por recorrer. Pero incluso acercarse a hacerlo de manera efectiva también requiere apoyo modular, ¿verdad? Para nosotros, ver que ustedes lograron esto sin necesidad de, por ejemplo, reescribir L2 Geth, realmente es un alivio. Para mí, esto demuestra que la modularidad está funcionando.

tdot: La situación ahora ha mejorado. A partir de este ejemplo, han convertido todo en pequeños módulos independientes que se pueden ajustar y cambiar atributos. Así que estoy muy ansioso por ver qué nuevas funciones se integrarán. Recuerdo que una vez nos preocupaba que teníamos una bifurcación que contenía todos los cambios en OP Stack, y que necesitábamos fusionarla en la rama principal. En ese momento pensamos: "Dios mío, revisar todo sería una locura."

Tuvimos que descomponerlo en partes más pequeñas, pero todo el proceso se llevó a cabo de manera muy fluida. La atmósfera de colaboración con el equipo es muy buena, por lo que el proceso de revisión también fue muy agradable. Se siente muy natural. Y creo que en la revisión y resolución de algunos problemas potenciales, este proceso fue muy rápido. Todo fue sorprendentemente fluido.

Ben: Esto es realmente genial. Este año, uno de nuestros enfoques es crear un camino de contribución para OP Stack. Así que estoy muy agradecido por su participación en las pruebas, impulsando estos procesos. Me alegra que estos procesos no hayan sido abrumadores y que hayamos logrado algunos resultados. Hablando de esto, tengo curiosidad, desde tu perspectiva, ¿cómo crees que se desarrollará este trabajo a continuación? ¿Qué es lo que más esperas desarrollar a continuación?

tdot: Hay muchas direcciones de trabajo diferentes. Principalmente se trata de la integración con el mecanismo de prueba de fallos. Adoptamos un enfoque progresivo para descentralizar toda la pila tecnológica y aumentar sus características sin permisos, con el objetivo final de lograr funciones como permisos sin licencia y salida forzada.

Tenemos este objetivo final y lo estamos logrando gradualmente mientras mantenemos la seguridad. Un desafío es que, a veces, no lanzar en la mainnet es más fácil, porque así no se necesita realizar un hard fork. Podrías pensar: "Oh, solo esperaré a que todo esté completamente listo para lanzar, así no hay necesidad de hacer un hard fork ni carga técnica." Sin embargo, si deseas lanzar rápidamente en la mainnet, debes lidiar con estas complejas actualizaciones y publicar con frecuencia. Hacer esto y mantener una alta disponibilidad siempre es un desafío.

Creo que habrá muchas mejoras en el aspecto del modo Plasma después de que el mecanismo de prueba de fallos y todas estas partes estén listas. Creo que todavía hay espacio para optimizar en términos de envío masivo de compromisos. Ahora lo hacemos de manera muy simple, un compromiso por cada transacción. Y el compromiso es simplemente el valor hash de los datos de entrada almacenados fuera de la cadena.

Por ahora, mantenemos las cosas lo más simples posible, de modo que la revisión sea sencilla y rápida, y no haya grandes diferencias con OP Stack. Sin embargo, ahora hay algunas optimizaciones que pueden hacer que sea más barato, como agrupar los compromisos o enviarlos al blob, o adoptar otros métodos diferentes. Así que definitivamente investigaremos esto para reducir los costos de L1.

Esto es algo que nos emociona mucho. Por supuesto, también estamos muy ansiosos por todo el contenido relacionado con la interoperabilidad que se avecina y poder interactuar entre todas las cadenas. Aclarar esto será un gran avance para los usuarios.

Muchos de estos trabajos definitivamente tendrán que ser realizados por ustedes. Pero queremos entender cómo son en el modo Plasma y qué diferentes supuestos de seguridad tienen.

Ben: Hablando de esto, esto