En este episodio especial de Devs on Devs, hemos invitado a tdot(, el desarrollador del protocolo central de Plasma Mode, quien también es desarrollador de Redstone ) y cofundador de Optimism, Ben Jones. 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 la conversación, discutieron el origen de la colaboración entre Redstone y Optimism, la importancia de revivir Plasma, la necesidad de llevar protocolos experimentales a entornos 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 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 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 apoye estas necesidades 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 la cadena y su despliegue en OP Stack. Hemos descubierto que OP Stack ya es muy útil.
Así que nos preguntamos: "¿Cómo podemos hacer que sea 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 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 disponibilidad de datos de la cadena OP Stack (DA), lo cual era muy costoso. Así que evidentemente no podíamos iniciar una L2 con calldata, ya que nuestros juegos 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, en la documentación inicial de OP Stack ya se mencionó explorar Alt DA.
Entonces 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 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. 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 hacer la menor modificación posible al OP Stack, sin afectar la ruta de rollup, ya que no queremos comprometer la seguridad de otras cadenas de rollup que utilizan el OP Stack.
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?" A pesar de estos cambios, OP Stack sigue siendo muy potente y funciona muy bien fuera de la caja. Este es el primer cambio que hemos realizado.
Después, necesitamos escribir contratos para crear estos desafíos. Hay desafíos de DA que obligan a que los datos se registren en 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, de modo que puedas derivar datos de una fuente de DA fuera de la cadena y de un contrato de desafío DA de L1, en caso de que los datos sean enviados a la cadena durante la resolución del desafío.
Ese 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 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 interesante.
Ben: Puedo hablar desde la perspectiva de OP. Mencionaste algunos trabajos tempranos de Lattice. Justo en ese momento, nosotros en Optimism hicimos una reescritura de extremo a extremo de toda la OP Stack, a la que 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 toda la experiencia que hemos aprendido al extremo, ¿cómo sería eso?" Esto evolucionó en lo que finalmente se llamó el repositorio de Bedrock, que es nuestra mayor actualización a la red.
En ese momento, colaboramos en un proyecto llamado OPCraft, y creo que Biomes es su heredero espiritual. Esta fue la vez que más nos divertimos jugando en la cadena. Al mismo tiempo, también respiramos aliviados, porque otras personas también pueden desarrollar utilizando 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 solo aquellas personas que han desarrollado grandes y complejas bibliotecas de código 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 cómo esto 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. 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 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, 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 sencilla". 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 es 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 hacia lo que inicialmente intentamos hacer, pero de una manera muy confusa e inmadura. Hemos completado un ciclo completo, ustedes han hecho abstracciones realmente geniales en torno a ello y han logrado que funcione de una manera razonable y sensata. Eso es realmente genial.
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 en ello. ¿Entiendes lo que quiero decir? Necesitamos avanzar lo más rápido posible hacia 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 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 paralelamente y mejorar mientras resolvemos problemas. Desde la investigación y el desarrollo hasta la implementación, la estabilidad de producción lleva mucho tiempo.
Llevar algo a la red principal, haciéndolo sin permiso, robusto y seguro, requiere una gran cantidad de tiempo. Ver todo el proceso en el que hemos logrado este objetivo es realmente asombroso. Por eso necesitamos mantener una alta agilidad, porque hay demasiadas cosas. Todo el ecosistema está evolucionando muy rápidamente. Creo que todos están entregando una gran cantidad de innovación. Es por eso que 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 mencionas, 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 hemos reducido aproximadamente 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 añades te aleja más del entorno de producción, haciendo que las cosas sean más difíciles de probar en la práctica y introduciendo más oportunidades de error. Por lo tanto, agradecemos mucho todo su esfuerzo en impulsar este proceso, especialmente por la contribución 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. 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 aún queda 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. 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 realmente impresionante.
Esta 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 dices, todavía hay un largo camino por recorrer. Pero incluso lograrlo de manera casi efectiva requiere soporte modular, ¿verdad? Para nosotros, ver que ustedes han logrado esto sin necesidad de, por ejemplo, reescribir L2 Geth, es un gran alivio. Para mí, esto demuestra que la modularidad está funcionando.
tdot: La situación ha mejorado ahora. A partir de este ejemplo, ustedes han convertido todo en pequeños módulos independientes que se pueden ajustar y cambiar de propiedades. Así que estoy muy emocionado por ver qué nuevas funciones se integrarán. Recuerdo que nos preocupaba que 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 transcurrió muy bien. La atmósfera de colaboración con el equipo fue excelente, así que el proceso de revisión también fue muy agradable. Se sintió muy natural. Además, creo que el proceso avanzó 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 de que estén participando en las pruebas y empujando estos procesos. Me alegra saber que estos procesos no han sido abrumadores y que hemos 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 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 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 quieres lanzar rápidamente la mainnet, debes lidiar con estas complejas actualizaciones y lanzar frecuentemente. Hacer esto y mantener una alta disponibilidad siempre es un desafío.
Creo que habrá muchas actualizaciones 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 envío 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.
Nos mantenemos lo más simples posible por el momento, para 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 hacerlo más barato, como agrupar los compromisos o enviarlos al blob, o adoptar otras.
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.
Los cofundadores de Optimism hablan con los desarrolladores de Plasma Mode sobre las mejoras de OP Stack y su futuro.
Devs on Devs: tdot y Ben Jones en conversación
En este episodio especial de Devs on Devs, hemos invitado a tdot(, el desarrollador del protocolo central de Plasma Mode, quien también es desarrollador de Redstone ) y cofundador de Optimism, Ben Jones. 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 la conversación, discutieron el origen de la colaboración entre Redstone y Optimism, la importancia de revivir Plasma, la necesidad de llevar protocolos experimentales a entornos 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 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 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 apoye estas necesidades 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 la cadena y su despliegue en OP Stack. Hemos descubierto que OP Stack ya es muy útil.
Así que nos preguntamos: "¿Cómo podemos hacer que sea 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 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 disponibilidad de datos de la cadena OP Stack (DA), lo cual era muy costoso. Así que evidentemente no podíamos iniciar una L2 con calldata, ya que nuestros juegos 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, en la documentación inicial de OP Stack ya se mencionó explorar Alt DA.
Entonces 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 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. 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 hacer la menor modificación posible al OP Stack, sin afectar la ruta de rollup, ya que no queremos comprometer la seguridad de otras cadenas de rollup que utilizan el OP Stack.
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?" A pesar de estos cambios, OP Stack sigue siendo muy potente y funciona muy bien fuera de la caja. Este es el primer cambio que hemos realizado.
Después, necesitamos escribir contratos para crear estos desafíos. Hay desafíos de DA que obligan a que los datos se registren en 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, de modo que puedas derivar datos de una fuente de DA fuera de la cadena y de un contrato de desafío DA de L1, en caso de que los datos sean enviados a la cadena durante la resolución del desafío.
Ese 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 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 interesante.
Ben: Puedo hablar desde la perspectiva de OP. Mencionaste algunos trabajos tempranos de Lattice. Justo en ese momento, nosotros en Optimism hicimos una reescritura de extremo a extremo de toda la OP Stack, a la que 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 toda la experiencia que hemos aprendido al extremo, ¿cómo sería eso?" Esto evolucionó en lo que finalmente se llamó el repositorio de Bedrock, que es nuestra mayor actualización a la red.
En ese momento, colaboramos en un proyecto llamado OPCraft, y creo que Biomes es su heredero espiritual. Esta fue la vez que más nos divertimos jugando en la cadena. Al mismo tiempo, también respiramos aliviados, porque otras personas también pueden desarrollar utilizando 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 solo aquellas personas que han desarrollado grandes y complejas bibliotecas de código 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 cómo esto 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. 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 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, 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 sencilla". 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 es 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 hacia lo que inicialmente intentamos hacer, pero de una manera muy confusa e inmadura. Hemos completado un ciclo completo, ustedes han hecho abstracciones realmente geniales en torno a ello y han logrado que funcione de una manera razonable y sensata. Eso es realmente genial.
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 en ello. ¿Entiendes lo que quiero decir? Necesitamos avanzar lo más rápido posible hacia 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 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 paralelamente y mejorar mientras resolvemos problemas. Desde la investigación y el desarrollo hasta la implementación, la estabilidad de producción lleva mucho tiempo.
Llevar algo a la red principal, haciéndolo sin permiso, robusto y seguro, requiere una gran cantidad de tiempo. Ver todo el proceso en el que hemos logrado este objetivo es realmente asombroso. Por eso necesitamos mantener una alta agilidad, porque hay demasiadas cosas. Todo el ecosistema está evolucionando muy rápidamente. Creo que todos están entregando una gran cantidad de innovación. Es por eso que 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 mencionas, 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 hemos reducido aproximadamente 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 añades te aleja más del entorno de producción, haciendo que las cosas sean más difíciles de probar en la práctica y introduciendo más oportunidades de error. Por lo tanto, agradecemos mucho todo su esfuerzo en impulsar este proceso, especialmente por la contribución 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. 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 aún queda 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. 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 realmente impresionante.
Esta 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 dices, todavía hay un largo camino por recorrer. Pero incluso lograrlo de manera casi efectiva requiere soporte modular, ¿verdad? Para nosotros, ver que ustedes han logrado esto sin necesidad de, por ejemplo, reescribir L2 Geth, es un gran alivio. Para mí, esto demuestra que la modularidad está funcionando.
tdot: La situación ha mejorado ahora. A partir de este ejemplo, ustedes han convertido todo en pequeños módulos independientes que se pueden ajustar y cambiar de propiedades. Así que estoy muy emocionado por ver qué nuevas funciones se integrarán. Recuerdo que nos preocupaba que 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 transcurrió muy bien. La atmósfera de colaboración con el equipo fue excelente, así que el proceso de revisión también fue muy agradable. Se sintió muy natural. Además, creo que el proceso avanzó 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 de que estén participando en las pruebas y empujando estos procesos. Me alegra saber que estos procesos no han sido abrumadores y que hemos 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 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 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 quieres lanzar rápidamente la mainnet, debes lidiar con estas complejas actualizaciones y lanzar frecuentemente. Hacer esto y mantener una alta disponibilidad siempre es un desafío.
Creo que habrá muchas actualizaciones 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 envío 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.
Nos mantenemos lo más simples posible por el momento, para 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 hacerlo más barato, como agrupar los compromisos o enviarlos al blob, o adoptar otras.