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

En este número especial de Devs on Devs, hemos invitado a tdot(, desarrollador del protocolo central de Plasma Mode y también 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 necesitan 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 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 en 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, 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 soporte estas necesidades y que además 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 ajusta a la filosofía de Ethereum y es completamente compatible con EVM." Lo que funciona en la red principal puede funcionar igual en OP Stack, esa es la solución ideal. Pero queremos que sea más barato.

En ese momento, calldata seguía siendo la disponibilidad de datos de la cadena OP Stack ( DA ), lo que era muy costoso. Así que claramente 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 probar otras soluciones de disponibilidad de datos ( Alt DA ). De hecho, ya se mencionó en la documentación inicial de OP Stack la exploración de Alt DA.

Así que nos preguntamos: "¿Qué pasaría si comenzamos desde DA fuera de la cadena?" Esperamos que todo el modelo de seguridad y todo lo que implica pueda depender de Ethereum L1. Por lo tanto, evitamos otras soluciones 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 conceptos antiguos de Plasma y colocarlos sobre rollup. Hay algunas diferencias aquí. La mayor duda 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 hacer la menor cantidad de cambios en 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 de otro lugar?" A pesar de estos cambios, el OP Stack sigue siendo muy potente y funciona muy bien de forma predeterminada. Este es el primer cambio que hemos realizado.

Después, necesitamos escribir un contrato para crear estos desafíos. Hay un desafío de DA que obliga 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 de L1, en caso de que los datos se envíen a la cadena durante la 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 hemos intentado reinventar la rueda ni cambiar todo el OP Stack, sino que hemos intentado 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 de los primeros trabajos de Lattice. Justo en ese mismo momento, nosotros en Optimism hicimos una reescritura de extremo a extremo de toda la pila OP, 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 llevar todas las experiencias aprendidas al extremo, ¿cómo sería eso?" Esto evolucionó hacia lo que finalmente se llamó el repositorio de 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 respiramos aliviados, porque otros también pueden utilizar 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 grandes 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 asombrosas es una gran confirmación. Luego, ver cómo esta situación se expande en la aplicación práctica a Plasma 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. La tarea que asumimos en ese momento superaba con creces la capacidad de la comunidad de escalado 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 ver por separado la prueba y el desafío de la validación de estado de los desafíos de datos. Al final, hace unos años nos dimos cuenta de que los Rollups son mucho más simples que Plasma. Creo que, en ese momento, la conclusión de la comunidad 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 primero una tarea más simple". Ahora utilizamos diferentes términos. Por ejemplo, en ese momento había conceptos como (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 realmente 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, ustedes han hecho unas abstracciones maravillosas alrededor de ello y han logrado que funcione 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 aún estamos trabajando. La clave es cómo evitar gastar hasta diez años. ¿Entiendes lo que quiero decir? Necesitamos alcanzar lo antes posible una fase 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 pueda lanzarse rápidamente y que funcione para ejecutar todas estas aplicaciones, de modo que puedan desarrollarse en paralelo y mejorar mientras resolvemos problemas. Desde el desarrollo hasta la implementación, la estabilidad de producción lleva mucho tiempo.

Para poner algo en línea en la mainnet, hacerlo sin permiso, sólido y seguro, se requiere una gran cantidad de tiempo. Ver todo el proceso para lograr este objetivo ha sido 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. 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 podría decirse que es una carga técnica. El principio de mínima modificación que mencionaste, es uno de los conceptos centrales en 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 en sí mismo. Porque tienes razón, estas cosas son realmente difíciles.

Cada línea de código que se añade te aleja más del entorno de producción, hace que las cosas sean más difíciles de probar en la práctica y introduce más oportunidades de error. Por lo tanto, agradecemos mucho todos sus esfuerzos en impulsar este proceso, especialmente la contribución al nuevo modelo operativo de OP Stack.

tdot: OP Stack ha creado una forma de avanzar rápidamente en este tipo de cosas. Coordinar a todos es muy difícil, porque evidentemente 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 forma regular. Desde el punto de vista de la coordinación, esto realmente no es fácil.

Ben: Sí, definitivamente aún queda un largo camino por recorrer. Pero esa es precisamente la atracción central de la modularidad. Para mí, desde la perspectiva de OP Stack, esto 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. Puramente desde la perspectiva de OP Stack, este es un ejemplo muy poderoso que demuestra que muchos excelentes desarrolladores principales ya se han unido y han mejorado este stack, lo cual es impresionante.

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

tdot: La situación ha mejorado. A partir de este ejemplo, han convertido todo en pequeños módulos independientes que se pueden ajustar y modificar. Así que estoy muy emocionado por ver qué nuevas funciones se integrarán. Recuerdo que una vez estábamos preocupados porque teníamos un fork que contenía todos los cambios en OP Stack y 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 fue muy fluido. La atmósfera de colaboración con el equipo fue muy buena, por lo que el proceso de revisión también fue agradable. Se sintió muy natural. Además, creo que el proceso fue muy rápido en la revisión y resolución de algunos problemas potenciales. 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 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 permisos, con el objetivo final de lograr funcionalidades como la ausencia 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 es más fácil no estar en la red principal, porque así no es necesario realizar bifurcaciones duras. Puedes pensar, "oh, solo tengo que esperar a que todo esté completamente listo antes de lanzar, así no tengo que hacer bifurcaciones duras y no hay carga técnica." Pero, si deseas lanzar rápidamente en la red principal, debes manejar estas actualizaciones complejas y publicar con frecuencia. Hacer esto y mantener alta disponibilidad siempre es un desafío.

Creo que habrá muchas actualizaciones en el aspecto del modelo Plasma una vez que el mecanismo de prueba de fallos y todas estas partes estén listas. Creo que todavía hay un poco de margen de optimización en el envío masivo de compromisos. 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.

Por el momento, mantenemos las cosas lo más simples posible, de modo que la revisión pueda ser sencilla y rápida, y no haya grandes diferencias con el OP Stack. Sin embargo, ahora hay algunas optimizaciones que pueden hacerlo más económico, como agrupar los commitments o enviarlos a un blob, o adoptar otros métodos diferentes. Así que definitivamente estudiaremos 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 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 cuáles son las diferentes suposiciones de seguridad.

Ben: Hablando de eso,