La hoja de ruta de Ethereum inicialmente incluía dos estrategias de escalado: sharding y protocolos Layer2. El sharding permite que cada nodo verifique y almacene solo una parte de las transacciones, mientras que Layer2 construye redes sobre Ethereum, aprovechando su seguridad pero manteniendo la mayor parte de los datos y cálculos fuera de la cadena principal. Estas dos metodologías finalmente se fusionaron en una hoja de ruta centrada en Rollup, que sigue siendo la estrategia de escalado de Ethereum hasta la fecha.
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 expandir el ecosistema. Este modelo es común en la sociedad: el sistema judicial (L1) existe para proteger los contratos y la propiedad, mientras que los emprendedores (L2) construyen sobre esta base, impulsando el desarrollo humano.
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 múltiples máquinas virtuales de Ethereum (EVM) Rollup 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, mientras mantenemos la robustez y la descentralización de Ethereum L1.
The Surge: Objetivos clave
El futuro de Ethereum a través de L2 puede alcanzar más de 100,000 TPS;
Mantener la descentralización y robustez de L1;
Al menos parte de L2 hereda completamente las propiedades fundamentales 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 (, bajo costo de operación de nodos ), escalabilidad ( para procesar un gran número de transacciones ) y seguridad (, donde un atacante necesitaría comprometer una gran parte de los nodos en la red para hacer que una sola transacción falle ).
La paradoja triangular no es un teorema, y las publicaciones que la presentan no incluyen una prueba matemática. Ofrece un argumento matemático heurístico: si un nodo amigable y descentralizado puede verificar N transacciones por segundo, y tienes una cadena que maneja 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) tu nodo se volverá poderoso, mientras que tu cadena no estará descentralizada. El artículo tiene como objetivo 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. Esto siempre es engañoso, ya que ejecutar nodos en estas cadenas es mucho más difícil que ejecutar nodos en Ethereum.
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 ejecutan correctamente, con solo descargar una pequeña cantidad de datos y realizar muy pocos cálculos. Los SNARKs son sin necesidad de confianza. El muestreo de disponibilidad de datos tiene un sutil modelo de confianza de pocos de N, pero conserva las características fundamentales que tiene una cadena no escalable, es decir, que incluso un ataque del 51% no puede forzar que los bloques malos sean aceptados por la red.
Otra forma de resolver el dilema de los tres es la arquitectura Plasma, que utiliza técnicas ingeniosas para trasladar la responsabilidad de la disponibilidad de los datos de monitoreo a los usuarios de manera compatible con incentivos. Ya en 2017-2019, cuando solo teníamos la prueba de fraude como medio para expandir la capacidad de cómputo, Plasma estaba muy limitado en la ejecución segura, pero con la popularización de los SNARKs, la arquitectura Plasma se vuelve 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 cadena de bloques Ethereum tendrá 3 blobs de aproximadamente 125 kB en cada slot de 12 segundos, o un ancho de banda de datos disponible por slot de aproximadamente 375 kB. Suponiendo que los datos de transacción se publiquen directamente en la cadena, la transferencia ERC20 es de aproximadamente 180 bytes, por lo tanto, el máximo TPS de Rollup en Ethereum es: 375000 / 12 / 180 = 173.6 TPS.
Si añadimos el valor máximo teórico del calldata de Ethereum (: 30 millones de Gas por slot / 16 gas por byte = 1,875,000 bytes por slot ), esto se convierte en 607 TPS. Usando PeerDAS, el número de blobs podría aumentar a 8-16, lo que proporcionaría entre 463 y 926 TPS para el 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 el campo primo de 253 bits (. Transmitimos las shares del polinomio, donde cada share contiene 16 valores de evaluación de 16 coordenadas adyacentes de un total de 8192 coordenadas. De estos 8192 valores de evaluación, cualquier 4096 ) se puede recuperar del blob según los parámetros propuestos actualmente: cualquiera de las 64 de 128 muestras posibles (.
El funcionamiento de PeerDAS permite 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 solo 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 usen SubnetDAS, mientras que otros nodos ), es decir, los clientes (, usen PeerDAS.
Desde un punto de vista teórico, podemos escalar un "muestreo 1D" a un tamaño bastante grande: si aumentamos el número máximo de blobs a 256) con un objetivo de 128(, entonces podemos alcanzar el objetivo de 16 MB, y con cada nodo de muestreo de disponibilidad de datos teniendo 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á el costo de reconstrucción.
Por lo tanto, al final queremos avanzar un paso más y realizar 2D sampling), este método no solo realiza muestreo aleatorio dentro del blob, sino también entre los blobs. Utilizando la propiedad lineal del compromiso KZG, se expande un conjunto de blobs en un bloque a través de un conjunto de nuevos blobs virtuales, los cuales codifican redundante la misma información.
Por lo tanto, al final queremos ir un paso más allá y realizar muestreo 2D, que no solo se realiza dentro del blob, sino también entre los blobs de manera aleatoria. La propiedad lineal del compromiso KZG se utiliza para expandir un conjunto de blobs dentro de un bloque, que contiene una nueva lista de blobs virtuales que codifican de manera redundante la misma información.
Es crucial que la expansión de los compromisos de cálculo 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 depender de la muestreo de disponibilidad de datos (DAS) para verificar la disponibilidad del bloque de datos. La muestreo de disponibilidad de datos unidimensional (1D DAS) también es esencialmente amigable para la construcción de bloques distribuidos.
( ¿Qué más se necesita hacer? ¿Qué compensaciones hay?
A continuación, se completará la implementación y el lanzamiento de PeerDAS. Luego, se aumentará continuamente la cantidad de blobs en PeerDAS, mientras se observa cuidadosamente la red y se mejora el software para garantizar la seguridad; este es un proceso gradual. Al mismo tiempo, esperamos que haya más trabajos académicos para regular PeerDAS y otras versiones de DAS, así como su interacción con cuestiones de seguridad como las reglas de selección de bifurcaciones.
En etapas más avanzadas en el futuro, necesitaremos hacer más trabajo para determinar la versión ideal de 2D DAS y demostrar sus propiedades de seguridad. También esperamos poder finalmente pasar de KZG a una alternativa que sea segura cuánticamente y no requiera un establecimiento de confianza. Actualmente, no está claro qué candidatos son amigables para la construcción de bloques distribuidos. Incluso utilizando la costosa técnica de "fuerza bruta", 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, el tamaño de un STARK es O)log(n) * log###log(n() hash ( utilizando STIR(, en realidad, el STARK es prácticamente del mismo tamaño que todo el blob.
El camino de realidad a largo plazo que creo es:
Implementar un DAS 2D ideal;
Mantener el uso de 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.
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 de L1 se volverán muy grandes y los clientes deseará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 2D DAS disminuirá, 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: aunque DAS es teóricamente amigable con la reconstrucción distribuida, en la práctica necesita combinarse con la propuesta de lista de inclusión de paquetes y su mecanismo de selección de bifurcación asociado.
![Vitalik nuevo artículo: El posible futuro de Ethereum, The Surge])https://img-cdn.gateio.im/webp-social/moments-c585e5f955b6646c513eaecf452b0597.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 de los protocolos de Layer. Cada slot de 16 MB, obtenemos:
16000000 / 12 / 180 = 7407 TPS
¿Qué pasaría si pudiéramos no solo resolver el problema del numerador, sino también el problema del denominador, permitiendo que cada transacción en el Rollup ocupe menos bytes en la cadena?
¿Qué es y cómo funciona?
En mi opinión, la mejor explicación es esta imagen de hace dos años:
En la compresión de ceros, utilizamos dos bytes para reemplazar cada secuencia larga de ceros, indicando cuántos ceros hay. Más allá de eso, 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 se pueden combinar en una única firma, la cual puede demostrar todas las originales.
Esta página puede contener contenido de terceros, que se proporciona únicamente con fines informativos (sin garantías ni declaraciones) y no debe considerarse como un respaldo por parte de Gate a las opiniones expresadas ni como asesoramiento financiero o profesional. Consulte el Descargo de responsabilidad para obtener más detalles.
6 me gusta
Recompensa
6
4
Compartir
Comentar
0/400
FloorSweeper
· 08-04 04:06
No preguntes por qué, L2 es genial.
Ver originalesResponder0
RamenDeFiSurvivor
· 08-04 04:05
¡L2 de Wala es realmente genial!
Ver originalesResponder0
ShadowStaker
· 08-04 04:02
hmm la eficiencia de mev en l2s aún necesita trabajo para ser honesto... la topología de la red no está del todo ahí aún
Ver originalesResponder0
BearMarketBuyer
· 08-04 03:59
¿Es la capa 2 o solo una broma? Solo estamos mirando.
Ethereum expansión nueva fase: Análisis profundo del mapa de ruta The Surge
El posible futuro de Ethereum: The Surge
La hoja de ruta de Ethereum inicialmente incluía dos estrategias de escalado: sharding y protocolos Layer2. El sharding permite que cada nodo verifique y almacene solo una parte de las transacciones, mientras que Layer2 construye redes sobre Ethereum, aprovechando su seguridad pero manteniendo la mayor parte de los datos y cálculos fuera de la cadena principal. Estas dos metodologías finalmente se fusionaron en una hoja de ruta centrada en Rollup, que sigue siendo la estrategia de escalado de Ethereum hasta la fecha.
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 expandir el ecosistema. Este modelo es común en la sociedad: el sistema judicial (L1) existe para proteger los contratos y la propiedad, mientras que los emprendedores (L2) construyen sobre esta base, impulsando el desarrollo humano.
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 múltiples máquinas virtuales de Ethereum (EVM) Rollup 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, mientras mantenemos la robustez y la 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 (, bajo costo de operación de nodos ), escalabilidad ( para procesar un gran número de transacciones ) y seguridad (, donde un atacante necesitaría comprometer una gran parte de los nodos en la red para hacer que una sola transacción falle ).
La paradoja triangular no es un teorema, y las publicaciones que la presentan no incluyen una prueba matemática. Ofrece un argumento matemático heurístico: si un nodo amigable y descentralizado puede verificar N transacciones por segundo, y tienes una cadena que maneja 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) tu nodo se volverá poderoso, mientras que tu cadena no estará descentralizada. El artículo tiene como objetivo 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. Esto siempre es engañoso, ya que ejecutar nodos en estas cadenas es mucho más difícil que ejecutar nodos en Ethereum.
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 ejecutan correctamente, con solo descargar una pequeña cantidad de datos y realizar muy pocos cálculos. Los SNARKs son sin necesidad de confianza. El muestreo de disponibilidad de datos tiene un sutil modelo de confianza de pocos de N, pero conserva las características fundamentales que tiene una cadena no escalable, es decir, que incluso un ataque del 51% no puede forzar que los bloques malos sean aceptados por la red.
Otra forma de resolver el dilema de los tres es la arquitectura Plasma, que utiliza técnicas ingeniosas para trasladar la responsabilidad de la disponibilidad de los datos de monitoreo a los usuarios de manera compatible con incentivos. Ya en 2017-2019, cuando solo teníamos la prueba de fraude como medio para expandir la capacidad de cómputo, Plasma estaba muy limitado en la ejecución segura, pero con la popularización de los SNARKs, la arquitectura Plasma se vuelve 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 cadena de bloques Ethereum tendrá 3 blobs de aproximadamente 125 kB en cada slot de 12 segundos, o un ancho de banda de datos disponible por slot de aproximadamente 375 kB. Suponiendo que los datos de transacción se publiquen directamente en la cadena, la transferencia ERC20 es de aproximadamente 180 bytes, por lo tanto, el máximo TPS de Rollup en Ethereum es: 375000 / 12 / 180 = 173.6 TPS.
Si añadimos el valor máximo teórico del calldata de Ethereum (: 30 millones de Gas por slot / 16 gas por byte = 1,875,000 bytes por slot ), esto se convierte en 607 TPS. Usando PeerDAS, el número de blobs podría aumentar a 8-16, lo que proporcionaría entre 463 y 926 TPS para el 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 el campo primo de 253 bits (. Transmitimos las shares del polinomio, donde cada share contiene 16 valores de evaluación de 16 coordenadas adyacentes de un total de 8192 coordenadas. De estos 8192 valores de evaluación, cualquier 4096 ) se puede recuperar del blob según los parámetros propuestos actualmente: cualquiera de las 64 de 128 muestras posibles (.
El funcionamiento de PeerDAS permite 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 solo 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 usen SubnetDAS, mientras que otros nodos ), es decir, los clientes (, usen PeerDAS.
Desde un punto de vista teórico, podemos escalar un "muestreo 1D" a un tamaño bastante grande: si aumentamos el número máximo de blobs a 256) con un objetivo de 128(, entonces podemos alcanzar el objetivo de 16 MB, y con cada nodo de muestreo de disponibilidad de datos teniendo 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á el costo de reconstrucción.
Por lo tanto, al final queremos avanzar un paso más y realizar 2D sampling), este método no solo realiza muestreo aleatorio dentro del blob, sino también entre los blobs. Utilizando la propiedad lineal del compromiso KZG, se expande un conjunto de blobs en un bloque a través de un conjunto de nuevos blobs virtuales, los cuales codifican redundante la misma información.
Por lo tanto, al final queremos ir un paso más allá y realizar muestreo 2D, que no solo se realiza dentro del blob, sino también entre los blobs de manera aleatoria. La propiedad lineal del compromiso KZG se utiliza para expandir un conjunto de blobs dentro de un bloque, que contiene una nueva lista de blobs virtuales que codifican de manera redundante la misma información.
Es crucial que la expansión de los compromisos de cálculo 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 depender de la muestreo de disponibilidad de datos (DAS) para verificar la disponibilidad del bloque de datos. La muestreo de disponibilidad de datos unidimensional (1D DAS) también es esencialmente amigable para la construcción de bloques distribuidos.
( ¿Qué más se necesita hacer? ¿Qué compensaciones hay?
A continuación, se completará la implementación y el lanzamiento de PeerDAS. Luego, se aumentará continuamente la cantidad de blobs en PeerDAS, mientras se observa cuidadosamente la red y se mejora el software para garantizar la seguridad; este es un proceso gradual. Al mismo tiempo, esperamos que haya más trabajos académicos para regular PeerDAS y otras versiones de DAS, así como su interacción con cuestiones de seguridad como las reglas de selección de bifurcaciones.
En etapas más avanzadas en el futuro, necesitaremos hacer más trabajo para determinar la versión ideal de 2D DAS y demostrar sus propiedades de seguridad. También esperamos poder finalmente pasar de KZG a una alternativa que sea segura cuánticamente y no requiera un establecimiento de confianza. Actualmente, no está claro qué candidatos son amigables para la construcción de bloques distribuidos. Incluso utilizando la costosa técnica de "fuerza bruta", 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, el tamaño de un STARK es O)log(n) * log###log(n() hash ( utilizando STIR(, en realidad, el STARK es prácticamente del mismo tamaño que todo el blob.
El camino de realidad a largo plazo que creo es:
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 de L1 se volverán muy grandes y los clientes deseará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 2D DAS disminuirá, 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: aunque DAS es teóricamente amigable con la reconstrucción distribuida, en la práctica necesita combinarse con la propuesta de lista de inclusión de paquetes y su mecanismo de selección de bifurcación asociado.
![Vitalik nuevo artículo: El posible futuro de Ethereum, The Surge])https://img-cdn.gateio.im/webp-social/moments-c585e5f955b6646c513eaecf452b0597.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 de los protocolos de Layer. Cada slot de 16 MB, obtenemos:
16000000 / 12 / 180 = 7407 TPS
¿Qué pasaría si pudiéramos no solo resolver el problema del numerador, sino también el problema del denominador, permitiendo que cada transacción en el Rollup ocupe menos bytes en la cadena?
¿Qué es y cómo funciona?
En mi opinión, la mejor explicación es esta imagen de hace dos años:
En la compresión de ceros, utilizamos dos bytes para reemplazar cada secuencia larga de ceros, indicando cuántos ceros hay. Más allá de eso, 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 se pueden combinar en una única firma, la cual puede demostrar todas las originales.