La hoja de ruta de Ethereum originalmente incluía dos estrategias de escalado: sharding y protocolos Layer2. El sharding permite que cada nodo verifique y almacene solo una pequeña parte de las transacciones, mientras que los protocolos Layer2 construyen una red sobre Ethereum. Estos dos caminos finalmente se fusionaron, formando una hoja de ruta centrada en Rollup, que sigue siendo la principal estrategia de escalado de Ethereum hasta el día de hoy.
La hoja de ruta centrada en Rollup propone una clara división de tareas: Ethereum L1 se enfoca en convertirse en una capa base fuerte y descentralizada, mientras que L2 asume la tarea de ayudar a escalar el ecosistema. Este modelo es común en la sociedad, como el sistema judicial (L1) que proporciona garantías básicas, mientras que los emprendedores (L2) impulsan el desarrollo sobre esa base.
Este año, con el lanzamiento de los blobs EIP-4844, el ancho de banda de datos de Ethereum L1 ha aumentado significativamente, y múltiples Rollups de la máquina virtual de Ethereum han entrado en la primera fase. Cada L2 existe como un "fragmento" con sus propias reglas internas y lógica. La diversidad y pluralidad en la implementación de fragmentos se han 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 y resolver estos problemas, mientras mantenemos la robustez 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: ( confianza, apertura, resistencia a la censura );
Ethereum debería sentirse como un ecosistema unificado, en lugar de 34 cadenas de bloques diferentes.
Contenido de este capítulo
Paradoja del triángulo de escalabilidad
Avances adicionales en el muestreo de disponibilidad de datos
Compresión de datos
Plasma Generalizado
Sistema de prueba L2 maduro
Mejora de la interoperabilidad entre L2
Ampliar la ejecución en L1
Paradoja del triángulo de escalabilidad
La paradoja del triángulo de la escalabilidad sostiene que existe una contradicción entre las tres características de la blockchain: descentralización, escalabilidad y seguridad. Este concepto no es un teorema matemático estricto, sino un argumento heurístico. Indica que si un nodo amigable con la descentralización puede verificar N transacciones por segundo, y tienes una cadena que puede procesar k*N transacciones por segundo, entonces o bien cada transacción solo puede ser vista por 1/k nodos, lo que reduce la seguridad (, o bien los nodos se vuelven poderosos ), lo que reduce la descentralización (.
Algunas cadenas de alto rendimiento afirman haber resuelto la paradoja del triángulo, pero en realidad es más difícil operar los nodos de estas cadenas que los nodos de Ethereum. Sin embargo, la combinación de muestreo de disponibilidad de datos con SNARKs realmente resuelve la paradoja del triángulo: permite a los clientes verificar la disponibilidad de una gran cantidad de datos y la corrección de los pasos de cálculo, descargando solo una pequeña cantidad de datos y realizando muy pocos cálculos.
Otra forma de resolver la paradoja del triángulo es la arquitectura Plasma, que transfiere la responsabilidad de la disponibilidad de datos a los usuarios. Con la popularización de los SNARKs, la arquitectura Plasma se vuelve viable para una gama más amplia de casos de uso.
![Vitalik nuevo artículo: Ethereum posible futuro, The Surge])https://img-cdn.gateio.im/webp-social/moments-40311fde406a2b6c83ba590c35e23a7c.webp(
Avances adicionales en el muestreo de disponibilidad de datos
) ¿Qué problema estamos resolviendo?
Después de la actualización Dencun en marzo de 2024, Ethereum tendrá 3 blobs de aproximadamente 125 kB por slot cada 12 segundos, o un ancho de banda de datos disponible de aproximadamente 375 kB por slot. Suponiendo que los datos de las transacciones se publiquen directamente en la cadena, una transferencia ERC20 es de aproximadamente 180 bytes, por lo que el máximo TPS de Rollup en Ethereum es de 173.6. Con los calldata de Ethereum, se puede alcanzar hasta 607 TPS. Usando PeerDAS, el número de blobs podría aumentar a 8-16, proporcionando entre 463 y 926 TPS para calldata.
Esta es una mejora significativa para Ethereum L1, pero no es suficiente. Nuestro objetivo a medio plazo es de 16 MB por slot, combinando mejoras en la compresión de datos Rollup, lo que llevará a aproximadamente 58000 TPS.
¿Qué es? ¿Cómo funciona?
PeerDAS es una implementación relativamente simple de "1D sampling". En Ethereum, cada blob es un polinomio de grado 4096 sobre un campo primo de 253 bits. Transmitimos las partes del polinomio, cada parte contiene 16 valores evaluados de 16 coordenadas adyacentes de un total de 8192 coordenadas. De estos 8192 valores evaluados, cualquier 4096 puede recuperar el blob.
PeerDAS permite que cada cliente escuche una pequeña cantidad de subredes y solicite blobs de otras subredes a través de preguntas a pares en la red p2p global. SubnetDAS, más conservador, utiliza únicamente el mecanismo de subredes, sin consultas adicionales a la capa de pares. La propuesta actual es que los nodos que participan en la prueba de participación utilicen SubnetDAS, mientras que otros nodos utilicen PeerDAS.
Teóricamente, podemos escalar el "muestreo 1D" a gran escala, pero esto haría que los clientes con ancho de banda limitado no pudieran muestrear. Por lo tanto, al final queremos un muestreo 2D, que realice muestreo aleatorio no solo dentro del blob, sino también entre los blobs.
¿Cuáles son los enlaces con la investigación existente?
Introducción a la publicación original sobre la disponibilidad de datos ###2018(
Documento de seguimiento
Artículo explicativo sobre DAS, paradigma
Disponibilidad 2D con compromisos KZG
PeerDAS y el artículo en ethresear.ch
EIP-7594
SubnetDAS en ethresear.ch
Matices de recuperabilidad en la muestreo 2D
) ¿Qué más se necesita hacer? ¿Cuáles son las compensaciones?
A continuación, se implementará y lanzará PeerDAS, y se aumentará continuamente el número de blobs en PeerDAS. Al mismo tiempo, esperamos más trabajos académicos que regulen la interacción entre DAS y problemas de seguridad como las reglas de selección de bifurcación.
En etapas más avanzadas en el futuro, necesitamos determinar la versión ideal del DAS 2D y demostrar sus propiedades de seguridad. También esperamos poder eventualmente pasar de KZG a una alternativa cuánticamente segura y que no requiera configuración de confianza.
La ruta de realidad a largo plazo podría ser:
Implementar el DAS 2D ideal;
Seguir utilizando 1D DAS, sacrificando la eficiencia del ancho de banda de muestreo, para aceptar un límite de datos más bajo por simplicidad y robustez;
Renunciar a DA y aceptar completamente Plasma como nuestra principal arquitectura Layer2 de enfoque.
¿Cómo interactuar con otras partes del roadmap?
Si se implementa la compresión de datos, la demanda de DAS 2D se reducirá, o al menos se retrasará; si Plasma se utiliza ampliamente, la demanda disminuirá aún más. DAS también plantea desafíos para los protocolos y mecanismos de construcción de bloques distribuidos.
![Vitalik nuevo artículo: El futuro posible de Ethereum, The Surge]###https://img-cdn.gateio.im/webp-social/moments-5d1a322bd6b6dfef0dbb78017226633d.webp(
Compresión de datos
) ¿Qué problema estamos resolviendo?
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 no solo pudiéramos resolver el problema de los numeradores, sino también el problema de los denominadores, haciendo que cada transacción en el Rollup ocupe menos bytes en la cadena?
¿Qué es y cómo funciona?
En la compresión de bytes cero, cada secuencia larga de bytes cero se reemplaza por dos bytes que indican cuántos bytes cero hay. Además, aprovechamos las propiedades específicas de las transacciones:
Agregación de firmas: cambiar de firmas ECDSA a firmas BLS, múltiples firmas se pueden combinar en una única firma.
Reemplazar direcciones con punteros: Si hemos utilizado una dirección anteriormente, podemos reemplazar la dirección de 20 bytes por un puntero de 4 bytes que apunte a una ubicación en el historial.
Serialización personalizada del valor de la transacción: utiliza un formato de punto decimal personalizado para representar la mayoría de los valores de moneda.
¿Cuáles son los enlaces con la investigación existente?
Explorar sequence.xyz
Optimización de contratos L2 Calldata
Diferencias en el estado de publicación de Rollups basadas en la prueba de validez en lugar de transacciones
BLS Wallet - Implementación de BLS Aggregation a través de ERC-4337
¿Qué más se necesita hacer y qué consideraciones hay?
Lo que se debe hacer a continuación es implementar realmente el plan mencionado anteriormente. Las principales compensaciones incluyen:
Cambiar a firmas BLS requiere un gran esfuerzo y reducirá la compatibilidad con los chips de hardware confiables.
La compresión dinámica hará que el código del cliente se vuelva más complejo.
Publicar las diferencias de estado en la cadena en lugar de transacciones reducirá la auditabilidad y hará que muchos softwares no funcionen.
¿Cómo interactuar con otras partes del mapa de ruta?
La adopción de ERC-4337 y la inclusión de parte de su contenido en el EVM de L2 pueden acelerar significativamente el despliegue de la tecnología de agregación. Colocar parte del contenido de ERC-4337 en L1 puede acelerar su despliegue en L2.
![Vitalik nuevo artículo: el futuro posible de Ethereum, The Surge]###https://img-cdn.gateio.im/webp-social/moments-71424e26868ad99f2adda7a27447820a.webp(
Plasma Generalizado
) ¿Qué problema estamos resolviendo?
Incluso con blobs de 16 MB y compresión de datos, 58,000 TPS puede no ser suficiente para satisfacer completamente las necesidades de pagos de los consumidores, redes sociales descentralizadas u otros campos de alta capacidad de ancho de banda, especialmente cuando comenzamos a considerar factores de privacidad, lo que podría reducir la escalabilidad entre 3 y 8 veces. Una opción actual es usar Validium, que almacena 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.
¿Qué es y cómo funciona?
Plasma es una solución de escalado que implica que un operador publique bloques fuera de la cadena y coloque la raíz de Merkle de esos bloques 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 ser la raíz del estado más reciente. 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.
Las versiones tempranas de Plasma solo podían manejar casos de uso de pagos y no podían expandirse de manera efectiva. Sin embargo, si requerimos que cada raíz sea verificada con SNARK, entonces Plasma se volverá mucho más poderoso. Cada juego de desafío puede simplificarse enormemente, ya que hemos eliminado la mayoría de las posibles rutas de trampa del operador. Al mismo tiempo, se abren nuevos caminos, permitiendo que la tecnología Plasma se expanda a una gama más amplia de categorías de activos. Finalmente, en el caso de que el operador no haga trampa, los usuarios pueden retirar fondos de inmediato, sin tener que esperar una semana para el período de desafío.
Una idea clave 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 considerablemente la situación actual del EVM superescalable ), es decir, Validium (.
Otra clase de estructura es la mezcla Plasma/Rollup, como Intmax. Estas construcciones colocan una cantidad mínima de datos de cada usuario en la cadena ), por ejemplo, 5 bytes (, de esta manera se pueden obtener ciertas características entre Plasma y Rollup: en el caso de Intmax, puedes lograr una escalabilidad y privacidad muy altas, aunque incluso con una capacidad de 16 MB, teóricamente se limita a aproximadamente 16,000,000 / 12 / 5 = 266,667 TPS.
) ¿Qué enlaces están relacionados con la investigación existente?
Documento original de Plasma
Plasma Cash
Plasma Cashflow
Intmax ###2023(
) ¿Qué más hay que hacer? ¿Qué compensaciones hay?
La tarea principal que queda por hacer es poner el sistema Plasma en producción real. Cualquier Validium puede mejorar al menos en cierta medida sus propiedades de seguridad al incorporar características de Plasma en su mecanismo de salida. El enfoque de la investigación está en obtener las mejores propiedades para EVM ### en términos de requisitos de confianza, costo de gas L1 en el peor de los casos y la capacidad de resistir ataques DoS.
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.
15 me gusta
Recompensa
15
6
Compartir
Comentar
0/400
RektButAlive
· hace20h
L2hacer dinero L1beber sopa estable
Ver originalesResponder0
StablecoinGuardian
· hace21h
¡Qué alto es el umbral de uso de L2~
Ver originalesResponder0
LayerHopper
· 07-21 05:02
Un explorador de L2, ahora tengo toda mi inversión en L2, solo sé que estoy aprovechando las oportunidades on-chain. De vez en cuando hago un poco de validadores para ganar algo de dinero.
Ver originalesResponder0
PanicSeller
· 07-21 04:53
Sin layer3, no soy optimista sobre la caída.
Ver originalesResponder0
FlyingLeek
· 07-21 04:50
Siempre mantener respeto por el mercado, esta ola de行情 realmente valió la pena.
Ver originalesResponder0
WinterWarmthCat
· 07-21 04:41
¿No es demasiado estúpido lograr la expansión conduciendo?
Progreso de la escalabilidad de Ethereum: Análisis de The Surge y perspectivas del roadmap de Rollup
El posible futuro de Ethereum: The Surge
La hoja de ruta de Ethereum originalmente incluía dos estrategias de escalado: sharding y protocolos Layer2. El sharding permite que cada nodo verifique y almacene solo una pequeña parte de las transacciones, mientras que los protocolos Layer2 construyen una red sobre Ethereum. Estos dos caminos finalmente se fusionaron, formando una hoja de ruta centrada en Rollup, que sigue siendo la principal estrategia de escalado de Ethereum hasta el día de hoy.
La hoja de ruta centrada en Rollup propone una clara división de tareas: Ethereum L1 se enfoca en convertirse en una capa base fuerte y descentralizada, mientras que L2 asume la tarea de ayudar a escalar el ecosistema. Este modelo es común en la sociedad, como el sistema judicial (L1) que proporciona garantías básicas, mientras que los emprendedores (L2) impulsan el desarrollo sobre esa base.
Este año, con el lanzamiento de los blobs EIP-4844, el ancho de banda de datos de Ethereum L1 ha aumentado significativamente, y múltiples Rollups de la máquina virtual de Ethereum han entrado en la primera fase. Cada L2 existe como un "fragmento" con sus propias reglas internas y lógica. La diversidad y pluralidad en la implementación de fragmentos se han 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 y resolver estos problemas, mientras mantenemos la robustez y descentralización de Ethereum L1.
The Surge: Objetivos Clave
Contenido de este capítulo
Paradoja del triángulo de escalabilidad
La paradoja del triángulo de la escalabilidad sostiene que existe una contradicción entre las tres características de la blockchain: descentralización, escalabilidad y seguridad. Este concepto no es un teorema matemático estricto, sino un argumento heurístico. Indica que si un nodo amigable con la descentralización puede verificar N transacciones por segundo, y tienes una cadena que puede procesar k*N transacciones por segundo, entonces o bien cada transacción solo puede ser vista por 1/k nodos, lo que reduce la seguridad (, o bien los nodos se vuelven poderosos ), lo que reduce la descentralización (.
Algunas cadenas de alto rendimiento afirman haber resuelto la paradoja del triángulo, pero en realidad es más difícil operar los nodos de estas cadenas que los nodos de Ethereum. Sin embargo, la combinación de muestreo de disponibilidad de datos con SNARKs realmente resuelve la paradoja del triángulo: permite a los clientes verificar la disponibilidad de una gran cantidad de datos y la corrección de los pasos de cálculo, descargando solo una pequeña cantidad de datos y realizando muy pocos cálculos.
Otra forma de resolver la paradoja del triángulo es la arquitectura Plasma, que transfiere la responsabilidad de la disponibilidad de datos a los usuarios. Con la popularización de los SNARKs, la arquitectura Plasma se vuelve viable para una gama más amplia de casos de uso.
![Vitalik nuevo artículo: Ethereum posible futuro, The Surge])https://img-cdn.gateio.im/webp-social/moments-40311fde406a2b6c83ba590c35e23a7c.webp(
Avances adicionales en el muestreo de disponibilidad de datos
) ¿Qué problema estamos resolviendo?
Después de la actualización Dencun en marzo de 2024, Ethereum tendrá 3 blobs de aproximadamente 125 kB por slot cada 12 segundos, o un ancho de banda de datos disponible de aproximadamente 375 kB por slot. Suponiendo que los datos de las transacciones se publiquen directamente en la cadena, una transferencia ERC20 es de aproximadamente 180 bytes, por lo que el máximo TPS de Rollup en Ethereum es de 173.6. Con los calldata de Ethereum, se puede alcanzar hasta 607 TPS. Usando PeerDAS, el número de blobs podría aumentar a 8-16, proporcionando entre 463 y 926 TPS para calldata.
Esta es una mejora significativa para Ethereum L1, pero no es suficiente. Nuestro objetivo a medio plazo es de 16 MB por slot, combinando mejoras en la compresión de datos Rollup, lo que llevará a aproximadamente 58000 TPS.
¿Qué es? ¿Cómo funciona?
PeerDAS es una implementación relativamente simple de "1D sampling". En Ethereum, cada blob es un polinomio de grado 4096 sobre un campo primo de 253 bits. Transmitimos las partes del polinomio, cada parte contiene 16 valores evaluados de 16 coordenadas adyacentes de un total de 8192 coordenadas. De estos 8192 valores evaluados, cualquier 4096 puede recuperar el blob.
PeerDAS permite que cada cliente escuche una pequeña cantidad de subredes y solicite blobs de otras subredes a través de preguntas a pares en la red p2p global. SubnetDAS, más conservador, utiliza únicamente el mecanismo de subredes, sin consultas adicionales a la capa de pares. La propuesta actual es que los nodos que participan en la prueba de participación utilicen SubnetDAS, mientras que otros nodos utilicen PeerDAS.
Teóricamente, podemos escalar el "muestreo 1D" a gran escala, pero esto haría que los clientes con ancho de banda limitado no pudieran muestrear. Por lo tanto, al final queremos un muestreo 2D, que realice muestreo aleatorio no solo dentro del blob, sino también entre los blobs.
¿Cuáles son los enlaces con la investigación existente?
) ¿Qué más se necesita hacer? ¿Cuáles son las compensaciones?
A continuación, se implementará y lanzará PeerDAS, y se aumentará continuamente el número de blobs en PeerDAS. Al mismo tiempo, esperamos más trabajos académicos que regulen la interacción entre DAS y problemas de seguridad como las reglas de selección de bifurcación.
En etapas más avanzadas en el futuro, necesitamos determinar la versión ideal del DAS 2D y demostrar sus propiedades de seguridad. También esperamos poder eventualmente pasar de KZG a una alternativa cuánticamente segura y que no requiera configuración de confianza.
La ruta de realidad a largo plazo podría ser:
¿Cómo interactuar con otras partes del roadmap?
Si se implementa la compresión de datos, la demanda de DAS 2D se reducirá, o al menos se retrasará; si Plasma se utiliza ampliamente, la demanda disminuirá aún más. DAS también plantea desafíos para los protocolos y mecanismos de construcción de bloques distribuidos.
![Vitalik nuevo artículo: El futuro posible de Ethereum, The Surge]###https://img-cdn.gateio.im/webp-social/moments-5d1a322bd6b6dfef0dbb78017226633d.webp(
Compresión de datos
) ¿Qué problema estamos resolviendo?
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 no solo pudiéramos resolver el problema de los numeradores, sino también el problema de los denominadores, haciendo que cada transacción en el Rollup ocupe menos bytes en la cadena?
¿Qué es y cómo funciona?
En la compresión de bytes cero, cada secuencia larga de bytes cero se reemplaza por dos bytes que indican cuántos bytes cero hay. Además, aprovechamos las propiedades específicas de las transacciones:
¿Cuáles son los enlaces con la investigación existente?
¿Qué más se necesita hacer y qué consideraciones hay?
Lo que se debe hacer a continuación es implementar realmente el plan mencionado anteriormente. Las principales compensaciones incluyen:
¿Cómo interactuar con otras partes del mapa de ruta?
La adopción de ERC-4337 y la inclusión de parte de su contenido en el EVM de L2 pueden acelerar significativamente el despliegue de la tecnología de agregación. Colocar parte del contenido de ERC-4337 en L1 puede acelerar su despliegue en L2.
![Vitalik nuevo artículo: el futuro posible de Ethereum, The Surge]###https://img-cdn.gateio.im/webp-social/moments-71424e26868ad99f2adda7a27447820a.webp(
Plasma Generalizado
) ¿Qué problema estamos resolviendo?
Incluso con blobs de 16 MB y compresión de datos, 58,000 TPS puede no ser suficiente para satisfacer completamente las necesidades de pagos de los consumidores, redes sociales descentralizadas u otros campos de alta capacidad de ancho de banda, especialmente cuando comenzamos a considerar factores de privacidad, lo que podría reducir la escalabilidad entre 3 y 8 veces. Una opción actual es usar Validium, que almacena 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.
¿Qué es y cómo funciona?
Plasma es una solución de escalado que implica que un operador publique bloques fuera de la cadena y coloque la raíz de Merkle de esos bloques 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 ser la raíz del estado más reciente. 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.
Las versiones tempranas de Plasma solo podían manejar casos de uso de pagos y no podían expandirse de manera efectiva. Sin embargo, si requerimos que cada raíz sea verificada con SNARK, entonces Plasma se volverá mucho más poderoso. Cada juego de desafío puede simplificarse enormemente, ya que hemos eliminado la mayoría de las posibles rutas de trampa del operador. Al mismo tiempo, se abren nuevos caminos, permitiendo que la tecnología Plasma se expanda a una gama más amplia de categorías de activos. Finalmente, en el caso de que el operador no haga trampa, los usuarios pueden retirar fondos de inmediato, sin tener que esperar una semana para el período de desafío.
Una idea clave 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 considerablemente la situación actual del EVM superescalable ), es decir, Validium (.
Otra clase de estructura es la mezcla Plasma/Rollup, como Intmax. Estas construcciones colocan una cantidad mínima de datos de cada usuario en la cadena ), por ejemplo, 5 bytes (, de esta manera se pueden obtener ciertas características entre Plasma y Rollup: en el caso de Intmax, puedes lograr una escalabilidad y privacidad muy altas, aunque incluso con una capacidad de 16 MB, teóricamente se limita a aproximadamente 16,000,000 / 12 / 5 = 266,667 TPS.
) ¿Qué enlaces están relacionados con la investigación existente?
) ¿Qué más hay que hacer? ¿Qué compensaciones hay?
La tarea principal que queda por hacer es poner el sistema Plasma en producción real. Cualquier Validium puede mejorar al menos en cierta medida sus propiedades de seguridad al incorporar características de Plasma en su mecanismo de salida. El enfoque de la investigación está en obtener las mejores propiedades para EVM ### en términos de requisitos de confianza, costo de gas L1 en el peor de los casos y la capacidad de resistir ataques DoS.