DEVS ON DEVS: Conversación entre TDOT y BEN JONES

En esta edición de la entrevista especial "Devs on Devs", hemos invitado a tdot(, desarrollador del protocolo central de Plasma Mode y también desarrollador de Redstone ), así como 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 forma flexible a proveedores de datos fuera de la cadena, lo que ahorra costos y mejora la escalabilidad. En esta conversación, discutieron los orígenes de la colaboración entre Redstone y Optimism, la importancia de revitalizar Plasma, la necesidad de introducir protocolos experimentales en entornos de producción, la hoja de ruta futura de Plasma Mode y OP Stack, y sus expectativas sobre el desarrollo en el ámbito de los juegos en toda la cadena.

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

Ben: ¿Cómo es el proceso para comenzar a mejorar OP Stack?

tdot: Me uní a Lattice hace aproximadamente un año, y me encargo específicamente de Plasma Mode. El objetivo es claro: tenemos muchas aplicaciones MUD que consumen una gran cantidad de gas, y al mismo tiempo estamos tratando de poner una gran cantidad de datos en la cadena, por lo que necesitamos una solución que sea económica y que soporte estas necesidades. El equipo de Lattice ya ha realizado algunas pruebas en OP Stack, como prototipar algunos mundos en cadena y desplegarlos 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 mainnet también puede funcionar en OP Stack, esa 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 OP Stack, lo cual era muy costoso. Así que claramente no podíamos iniciar un L2 con calldata, ya que nuestro juego en cadena completo y el mundo MUD requieren un mayor rendimiento. Por lo tanto, decidimos empezar a probar otras soluciones de disponibilidad de datos Alt DA. De hecho, en la documentación inicial de OP Stack ya se mencionaba 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 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 efectivo en L1.

Esta es la razón por la cual necesitamos reutilizar algunos conceptos antiguos de Plasma y colocarlos sobre rollup. Aquí hay algunas diferencias. La mayor pregunta es, ¿cómo implementar la DA fuera de cadena y los desafíos de datos en cadena sobre el OP Stack existente? Nuestro objetivo es hacer la menor modificación posible al OP Stack, sin afectar el camino del rollup, porque no queremos afectar la seguridad de otras cadenas de rollup que utilizan el OP Stack.

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

Después, necesitamos redactar un contrato 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 el contrato 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 en 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 de la cuestión. Es complicado, porque queremos mantener las cosas elegantes y robustas. Al mismo tiempo, es un concepto relativamente simple. No estamos tratando de reinventar la rueda ni cambiar toda la pila OP, sino de intentar mantener las cosas simples en un entorno complejo. Así que, en general, ha sido un viaje de ingeniería muy genial.

Ben: Puedo hablar desde la perspectiva de OP. Mencionaste algunos trabajos tempranos de Lattice. Justo en ese mismo momento, nosotros en Optimism prácticamente reescribimos todo el OP Stack de extremo a extremo, y a esta versión la llamamos Bedrock.

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

En ese momento, colaboramos contigo 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 respiramos aliviados, porque otros también pueden usar OP Stack para desarrollar. 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 enormes y complejas bibliotecas de código los que pueden hacer esto. Cuando comenzamos a colaborar, ver a otros poder hacerse cargo de esta biblioteca de código y hacer cosas realmente increíbles es una gran validación. Luego, ver que esta situación se expande a Plasma en aplicaciones reales es simplemente 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. La tarea que asumimos en ese momento superaba con creces la capacidad de la comunidad de escalabilidad de entonces. El diseño que ves en el diseño temprano de Plasma puede no tener una relación directa con el Plasma de hoy.

Hoy, Plasma es mucho más simple. Separaremos la prueba y el desafío de la validació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 ese período.

Pero siempre hemos creído que "Plasma no ha muerto, solo que podemos intentar primero una tarea más simple". Ahora usamos diferentes términos. Por ejemplo, en ese momento había conceptos como (exits), ahora puedes mirar hacia atrás y decir "oh, eso fue un desafío de disponibilidad de datos con algunos pasos adicionales". Así que es asombroso ver no solo que OP Stack está siendo utilizado por otros, sino que también ha evolucionado en algo que originalmente intentamos, pero de una manera muy confusa e inmadura. Hemos completado un ciclo completo, y ustedes han hecho abstracciones increíbles alrededor de eso, haciéndolo 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 enfrenta algunos desafíos y problemas no resueltos, en los que seguimos trabajando. La clave es ¿cómo evitar gastar hasta diez años? ¿Entiendes lo que quiero decir? Necesitamos llegar lo antes posible a 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 pueda lanzar rápidamente y que funcione, para ejecutar todas estas aplicaciones, de modo que puedan desarrollarse en paralelo y mejorar mientras resolvemos los problemas. Desde la investigación y desarrollo hasta la implementación de la estabilidad en producción, toma mucho tiempo.

