El mapa de ruta de Ethereum incluía originalmente 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 Layer2 construye una red sobre Ethereum, aprovechando su seguridad mientras mantiene la mayor parte de los datos y cálculos fuera de la cadena principal. Estas dos rutas finalmente se fusionaron, formando un mapa de ruta centrado en Rollup, que sigue siendo la principal estrategia de escalado de Ethereum hasta la fecha.
La hoja de ruta centrada en Rollup propone una clara división de funciones: Ethereum L1 se enfoca en ser una capa base fuerte y descentralizada, mientras que L2 asume la tarea de ayudar a expandir el ecosistema. Este modelo es común en la sociedad, similar al sistema judicial (L1) que existe para proteger los contratos y la propiedad, mientras que los emprendedores (L2) innovan sobre esta base.
Este año, esta hoja de ruta ha logrado importantes avances: el lanzamiento de los blobs de EIP-4844 ha aumentado significativamente el ancho de banda de datos de Ethereum L1, y varios EVM Rollups han entrado en la primera fase. Cada L2 existe como un "fragmento" con sus propias reglas y lógica, y la diversidad en la implementación de fragmentos se ha convertido en una realidad. Sin embargo, 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
Ethereum podrá alcanzar más de 100,000 TPS a través de L2 en el futuro;
Mantener la descentralización y robustez de L1;
Al menos algunos L2 heredan completamente las propiedades fundamentales de Ethereum de la confianza, la apertura y la resistencia a la censura (;
Ethereum debería sentirse como un ecosistema unificado, y no como 34 cadenas de bloques diferentes.
Contenido de este capítulo
Paradoja del triángulo de escalabilidad
Avances adicionales en la 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
![Vitalik nuevo artículo: el futuro posible de Ethereum, The Surge])https://img-cdn.gateio.im/webp-social/moments-0a07a34094cbf643fdead78b4dd682c6.webp(
Paradoja del triángulo de escalabilidad
La paradoja del triángulo de la escalabilidad sostiene que hay una contradicción entre la descentralización, la escalabilidad y la seguridad de la blockchain. No es un teorema, sino que indica que romper la paradoja del triángulo es difícil y requiere salir del marco de pensamiento establecido. Algunas cadenas de alto rendimiento afirman haber resuelto la paradoja del triángulo, pero esto suele ser engañoso, ya que operar nodos en estas cadenas es más difícil que en Ethereum.
Sin embargo, la combinación de muestreo de disponibilidad de datos con SNARKs realmente resuelve la paradoja triangular: permite que los clientes descarguen solo una pequeña cantidad de datos y realicen muy pocos cálculos para verificar la disponibilidad de grandes cantidades de datos y la corrección de los pasos de cálculo. Los SNARKs son sin necesidad de confianza, mientras que el muestreo de disponibilidad de datos tiene un sutil modelo de confianza few-of-N, pero conserva las características básicas de una cadena no escalable.
La arquitectura Plasma es otra solución que transfiere la responsabilidad de la disponibilidad de datos a los usuarios de manera incentivadora. Con la popularidad de los SNARKs, Plasma se vuelve viable para escenarios de uso más amplios.
![Vitalik nuevo artículo: El futuro posible de Ethereum, 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?
Actualmente, en Ethereum, cada slot de 12 segundos tiene 3 blobs de aproximadamente 125 kB, con un ancho de banda de datos disponible de aproximadamente 375 kB. Asumiendo que los datos de transacciones se publican directamente en la cadena, una transferencia ERC20 ocupa aproximadamente 180 bytes, por lo que el TPS máximo de Rollup en Ethereum es de 173.6. Sumando el calldata se puede alcanzar hasta 607 TPS. Usando PeerDAS, la cantidad de blobs podría aumentar a 8-16, proporcionando entre 463 y 926 TPS para el calldata.
Esta es una mejora significativa, pero aún no es suficiente. Nuestro objetivo a medio plazo es de 16 MB por slot, combinando mejoras en la compresión de datos de Rollup, lo que traerá ~58000 TPS.
¿Qué es? ¿Cómo funciona?
PeerDAS es una implementación simple de "muestreo 1D". En Ethereum, cada blob es un polinomio de 4096 sobre un campo primo de 253 bits. Transmitimos las partes del polinomio, cada parte contiene 16 evaluaciones en 16 coordenadas adyacentes de 8192 coordenadas. Cualquier 4096 evaluaciones pueden restaurar el blob.
PeerDAS permite que cada cliente escuche una pequeña cantidad de subredes, la i-ésima subred transmite la i-ésima muestra de cualquier blob, y el cliente solicita blobs en otras subredes consultando pares en la red p2p global. SubnetDAS utiliza únicamente el mecanismo de subred, sin consultas adicionales a la capa de pares. La propuesta actual permite que los nodos que participan en la prueba de participación utilicen SubnetDAS, mientras que otros nodos utilizan PeerDAS.
Teóricamente, podemos escalar "1D sampling" a gran escala: si aumentamos el número máximo de blobs a 256, podemos alcanzar el objetivo de 16MB, mientras que cada nodo necesita procesar 1 MB de datos por slot. Esto es apenas factible, pero significa que los clientes con ancho de banda limitado no pueden muestrear. Podemos optimizar reduciendo el número de blobs y aumentando el tamaño de los blobs, pero esto aumentará el costo de reconstrucción.
Por lo tanto, al final queremos realizar muestreo 2D, no solo muestreando aleatoriamente dentro de los blobs, sino también entre los blobs. Utilizando la propiedad lineal de los compromisos KZG, expandimos el conjunto de blobs en un bloque a través de un nuevo conjunto de blobs virtuales, que codifican redundamente la misma información.
La muestreo 2D es amigable para la construcción de bloques distribuidos, los nodos que realmente construyen bloques solo necesitan tener el compromiso KZG de blob y pueden confiar en la muestreo de disponibilidad de datos para verificar la disponibilidad de los bloques de datos. El DAS 1D también es esencialmente amigable para la construcción de bloques distribuidos.
¿Qué más se necesita hacer? ¿Cuáles son las compensaciones?
A continuación está la implementación y lanzamiento de PeerDAS. Después, aumentar continuamente el número de blobs en PeerDAS, al mismo tiempo que se observa cuidadosamente la red y se mejora el software para garantizar la seguridad. También necesitamos más trabajo académico para normalizar PeerDAS y su interacción con problemas de seguridad como las reglas de selección de bifurcación.
En el futuro, necesitamos determinar la versión ideal de 2D DAS y demostrar sus propiedades de seguridad. También queremos pasar de KZG a alternativas cuánticamente seguras y sin necesidad de configuración de confianza, pero actualmente no está claro qué candidatos son amigables para la construcción de bloques distribuidos.
El camino de realidad a largo plazo que yo considero es:
Implementar un DAS 2D ideal;
Mantener el uso de 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 la principal arquitectura Layer2.
Incluso si decidimos expandir la ejecución directamente en la capa L1, esta opción existe. Si L1 tiene que manejar una gran cantidad de TPS, los bloques de L1 se volverán muy grandes, y los clientes necesitarán verificar su corrección de manera eficiente, por lo tanto, tendremos que usar la misma tecnología en la capa L1 que en Rollup.
¿Cómo interactuar con otras partes del mapa de ruta?
Si se logra la compresión de datos, la demanda de 2D DAS disminuirá o 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: aunque DAS es teóricamente amigable con la reconstrucción distribuida, en la práctica esto debe combinarse con la propuesta de lista de inclusión de paquetes y su mecanismo de selección de bifurcación relacionado.
![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 del numerador, sino también el problema del denominador, 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 ceros, se reemplaza cada secuencia larga de ceros con dos bytes que indican cuántos ceros hay. Más allá de eso, aprovechamos propiedades específicas de las transacciones:
Agregación de firmas: pasar de firmas ECDSA a firmas BLS, las firmas BLS se pueden combinar en una única firma, probando la validez de todas las firmas originales. En L1, debido al alto costo computacional de la verificación, no se considera el uso de firmas BLS. Pero en L2, un entorno con escasez de datos, tiene sentido utilizar firmas BLS. La característica de agregación de ERC-4337 proporciona un camino para implementar esta funcionalidad.
Reemplazar direcciones con punteros: Si se ha utilizado anteriormente una dirección, 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 de valores de transacción: La mayoría de los valores de transacción tienen pocos dígitos, por ejemplo, 0.25 ETH se representa como 250,000,000,000,000,000 wei. Las tarifas base máximas y las tarifas prioritarias son similares. Por lo tanto, podemos usar un formato de punto flotante decimal personalizado para representar la mayoría de los valores monetarios.
¿Qué más se necesita hacer y qué compromisos hay?
Lo que hay que hacer a continuación es implementar realmente el plan mencionado anteriormente. Las principales consideraciones incluyen:
Cambiar a la firma BLS requiere un gran esfuerzo y disminuirá la compatibilidad con los chips de hardware confiables. Se puede utilizar un encapsulamiento ZK-SNARK de otros esquemas de firma como alternativa.
La compresión dinámica ###, si se reemplaza la dirección ( con punteros, hará que el código del cliente se vuelva complejo.
Publicar diferencias de estado en la cadena en lugar de transacciones reducirá la auditabilidad y hará que muchos software ), como exploradores de bloques (, no funcionen.
) ¿Cómo interactuar con otras partes del mapa de ruta?
Adoptando ERC-4337 y finalmente incorporando parte de su contenido en L2 EVM, se puede acelerar significativamente el despliegue de la tecnología de agregación. Colocar parte del contenido de ERC-4337 en L1 puede acelerar su implementación en L2.
![Vitalik nuevo artículo: el posible futuro de Ethereum, The Surge]###https://img-cdn.gateio.im/webp-social/moments-71424e26868ad99f2adda7a27447820a.webp(
Plasma Generalizado
) ¿Qué problema estamos resolviendo?
Incluso utilizando un blob 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 alto ancho de banda, especialmente cuando consideramos factores de privacidad, lo que puede reducir la escalabilidad de 3 a 8 veces. Para escenarios de aplicaciones de alto volumen de transacciones y bajo valor, una opción actual es utilizar 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 los operadores publiquen bloques fuera de la cadena y coloquen la raíz de Merkle de estos bloques en la cadena. Para cada bloque, los operadores envían a cada usuario una prueba de rama de Merkle que muestra los cambios o la falta de cambios en los activos de ese usuario. Los usuarios pueden extraer activos proporcionando la rama de Merkle. Es importante que esta rama no tenga que tener como raíz el estado más reciente. Por lo tanto, incluso si hay problemas de disponibilidad de datos, los usuarios aún pueden recuperar sus activos extrayendo el estado más reciente disponible. Si un usuario presenta una rama no válida, se puede determinar la propiedad de los activos a través de un mecanismo de desafío en la cadena.
Las primeras versiones de Plasma solo podían manejar casos de uso de pagos, lo que dificultaba su promoción efectiva. Sin embargo, si se exige que cada raíz sea verificada con SNARK, Plasma se volverá mucho más potente. Cada juego de desafío puede ser simplificado en gran medida, ya que hemos eliminado la mayoría de las posibles vías de trampa por parte de los operadores. Al mismo tiempo, también se abren nuevas vías, lo que permite 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 necesidad de esperar una semana para el período de desafío.
Una forma de crear una cadena Plasma EVM ### no es la única forma (: utilizar ZK-SNARK para construir un árbol UTXO paralelo, reflejando los cambios de saldo realizados por EVM, y definir un mapeo único de "el mismo token" en diferentes momentos históricos. Luego se puede construir la estructura Plasma sobre esto.
Una idea clave es que el sistema Plasma no necesita ser perfecto. Incluso si solo puedes proteger un subconjunto de activos ), como solo en el pasado.
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.
17 me gusta
Recompensa
17
6
Compartir
Comentar
0/400
MetaverseVagabond
· 07-16 11:43
Temprano sumar en el mundo Cripto, tontos viejos que han cortado minería y negociado NFTs.
Ver originalesResponder0
LiquidityOracle
· 07-14 02:19
Solo son palabras vacías, L2 trabaja y L1 se queda quieto.
Ver originalesResponder0
TrustlessMaximalist
· 07-14 02:11
alcista L2, Billetera ya lista
Ver originalesResponder0
CryptoPhoenix
· 07-14 01:59
¡El experto ha regresado! Los tontos del mercado bajista están reconstruyendo su mentalidad en el fondo...
Ver originalesResponder0
Blockwatcher9000
· 07-14 01:58
¿l2 no es en el fondo un parche?
Ver originalesResponder0
GasFeeCrybaby
· 07-14 01:57
Un tonto del mundo Cripto que ha perdido mucho, ¿quién entiende el gas que pago por mis operaciones impulsivas todos los días?
Ethereum La hoja de ruta The Surge: del Rollup al camino de escalado de 100,000 TPS
El posible futuro de Ethereum: The Surge
El mapa de ruta de Ethereum incluía originalmente 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 Layer2 construye una red sobre Ethereum, aprovechando su seguridad mientras mantiene la mayor parte de los datos y cálculos fuera de la cadena principal. Estas dos rutas finalmente se fusionaron, formando un mapa de ruta centrado en Rollup, que sigue siendo la principal estrategia de escalado de Ethereum hasta la fecha.
La hoja de ruta centrada en Rollup propone una clara división de funciones: Ethereum L1 se enfoca en ser una capa base fuerte y descentralizada, mientras que L2 asume la tarea de ayudar a expandir el ecosistema. Este modelo es común en la sociedad, similar al sistema judicial (L1) que existe para proteger los contratos y la propiedad, mientras que los emprendedores (L2) innovan sobre esta base.
Este año, esta hoja de ruta ha logrado importantes avances: el lanzamiento de los blobs de EIP-4844 ha aumentado significativamente el ancho de banda de datos de Ethereum L1, y varios EVM Rollups han entrado en la primera fase. Cada L2 existe como un "fragmento" con sus propias reglas y lógica, y la diversidad en la implementación de fragmentos se ha convertido en una realidad. Sin embargo, 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
Contenido de este capítulo
![Vitalik nuevo artículo: el futuro posible de Ethereum, The Surge])https://img-cdn.gateio.im/webp-social/moments-0a07a34094cbf643fdead78b4dd682c6.webp(
Paradoja del triángulo de escalabilidad
La paradoja del triángulo de la escalabilidad sostiene que hay una contradicción entre la descentralización, la escalabilidad y la seguridad de la blockchain. No es un teorema, sino que indica que romper la paradoja del triángulo es difícil y requiere salir del marco de pensamiento establecido. Algunas cadenas de alto rendimiento afirman haber resuelto la paradoja del triángulo, pero esto suele ser engañoso, ya que operar nodos en estas cadenas es más difícil que en Ethereum.
Sin embargo, la combinación de muestreo de disponibilidad de datos con SNARKs realmente resuelve la paradoja triangular: permite que los clientes descarguen solo una pequeña cantidad de datos y realicen muy pocos cálculos para verificar la disponibilidad de grandes cantidades de datos y la corrección de los pasos de cálculo. Los SNARKs son sin necesidad de confianza, mientras que el muestreo de disponibilidad de datos tiene un sutil modelo de confianza few-of-N, pero conserva las características básicas de una cadena no escalable.
La arquitectura Plasma es otra solución que transfiere la responsabilidad de la disponibilidad de datos a los usuarios de manera incentivadora. Con la popularidad de los SNARKs, Plasma se vuelve viable para escenarios de uso más amplios.
![Vitalik nuevo artículo: El futuro posible de Ethereum, 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?
Actualmente, en Ethereum, cada slot de 12 segundos tiene 3 blobs de aproximadamente 125 kB, con un ancho de banda de datos disponible de aproximadamente 375 kB. Asumiendo que los datos de transacciones se publican directamente en la cadena, una transferencia ERC20 ocupa aproximadamente 180 bytes, por lo que el TPS máximo de Rollup en Ethereum es de 173.6. Sumando el calldata se puede alcanzar hasta 607 TPS. Usando PeerDAS, la cantidad de blobs podría aumentar a 8-16, proporcionando entre 463 y 926 TPS para el calldata.
Esta es una mejora significativa, pero aún no es suficiente. Nuestro objetivo a medio plazo es de 16 MB por slot, combinando mejoras en la compresión de datos de Rollup, lo que traerá ~58000 TPS.
¿Qué es? ¿Cómo funciona?
PeerDAS es una implementación simple de "muestreo 1D". En Ethereum, cada blob es un polinomio de 4096 sobre un campo primo de 253 bits. Transmitimos las partes del polinomio, cada parte contiene 16 evaluaciones en 16 coordenadas adyacentes de 8192 coordenadas. Cualquier 4096 evaluaciones pueden restaurar el blob.
PeerDAS permite que cada cliente escuche una pequeña cantidad de subredes, la i-ésima subred transmite la i-ésima muestra de cualquier blob, y el cliente solicita blobs en otras subredes consultando pares en la red p2p global. SubnetDAS utiliza únicamente el mecanismo de subred, sin consultas adicionales a la capa de pares. La propuesta actual permite que los nodos que participan en la prueba de participación utilicen SubnetDAS, mientras que otros nodos utilizan PeerDAS.
Teóricamente, podemos escalar "1D sampling" a gran escala: si aumentamos el número máximo de blobs a 256, podemos alcanzar el objetivo de 16MB, mientras que cada nodo necesita procesar 1 MB de datos por slot. Esto es apenas factible, pero significa que los clientes con ancho de banda limitado no pueden muestrear. Podemos optimizar reduciendo el número de blobs y aumentando el tamaño de los blobs, pero esto aumentará el costo de reconstrucción.
Por lo tanto, al final queremos realizar muestreo 2D, no solo muestreando aleatoriamente dentro de los blobs, sino también entre los blobs. Utilizando la propiedad lineal de los compromisos KZG, expandimos el conjunto de blobs en un bloque a través de un nuevo conjunto de blobs virtuales, que codifican redundamente la misma información.
La muestreo 2D es amigable para la construcción de bloques distribuidos, los nodos que realmente construyen bloques solo necesitan tener el compromiso KZG de blob y pueden confiar en la muestreo de disponibilidad de datos para verificar la disponibilidad de los bloques de datos. El DAS 1D también es esencialmente amigable para la construcción de bloques distribuidos.
¿Qué más se necesita hacer? ¿Cuáles son las compensaciones?
A continuación está la implementación y lanzamiento de PeerDAS. Después, aumentar continuamente el número de blobs en PeerDAS, al mismo tiempo que se observa cuidadosamente la red y se mejora el software para garantizar la seguridad. También necesitamos más trabajo académico para normalizar PeerDAS y su interacción con problemas de seguridad como las reglas de selección de bifurcación.
En el futuro, necesitamos determinar la versión ideal de 2D DAS y demostrar sus propiedades de seguridad. También queremos pasar de KZG a alternativas cuánticamente seguras y sin necesidad de configuración de confianza, pero actualmente no está claro qué candidatos son amigables para la construcción de bloques distribuidos.
El camino de realidad a largo plazo que yo considero es:
Incluso si decidimos expandir la ejecución directamente en la capa L1, esta opción existe. Si L1 tiene que manejar una gran cantidad de TPS, los bloques de L1 se volverán muy grandes, y los clientes necesitarán verificar su corrección de manera eficiente, por lo tanto, tendremos que usar la misma tecnología en la capa L1 que en Rollup.
¿Cómo interactuar con otras partes del mapa de ruta?
Si se logra la compresión de datos, la demanda de 2D DAS disminuirá o 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: aunque DAS es teóricamente amigable con la reconstrucción distribuida, en la práctica esto debe combinarse con la propuesta de lista de inclusión de paquetes y su mecanismo de selección de bifurcación relacionado.
![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 del numerador, sino también el problema del denominador, 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 ceros, se reemplaza cada secuencia larga de ceros con dos bytes que indican cuántos ceros hay. Más allá de eso, aprovechamos propiedades específicas de las transacciones:
Agregación de firmas: pasar de firmas ECDSA a firmas BLS, las firmas BLS se pueden combinar en una única firma, probando la validez de todas las firmas originales. En L1, debido al alto costo computacional de la verificación, no se considera el uso de firmas BLS. Pero en L2, un entorno con escasez de datos, tiene sentido utilizar firmas BLS. La característica de agregación de ERC-4337 proporciona un camino para implementar esta funcionalidad.
Reemplazar direcciones con punteros: Si se ha utilizado anteriormente una dirección, 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 de valores de transacción: La mayoría de los valores de transacción tienen pocos dígitos, por ejemplo, 0.25 ETH se representa como 250,000,000,000,000,000 wei. Las tarifas base máximas y las tarifas prioritarias son similares. Por lo tanto, podemos usar un formato de punto flotante decimal personalizado para representar la mayoría de los valores monetarios.
¿Qué más se necesita hacer y qué compromisos hay?
Lo que hay que hacer a continuación es implementar realmente el plan mencionado anteriormente. Las principales consideraciones incluyen:
Cambiar a la firma BLS requiere un gran esfuerzo y disminuirá la compatibilidad con los chips de hardware confiables. Se puede utilizar un encapsulamiento ZK-SNARK de otros esquemas de firma como alternativa.
La compresión dinámica ###, si se reemplaza la dirección ( con punteros, hará que el código del cliente se vuelva complejo.
Publicar diferencias de estado en la cadena en lugar de transacciones reducirá la auditabilidad y hará que muchos software ), como exploradores de bloques (, no funcionen.
) ¿Cómo interactuar con otras partes del mapa de ruta?
Adoptando ERC-4337 y finalmente incorporando parte de su contenido en L2 EVM, se puede acelerar significativamente el despliegue de la tecnología de agregación. Colocar parte del contenido de ERC-4337 en L1 puede acelerar su implementación en L2.
![Vitalik nuevo artículo: el posible futuro de Ethereum, The Surge]###https://img-cdn.gateio.im/webp-social/moments-71424e26868ad99f2adda7a27447820a.webp(
Plasma Generalizado
) ¿Qué problema estamos resolviendo?
Incluso utilizando un blob 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 alto ancho de banda, especialmente cuando consideramos factores de privacidad, lo que puede reducir la escalabilidad de 3 a 8 veces. Para escenarios de aplicaciones de alto volumen de transacciones y bajo valor, una opción actual es utilizar 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 los operadores publiquen bloques fuera de la cadena y coloquen la raíz de Merkle de estos bloques en la cadena. Para cada bloque, los operadores envían a cada usuario una prueba de rama de Merkle que muestra los cambios o la falta de cambios en los activos de ese usuario. Los usuarios pueden extraer activos proporcionando la rama de Merkle. Es importante que esta rama no tenga que tener como raíz el estado más reciente. Por lo tanto, incluso si hay problemas de disponibilidad de datos, los usuarios aún pueden recuperar sus activos extrayendo el estado más reciente disponible. Si un usuario presenta una rama no válida, se puede determinar la propiedad de los activos a través de un mecanismo de desafío en la cadena.
Las primeras versiones de Plasma solo podían manejar casos de uso de pagos, lo que dificultaba su promoción efectiva. Sin embargo, si se exige que cada raíz sea verificada con SNARK, Plasma se volverá mucho más potente. Cada juego de desafío puede ser simplificado en gran medida, ya que hemos eliminado la mayoría de las posibles vías de trampa por parte de los operadores. Al mismo tiempo, también se abren nuevas vías, lo que permite 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 necesidad de esperar una semana para el período de desafío.
Una forma de crear una cadena Plasma EVM ### no es la única forma (: utilizar ZK-SNARK para construir un árbol UTXO paralelo, reflejando los cambios de saldo realizados por EVM, y definir un mapeo único de "el mismo token" en diferentes momentos históricos. Luego se puede construir la estructura Plasma sobre esto.
Una idea clave es que el sistema Plasma no necesita ser perfecto. Incluso si solo puedes proteger un subconjunto de activos ), como solo en el pasado.