Comenzar un artículo de resumen con algo como "¿Qué es un resumen" o "¿Por qué necesitamos un resumen" es como matar al tío Ben o dispararle a la mamá y al papá de Wayne en cada versión de las películas de Spider-Man y Batman. Lo mismo que papá. Si está leyendo este artículo, supongo que ya tiene una comprensión básica de los problemas anteriores. Aquí, nos saltamos el debate entre la cadena de aplicaciones y el paquete acumulativo de aplicaciones y vamos directamente al tema.
El auge de los paquetes acumulativos de aplicaciones específicas****Los paquetes acumulativos universales son frustrantes
Universal Rollup es como el sistema escolar de la India (estoy seguro de que tienen características similares a otros sistemas escolares, pero solo tengo experiencia de primera mano con él).
Los atletas, cantantes, matemáticos, pensadores y economistas deben pasar por el mismo proceso para obtener una calificación aprobatoria. El sistema no está "sesgado" hacia ningún grupo en particular, pero tampoco es "justo" para todos. Pero bueno, ¡nos hicimos amigos! (Esto será importante más adelante).
Del mismo modo, para las aplicaciones en un Rollup universal, el cuello de botella es el propio entorno de ejecución, ya que el Rollup no puede satisfacer las necesidades de cada aplicación individualmente. Cada aplicación puede requerir un tipo diferente de optimización y es posible que cualquier mejora personalizada no esté justificada para ellas. Sin embargo, si sólo estás experimentando y quieres hacerte una idea aproximada, esta es la opción más conveniente. Además, para algunas aplicaciones, como las de algunos estudiantes promedio, ¡esta podría ser la solución correcta!
El resumen específico de la aplicación es confuso
Bueno, mi hijo es demasiado atlético para la escuela pública y necesita entrenamiento especial. ¿Necesito enviarlo a una escuela de deportes o debería contratar a un entrenador personal…?
El resumen es difícil de clasificar claramente****Juguemos
Hay 8 paquetes acumulativos de aplicaciones específicas a continuación. Sin embargo, 1 elemento de cada grupo en realidad no pertenece a ese grupo. ¿Puedes decir cuál es?
La especificidad de la aplicación se está convirtiendo en un término confuso. Hay algunos Rollups de aplicaciones específicas que permiten que los contratos se implementen encima de ellos mismos; también hay algunos Rollups de aplicaciones específicas que permiten la implementación de contratos porque sus máquinas virtuales lo soportan, pero habrá ciertas restricciones; tienen máquinas virtuales cerradas o no tienen máquinas virtuales. máquinas en absoluto y no admiten otros tipos de desarrollo.
¿Es justo clasificarlos juntos?
Respuestas al ejercicio anterior:
Grupo1: Celo es una opción extraña porque permite a otros desarrolladores crear aplicaciones que otros desarrolladores pueden usar directamente. Otros proyectos a considerar en el Grupo 1 son Fuel-v1, Aevo, RhinoFi, etc.
Grupo 2: Loopring es una elección extraña ya que es el único Rollup especialmente diseñado que funciona de inmediato, mientras que el resto son redes optimizadas para características específicas como privacidad, NFT y TPS para las aplicaciones implementadas en él. Estas funciones pueden ser heredado. Otros proyectos que se pueden considerar en el Grupo 2 son Kinto, Kroma, Public Goods Network, etc.
Problemas al implementar contratos en máquinas virtuales generales modificadas
Estas máquinas virtuales en las que se implementan contratos inteligentes no son más que máquinas de estado completas de Turing. Los contratos que implementa en ellos solo modifican el estado en sí, en realidad no afectan las reglas centrales de transición de estado de la VM. Rollup es esencialmente una máquina virtual sobre la cual se encuentra su lógica empresarial.
Su lógica empresarial está separada de las funciones de transición de estado de Rollup.
También lo llamo el "paradigma de contrato inteligente para crear aplicaciones" porque se implementa cierta lógica adicional sobre una máquina virtual. Rollup no se ocupa "directamente" de probar la lógica de la aplicación. La VM es el paquete acumulativo, no su aplicación.
Por supuesto, usted es el único propietario de la máquina virtual, su aplicación es el único ciudadano y puede mejorar continuamente la base para adaptarla a su aplicación. Puede continuar mejorando la función de transición de estado (STF) y agregar o eliminar códigos de operación para mejorar el rendimiento de la aplicación, pero la aplicación sigue siendo independiente y limitada por la propia VM.
Como el Lamborghini Urus tirando de un Lamborghini Huracan
Una aplicación separada en un paquete acumulativo de aplicaciones específico puede funcionar mejor. ¿Qué pasaría si siguiera mejorando el STF para que su alcance fuera cada vez más pequeño para adaptarse a la lógica empresarial de su aplicación? Con el tiempo, a medida que se fortalezca, el STF convergerá hasta un punto en el que la lógica empresarial y el STF se superpondrán, momento en el que se dará cuenta... ¡oh, espere un minuto!
Nace el Micro-Rollup
Por tanto, Micro-Rollup no es más que un Rollup en el que la función de transición de estado de la aplicación es la propia lógica de negocio.
La aplicación se convierte en un Rollup, el estado se puede gestionar de cualquier forma posible en cualquier entorno de ejecución y las reglas de transición de estado se pueden aplicar directamente en el tiempo de ejecución de la aplicación. La aplicación se puede personalizar sin restricciones. Las pruebas están vinculadas a su lógica empresarial en lugar de a la máquina, lo que hace que su aplicación sea liviana.
Micro-Rollup no tiene restricciones en términos de experiencia del desarrollador. Puede crearlos utilizando cualquier herramienta que desee porque no se limitan a máquinas virtuales. Parecen aplicaciones backend web2, pero publican periódicamente pruebas de transacciones en L1. Creo que este será un factor importante que influirá en que los desarrolladores web2 pasen al espacio web3.
En realidad, un mejor ejemplo sería el Rimac Nevera, ya que es más rápido y eléctrico, por lo que probablemente su funcionamiento sea más económico.
El único inconveniente de este enfoque es el mecanismo de prueba personalizado para cada aplicación diferente. Si la lógica de la aplicación se puede compilar en un intermediario común, entonces probar el intermediario público elimina la molestia de probar cada aplicación individualmente, pero personalmente creo que esto es solo una compensación entre eficiencia y un desarrollo más rápido.
Hay formas de resolver este problema sin utilizar una capa de ejecución que involucre una máquina virtual. ¿Qué pasaría si existiera una herramienta que permitiera a los desarrolladores hacer esto?
Esta es la misión de Stackr Labs: estamos creando un marco Micro-Rollup y un SDK para que todos puedan crear sus aplicaciones en cualquier idioma que quieran sin restricciones, al igual que crear aplicaciones backend web2. El procedimiento es el mismo. Hacer que el desarrollo de Micro-Rollup sea tan fácil como escribir e implementar contratos inteligentes, sin mencionar la modularidad, aumenta la capacidad de los desarrolladores para elegir cualquier ecosistema.
** Entonces, ¿es real el Micro-Rollup? **
Siempre lo ha sido, tan real como el propio Rollup.
Aplicaciones como Loopring, dYdX y Fuel-v1 ya existen o existen desde hace mucho tiempo. Estos son paquetes acumulativos altamente optimizados con lógica personalizada que se ejecuta específicamente para atender su caso de uso. La primera aplicación Rollup específica que conozco y en la que he trabajado personalmente que no está basada en una máquina virtual es Hubble Optimistic Rollup, un proyecto de 3 años que en un momento sirvió como infraestructura central para el token Worldcoin.
Hoy en día es cada vez más importante diferenciar estos términos.
Los casos de uso de Micro-Rollups son infinitos:
Productos de consumo como juegos, intercambios y mercados NFT
La cadena de aplicaciones se puede convertir en un paquete acumulativo de aplicaciones.
Incluso puede crear nuevos tipos de máquinas virtuales que admitan casos de uso únicos, abriendo la puerta a la innovación en máquinas virtuales.
en conclusión
Al árbol de estructura que mostré anteriormente le faltaban elementos para la máquina de estados personalizada.
Además, implementar un único protocolo mediante un paquete acumulativo basado en VM o EVM no es eficiente para aplicaciones independientes. Es adecuado para aplicaciones que ya tienen una gran cantidad de contratos inteligentes y ejecutan sus protocolos en una cadena similar a EVM, pero no para "aplicaciones que quieren más" y quieren deshacerse de las limitaciones de VM.
Entonces, si podamos el árbol, el árbol final se verá así. Por eso creo que App-Rollup, Micro-Rollup o RollApp se llamarán App en un futuro próximo.
Por lo tanto, Micro Rollup = Aplicación en Rollup Aplicación como Rollup.
Ver originales
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.
¿Es Micro-Rollup la próxima ola?
Escrito por: KAUTUK, desarrollador de Stackr. Compilado por: Luffy, Foresight News.
Comenzar un artículo de resumen con algo como "¿Qué es un resumen" o "¿Por qué necesitamos un resumen" es como matar al tío Ben o dispararle a la mamá y al papá de Wayne en cada versión de las películas de Spider-Man y Batman. Lo mismo que papá. Si está leyendo este artículo, supongo que ya tiene una comprensión básica de los problemas anteriores. Aquí, nos saltamos el debate entre la cadena de aplicaciones y el paquete acumulativo de aplicaciones y vamos directamente al tema.
El auge de los paquetes acumulativos de aplicaciones específicas****Los paquetes acumulativos universales son frustrantes
Universal Rollup es como el sistema escolar de la India (estoy seguro de que tienen características similares a otros sistemas escolares, pero solo tengo experiencia de primera mano con él).
Los atletas, cantantes, matemáticos, pensadores y economistas deben pasar por el mismo proceso para obtener una calificación aprobatoria. El sistema no está "sesgado" hacia ningún grupo en particular, pero tampoco es "justo" para todos. Pero bueno, ¡nos hicimos amigos! (Esto será importante más adelante).
Del mismo modo, para las aplicaciones en un Rollup universal, el cuello de botella es el propio entorno de ejecución, ya que el Rollup no puede satisfacer las necesidades de cada aplicación individualmente. Cada aplicación puede requerir un tipo diferente de optimización y es posible que cualquier mejora personalizada no esté justificada para ellas. Sin embargo, si sólo estás experimentando y quieres hacerte una idea aproximada, esta es la opción más conveniente. Además, para algunas aplicaciones, como las de algunos estudiantes promedio, ¡esta podría ser la solución correcta!
El resumen específico de la aplicación es confuso
Bueno, mi hijo es demasiado atlético para la escuela pública y necesita entrenamiento especial. ¿Necesito enviarlo a una escuela de deportes o debería contratar a un entrenador personal…?
El resumen es difícil de clasificar claramente****Juguemos
Hay 8 paquetes acumulativos de aplicaciones específicas a continuación. Sin embargo, 1 elemento de cada grupo en realidad no pertenece a ese grupo. ¿Puedes decir cuál es?
La especificidad de la aplicación se está convirtiendo en un término confuso. Hay algunos Rollups de aplicaciones específicas que permiten que los contratos se implementen encima de ellos mismos; también hay algunos Rollups de aplicaciones específicas que permiten la implementación de contratos porque sus máquinas virtuales lo soportan, pero habrá ciertas restricciones; tienen máquinas virtuales cerradas o no tienen máquinas virtuales. máquinas en absoluto y no admiten otros tipos de desarrollo.
¿Es justo clasificarlos juntos?
Respuestas al ejercicio anterior:
Grupo1: Celo es una opción extraña porque permite a otros desarrolladores crear aplicaciones que otros desarrolladores pueden usar directamente. Otros proyectos a considerar en el Grupo 1 son Fuel-v1, Aevo, RhinoFi, etc.
Grupo 2: Loopring es una elección extraña ya que es el único Rollup especialmente diseñado que funciona de inmediato, mientras que el resto son redes optimizadas para características específicas como privacidad, NFT y TPS para las aplicaciones implementadas en él. Estas funciones pueden ser heredado. Otros proyectos que se pueden considerar en el Grupo 2 son Kinto, Kroma, Public Goods Network, etc.
Problemas al implementar contratos en máquinas virtuales generales modificadas
Estas máquinas virtuales en las que se implementan contratos inteligentes no son más que máquinas de estado completas de Turing. Los contratos que implementa en ellos solo modifican el estado en sí, en realidad no afectan las reglas centrales de transición de estado de la VM. Rollup es esencialmente una máquina virtual sobre la cual se encuentra su lógica empresarial.
Su lógica empresarial está separada de las funciones de transición de estado de Rollup.
También lo llamo el "paradigma de contrato inteligente para crear aplicaciones" porque se implementa cierta lógica adicional sobre una máquina virtual. Rollup no se ocupa "directamente" de probar la lógica de la aplicación. La VM es el paquete acumulativo, no su aplicación.
Por supuesto, usted es el único propietario de la máquina virtual, su aplicación es el único ciudadano y puede mejorar continuamente la base para adaptarla a su aplicación. Puede continuar mejorando la función de transición de estado (STF) y agregar o eliminar códigos de operación para mejorar el rendimiento de la aplicación, pero la aplicación sigue siendo independiente y limitada por la propia VM.
Como el Lamborghini Urus tirando de un Lamborghini Huracan
Una aplicación separada en un paquete acumulativo de aplicaciones específico puede funcionar mejor. ¿Qué pasaría si siguiera mejorando el STF para que su alcance fuera cada vez más pequeño para adaptarse a la lógica empresarial de su aplicación? Con el tiempo, a medida que se fortalezca, el STF convergerá hasta un punto en el que la lógica empresarial y el STF se superpondrán, momento en el que se dará cuenta... ¡oh, espere un minuto!
Nace el Micro-Rollup
Por tanto, Micro-Rollup no es más que un Rollup en el que la función de transición de estado de la aplicación es la propia lógica de negocio.
La aplicación se convierte en un Rollup, el estado se puede gestionar de cualquier forma posible en cualquier entorno de ejecución y las reglas de transición de estado se pueden aplicar directamente en el tiempo de ejecución de la aplicación. La aplicación se puede personalizar sin restricciones. Las pruebas están vinculadas a su lógica empresarial en lugar de a la máquina, lo que hace que su aplicación sea liviana.
Micro-Rollup no tiene restricciones en términos de experiencia del desarrollador. Puede crearlos utilizando cualquier herramienta que desee porque no se limitan a máquinas virtuales. Parecen aplicaciones backend web2, pero publican periódicamente pruebas de transacciones en L1. Creo que este será un factor importante que influirá en que los desarrolladores web2 pasen al espacio web3.
En realidad, un mejor ejemplo sería el Rimac Nevera, ya que es más rápido y eléctrico, por lo que probablemente su funcionamiento sea más económico.
El único inconveniente de este enfoque es el mecanismo de prueba personalizado para cada aplicación diferente. Si la lógica de la aplicación se puede compilar en un intermediario común, entonces probar el intermediario público elimina la molestia de probar cada aplicación individualmente, pero personalmente creo que esto es solo una compensación entre eficiencia y un desarrollo más rápido.
Hay formas de resolver este problema sin utilizar una capa de ejecución que involucre una máquina virtual. ¿Qué pasaría si existiera una herramienta que permitiera a los desarrolladores hacer esto?
Esta es la misión de Stackr Labs: estamos creando un marco Micro-Rollup y un SDK para que todos puedan crear sus aplicaciones en cualquier idioma que quieran sin restricciones, al igual que crear aplicaciones backend web2. El procedimiento es el mismo. Hacer que el desarrollo de Micro-Rollup sea tan fácil como escribir e implementar contratos inteligentes, sin mencionar la modularidad, aumenta la capacidad de los desarrolladores para elegir cualquier ecosistema.
** Entonces, ¿es real el Micro-Rollup? **
Siempre lo ha sido, tan real como el propio Rollup.
Aplicaciones como Loopring, dYdX y Fuel-v1 ya existen o existen desde hace mucho tiempo. Estos son paquetes acumulativos altamente optimizados con lógica personalizada que se ejecuta específicamente para atender su caso de uso. La primera aplicación Rollup específica que conozco y en la que he trabajado personalmente que no está basada en una máquina virtual es Hubble Optimistic Rollup, un proyecto de 3 años que en un momento sirvió como infraestructura central para el token Worldcoin.
Hoy en día es cada vez más importante diferenciar estos términos.
Los casos de uso de Micro-Rollups son infinitos:
en conclusión
Al árbol de estructura que mostré anteriormente le faltaban elementos para la máquina de estados personalizada.
Además, implementar un único protocolo mediante un paquete acumulativo basado en VM o EVM no es eficiente para aplicaciones independientes. Es adecuado para aplicaciones que ya tienen una gran cantidad de contratos inteligentes y ejecutan sus protocolos en una cadena similar a EVM, pero no para "aplicaciones que quieren más" y quieren deshacerse de las limitaciones de VM.
Entonces, si podamos el árbol, el árbol final se verá así. Por eso creo que App-Rollup, Micro-Rollup o RollApp se llamarán App en un futuro próximo.
Por lo tanto, Micro Rollup = Aplicación en Rollup Aplicación como Rollup.