The Surge: El futuro de la escalabilidad de Ethereum
En la hoja de ruta de Ethereum, inicialmente había dos estrategias de escalado: fragmentación y protocolos Layer 2. Estas dos estrategias finalmente se fusionaron, formando una hoja de ruta centrada en Rollup, que sigue siendo la estrategia de escalado de Ethereum hasta el día de hoy.
La hoja de ruta centrada en Rollup propone una división de trabajo simple: Ethereum L1 se enfoca en ser una capa base poderosa y descentralizada, mientras que L2 asume la tarea de ayudar a expandir el ecosistema. Este modelo es omnipresente en la sociedad: la existencia del sistema judicial (L1) es para proteger contratos y derechos de propiedad, mientras que los emprendedores (L2) construyen sobre esta base, impulsando a la humanidad hacia adelante.
Este año, la hoja de ruta centrada en Rollup ha logrado importantes resultados: con el lanzamiento de los blobs EIP-4844, el ancho de banda de datos de Ethereum L1 ha aumentado significativamente, y múltiples EVM Rollup han entrado en la primera fase. Cada L2 existe como un "fragmento" con sus propias reglas y lógica, y la diversidad y pluralidad en la implementación de fragmentos se ha convertido en una realidad. Sin embargo, seguir este camino también presenta algunos desafíos únicos. Por lo tanto, nuestra tarea ahora es completar la hoja de ruta centrada en Rollup, resolver estos problemas, mientras mantenemos la robustez y la 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: ( confiar, ser abierto y resistente a la censura );
Ethereum debería sentirse como un ecosistema unificado, no como 34 blockchains 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
Expandir la ejecución en L1
Paradoja del triángulo de escalabilidad
El triángulo de la escalabilidad sostiene que hay una contradicción entre las tres características de la blockchain: descentralización (, bajo costo de los nodos de operación ), escalabilidad ( con un gran número de transacciones procesadas ) y seguridad ( donde un atacante necesitaría comprometer una gran parte de los nodos en la red para hacer que una transacción falle ).
Es importante notar que la paradoja del triángulo no es un teorema, y las publicaciones que introducen la paradoja del triángulo tampoco incluyen una prueba matemática. Se 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 manejar 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 llevar a cabo una transacción maliciosa, o (ii) tus nodos se volverán poderosos, mientras que tu cadena no se descentralizará. El propósito de este artículo nunca ha sido demostrar que romper la paradoja del triángulo es imposible; por el contrario, su objetivo es mostrar que romper la paradoja ternaria es difícil y requiere, de alguna manera, salir del marco de pensamiento implícito en ese argumento.
Durante años, algunas cadenas de alto rendimiento han afirmado que resuelven el trilema sin cambiar fundamentalmente la arquitectura, a menudo optimizando los nodos mediante técnicas de ingeniería de software. Esto siempre es engañoso, ya que ejecutar nodos en estas cadenas es mucho más difícil que ejecutar nodos en Ethereum. Este artículo explorará por qué es así y por qué la ingeniería de software del cliente L1 por sí sola no puede escalar Ethereum.
Sin embargo, la combinación de muestreo de disponibilidad de datos y SNARKs realmente resuelve la paradoja triangular: permite a los clientes verificar que cierta cantidad de datos está disponible y que cierta cantidad de pasos de cálculo se ejecutan correctamente, al descargar solo una pequeña cantidad de datos y realizar muy poco cálculo. Los SNARKs son sin confianza. El muestreo de disponibilidad de datos tiene un modelo de confianza sutil de pocos de N, pero conserva las características fundamentales que tiene una cadena no escalable, es decir, incluso un ataque del 51% no puede forzar que bloques malos sean aceptados por la red.
Otra forma de resolver el dilema de tres caminos es la arquitectura Plasma, que utiliza tecnologías ingeniosas para transferir la responsabilidad de monitorear la disponibilidad de datos a los usuarios de manera compatible con los incentivos. Desde 2017 hasta 2019, cuando solo teníamos pruebas de fraude como medio para ampliar la capacidad de cómputo, Plasma tenía limitaciones significativas en la ejecución segura, pero con la proliferación de SNARKs, la arquitectura Plasma se ha vuelto más viable para un rango de casos de uso más amplio que nunca.
Avances adicionales en el muestreo de disponibilidad de datos
¿Qué problema estamos resolviendo?
El 13 de marzo de 2024, cuando se implemente la actualización Dencun, la blockchain de Ethereum tendrá 3 blobs de aproximadamente 125 kB por slot cada 12 segundos, o un ancho de banda de datos disponible por slot 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 que el máximo TPS de Rollup en Ethereum es: 375000 / 12 / 180 = 173.6 TPS.
Si sumamos el valor máximo teórico del calldata de Ethereum (: por cada slot 30 millones de Gas / por byte 16 gas = por cada slot 1,875,000 bytes ), se convierte en 607 TPS. Usando PeerDAS, la cantidad de blobs podría aumentar a 8-16, lo que proporcionaría 463-926 TPS para calldata.
Esta es una mejora significativa para Ethereum L1, pero no es suficiente. Queremos más escalabilidad. Nuestro objetivo a medio plazo es de 16 MB por slot, lo que, combinado con las mejoras en la compresión de datos de Rollup, traerá ~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 4096 en un campo primo de 253 bits. Transmitimos las shares del polinomio, donde cada share contiene 16 evaluaciones de 16 coordenadas adyacentes de un total de 8192 coordenadas. De estas 8192 evaluaciones, cualquier 4096 ( según los parámetros propuestos actualmente: cualquier 64 de 128 posibles muestras ) se puede recuperar el blob.
El funcionamiento de PeerDAS es 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 ( quién escuchará diferentes subredes ) para obtener los blobs que necesita en otras subredes. Una versión más conservadora, SubnetDAS, 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 (, es decir, los clientes ), utilicen PeerDAS.
Desde un punto de vista teórico, podemos escalar un "muestreo 1D" bastante grande: si aumentamos el número máximo de blobs a 256( con un objetivo de 128), entonces podemos alcanzar un objetivo de 16MB, y en el muestreo de disponibilidad de datos, cada nodo tiene 16 muestras * 128 blobs * 512 bytes por cada blob por cada muestra = 1 MB de ancho de banda de datos por slot. Esto está apenas dentro de nuestro rango de tolerancia: es factible, pero significa que los clientes con ancho de banda limitado no pueden muestrear. Podemos optimizar esto hasta cierto punto reduciendo el número de blobs y aumentando el tamaño de los blobs, pero esto aumentará los costos de reconstrucción.
Por lo tanto, al final queremos ir un paso más allá y realizar muestreo 2D, un método que no solo realiza muestreo aleatorio dentro del blob, sino también entre los blobs. Aprovechando la propiedad lineal de las promesas KZG, ampliamos el conjunto de blobs en un bloque mediante un conjunto de nuevos blobs virtuales que codifican redundante la misma información.
Es fundamental que la expansión del compromiso de cálculo no requiera blobs, por lo que esta solución es, en esencia, amigable con la construcción de bloques distribuidos. Los nodos que realmente construyen bloques solo necesitan poseer el compromiso KZG de los blobs, y pueden confiar en el muestreo de disponibilidad de datos para verificar la disponibilidad de los bloques de datos. El muestreo de disponibilidad de datos unidimensional también es, en esencia, amigable con la construcción de bloques distribuidos.
¿Qué más hay que hacer? ¿Cuáles son las consideraciones?
A continuación se encuentra la implementación y lanzamiento de PeerDAS. Después, aumentar constantemente el número de blobs en PeerDAS, mientras se observa cuidadosamente la red y se mejora el software para garantizar la seguridad, es un proceso gradual. Al mismo tiempo, esperamos que haya más trabajo académico para regular PeerDAS y otras versiones de DAS y su interacción con cuestiones de seguridad relacionadas con las reglas de selección de bifurcación.
En etapas más avanzadas en el futuro, 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 frente a quantum y que no requiera configuraciones de confianza. Actualmente, no está claro qué candidatos son amigables para la construcción de bloques distribuidos. Incluso utilizando técnicas de "fuerza bruta" costosas, es decir, utilizando STARK recursivo para generar pruebas de validez para reconstruir filas y columnas, no es suficiente para satisfacer la demanda, ya que, aunque técnicamente, un STARK tiene un tamaño de O(log(n) * log(log(n)) hash( usando STIR), en realidad, el STARK es casi del mismo tamaño que el blob completo.
El camino real a largo plazo que creo que es:
Implementar un DAS 2D ideal;
Insistir en usar 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 sigue existiendo. 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 que tendremos que utilizar en la capa L1 las mismas tecnologías que Rollup(, como ZK-EVM y DAS).
¿Cómo interactuar con otras partes del mapa de ruta?
Si se logra la compresión de datos, la demanda de DAS 2D disminuirá o al menos se retrasará, y si Plasma se utiliza ampliamente, la demanda disminuirá aún más. DAS también plantea desafíos a los protocolos y mecanismos de construcción de bloques distribuidos: aunque DAS es teóricamente amigable para 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 elección de bifurcación circundante.
Compresión de datos
¿Qué problema estamos resolviendo?
Cada transacción en un Rollup ocupará 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 de los protocolos de capa. 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 del denominador, para 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, se reemplaza cada secuencia larga de bytes cero por dos bytes que indican cuántos bytes cero hay. Más aún, aprovechamos las propiedades específicas de las transacciones:
Agregación de firmas: Hemos cambiado de firmas ECDSA a firmas BLS. La característica de las firmas BLS es que múltiples firmas pueden combinarse en una única firma, y esta firma puede probar la validez de todas las firmas originales. En la capa L1, no se considera el uso de firmas BLS debido a que, incluso con la agregación, el costo computacional de verificación es alto. Sin embargo, en un entorno de L2 donde los datos son escasos, tiene sentido usar firmas BLS. La característica de agregación de ERC-4337 proporciona un camino para implementar esta funcionalidad.
Reemplazar la dirección con punteros: Si se ha utilizado una dirección en el pasado, podemos reemplazar la dirección de 20 bytes con un puntero de 4 bytes que apunta a una ubicación en el historial.
Serialización personalizada del valor de la transacción ------ La mayoría de los valores de transacción tienen pocos dígitos, por ejemplo, 0.25 Ether se representa como 250
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.
22 me gusta
Recompensa
22
4
Compartir
Comentar
0/400
BrokeBeans
· 07-22 21:16
¿Todavía estás haciendo ampliación de datos? Ya está muy gastado.
Ver originalesResponder0
BearMarketSurvivor
· 07-22 21:15
La línea de suministro trasera es muy estable, la fuerza de Ethereum sigue aumentando.
La ruta de expansión de Ethereum: Análisis de la estrategia de escalado The Surge y objetivos futuros
The Surge: El futuro de la escalabilidad de Ethereum
En la hoja de ruta de Ethereum, inicialmente había dos estrategias de escalado: fragmentación y protocolos Layer 2. Estas dos estrategias finalmente se fusionaron, formando una hoja de ruta centrada en Rollup, que sigue siendo la estrategia de escalado de Ethereum hasta el día de hoy.
La hoja de ruta centrada en Rollup propone una división de trabajo simple: Ethereum L1 se enfoca en ser una capa base poderosa y descentralizada, mientras que L2 asume la tarea de ayudar a expandir el ecosistema. Este modelo es omnipresente en la sociedad: la existencia del sistema judicial (L1) es para proteger contratos y derechos de propiedad, mientras que los emprendedores (L2) construyen sobre esta base, impulsando a la humanidad hacia adelante.
Este año, la hoja de ruta centrada en Rollup ha logrado importantes resultados: con el lanzamiento de los blobs EIP-4844, el ancho de banda de datos de Ethereum L1 ha aumentado significativamente, y múltiples EVM Rollup han entrado en la primera fase. Cada L2 existe como un "fragmento" con sus propias reglas y lógica, y la diversidad y pluralidad en la implementación de fragmentos se ha convertido en una realidad. Sin embargo, seguir este camino también presenta algunos desafíos únicos. Por lo tanto, nuestra tarea ahora es completar la hoja de ruta centrada en Rollup, resolver estos problemas, mientras mantenemos la robustez y la descentralización de Ethereum L1.
The Surge: Objetivos clave
Contenido de este capítulo
Paradoja del triángulo de escalabilidad
El triángulo de la escalabilidad sostiene que hay una contradicción entre las tres características de la blockchain: descentralización (, bajo costo de los nodos de operación ), escalabilidad ( con un gran número de transacciones procesadas ) y seguridad ( donde un atacante necesitaría comprometer una gran parte de los nodos en la red para hacer que una transacción falle ).
Es importante notar que la paradoja del triángulo no es un teorema, y las publicaciones que introducen la paradoja del triángulo tampoco incluyen una prueba matemática. Se 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 manejar 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 llevar a cabo una transacción maliciosa, o (ii) tus nodos se volverán poderosos, mientras que tu cadena no se descentralizará. El propósito de este artículo nunca ha sido demostrar que romper la paradoja del triángulo es imposible; por el contrario, su objetivo es mostrar que romper la paradoja ternaria es difícil y requiere, de alguna manera, salir del marco de pensamiento implícito en ese argumento.
Durante años, algunas cadenas de alto rendimiento han afirmado que resuelven el trilema sin cambiar fundamentalmente la arquitectura, a menudo optimizando los nodos mediante técnicas de ingeniería de software. Esto siempre es engañoso, ya que ejecutar nodos en estas cadenas es mucho más difícil que ejecutar nodos en Ethereum. Este artículo explorará por qué es así y por qué la ingeniería de software del cliente L1 por sí sola no puede escalar Ethereum.
Sin embargo, la combinación de muestreo de disponibilidad de datos y SNARKs realmente resuelve la paradoja triangular: permite a los clientes verificar que cierta cantidad de datos está disponible y que cierta cantidad de pasos de cálculo se ejecutan correctamente, al descargar solo una pequeña cantidad de datos y realizar muy poco cálculo. Los SNARKs son sin confianza. El muestreo de disponibilidad de datos tiene un modelo de confianza sutil de pocos de N, pero conserva las características fundamentales que tiene una cadena no escalable, es decir, incluso un ataque del 51% no puede forzar que bloques malos sean aceptados por la red.
Otra forma de resolver el dilema de tres caminos es la arquitectura Plasma, que utiliza tecnologías ingeniosas para transferir la responsabilidad de monitorear la disponibilidad de datos a los usuarios de manera compatible con los incentivos. Desde 2017 hasta 2019, cuando solo teníamos pruebas de fraude como medio para ampliar la capacidad de cómputo, Plasma tenía limitaciones significativas en la ejecución segura, pero con la proliferación de SNARKs, la arquitectura Plasma se ha vuelto más viable para un rango de casos de uso más amplio que nunca.
Avances adicionales en el muestreo de disponibilidad de datos
¿Qué problema estamos resolviendo?
El 13 de marzo de 2024, cuando se implemente la actualización Dencun, la blockchain de Ethereum tendrá 3 blobs de aproximadamente 125 kB por slot cada 12 segundos, o un ancho de banda de datos disponible por slot 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 que el máximo TPS de Rollup en Ethereum es: 375000 / 12 / 180 = 173.6 TPS.
Si sumamos el valor máximo teórico del calldata de Ethereum (: por cada slot 30 millones de Gas / por byte 16 gas = por cada slot 1,875,000 bytes ), se convierte en 607 TPS. Usando PeerDAS, la cantidad de blobs podría aumentar a 8-16, lo que proporcionaría 463-926 TPS para calldata.
Esta es una mejora significativa para Ethereum L1, pero no es suficiente. Queremos más escalabilidad. Nuestro objetivo a medio plazo es de 16 MB por slot, lo que, combinado con las mejoras en la compresión de datos de Rollup, traerá ~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 4096 en un campo primo de 253 bits. Transmitimos las shares del polinomio, donde cada share contiene 16 evaluaciones de 16 coordenadas adyacentes de un total de 8192 coordenadas. De estas 8192 evaluaciones, cualquier 4096 ( según los parámetros propuestos actualmente: cualquier 64 de 128 posibles muestras ) se puede recuperar el blob.
El funcionamiento de PeerDAS es 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 ( quién escuchará diferentes subredes ) para obtener los blobs que necesita en otras subredes. Una versión más conservadora, SubnetDAS, 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 (, es decir, los clientes ), utilicen PeerDAS.
Desde un punto de vista teórico, podemos escalar un "muestreo 1D" bastante grande: si aumentamos el número máximo de blobs a 256( con un objetivo de 128), entonces podemos alcanzar un objetivo de 16MB, y en el muestreo de disponibilidad de datos, cada nodo tiene 16 muestras * 128 blobs * 512 bytes por cada blob por cada muestra = 1 MB de ancho de banda de datos por slot. Esto está apenas dentro de nuestro rango de tolerancia: es factible, pero significa que los clientes con ancho de banda limitado no pueden muestrear. Podemos optimizar esto hasta cierto punto reduciendo el número de blobs y aumentando el tamaño de los blobs, pero esto aumentará los costos de reconstrucción.
Por lo tanto, al final queremos ir un paso más allá y realizar muestreo 2D, un método que no solo realiza muestreo aleatorio dentro del blob, sino también entre los blobs. Aprovechando la propiedad lineal de las promesas KZG, ampliamos el conjunto de blobs en un bloque mediante un conjunto de nuevos blobs virtuales que codifican redundante la misma información.
Es fundamental que la expansión del compromiso de cálculo no requiera blobs, por lo que esta solución es, en esencia, amigable con la construcción de bloques distribuidos. Los nodos que realmente construyen bloques solo necesitan poseer el compromiso KZG de los blobs, y pueden confiar en el muestreo de disponibilidad de datos para verificar la disponibilidad de los bloques de datos. El muestreo de disponibilidad de datos unidimensional también es, en esencia, amigable con la construcción de bloques distribuidos.
¿Qué más hay que hacer? ¿Cuáles son las consideraciones?
A continuación se encuentra la implementación y lanzamiento de PeerDAS. Después, aumentar constantemente el número de blobs en PeerDAS, mientras se observa cuidadosamente la red y se mejora el software para garantizar la seguridad, es un proceso gradual. Al mismo tiempo, esperamos que haya más trabajo académico para regular PeerDAS y otras versiones de DAS y su interacción con cuestiones de seguridad relacionadas con las reglas de selección de bifurcación.
En etapas más avanzadas en el futuro, 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 frente a quantum y que no requiera configuraciones de confianza. Actualmente, no está claro qué candidatos son amigables para la construcción de bloques distribuidos. Incluso utilizando técnicas de "fuerza bruta" costosas, es decir, utilizando STARK recursivo para generar pruebas de validez para reconstruir filas y columnas, no es suficiente para satisfacer la demanda, ya que, aunque técnicamente, un STARK tiene un tamaño de O(log(n) * log(log(n)) hash( usando STIR), en realidad, el STARK es casi del mismo tamaño que el blob completo.
El camino real a largo plazo que creo que es:
Por favor, tenga en cuenta que, incluso si decidimos expandir la ejecución directamente en la capa L1, esta opción sigue existiendo. 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 que tendremos que utilizar en la capa L1 las mismas tecnologías que Rollup(, como ZK-EVM y DAS).
¿Cómo interactuar con otras partes del mapa de ruta?
Si se logra la compresión de datos, la demanda de DAS 2D disminuirá o al menos se retrasará, y si Plasma se utiliza ampliamente, la demanda disminuirá aún más. DAS también plantea desafíos a los protocolos y mecanismos de construcción de bloques distribuidos: aunque DAS es teóricamente amigable para 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 elección de bifurcación circundante.
Compresión de datos
¿Qué problema estamos resolviendo?
Cada transacción en un Rollup ocupará 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 de los protocolos de capa. 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 del denominador, para 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, se reemplaza cada secuencia larga de bytes cero por dos bytes que indican cuántos bytes cero hay. Más aún, aprovechamos las propiedades específicas de las transacciones:
Agregación de firmas: Hemos cambiado de firmas ECDSA a firmas BLS. La característica de las firmas BLS es que múltiples firmas pueden combinarse en una única firma, y esta firma puede probar la validez de todas las firmas originales. En la capa L1, no se considera el uso de firmas BLS debido a que, incluso con la agregación, el costo computacional de verificación es alto. Sin embargo, en un entorno de L2 donde los datos son escasos, tiene sentido usar firmas BLS. La característica de agregación de ERC-4337 proporciona un camino para implementar esta funcionalidad.
Reemplazar la dirección con punteros: Si se ha utilizado una dirección en el pasado, podemos reemplazar la dirección de 20 bytes con un puntero de 4 bytes que apunta a una ubicación en el historial.
Serialización personalizada del valor de la transacción ------ La mayoría de los valores de transacción tienen pocos dígitos, por ejemplo, 0.25 Ether se representa como 250