En esta edición especial de Devs on Devs, invitamos al desarrollador del protocolo central de Plasma Mode, tdot(, quien también es desarrollador de Redstone, ), y al 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 esta conversación, discutieron los orígenes de la colaboración entre Redstone y Optimism, la importancia de revitalizar Plasma, la necesidad de llevar protocolos experimentales al entorno 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 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, 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 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 implementación 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 que es completamente compatible con EVM." Lo que funciona en la mainnet también puede funcionar en OP Stack, lo cual 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. Así que claramente no podíamos iniciar un 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, 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 el 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 la DA fuera de la cadena y los desafíos de datos en la cadena sobre la pila OP existente? Nuestro objetivo es hacer el menor cambio posible en la pila OP, sin afectar el camino de rollup, ya que no queremos afectar la seguridad de otras cadenas de rollup que utilizan la pila OP.
Al diseñar un rollup, no piensas: "¿Qué pasaría si alguien cambiara el proceso de generación de datos para almacenar datos desde otros lugares?" Incluso con estos cambios, OP Stack sigue siendo muy robusto y funciona muy bien listo para usar. Este es el primer cambio que hemos realizado.
Después, necesitamos escribir 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 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 principal de la situación. Es complicado, porque queremos mantener las cosas elegantes y sólidas. 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 interesante.
Ben: Puedo hablar desde la perspectiva de OP. Mencionaste algunos trabajos tempranos de Lattice. Justo en ese momento, nosotros en Optimism realizamos una reescritura de extremo a extremo de toda la pila OP, 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 lecciones aprendidas al extremo, ¿cómo sería eso?" Esto evolucionó hasta convertirse en la biblioteca de código que finalmente se conoce como 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 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 las 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 afirmació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 la época. 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 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 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 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 ha sido utilizado por otros, sino que también ha evolucionado en algo que originalmente intentamos hacer pero de una manera muy confusa e inmadura. Hemos completado un ciclo completo, ustedes han hecho abstracciones maravillosas alrededor de ellas, y las han hecho 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 aún enfrenta 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 etapa en la que podamos entregar resultados.
Esta es nuestra idea. Ya tenemos muchas aplicaciones basadas en MUD listas para lanzarse de inmediato en la mainnet. 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 funcionar, para ejecutar todas estas aplicaciones, de modo que estas aplicaciones puedan desarrollarse simultáneamente y mejorar mientras resolvemos problemas. Desde la investigación y el desarrollo hasta la implementación de la estabilidad de producción lleva mucho tiempo.
Para lanzar algo en la red principal, que sea sin permisos, robusto y seguro, se requiere mucho tiempo. Ver todo el proceso para lograr este objetivo ha sido realmente asombroso. Es por eso que necesitamos mantener una alta agilidad, porque 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 mantenerte al día, pero tampoco puedes comprometer la seguridad y el rendimiento, de lo contrario el sistema no podrá funcionar.
Ben: O más bien, una carga técnica. El principio de menor modificación que mencionaste es una de nuestras ideas centrales al realizar la reescritura de Bedrock. Hablé sobre la reescritura completa de extremo a extremo, pero más importante aún, 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 se añade te aleja más del entorno de producción, dificultando las pruebas en situaciones reales y generando más oportunidades de errores. Por lo tanto, agradecemos mucho todos sus esfuerzos en impulsar este proceso, especialmente por la contribución al nuevo modo de operación 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, 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 increíbles 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 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 dices, todavía queda un largo camino por recorrer. Pero incluso acercarse a hacerlo de manera efectiva requiere apoyo modular, ¿verdad? Para nosotros, ver que lo han logrado sin necesidad de reescribir 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, ustedes han convertido todo en módulos independientes que se pueden ajustar y cambiar de atributos. Así que estoy muy ansioso por ver qué nuevas funciones se integrarán. Recuerdo que solíamos preocuparnos por tener un fork que incluía todos los cambios en OP Stack, y que necesitábamos fusionarlo en la rama principal. Pensamos en ese momento, "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 excelente, por lo que el proceso de revisión también fue muy agradable. Se sintió muy natural. Y 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 contribuciones 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 esto, tengo curiosidad, desde tu perspectiva, ¿cómo crees que evolucionará 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 permisos sin autorización y 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 mainnet puede ser más fácil, porque así no se necesita realizar un hard fork. Podrías pensar: "Oh, solo esperaré hasta que todo esté completamente listo para lanzar, así no será necesario hacer un hard fork y no hay carga técnica." Pero, si quieres lanzar rápidamente en la mainnet, debes lidiar con estas actualizaciones complejas 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 listas. Creo que todavía hay espacio para optimizar en la presentación masiva 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, mantendremos las cosas lo más simples posible, de modo que la revisión pueda ser simple y rápida, y no haya grandes diferencias con el OP Stack. Sin embargo, ahora hay algunas optimizaciones que pueden hacerlo más barato, como procesar los compromisos en lotes 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 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.
Muchas de estas tareas definitivamente tendrán que ser realizadas por ustedes. Pero queremos aclarar cómo se ven en el modo Plasma y cuáles son las diferentes suposiciones de seguridad.
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.
16 me gusta
Recompensa
16
6
Compartir
Comentar
0/400
GateUser-0717ab66
· hace5h
¿Cuánto cuesta esto?
Ver originalesResponder0
ImpermanentPhobia
· hace19h
El grupo de ambiente ha venido a ver la obra.
Ver originalesResponder0
just_another_wallet
· hace19h
¿Plasma aún puede salvar?
Ver originalesResponder0
BlockchainDecoder
· hace19h
Desde un punto de vista técnico, ¿es realmente razonable elegir la publicación de datos L1 selectivos como una solución de compromiso?
Ver originalesResponder0
GetRichLeek
· hace19h
Preparar una emboscada op ha pasado medio año, ¿realmente podrá explotar?
Ver originalesResponder0
SchrodingerGas
· hace19h
¿Quién puede calcular cuánto gas ahorra esta cosa? Espera, voy a hacer un modelo.
Diálogo de innovadores de OP Stack: ¿Cómo el Modo Plasma cambiará el futuro de los juegos en cadena?
DEVS EN DEVS: Diálogo entre TDOT y BEN JONES
En esta edición especial de Devs on Devs, invitamos al desarrollador del protocolo central de Plasma Mode, tdot(, quien también es desarrollador de Redstone, ), y al 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 esta conversación, discutieron los orígenes de la colaboración entre Redstone y Optimism, la importancia de revitalizar Plasma, la necesidad de llevar protocolos experimentales al entorno 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 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, 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 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 implementación 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 que es completamente compatible con EVM." Lo que funciona en la mainnet también puede funcionar en OP Stack, lo cual 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. Así que claramente no podíamos iniciar un 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, 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 el 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 la DA fuera de la cadena y los desafíos de datos en la cadena sobre la pila OP existente? Nuestro objetivo es hacer el menor cambio posible en la pila OP, sin afectar el camino de rollup, ya que no queremos afectar la seguridad de otras cadenas de rollup que utilizan la pila OP.
Al diseñar un rollup, no piensas: "¿Qué pasaría si alguien cambiara el proceso de generación de datos para almacenar datos desde otros lugares?" Incluso con estos cambios, OP Stack sigue siendo muy robusto y funciona muy bien listo para usar. Este es el primer cambio que hemos realizado.
Después, necesitamos escribir 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 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 principal de la situación. Es complicado, porque queremos mantener las cosas elegantes y sólidas. 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 interesante.
Ben: Puedo hablar desde la perspectiva de OP. Mencionaste algunos trabajos tempranos de Lattice. Justo en ese momento, nosotros en Optimism realizamos una reescritura de extremo a extremo de toda la pila OP, 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 lecciones aprendidas al extremo, ¿cómo sería eso?" Esto evolucionó hasta convertirse en la biblioteca de código que finalmente se conoce como 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 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 las 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 afirmació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 la época. 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 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 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 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 ha sido utilizado por otros, sino que también ha evolucionado en algo que originalmente intentamos hacer pero de una manera muy confusa e inmadura. Hemos completado un ciclo completo, ustedes han hecho abstracciones maravillosas alrededor de ellas, y las han hecho 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 aún enfrenta 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 etapa en la que podamos entregar resultados.
Esta es nuestra idea. Ya tenemos muchas aplicaciones basadas en MUD listas para lanzarse de inmediato en la mainnet. 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 funcionar, para ejecutar todas estas aplicaciones, de modo que estas aplicaciones puedan desarrollarse simultáneamente y mejorar mientras resolvemos problemas. Desde la investigación y el desarrollo hasta la implementación de la estabilidad de producción lleva mucho tiempo.
Para lanzar algo en la red principal, que sea sin permisos, robusto y seguro, se requiere mucho tiempo. Ver todo el proceso para lograr este objetivo ha sido realmente asombroso. Es por eso que necesitamos mantener una alta agilidad, porque 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 mantenerte al día, pero tampoco puedes comprometer la seguridad y el rendimiento, de lo contrario el sistema no podrá funcionar.
Ben: O más bien, una carga técnica. El principio de menor modificación que mencionaste es una de nuestras ideas centrales al realizar la reescritura de Bedrock. Hablé sobre la reescritura completa de extremo a extremo, pero más importante aún, 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 se añade te aleja más del entorno de producción, dificultando las pruebas en situaciones reales y generando más oportunidades de errores. Por lo tanto, agradecemos mucho todos sus esfuerzos en impulsar este proceso, especialmente por la contribución al nuevo modo de operación 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, 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 increíbles 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 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 dices, todavía queda un largo camino por recorrer. Pero incluso acercarse a hacerlo de manera efectiva requiere apoyo modular, ¿verdad? Para nosotros, ver que lo han logrado sin necesidad de reescribir 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, ustedes han convertido todo en módulos independientes que se pueden ajustar y cambiar de atributos. Así que estoy muy ansioso por ver qué nuevas funciones se integrarán. Recuerdo que solíamos preocuparnos por tener un fork que incluía todos los cambios en OP Stack, y que necesitábamos fusionarlo en la rama principal. Pensamos en ese momento, "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 excelente, por lo que el proceso de revisión también fue muy agradable. Se sintió muy natural. Y 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 contribuciones 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 esto, tengo curiosidad, desde tu perspectiva, ¿cómo crees que evolucionará 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 permisos sin autorización y 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 mainnet puede ser más fácil, porque así no se necesita realizar un hard fork. Podrías pensar: "Oh, solo esperaré hasta que todo esté completamente listo para lanzar, así no será necesario hacer un hard fork y no hay carga técnica." Pero, si quieres lanzar rápidamente en la mainnet, debes lidiar con estas actualizaciones complejas 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 listas. Creo que todavía hay espacio para optimizar en la presentación masiva 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, mantendremos las cosas lo más simples posible, de modo que la revisión pueda ser simple y rápida, y no haya grandes diferencias con el OP Stack. Sin embargo, ahora hay algunas optimizaciones que pueden hacerlo más barato, como procesar los compromisos en lotes 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 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.
Muchas de estas tareas definitivamente tendrán que ser realizadas por ustedes. Pero queremos aclarar cómo se ven en el modo Plasma y cuáles son las diferentes suposiciones de seguridad.
Ben: