DEVS ON DEVS: Diálogo entre TDOT y BEN JONES

En esta edición especial de "Desarrolladores para Desarrolladores", hemos invitado a tdot, desarrollador del protocolo central de Plasma Mode (que 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 sin necesidad de publicar datos en L1, sino que pueden cambiar de manera flexible a proveedores de datos fuera de la cadena, lo que ahorra costos y mejora la escalabilidad. En esta conversación, discutieron el origen de la colaboración entre Redstone y Optimism, la importancia de revivir Plasma, la necesidad de introducir protocolos experimentales en el entorno de producción, la hoja de ruta futura de Plasma Mode y OP Stack, así como su entusiasmo por 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 de mejora del OP Stack?

tdot: Me uní a Lattice hace aproximadamente un año, encargado específicamente del Modo Plasma. El objetivo es muy claro: tenemos muchas aplicaciones MUD que consumen una gran cantidad de gas, mientras intentamos poner una gran cantidad de datos en la cadena, por lo que necesitamos una solución que apoye estas necesidades y que 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.

Así que 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 alinea con la filosofía de Ethereum y que es totalmente 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 (DA) de la cadena OP Stack, lo cual era muy costoso. Así que evidentemente no podíamos iniciar un L2 con calldata, ya que nuestro juego de cadena completa y el mundo MUD requieren un mayor rendimiento. Por lo tanto, decidimos comenzar a explorar otras soluciones de disponibilidad de datos (Alt DA). De hecho, ya se mencionó en la documentación inicial de OP Stack 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 efectivo en L1.

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

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

Después, necesitamos escribir un contrato para crear estos desafíos. Hay desafíos de DA para forzar que los datos se suban 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 derivado, 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 la resolución del desafío.

Este es el meollo del asunto. Es complicado, porque queremos mantener las cosas elegantes y robustas. Al mismo tiempo, es un concepto relativamente simple. No hemos intentado reinventar la rueda ni cambiar toda la pila OP, sino que hemos intentado 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 casi reescribimos todo el OP Stack de extremo a extremo, a esta publicación la llamamos Bedrock.

Básicamente, después de construir rollup durante dos años, dimos un paso atrás y reflexionamos: "Bueno, si vamos a llevar toda la experiencia aprendida 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 con ustedes en un proyecto llamado OPCraft, y creo que Biomes es su heredero 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 solo aquellas personas que han desarrollado una enorme y compleja base de código pueden hacer esto. Cuando comenzamos a colaborar, ver a otros hacerse cargo de esta base de código y hacer cosas realmente asombrosas es una gran afirmación. Luego ver que esta situación se expande a Plasma en la aplicación práctica es increíble. 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 escalado. 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 sencillo. Separaremos la prueba y el desafío de la verificación de estado del desafío de 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 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 OP Stack está siendo utilizado por otros, sino que también ha evolucionado a lo que inicialmente intentamos hacer, pero de una manera muy confusa e inmadura. Hemos completado un ciclo completo, y ustedes han hecho abstracciones increíbles alrededor de ello, haciéndolo funcionar de 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, y seguimos trabajando en ello. La clave es cómo evitar gastar hasta diez años. ¿Sabes a qué me refiero? Necesitamos alcanzar lo antes posible una etapa en la que podamos entregar resultados.

Esta es nuestra idea. Ya tenemos muchas aplicaciones basadas en MUD que desean lanzarse inmediatamente en la mainnet. Necesitamos preparar una mainnet para estos juegos lo antes posible. La gente ya está esperando y lista. Necesitas una cadena que se pueda lanzar rápidamente y que funcione, para ejecutar todas estas aplicaciones, de modo que estas aplicaciones puedan desarrollarse en paralelo y mejorar mientras resolvemos problemas. Desde la I+D hasta la implementación de la estabilidad de producción lleva mucho tiempo.

Para lanzar algo en la mainnet de manera sin permisos, robusta y segura, se necesita una gran cantidad de tiempo. Ver todo el proceso que hemos logrado para alcanzar este objetivo es realmente impresionante. Por eso necesitamos mantener una alta agilidad, ya que hay demasiadas cosas. Todo el ecosistema se está desarrollando muy rápido. Creo que todos están entregando una gran cantidad de innovación. Es por eso que debes mantener el ritmo, 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 de nuestra reescritura de Bedrock. Hablé sobre la reescritura de extremo a extremo, pero lo más importante es que redujimos 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 adicional te aleja más del entorno de producción, haciendo que sea más difícil probar las cosas en la práctica y introduciendo más oportunidades de error. Así que, estamos muy agradecidos por todos sus esfuerzos en impulsar este proceso, especialmente por la contribución al nuevo modo de operación de OP Stack.

tdot： OP Stack ha creado una manera de avanzar rápidamente en este tipo de cosas. Es muy difícil coordinar a todos, ya que 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í, definitivamente todavía 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 asombrosos juegos y mundos virtuales que se están construyendo actualmente en Redstone. Desde la perspectiva de OP Stack, este es un ejemplo muy poderoso que demuestra que muchos excelentes desarrolladores centrales se han unido y han mejorado este stack, lo cual es realmente impresionante.

Es la primera vez que puedes cambiar significativamente las propiedades del sistema a través de un valor booleano clave. Poder lograr esto por completo, como mencionas, realmente hay un largo camino por recorrer. Pero incluso acercarse a hacerlo de manera efectiva requiere soporte 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, lo que permite ajustar y cambiar propiedades. Así que estoy muy ansioso por ver qué nuevas funciones se integrarán. Recuerdo que solíamos preocuparnos de que tuviéramos un fork que incluía todos los cambios en el OP Stack, y que necesitábamos fusionarlo 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 fue excelente, así que el proceso de revisión también fue agradable. Se sintió muy natural. Y creo que en la revisión y la resolución de algunos problemas potenciales, el proceso fue muy rápido. Todo salió inesperadamente bien.

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 eso, 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 permiso, con el objetivo final de lograr funciones como la falta de permiso y la salida forzada.

Tenemos este objetivo final y lo alcanzamos gradualmente mientras mantenemos la seguridad. Un desafío es que a veces es más fácil no lanzar la red principal, porque 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 necesitaré hacer un hard fork y no habrá carga técnica." Sin embargo, si deseas lanzar la red principal rápidamente, debes manejar estas complejas actualizaciones y lanzar 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 fallos y todas estas partes estén preparadas. Creo que todavía hay espacio para optimizar en el envío por lotes de compromisos. Ahora lo hacemos de forma 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.

Por ahora mantenemos las cosas lo más simples posible, de esta manera la revisión puede ser sencilla y rápida, y no hay grandes diferencias con OP Stack. Sin embargo, ahora hay algunas optimizaciones que pueden hacerlo 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.

Estamos muy emocionados por esto. 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 tienen que ser realizados por ustedes. Pero queremos entender cómo se ven en el modo Plasma, y