La hoja de ruta de Ethereum incluía originalmente dos estrategias de escalado: sharding y protocolos de Layer2. El sharding permite que cada nodo verifique y almacene solo una pequeña parte de las transacciones, mientras que Layer2 mantiene la mayor parte de los datos y cálculos fuera de la cadena principal. Estas dos metodologías se fusionaron eventualmente, formando una hoja de ruta centrada en Rollup, que sigue siendo la estrategia de escalado actual de Ethereum.
La hoja de ruta centrada en Rollup propone una división de trabajo simple: Ethereum L1 se enfoca en convertirse en una capa base poderosa y descentralizada, mientras que L2 asume la tarea de ayudar a escalar el ecosistema. Este modelo es común en la sociedad: la existencia del sistema judicial (L1) es para proteger contratos y derechos de propiedad, mientras que los emprendedores (L2) construyen sobre esa base.
Este año, la hoja de ruta centrada en Rollup ha logrado avances importantes: el lanzamiento de blobs EIP-4844 ha aumentado significativamente el ancho de banda de datos de Ethereum L1, y varios Rollups EVM han entrado en la primera fase. Cada L2 existe como un "fragmento" independiente, y la diversidad de enfoques para implementar fragmentos se ha convertido en una realidad. Pero este camino también enfrenta algunos desafíos únicos. Nuestra tarea ahora es completar la hoja de ruta centrada en Rollup, resolver estos problemas y al mismo tiempo mantener la solidez y descentralización de Ethereum L1.
The Surge: Objetivos Clave
En el futuro, Ethereum podrá alcanzar más de 100,000 TPS a través de L2;
Mantener la descentralización y robustez de L1;
Al menos algunos L2 heredan completamente las propiedades centrales de Ethereum ( de confianza, apertura y resistencia a la censura );
Ethereum debería sentirse como un ecosistema unificado, y no como 34 cadenas de bloques diferentes.
Paradoja del triángulo de escalabilidad
La paradoja del triángulo de escalabilidad sostiene que hay una contradicción entre las tres características de la blockchain: descentralización, escalabilidad y seguridad. Presenta un argumento matemático heurístico: si un nodo amigable con la descentralización puede validar N transacciones por segundo, y tienes una cadena que puede procesar k*N transacciones por segundo, entonces (i) cada transacción solo puede ser vista por 1/k nodos, lo que significa que un atacante solo necesita comprometer unos pocos nodos para ejecutar una transacción maliciosa, o (ii) tus nodos se volverán poderosos, mientras que tu cadena no estará descentralizada.
Sin embargo, la combinación de muestreo de disponibilidad de datos y SNARKs realmente resuelve la paradoja del triángulo: permite a los clientes verificar que una cierta cantidad de datos está disponible y que una cierta cantidad de pasos de cálculo se están ejecutando correctamente, con solo descargar una pequeña cantidad de datos y realizar muy pocos cálculos. Otra solución es la arquitectura Plasma, que transfiere la responsabilidad de monitorear la disponibilidad de datos a los usuarios. Con la popularidad de los SNARKs, la arquitectura Plasma se vuelve más viable para una gama más amplia de casos de uso.
Avances adicionales en el muestreo de disponibilidad de datos
Actualmente, cada slot de Ethereum de 12 segundos tiene 3 blobs de aproximadamente 125 kB, con un ancho de banda de datos disponible de aproximadamente 375 kB. Suponiendo que los datos de la transacción se publiquen directamente en la cadena, la transferencia ERC20 es de aproximadamente 180 bytes, por lo tanto, el TPS máximo de Rollup en Ethereum es de 173.6. Nuestro objetivo a medio plazo es de 16 MB por slot, y si se combinan mejoras en la compresión de datos de Rollup, esto traerá aproximadamente 58000 TPS.
PeerDAS es una implementación relativamente simple de "1D sampling". En Ethereum, cada blob es un polinomio de 4096 grados en un campo primo de 253 bits. Difundimos las partes del polinomio, donde cada parte contiene 16 valores de evaluación de 16 coordenadas adyacentes de un total de 8192 coordenadas. De estos 8192 valores de evaluación, cualquiera de los 4096 puede recuperar el blob.
El funcionamiento de PeerDAS consiste en permitir que cada cliente escuche una pequeña cantidad de subredes, donde la i-ésima subred transmite la i-ésima muestra de cualquier blob y solicita a los pares en la red p2p global los blobs de otras subredes que necesita. Una versión más conservadora, SubnetDAS, utiliza únicamente el mecanismo de subredes, sin consultas adicionales al nivel de pares.
Teóricamente, podemos escalar el "muestreo 1D" bastante grande: si aumentamos el número máximo de blobs a 256( con un objetivo de 128), podemos alcanzar el objetivo de 16 MB, mientras que en el muestreo de disponibilidad de datos, cada nodo necesita manejar 1 MB de ancho de banda por cada slot. Esto está apenas dentro de nuestro rango de tolerancia, lo que significa que los clientes con ancho de banda limitado no pueden muestrear.
Por lo tanto, finalmente queremos avanzar más, realizando muestreo 2D, que no solo se realiza dentro del blob, sino también entre los blobs de forma aleatoria. La propiedad lineal del compromiso KZG se utiliza para expandir un conjunto de blobs dentro de un bloque, que incluye una nueva lista de blobs virtuales codificados de forma redundante con la misma información.
Es crucial que la expansión del compromiso de cómputo no requiera blobs, por lo que este enfoque es fundamentalmente amigable para la construcción de bloques distribuidos. Los nodos que realmente construyen bloques solo necesitan tener el compromiso KZG de blobs, y pueden confiar en la muestreo de disponibilidad de datos (DAS) para verificar la disponibilidad de los bloques de datos.
A continuación se encuentra la implementación y lanzamiento de PeerDAS. Después, aumentar gradualmente la cantidad de blobs en PeerDAS, al mismo tiempo observando cuidadosamente la red y mejorando el software para garantizar la seguridad, es un proceso progresivo. También esperamos más trabajo académico para regular PeerDAS y otras versiones de DAS, así como la interacción con cuestiones de seguridad como las reglas de selección de bifurcación.
En etapas futuras más avanzadas, necesitamos hacer más trabajo para determinar la versión ideal de 2D DAS y demostrar sus propiedades de seguridad. También esperamos poder eventualmente pasar de KZG a una alternativa que sea segura cuánticamente y que no requiera un entorno confiable.
El camino de realidad a largo plazo que yo veo es:
Implementar el DAS 2D ideal;
Continuar usando 1D DAS, sacrificando la eficiencia del ancho de banda de muestreo, aceptando un límite de datos más bajo por simplicidad y robustez.
Abandonar DA y aceptar completamente Plasma como nuestra principal arquitectura Layer2 de interés.
Por favor, tenga en cuenta que, incluso si decidimos expandir la ejecución directamente en la capa L1, esta opción existe. Esto se debe a que si la capa L1 tiene que manejar una gran cantidad de TPS, los bloques L1 se volverán muy grandes, y los clientes querrán tener un método eficiente para verificar su corrección, por lo tanto, tendremos que usar en la capa L1 las mismas tecnologías que Rollup( como ZK-EVM y DAS).
Compresión de datos
Cada transacción en un Rollup ocupa una gran cantidad de espacio de datos en la cadena: una transferencia ERC20 requiere aproximadamente 180 bytes. Incluso con un muestreo de disponibilidad de datos ideal, esto limita la escalabilidad del protocolo Layer. Cada slot es de 16 MB, obtenemos:
16000000 / 12 / 180 = 7407 TPS
¿Qué pasaría si pudiéramos no solo resolver los problemas del numerador, sino también los problemas del denominador, para que cada transacción en el Rollup ocupe menos bytes en la cadena?
Existen varias maneras de comprimir datos:
Compresión de cero bytes: reemplaza cada secuencia larga de cero bytes con dos bytes que indican cuántos cero bytes hay.
Agregación de firmas: Cambio de firmas ECDSA a firmas BLS. La característica de las firmas BLS es que múltiples firmas pueden combinarse en una sola firma, y esta firma puede probar la validez de todas las firmas originales.
Reemplazar direcciones con punteros: Si se ha utilizado una dirección anteriormente, podemos reemplazar la dirección de 20 bytes por un puntero de 4 bytes que apunte a una posición en el historial.
Serialización personalizada de valores de transacción: la mayoría de los valores de transacción tienen pocos dígitos, por ejemplo, 0.25 Ether se representa como 250,000,000,000,000,000 wei. La tarifa base máxima y la tarifa prioritaria son similares. Por lo tanto, podemos usar un formato de punto flotante decimal personalizado para representar la mayoría de los valores monetarios.
Diferencias en el estado de publicación de Rollups basadas en la prueba de validez en lugar de transacciones.
Lo que se debe hacer a continuación es implementar realmente el plan anterior. Los principales compromisos incluyen:
Cambiar a la firma BLS requiere un gran esfuerzo y reducirá la compatibilidad con los chips de hardware confiables que pueden mejorar la seguridad. Se puede utilizar un encapsulamiento ZK-SNARK de otros esquemas de firma como sustituto.
Compresión dinámica ( Por ejemplo, reemplazar direcciones ) con punteros puede complicar el código del cliente.
Publicar diferencias de estado en la cadena en lugar de transacciones reducirá la auditabilidad y hará que muchos software (, como exploradores de bloques ), no puedan funcionar.
La adopción de ERC-4337 y la inclusión de parte de su contenido en el L2 EVM pueden acelerar significativamente el despliegue de la tecnología de agregación. Colocar parte del contenido de ERC-4337 en el L1 puede acelerar su implementación en el L2.
Plasma Generalizado
Incluso con blobs de 16 MB y compresión de datos, 58,000 TPS puede no ser suficiente para satisfacer completamente la demanda de pagos de consumidores, redes sociales descentralizadas u otros campos de alto ancho de banda, especialmente cuando comenzamos a considerar factores de privacidad, lo que puede reducir la escalabilidad entre 3 y 8 veces. Para escenarios de aplicaciones de alto volumen de transacciones y bajo valor, una opción actual es utilizar Validium, que mantiene los datos fuera de la cadena y adopta un modelo de seguridad interesante: los operadores no pueden robar los fondos de los usuarios, pero pueden congelar temporal o permanentemente los fondos de todos los usuarios. Pero podemos hacerlo mejor.
Plasma es una solución de escalabilidad que implica que un operador publique bloques fuera de la cadena y coloque la raíz de Merkle de estos bloques en la cadena (, a diferencia de Rollup, que coloca bloques completos en la cadena ). Para cada bloque, el operador enviará a cada usuario una rama de Merkle para demostrar qué cambios han ocurrido en los activos de ese usuario, o si no ha habido cambios. Los usuarios pueden extraer sus activos proporcionando la rama de Merkle. Es importante que esta rama no tenga que tener el estado más reciente como raíz. Por lo tanto, incluso si hay problemas de disponibilidad de datos, los usuarios aún pueden recuperar sus activos extrayendo su estado más reciente disponible. Si un usuario presenta una rama inválida (, por ejemplo, extrayendo activos que ya ha enviado a otras personas, o si el operador crea un activo de la nada ), se puede determinar la titularidad legítima de los activos a través del mecanismo de desafío en la cadena.
Las versiones tempranas de Plasma solo podían manejar casos de uso de pagos y no podían ser promovidas de manera efectiva. Sin embargo, si requerimos que cada raíz sea verificada con SNARK, entonces Plasma se vuelve mucho más poderoso. Cada juego de desafío puede simplificarse considerablemente, ya que hemos excluido la mayoría de las posibles rutas de trampa de los operadores. Al mismo tiempo, se abren nuevas rutas que permiten que la tecnología Plasma se expanda a una gama más amplia de categorías de activos. Por último, en el caso de que los operadores no hagan trampa, los usuarios pueden retirar fondos de inmediato, sin tener que esperar una semana del período de desafío.
Una clave de entendimiento es que el sistema Plasma no necesita ser perfecto. Incluso si solo puedes proteger un subconjunto de activos (, por ejemplo, solo los tokens que no se han movido en la última semana ), ya has mejorado significativamente la situación actual del EVM extremadamente escalable (, es decir, Validium ).
Otro tipo de estructura es la mezcla de Plasma/Rollup, como Intmax. Estas construcciones colocan una cantidad muy pequeña de datos de cada usuario en la cadena (, por ejemplo, 5 bytes ), haciendo esto se pueden obtener ciertas características entre Plasma y Rollup: en el caso de Intmax, puedes obtener una escalabilidad y privacidad muy altas, aunque incluso con una capacidad de 16 MB, teóricamente también está limitado a aproximadamente 16.
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.
10 me gusta
Recompensa
10
5
Compartir
Comentar
0/400
DeFiCaffeinator
· hace17h
Ha llegado el nuevo campo de recolección de tontos L2.
Ver originalesResponder0
BlockchainTherapist
· hace17h
eth es el rey de la montaña
Ver originalesResponder0
CryptoHistoryClass
· hace17h
*revisa patrones históricos* otra narrativa de escalado de eth... al igual que la exageración de plasma de 2018 en mi opinión
Ver originalesResponder0
Rugman_Walking
· hace18h
¡El ecosistema de Eth es el camino, no hay que pensar demasiado!
Ver originalesResponder0
MidnightTrader
· hace18h
Los jugadores del ecosistema L2 realmente están ganando mucho.
Ethereum The Surge: la visión de 100,000 TPS y la solución al problema de escalabilidad
El posible futuro de Ethereum: The Surge
La hoja de ruta de Ethereum incluía originalmente dos estrategias de escalado: sharding y protocolos de Layer2. El sharding permite que cada nodo verifique y almacene solo una pequeña parte de las transacciones, mientras que Layer2 mantiene la mayor parte de los datos y cálculos fuera de la cadena principal. Estas dos metodologías se fusionaron eventualmente, formando una hoja de ruta centrada en Rollup, que sigue siendo la estrategia de escalado actual de Ethereum.
La hoja de ruta centrada en Rollup propone una división de trabajo simple: Ethereum L1 se enfoca en convertirse en una capa base poderosa y descentralizada, mientras que L2 asume la tarea de ayudar a escalar el ecosistema. Este modelo es común en la sociedad: la existencia del sistema judicial (L1) es para proteger contratos y derechos de propiedad, mientras que los emprendedores (L2) construyen sobre esa base.
Este año, la hoja de ruta centrada en Rollup ha logrado avances importantes: el lanzamiento de blobs EIP-4844 ha aumentado significativamente el ancho de banda de datos de Ethereum L1, y varios Rollups EVM han entrado en la primera fase. Cada L2 existe como un "fragmento" independiente, y la diversidad de enfoques para implementar fragmentos se ha convertido en una realidad. Pero este camino también enfrenta algunos desafíos únicos. Nuestra tarea ahora es completar la hoja de ruta centrada en Rollup, resolver estos problemas y al mismo tiempo mantener la solidez y descentralización de Ethereum L1.
The Surge: Objetivos Clave
Paradoja del triángulo de escalabilidad
La paradoja del triángulo de escalabilidad sostiene que hay una contradicción entre las tres características de la blockchain: descentralización, escalabilidad y seguridad. Presenta un argumento matemático heurístico: si un nodo amigable con la descentralización puede validar N transacciones por segundo, y tienes una cadena que puede procesar k*N transacciones por segundo, entonces (i) cada transacción solo puede ser vista por 1/k nodos, lo que significa que un atacante solo necesita comprometer unos pocos nodos para ejecutar una transacción maliciosa, o (ii) tus nodos se volverán poderosos, mientras que tu cadena no estará descentralizada.
Sin embargo, la combinación de muestreo de disponibilidad de datos y SNARKs realmente resuelve la paradoja del triángulo: permite a los clientes verificar que una cierta cantidad de datos está disponible y que una cierta cantidad de pasos de cálculo se están ejecutando correctamente, con solo descargar una pequeña cantidad de datos y realizar muy pocos cálculos. Otra solución es la arquitectura Plasma, que transfiere la responsabilidad de monitorear la disponibilidad de datos a los usuarios. Con la popularidad de los SNARKs, la arquitectura Plasma se vuelve más viable para una gama más amplia de casos de uso.
Avances adicionales en el muestreo de disponibilidad de datos
Actualmente, cada slot de Ethereum de 12 segundos tiene 3 blobs de aproximadamente 125 kB, con un ancho de banda de datos disponible de aproximadamente 375 kB. Suponiendo que los datos de la transacción se publiquen directamente en la cadena, la transferencia ERC20 es de aproximadamente 180 bytes, por lo tanto, el TPS máximo de Rollup en Ethereum es de 173.6. Nuestro objetivo a medio plazo es de 16 MB por slot, y si se combinan mejoras en la compresión de datos de Rollup, esto traerá aproximadamente 58000 TPS.
PeerDAS es una implementación relativamente simple de "1D sampling". En Ethereum, cada blob es un polinomio de 4096 grados en un campo primo de 253 bits. Difundimos las partes del polinomio, donde cada parte contiene 16 valores de evaluación de 16 coordenadas adyacentes de un total de 8192 coordenadas. De estos 8192 valores de evaluación, cualquiera de los 4096 puede recuperar el blob.
El funcionamiento de PeerDAS consiste en permitir que cada cliente escuche una pequeña cantidad de subredes, donde la i-ésima subred transmite la i-ésima muestra de cualquier blob y solicita a los pares en la red p2p global los blobs de otras subredes que necesita. Una versión más conservadora, SubnetDAS, utiliza únicamente el mecanismo de subredes, sin consultas adicionales al nivel de pares.
Teóricamente, podemos escalar el "muestreo 1D" bastante grande: si aumentamos el número máximo de blobs a 256( con un objetivo de 128), podemos alcanzar el objetivo de 16 MB, mientras que en el muestreo de disponibilidad de datos, cada nodo necesita manejar 1 MB de ancho de banda por cada slot. Esto está apenas dentro de nuestro rango de tolerancia, lo que significa que los clientes con ancho de banda limitado no pueden muestrear.
Por lo tanto, finalmente queremos avanzar más, realizando muestreo 2D, que no solo se realiza dentro del blob, sino también entre los blobs de forma aleatoria. La propiedad lineal del compromiso KZG se utiliza para expandir un conjunto de blobs dentro de un bloque, que incluye una nueva lista de blobs virtuales codificados de forma redundante con la misma información.
Es crucial que la expansión del compromiso de cómputo no requiera blobs, por lo que este enfoque es fundamentalmente amigable para la construcción de bloques distribuidos. Los nodos que realmente construyen bloques solo necesitan tener el compromiso KZG de blobs, y pueden confiar en la muestreo de disponibilidad de datos (DAS) para verificar la disponibilidad de los bloques de datos.
A continuación se encuentra la implementación y lanzamiento de PeerDAS. Después, aumentar gradualmente la cantidad de blobs en PeerDAS, al mismo tiempo observando cuidadosamente la red y mejorando el software para garantizar la seguridad, es un proceso progresivo. También esperamos más trabajo académico para regular PeerDAS y otras versiones de DAS, así como la interacción con cuestiones de seguridad como las reglas de selección de bifurcación.
En etapas futuras más avanzadas, necesitamos hacer más trabajo para determinar la versión ideal de 2D DAS y demostrar sus propiedades de seguridad. También esperamos poder eventualmente pasar de KZG a una alternativa que sea segura cuánticamente y que no requiera un entorno confiable.
El camino de realidad a largo plazo que yo veo es:
Por favor, tenga en cuenta que, incluso si decidimos expandir la ejecución directamente en la capa L1, esta opción existe. Esto se debe a que si la capa L1 tiene que manejar una gran cantidad de TPS, los bloques L1 se volverán muy grandes, y los clientes querrán tener un método eficiente para verificar su corrección, por lo tanto, tendremos que usar en la capa L1 las mismas tecnologías que Rollup( como ZK-EVM y DAS).
Compresión de datos
Cada transacción en un Rollup ocupa una gran cantidad de espacio de datos en la cadena: una transferencia ERC20 requiere aproximadamente 180 bytes. Incluso con un muestreo de disponibilidad de datos ideal, esto limita la escalabilidad del protocolo Layer. Cada slot es de 16 MB, obtenemos:
16000000 / 12 / 180 = 7407 TPS
¿Qué pasaría si pudiéramos no solo resolver los problemas del numerador, sino también los problemas del denominador, para que cada transacción en el Rollup ocupe menos bytes en la cadena?
Existen varias maneras de comprimir datos:
Compresión de cero bytes: reemplaza cada secuencia larga de cero bytes con dos bytes que indican cuántos cero bytes hay.
Agregación de firmas: Cambio de firmas ECDSA a firmas BLS. La característica de las firmas BLS es que múltiples firmas pueden combinarse en una sola firma, y esta firma puede probar la validez de todas las firmas originales.
Reemplazar direcciones con punteros: Si se ha utilizado una dirección anteriormente, podemos reemplazar la dirección de 20 bytes por un puntero de 4 bytes que apunte a una posición en el historial.
Serialización personalizada de valores de transacción: la mayoría de los valores de transacción tienen pocos dígitos, por ejemplo, 0.25 Ether se representa como 250,000,000,000,000,000 wei. La tarifa base máxima y la tarifa prioritaria son similares. Por lo tanto, podemos usar un formato de punto flotante decimal personalizado para representar la mayoría de los valores monetarios.
Diferencias en el estado de publicación de Rollups basadas en la prueba de validez en lugar de transacciones.
Lo que se debe hacer a continuación es implementar realmente el plan anterior. Los principales compromisos incluyen:
Cambiar a la firma BLS requiere un gran esfuerzo y reducirá la compatibilidad con los chips de hardware confiables que pueden mejorar la seguridad. Se puede utilizar un encapsulamiento ZK-SNARK de otros esquemas de firma como sustituto.
Compresión dinámica ( Por ejemplo, reemplazar direcciones ) con punteros puede complicar el código del cliente.
Publicar diferencias de estado en la cadena en lugar de transacciones reducirá la auditabilidad y hará que muchos software (, como exploradores de bloques ), no puedan funcionar.
La adopción de ERC-4337 y la inclusión de parte de su contenido en el L2 EVM pueden acelerar significativamente el despliegue de la tecnología de agregación. Colocar parte del contenido de ERC-4337 en el L1 puede acelerar su implementación en el L2.
Plasma Generalizado
Incluso con blobs de 16 MB y compresión de datos, 58,000 TPS puede no ser suficiente para satisfacer completamente la demanda de pagos de consumidores, redes sociales descentralizadas u otros campos de alto ancho de banda, especialmente cuando comenzamos a considerar factores de privacidad, lo que puede reducir la escalabilidad entre 3 y 8 veces. Para escenarios de aplicaciones de alto volumen de transacciones y bajo valor, una opción actual es utilizar Validium, que mantiene los datos fuera de la cadena y adopta un modelo de seguridad interesante: los operadores no pueden robar los fondos de los usuarios, pero pueden congelar temporal o permanentemente los fondos de todos los usuarios. Pero podemos hacerlo mejor.
Plasma es una solución de escalabilidad que implica que un operador publique bloques fuera de la cadena y coloque la raíz de Merkle de estos bloques en la cadena (, a diferencia de Rollup, que coloca bloques completos en la cadena ). Para cada bloque, el operador enviará a cada usuario una rama de Merkle para demostrar qué cambios han ocurrido en los activos de ese usuario, o si no ha habido cambios. Los usuarios pueden extraer sus activos proporcionando la rama de Merkle. Es importante que esta rama no tenga que tener el estado más reciente como raíz. Por lo tanto, incluso si hay problemas de disponibilidad de datos, los usuarios aún pueden recuperar sus activos extrayendo su estado más reciente disponible. Si un usuario presenta una rama inválida (, por ejemplo, extrayendo activos que ya ha enviado a otras personas, o si el operador crea un activo de la nada ), se puede determinar la titularidad legítima de los activos a través del mecanismo de desafío en la cadena.
Las versiones tempranas de Plasma solo podían manejar casos de uso de pagos y no podían ser promovidas de manera efectiva. Sin embargo, si requerimos que cada raíz sea verificada con SNARK, entonces Plasma se vuelve mucho más poderoso. Cada juego de desafío puede simplificarse considerablemente, ya que hemos excluido la mayoría de las posibles rutas de trampa de los operadores. Al mismo tiempo, se abren nuevas rutas que permiten que la tecnología Plasma se expanda a una gama más amplia de categorías de activos. Por último, en el caso de que los operadores no hagan trampa, los usuarios pueden retirar fondos de inmediato, sin tener que esperar una semana del período de desafío.
Una clave de entendimiento es que el sistema Plasma no necesita ser perfecto. Incluso si solo puedes proteger un subconjunto de activos (, por ejemplo, solo los tokens que no se han movido en la última semana ), ya has mejorado significativamente la situación actual del EVM extremadamente escalable (, es decir, Validium ).
Otro tipo de estructura es la mezcla de Plasma/Rollup, como Intmax. Estas construcciones colocan una cantidad muy pequeña de datos de cada usuario en la cadena (, por ejemplo, 5 bytes ), haciendo esto se pueden obtener ciertas características entre Plasma y Rollup: en el caso de Intmax, puedes obtener una escalabilidad y privacidad muy altas, aunque incluso con una capacidad de 16 MB, teóricamente también está limitado a aproximadamente 16.