En este número especial de Devs on Devs, invitamos a tdot(, el desarrollador del protocolo central de Plasma Mode y también desarrollador de Redstone ), junto con Ben Jones, cofundador de un conocido proyecto de Layer 2, para dialogar. Este conocido proyecto de Layer 2 es un impulsor clave del OP Stack. Plasma Mode permite a los desarrolladores construir sobre el OP Stack sin necesidad de publicar datos en L1, sino que pueden cambiar de manera flexible a proveedores de datos fuera de la cadena, ahorrando costos y mejorando la escalabilidad. En esta conversación, exploraron el origen de la colaboración entre Redstone y el proyecto de Layer 2, la importancia de revivir Plasma, la necesidad de llevar protocolos experimentales al entorno de producción, la hoja de ruta futura de Plasma Mode y el OP Stack, así como su entusiasmo por el desarrollo del campo de los juegos en la cadena.
Cómo usar el modo Plasma para mejorar OP Stack
Ben: ¿Cómo es el proceso para comenzar a mejorar OP Stack?
tdot: Me uní a Lattice hace aproximadamente un año, específicamente para encargarme 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 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 la cadena y su despliegue en OP Stack. Hemos encontrado que OP Stack ya es muy fácil de usar.
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 alinea con la filosofía de Ethereum y es completamente compatible con EVM." Lo que funciona en la mainnet también puede funcionar 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 iniciar un L2, ya que nuestro juego de cadena completa y el mundo MUD requieren un mayor rendimiento. Así que 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 que se debía explorar Alt DA.
Así que nos preguntamos: "¿Qué pasaría si comenzáramos 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 DA alternativo 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. Aquí hay algunas diferencias. La mayor pregunta es, ¿cómo implementar la DA fuera de la cadena y el desafío de datos en la cadena sobre la pila OP existente? Nuestro objetivo es hacer el menor número de cambios posible en la pila OP, sin afectar la ruta de rollup, porque 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 cambia el proceso de generación de datos para almacenar datos en otro lugar?" Incluso con estos cambios, el OP Stack sigue siendo muy robusto y funciona bien desde el primer momento. Este es el primer cambio que hemos realizado.
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 durante el proceso de derivación, para 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 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 momento, casi hicimos una reescritura de extremo a extremo de toda la pila de OP, a esta publicación la llamamos Bedrock.
Básicamente, después de construir el rollup durante dos años, dimos un paso atrás y reflexionamos diciendo: "Bueno, si queremos llevar toda la experiencia que hemos aprendido al extremo, ¿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, creo que Biomes es su heredero espiritual, fue la vez que más nos divertimos jugando en la cadena. Al mismo tiempo, también suspiramos 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 cadenas.
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 tomar este repositorio de código y hacer cosas realmente increíbles es una gran validación. Luego, ver cómo esta situación se expande a la aplicación práctica en Plasma es realmente genial. Incluso puedo hablar un poco sobre esa historia.
Antes de la fundación de un conocido proyecto de Layer 2, en realidad estábamos investigando una tecnología llamada Plasma. La tarea que asumimos en ese momento superó 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 validación del 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 escalado de Ethereum de ese período.
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 existían conceptos como (exits), y 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 no solo que 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, y ustedes han creado abstracciones fantásticas en torno a ello, haciéndolo funcionar de una manera razonable y sensata. Esto es realmente genial.
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 ellos. La clave es cómo evitar gastar hasta diez años en esto. ¿Sabes a qué me refiero? 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 desean lanzarse de inmediato en la mainnet. Necesitamos preparar una mainnet lo antes posible para estos juegos. 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 estas aplicaciones puedan desarrollarse en paralelo y mejorar mientras resolvemos problemas. Desde la investigación y desarrollo hasta lograr la estabilidad en producción, toma mucho tiempo.
Llevar algo a la mainnet, para que sea sin permisos, robusto y seguro, requiere mucho tiempo. Ver todo el proceso para lograr este objetivo es realmente asombroso. Por eso 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 debes estar al día, pero tampoco puedes comprometer la seguridad y el rendimiento, de lo contrario el sistema no funcionará.
Ben: O se podría decir que es una carga técnica. El principio de mínimo cambio que mencionas, es una de las ideas centrales en nuestra reescritura de Bedrock. Hablé sobre toda 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 contundente. 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, dificultando que las cosas pasen por pruebas prácticas y aumentando las oportunidades de errores. Por lo tanto, estamos muy agradecidos por todos los esfuerzos que han hecho para impulsar este proceso, especialmente por las contribuciones al nuevo modo de operación de OP Stack.
tdot: OP Stack ha creado efectivamente una forma de avanzar rápidamente en este tipo de cosas. Coordinar a todos es muy difícil, porque somos claramente 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 regularmente. Desde el punto de vista de la coordinación, esto realmente no es fácil.
Ben: Sí, de hecho, aún queda un largo camino por recorrer. Pero esa es precisamente la esencia 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 actualmente en Redstone. Desde la perspectiva de OP Stack, este es un ejemplo muy poderoso que demuestra que muchos excelentes desarrolladores principales se han unido y han mejorado este stack, lo cual es realmente impresionante.
Esta es la primera vez que puedes cambiar significativamente las propiedades del sistema a través de un valor booleano clave. Poder hacer esto de manera completa, como dijiste, ciertamente queda un largo camino por recorrer. Pero incluso acercarse a hacerlo de manera efectiva requiere soporte modular, ¿verdad? Para nosotros, es un gran alivio ver que han logrado esto sin necesidad de, por ejemplo, reescribir L2 Geth. 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 cambiar en sus propiedades. Así que estoy muy ansioso por ver qué nuevas funciones se integrarán. Recuerdo que nos preocupaba que tuviéramos una bifurcación que incluyera todos los cambios en OP Stack, y que necesitaríamos fusionarla en la rama principal. En ese momento pensamos: "Dios mío, sería una locura revisar todo."
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, por lo que el proceso de revisión también fue muy agradable. Se sintió muy natural. Y creo que en términos de revisión y resolución de algunos problemas potenciales, este proceso fue muy rápido. Todo salió sorprendentemente 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 de que estén participando en las pruebas, impulsando estos procesos. Estoy contento de 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 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 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 lanzar la mainnet, porque así no es necesario hacer un hard fork. Podrías pensar: "Oh, solo tengo que esperar hasta que todo esté completamente listo para lanzar, así no tengo que hacer un hard fork y tampoco tengo la carga técnica." Pero, si quieres lanzar la mainnet rápidamente, debes lidiar con estas complejas actualizaciones y lanzar frecuentemente. Hacer esto y mantener 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 listas. Creo que todavía hay espacio para optimizaciones en el compromiso de envío por lotes. Actualmente lo hacemos de una manera muy sencilla, un compromiso por cada transacción. Y el compromiso es simplemente el valor hash de los datos de entrada almacenados fuera de la cadena.
Mantenemos las cosas lo más simples posible por ahora, para que la revisión sea sencilla y rápida, y no haya grandes diferencias con OP Stack. Pero ahora hay algunas optimizaciones que pueden hacerlo más barato, como agrupar los compromisos o enviarlos.
Esta página puede contener contenido de terceros, que se proporciona únicamente con fines informativos (sin garantías ni declaraciones) y no debe considerarse como un respaldo por parte de Gate a las opiniones expresadas ni como asesoramiento financiero o profesional. Consulte el Descargo de responsabilidad para obtener más detalles.
Colisión entre Plasma Mode y OP Stack: el futuro de los juegos en la cadena completa
Devs on Devs: conversación entre tdot y Ben Jones
En este número especial de Devs on Devs, invitamos a tdot(, el desarrollador del protocolo central de Plasma Mode y también desarrollador de Redstone ), junto con Ben Jones, cofundador de un conocido proyecto de Layer 2, para dialogar. Este conocido proyecto de Layer 2 es un impulsor clave del OP Stack. Plasma Mode permite a los desarrolladores construir sobre el OP Stack sin necesidad de publicar datos en L1, sino que pueden cambiar de manera flexible a proveedores de datos fuera de la cadena, ahorrando costos y mejorando la escalabilidad. En esta conversación, exploraron el origen de la colaboración entre Redstone y el proyecto de Layer 2, la importancia de revivir Plasma, la necesidad de llevar protocolos experimentales al entorno de producción, la hoja de ruta futura de Plasma Mode y el OP Stack, así como su entusiasmo por el desarrollo del campo de los juegos en la cadena.
Cómo usar el modo Plasma para mejorar OP Stack
Ben: ¿Cómo es el proceso para comenzar a mejorar OP Stack?
tdot: Me uní a Lattice hace aproximadamente un año, específicamente para encargarme 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 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 la cadena y su despliegue en OP Stack. Hemos encontrado que OP Stack ya es muy fácil de usar.
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 alinea con la filosofía de Ethereum y es completamente compatible con EVM." Lo que funciona en la mainnet también puede funcionar 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 iniciar un L2, ya que nuestro juego de cadena completa y el mundo MUD requieren un mayor rendimiento. Así que 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 que se debía explorar Alt DA.
Así que nos preguntamos: "¿Qué pasaría si comenzáramos 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 DA alternativo 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. Aquí hay algunas diferencias. La mayor pregunta es, ¿cómo implementar la DA fuera de la cadena y el desafío de datos en la cadena sobre la pila OP existente? Nuestro objetivo es hacer el menor número de cambios posible en la pila OP, sin afectar la ruta de rollup, porque 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 cambia el proceso de generación de datos para almacenar datos en otro lugar?" Incluso con estos cambios, el OP Stack sigue siendo muy robusto y funciona bien desde el primer momento. Este es el primer cambio que hemos realizado.
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 durante el proceso de derivación, para 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 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 momento, casi hicimos una reescritura de extremo a extremo de toda la pila de OP, a esta publicación la llamamos Bedrock.
Básicamente, después de construir el rollup durante dos años, dimos un paso atrás y reflexionamos diciendo: "Bueno, si queremos llevar toda la experiencia que hemos aprendido al extremo, ¿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, creo que Biomes es su heredero espiritual, fue la vez que más nos divertimos jugando en la cadena. Al mismo tiempo, también suspiramos 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 cadenas.
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 tomar este repositorio de código y hacer cosas realmente increíbles es una gran validación. Luego, ver cómo esta situación se expande a la aplicación práctica en Plasma es realmente genial. Incluso puedo hablar un poco sobre esa historia.
Antes de la fundación de un conocido proyecto de Layer 2, en realidad estábamos investigando una tecnología llamada Plasma. La tarea que asumimos en ese momento superó 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 validación del 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 escalado de Ethereum de ese período.
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 existían conceptos como (exits), y 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 no solo que 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, y ustedes han creado abstracciones fantásticas en torno a ello, haciéndolo funcionar de una manera razonable y sensata. Esto es realmente genial.
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 ellos. La clave es cómo evitar gastar hasta diez años en esto. ¿Sabes a qué me refiero? 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 desean lanzarse de inmediato en la mainnet. Necesitamos preparar una mainnet lo antes posible para estos juegos. 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 estas aplicaciones puedan desarrollarse en paralelo y mejorar mientras resolvemos problemas. Desde la investigación y desarrollo hasta lograr la estabilidad en producción, toma mucho tiempo.
Llevar algo a la mainnet, para que sea sin permisos, robusto y seguro, requiere mucho tiempo. Ver todo el proceso para lograr este objetivo es realmente asombroso. Por eso 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 debes estar al día, pero tampoco puedes comprometer la seguridad y el rendimiento, de lo contrario el sistema no funcionará.
Ben: O se podría decir que es una carga técnica. El principio de mínimo cambio que mencionas, es una de las ideas centrales en nuestra reescritura de Bedrock. Hablé sobre toda 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 contundente. 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, dificultando que las cosas pasen por pruebas prácticas y aumentando las oportunidades de errores. Por lo tanto, estamos muy agradecidos por todos los esfuerzos que han hecho para impulsar este proceso, especialmente por las contribuciones al nuevo modo de operación de OP Stack.
tdot: OP Stack ha creado efectivamente una forma de avanzar rápidamente en este tipo de cosas. Coordinar a todos es muy difícil, porque somos claramente 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 regularmente. Desde el punto de vista de la coordinación, esto realmente no es fácil.
Ben: Sí, de hecho, aún queda un largo camino por recorrer. Pero esa es precisamente la esencia 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 actualmente en Redstone. Desde la perspectiva de OP Stack, este es un ejemplo muy poderoso que demuestra que muchos excelentes desarrolladores principales se han unido y han mejorado este stack, lo cual es realmente impresionante.
Esta es la primera vez que puedes cambiar significativamente las propiedades del sistema a través de un valor booleano clave. Poder hacer esto de manera completa, como dijiste, ciertamente queda un largo camino por recorrer. Pero incluso acercarse a hacerlo de manera efectiva requiere soporte modular, ¿verdad? Para nosotros, es un gran alivio ver que han logrado esto sin necesidad de, por ejemplo, reescribir L2 Geth. 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 cambiar en sus propiedades. Así que estoy muy ansioso por ver qué nuevas funciones se integrarán. Recuerdo que nos preocupaba que tuviéramos una bifurcación que incluyera todos los cambios en OP Stack, y que necesitaríamos fusionarla en la rama principal. En ese momento pensamos: "Dios mío, sería una locura revisar todo."
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, por lo que el proceso de revisión también fue muy agradable. Se sintió muy natural. Y creo que en términos de revisión y resolución de algunos problemas potenciales, este proceso fue muy rápido. Todo salió sorprendentemente 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 de que estén participando en las pruebas, impulsando estos procesos. Estoy contento de 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 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 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 lanzar la mainnet, porque así no es necesario hacer un hard fork. Podrías pensar: "Oh, solo tengo que esperar hasta que todo esté completamente listo para lanzar, así no tengo que hacer un hard fork y tampoco tengo la carga técnica." Pero, si quieres lanzar la mainnet rápidamente, debes lidiar con estas complejas actualizaciones y lanzar frecuentemente. Hacer esto y mantener 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 listas. Creo que todavía hay espacio para optimizaciones en el compromiso de envío por lotes. Actualmente lo hacemos de una manera muy sencilla, un compromiso por cada transacción. Y el compromiso es simplemente el valor hash de los datos de entrada almacenados fuera de la cadena.
Mantenemos las cosas lo más simples posible por ahora, para que la revisión sea sencilla y rápida, y no haya grandes diferencias con OP Stack. Pero ahora hay algunas optimizaciones que pueden hacerlo más barato, como agrupar los compromisos o enviarlos.