Para poner algo en la mainnet, hacerlo sin permisos, robusto y seguro, se necesita una gran cantidad de tiempo. Ver todo el proceso que hemos logrado para alcanzar este objetivo es realmente asombroso. Es por eso que necesitamos mantener una alta agilidad, porque hay demasiadas cosas. Todo el ecosistema está evolucionando muy rápido. Creo que todos están entregando una gran cantidad de innovaciones. Por eso tienes que mantenerte al día, pero tampoco puedes comprometer la seguridad y el rendimiento, de lo contrario el sistema no podrá funcionar.

Ben: O quizás se trate de una carga técnica. El principio de la mínima intervención que mencionas es una de las ideas centrales de nuestra reescritura de Bedrock. Hablé sobre la reescritura completa de extremo a extremo, pero lo más importante es que hemos reducido alrededor de 50,000 líneas de código, lo cual es muy poderoso por sí mismo. Porque tienes razón, estas cosas son realmente difíciles.

Cada línea de código que agregas te aleja más del entorno de producción, dificultando que las cosas sean probadas en situaciones reales y generando más oportunidades de errores. Por lo tanto, agradecemos mucho todos los esfuerzos que han realizado para impulsar este proceso, especialmente la contribución al nuevo modelo operativo de OP Stack.

tdot: OP Stack realmente ha creado una forma 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 realmente no es fácil.

Ben: Sí, todavía queda un largo camino por recorrer. Pero esa es precisamente la esencia de la modularidad. Para mí, desde la perspectiva del OP Stack, esta es una de las cosas más emocionantes, sin mencionar los juegos y mundos virtuales asombrosos que se están construyendo ahora en Redstone. Puramente desde la perspectiva del OP Stack, este es un ejemplo muy poderoso de que muchos excelentes desarrolladores principales ya 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 por completo, como dijiste, definitivamente hay un largo camino por recorrer. Pero incluso acercarse a hacerlo de manera efectiva requiere apoyo modular, ¿verdad? Para nosotros, ver que ustedes han logrado 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 emocionado de ver qué nuevas funciones se integrarán. Recuerdo que nos preocupaba que tuviéramos una bifurcación que incluía todos los cambios en el OP Stack, y que necesitábamos fusionarlos 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 transcurrió muy bien. La atmósfera de colaboración con el equipo es excelente, por lo que el proceso de revisión también fue agradable. Se sintió muy natural. Además, creo que en la revisión y la resolución de algunos problemas potenciales, el proceso avanzó muy rápido. Todo fue sorprendentemente fluido.

Ben: Esto es realmente genial. Este año, uno de nuestros enfoques es crear rutas de contribución para OP Stack. Así que agradezco mucho su participación en las pruebas, impulsando estos procesos. Estoy contento de 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 integra 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 la falta de permisos y la 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 red principal es más fácil, ya que así no es necesario realizar un hard fork. Podrías pensar: "Oh, solo tengo que esperar hasta que todo esté completamente listo para lanzar, así no necesito hacer un hard fork y no hay carga técnica." Pero, si deseas lanzar rápidamente en la red principal, debes manejar 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 una vez que el mecanismo de prueba de fallo y todas estas partes estén listas. Creo que todavía hay espacio para optimizaciones en la presentación de compromisos por lotes. Ahora lo hacemos de manera muy simple, un compromiso por cada transacción. Y el compromiso es solo el valor hash de los datos de entrada almacenados fuera de la cadena.

Mantenemos las cosas lo más simples posible por el momento, para que la revisión sea simple 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 a un 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 esperamos con ansias todo el contenido relacionado con la interoperabilidad que se avecina y la capacidad de interactuar entre todas las cadenas. Aclarar esto será un gran avance para los usuarios.

Muchos de estos trabajos seguramente deberán ser realizados por ustedes. Pero queremos entender cómo se ven bajo el modo Plasma y cuáles son las diferentes hipótesis de seguridad.

Ben: Hablando de esto, será sobre OP Stack