Las estrategias de escalabilidad de Ethereum inicialmente tenían dos tipos: sharding y protocolos Layer 2. El sharding permite que cada nodo verifique y almacene solo una parte de las transacciones, mientras que Layer 2 construye redes sobre Ethereum. Estas dos estrategias finalmente se fusionaron, formando 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, como en el sistema judicial (L1) que protege los contratos y la propiedad, mientras que los emprendedores (L2) construyen sobre esta base.
Este año, la hoja de ruta centrada en Rollup ha logrado importantes resultados: los blobs de EIP-4844 han incrementado significativamente el ancho de banda de datos de Ethereum L1, y múltiples Rollups de la máquina virtual de Ethereum han entrado en la primera fase. Cada L2 existe como un "shard" con sus propias reglas y lógica; la diversidad y pluralidad en la implementación de shards se ha convertido en una realidad. Pero este camino también enfrenta algunos desafíos únicos. Nuestra tarea ahora es completar la hoja de ruta centrada en Rollup, resolver estos problemas, al mismo tiempo que mantenemos la solidez y descentralización de Ethereum L1.
The Surge: Objetivos clave
En el futuro, Ethereum podrá alcanzar más de 100,000 TPS a través de L2;
Mantener la descentralización y robustez de L1;
Al menos algunos L2 heredan completamente las propiedades centrales de Ethereum ( de confianza, apertura y resistencia a la censura );
Ethereum debería sentirse como un ecosistema unificado, no como 34 cadenas de bloques diferentes.
Resumen del contenido
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 tres características de la blockchain: descentralización (, bajo costo de los nodos de operación ), escalabilidad ( para procesar un gran número de transacciones ) y seguridad (, donde un atacante necesitaría comprometer una gran proporción de nodos para hacer fallar una transacción individual ).
La paradoja triangular no es un teorema, y el post que la presenta tampoco incluye una prueba matemática. Ofrece un argumento heurístico: si los nodos amigables y descentralizados pueden verificar N transacciones por segundo, tienes una cadena que procesa k*N transacciones por segundo, entonces: (i) cada transacción solo puede ser vista por 1/k nodos, un atacante solo necesita comprometer unos pocos nodos para realizar transacciones maliciosas, o (ii) tus nodos se volverán más poderosos, y la cadena no estará descentralizada. El artículo no pretende demostrar que romper la paradoja triangular es imposible, sino que muestra que es difícil y requiere salir del marco de pensamiento implícito del argumento.
Durante años, algunas cadenas de alto rendimiento han afirmado resolver el trilema sin cambiar fundamentalmente su 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 más difícil que 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 con SNARKs resuelve efectivamente la paradoja triangular: permite que los clientes descarguen solo una pequeña cantidad de datos y realicen muy pocos cálculos para verificar que una cierta cantidad de datos está disponible y que ciertos pasos de cálculo se han ejecutado correctamente. Los SNARKs no requieren confianza. El muestreo de disponibilidad de datos tiene un sutil modelo de confianza de few-of-N, pero conserva las características fundamentales de una cadena no escalable, ya que incluso un ataque del 51% no puede forzar que bloques malos sean aceptados por la red.
Otra forma de resolver el dilema de los tres es la arquitectura Plasma, que ingeniosamente transfiere la responsabilidad de la vigilancia de la disponibilidad de datos a los usuarios. De 2017 a 2019, cuando solo teníamos pruebas de fraude para expandir la capacidad computacional, Plasma estuvo muy limitado en la ejecución segura, pero con la popularización de los SNARKs, la arquitectura Plasma se vuelve más viable para una gama más amplia de escenarios de uso.
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 de Ethereum tendrá 3 blobs de aproximadamente 125 kB en cada slot de 12 segundos, es decir, el ancho de banda de datos disponible por slot será de aproximadamente 375 kB. Suponiendo que los datos de la transacción se publiquen directamente en la cadena, una transferencia ERC20 ocupa aproximadamente 180 bytes, entonces el TPS máximo de Rollup en Ethereum será: 375000 / 12 / 180 = 173.6 TPS.
El valor máximo teórico de calldata de Ethereum( es: 30 millones de Gas por slot / 16 gas por byte = 1,875,000 bytes por slot), lo que se traduce en 607 TPS. Usando PeerDAS, la cantidad de blobs podría aumentar a 8-16, lo que proporcionaría entre 463 y 926 TPS para calldata.
Esta es una mejora significativa para Ethereum L1, pero no es suficiente. Queremos más escalabilidad. El objetivo a medio plazo es de 16 MB por slot, combinado con mejoras en la compresión de datos de Rollup, lo que traerá 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 4096 sobre un campo primo de 253 bits. Transmitimos las shares del polinomio, cada share contiene 16 evaluaciones de 16 coordenadas adyacentes de un total de 8192 coordenadas. De estas 8192 evaluaciones, cualquier 4096 ( se puede recuperar el blob según los parámetros de propuesta actuales: 64 de cualquiera de los 128 posibles muestras ).
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á las diferentes subredes ) para obtener los blobs que necesita en otras subredes. Una versión más conservadora, SubnetDAS, utiliza únicamente el mecanismo de subred, sin consultas adicionales a la capa de pares. La propuesta actual permite que los nodos de prueba de participación utilicen SubnetDAS, mientras que otros nodos (, es decir, los clientes ), utilizan PeerDAS.
Teóricamente, podemos escalar el tamaño de la "muestra 1D" muy grande: si aumentamos el número máximo de blobs a 256( con un objetivo de 128), podemos alcanzar un objetivo de 16 MB, y en la muestra de disponibilidad de datos, cada nodo tiene 16 muestras * 128 blobs * 512 bytes por muestra por blob = 1 MB de ancho de banda de datos por slot. Esto está apenas dentro del rango de tolerancia: es 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ía el costo de reconstrucción.
Por lo tanto, finalmente queremos ir un paso más allá y realizar muestreo 2D, muestreando aleatoriamente no solo dentro de los blobs, sino también entre los blobs. Utilizando la propiedad lineal del compromiso KZG, expandimos el conjunto de blobs en un bloque a través de un nuevo conjunto de blobs virtuales, donde estos blobs virtuales codifican redundante la misma información.
Es importante destacar que la expansión de compromisos de cálculo no requiere tener blobs, por lo que este enfoque es fundamentalmente amigable con la construcción de bloques distribuidos. Los nodos que realmente construyen bloques solo necesitan tener el compromiso KZG del blob, y pueden confiar en la verificación de disponibilidad de datos mediante muestreo de disponibilidad de datos. El muestreo de disponibilidad de datos unidimensional también es esencialmente amigable con la construcción de bloques distribuidos.
¿Qué más se necesita hacer? ¿Cuáles son las compensaciones?
A continuación se completará la implementación y lanzamiento de PeerDAS. Después, se incrementará continuamente la cantidad de blobs en PeerDAS, mientras se observa cuidadosamente la red y se mejora el software para garantizar la seguridad, lo cual es un proceso gradual. Al mismo tiempo, esperamos que haya más trabajo académico para normalizar PeerDAS y otras versiones de DAS, así como su interacción con problemas de seguridad como las reglas de selección de bifurcación.
En etapas más avanzadas en el futuro, necesitaremos más trabajo para determinar la versión ideal de 2D DAS y demostrar sus atributos de seguridad. También esperamos poder finalmente pasar de KZG a alternativas que sean seguras cuánticamente y no requieran una configuración confiable. Actualmente no está claro qué soluciones candidatas son amigables con la construcción de bloques distribuidos. Incluso usando la costosa tecnología de "fuerza bruta", es decir, usando STARK recursivo para generar pruebas de validez para reconstruir filas y columnas, no es suficiente para satisfacer la demanda, ya que aunque técnicamente STARK tiene un tamaño de O(log(n) * log(log(n)) valor hash ( usando STIR), en realidad STARK es casi del mismo tamaño que todo el blob.
Creo que la ruta de realidad a largo plazo es:
Implementar el 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.
Por favor, ten 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 de L1 se volverán muy grandes, y los clientes querrán tener métodos eficientes para verificar su corrección, por lo tanto, tendremos que usar en la capa L1 la misma tecnología 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á; si Plasma se usa 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 teóricamente DAS es 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 correspondiente.
Compresión de datos
¿Qué problema estamos resolviendo?
Cada transacción en 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 no solo pudiéramos resolver problemas de moléculas, sino también problemas de denominadores, permitiendo que cada transacción en un 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:
Compresión de ceros, utilizando dos bytes para reemplazar cada secuencia larga de ceros, indicando cuántos ceros hay. Además, aprovechamos las propiedades específicas de la transacción:
Agregación de firmas: cambiamos de firmas ECDSA a firmas BLS. La característica de las firmas BLS es que múltiples firmas pueden combinarse en una única firma, esta firma puede probar la validez de todas las firmas originales. En la capa L1, debido a que incluso con la agregación, el costo computacional de verificación es alto, no se considera el uso de firmas BLS. Pero en un entorno L2, donde los datos son escasos, tiene sentido usar firmas BLS. La característica de agregación 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 con un puntero de 4 bytes que apunte a una posición en el historial.
Serialización personalizada de valores de transacción: La mayoría de los valores de transacción tienen pocos dígitos, por ejemplo, 0.25 Ether se representa como 250,000,000,000,000,000 wei. Las tarifas base máximas y las tarifas prioritarias son similares. Por lo tanto, podemos utilizar un formato decimal de punto flotante 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 que pueden aumentar la seguridad. Se puede utilizar un encapsulamiento ZK-SNARK con otros esquemas de firma como alternativa.
Compresión dinámica ( Por ejemplo, reemplazar direcciones ) con punteros hará que el código del cliente se vuelva más complejo.
Publicar las diferencias de estado en la cadena en lugar de las transacciones reducirá la auditabilidad, lo que hará que muchos softwares ( como los exploradores de bloques ) no puedan funcionar.
¿Cómo interactuar con otras partes de la hoja de ruta?
Adoptando ERC-4337, y finalmente incorporando parte de su contenido.
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.
24 me gusta
Recompensa
24
6
Compartir
Comentar
0/400
LongTermDreamer
· 07-22 01:04
Dentro de tres años, todos tendrán que mirar la cara de nuestro L2. Acumular un poco no está de más.
Ver originalesResponder0
alpha_leaker
· 07-19 10:23
En un bull run hay que usar L2 para ganar.
Ver originalesResponder0
GasDevourer
· 07-19 01:26
¡No entiendo L2 y perdí los pantalones!
Ver originalesResponder0
TrustlessMaximalist
· 07-19 01:21
Rollup es genial, introducir una posición es lo correcto.
Ver originalesResponder0
consensus_whisperer
· 07-19 01:11
¿Cuánto tiempo tomará llegar a 100,000 tps? Solo quiero una respuesta clara.
Ver originalesResponder0
GateUser-3824aa38
· 07-19 01:10
Después de dar vueltas, Bitcoin sigue siendo el más útil.
La expansión de Ethereum: Análisis de The Surge y perspectivas de desarrollo de L2
Futuro posible de Ethereum: The Surge
Las estrategias de escalabilidad de Ethereum inicialmente tenían dos tipos: sharding y protocolos Layer 2. El sharding permite que cada nodo verifique y almacene solo una parte de las transacciones, mientras que Layer 2 construye redes sobre Ethereum. Estas dos estrategias finalmente se fusionaron, formando 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, como en el sistema judicial (L1) que protege los contratos y la propiedad, mientras que los emprendedores (L2) construyen sobre esta base.
Este año, la hoja de ruta centrada en Rollup ha logrado importantes resultados: los blobs de EIP-4844 han incrementado significativamente el ancho de banda de datos de Ethereum L1, y múltiples Rollups de la máquina virtual de Ethereum han entrado en la primera fase. Cada L2 existe como un "shard" con sus propias reglas y lógica; la diversidad y pluralidad en la implementación de shards se ha convertido en una realidad. Pero este camino también enfrenta algunos desafíos únicos. Nuestra tarea ahora es completar la hoja de ruta centrada en Rollup, resolver estos problemas, al mismo tiempo que mantenemos la solidez y descentralización de Ethereum L1.
The Surge: Objetivos clave
Resumen del contenido
Paradoja del triángulo de escalabilidad
El triángulo de la escalabilidad sostiene que hay una contradicción entre tres características de la blockchain: descentralización (, bajo costo de los nodos de operación ), escalabilidad ( para procesar un gran número de transacciones ) y seguridad (, donde un atacante necesitaría comprometer una gran proporción de nodos para hacer fallar una transacción individual ).
La paradoja triangular no es un teorema, y el post que la presenta tampoco incluye una prueba matemática. Ofrece un argumento heurístico: si los nodos amigables y descentralizados pueden verificar N transacciones por segundo, tienes una cadena que procesa k*N transacciones por segundo, entonces: (i) cada transacción solo puede ser vista por 1/k nodos, un atacante solo necesita comprometer unos pocos nodos para realizar transacciones maliciosas, o (ii) tus nodos se volverán más poderosos, y la cadena no estará descentralizada. El artículo no pretende demostrar que romper la paradoja triangular es imposible, sino que muestra que es difícil y requiere salir del marco de pensamiento implícito del argumento.
Durante años, algunas cadenas de alto rendimiento han afirmado resolver el trilema sin cambiar fundamentalmente su 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 más difícil que 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 con SNARKs resuelve efectivamente la paradoja triangular: permite que los clientes descarguen solo una pequeña cantidad de datos y realicen muy pocos cálculos para verificar que una cierta cantidad de datos está disponible y que ciertos pasos de cálculo se han ejecutado correctamente. Los SNARKs no requieren confianza. El muestreo de disponibilidad de datos tiene un sutil modelo de confianza de few-of-N, pero conserva las características fundamentales de una cadena no escalable, ya que incluso un ataque del 51% no puede forzar que bloques malos sean aceptados por la red.
Otra forma de resolver el dilema de los tres es la arquitectura Plasma, que ingeniosamente transfiere la responsabilidad de la vigilancia de la disponibilidad de datos a los usuarios. De 2017 a 2019, cuando solo teníamos pruebas de fraude para expandir la capacidad computacional, Plasma estuvo muy limitado en la ejecución segura, pero con la popularización de los SNARKs, la arquitectura Plasma se vuelve más viable para una gama más amplia de escenarios de uso.
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 de Ethereum tendrá 3 blobs de aproximadamente 125 kB en cada slot de 12 segundos, es decir, el ancho de banda de datos disponible por slot será de aproximadamente 375 kB. Suponiendo que los datos de la transacción se publiquen directamente en la cadena, una transferencia ERC20 ocupa aproximadamente 180 bytes, entonces el TPS máximo de Rollup en Ethereum será: 375000 / 12 / 180 = 173.6 TPS.
El valor máximo teórico de calldata de Ethereum( es: 30 millones de Gas por slot / 16 gas por byte = 1,875,000 bytes por slot), lo que se traduce en 607 TPS. Usando PeerDAS, la cantidad de blobs podría aumentar a 8-16, lo que proporcionaría entre 463 y 926 TPS para calldata.
Esta es una mejora significativa para Ethereum L1, pero no es suficiente. Queremos más escalabilidad. El objetivo a medio plazo es de 16 MB por slot, combinado con mejoras en la compresión de datos de Rollup, lo que traerá 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 4096 sobre un campo primo de 253 bits. Transmitimos las shares del polinomio, cada share contiene 16 evaluaciones de 16 coordenadas adyacentes de un total de 8192 coordenadas. De estas 8192 evaluaciones, cualquier 4096 ( se puede recuperar el blob según los parámetros de propuesta actuales: 64 de cualquiera de los 128 posibles muestras ).
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á las diferentes subredes ) para obtener los blobs que necesita en otras subredes. Una versión más conservadora, SubnetDAS, utiliza únicamente el mecanismo de subred, sin consultas adicionales a la capa de pares. La propuesta actual permite que los nodos de prueba de participación utilicen SubnetDAS, mientras que otros nodos (, es decir, los clientes ), utilizan PeerDAS.
Teóricamente, podemos escalar el tamaño de la "muestra 1D" muy grande: si aumentamos el número máximo de blobs a 256( con un objetivo de 128), podemos alcanzar un objetivo de 16 MB, y en la muestra de disponibilidad de datos, cada nodo tiene 16 muestras * 128 blobs * 512 bytes por muestra por blob = 1 MB de ancho de banda de datos por slot. Esto está apenas dentro del rango de tolerancia: es 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ía el costo de reconstrucción.
Por lo tanto, finalmente queremos ir un paso más allá y realizar muestreo 2D, muestreando aleatoriamente no solo dentro de los blobs, sino también entre los blobs. Utilizando la propiedad lineal del compromiso KZG, expandimos el conjunto de blobs en un bloque a través de un nuevo conjunto de blobs virtuales, donde estos blobs virtuales codifican redundante la misma información.
Es importante destacar que la expansión de compromisos de cálculo no requiere tener blobs, por lo que este enfoque es fundamentalmente amigable con la construcción de bloques distribuidos. Los nodos que realmente construyen bloques solo necesitan tener el compromiso KZG del blob, y pueden confiar en la verificación de disponibilidad de datos mediante muestreo de disponibilidad de datos. El muestreo de disponibilidad de datos unidimensional también es esencialmente amigable con la construcción de bloques distribuidos.
¿Qué más se necesita hacer? ¿Cuáles son las compensaciones?
A continuación se completará la implementación y lanzamiento de PeerDAS. Después, se incrementará continuamente la cantidad de blobs en PeerDAS, mientras se observa cuidadosamente la red y se mejora el software para garantizar la seguridad, lo cual es un proceso gradual. Al mismo tiempo, esperamos que haya más trabajo académico para normalizar PeerDAS y otras versiones de DAS, así como su interacción con problemas de seguridad como las reglas de selección de bifurcación.
En etapas más avanzadas en el futuro, necesitaremos más trabajo para determinar la versión ideal de 2D DAS y demostrar sus atributos de seguridad. También esperamos poder finalmente pasar de KZG a alternativas que sean seguras cuánticamente y no requieran una configuración confiable. Actualmente no está claro qué soluciones candidatas son amigables con la construcción de bloques distribuidos. Incluso usando la costosa tecnología de "fuerza bruta", es decir, usando STARK recursivo para generar pruebas de validez para reconstruir filas y columnas, no es suficiente para satisfacer la demanda, ya que aunque técnicamente STARK tiene un tamaño de O(log(n) * log(log(n)) valor hash ( usando STIR), en realidad STARK es casi del mismo tamaño que todo el blob.
Creo que la ruta de realidad a largo plazo es:
Por favor, ten 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 de L1 se volverán muy grandes, y los clientes querrán tener métodos eficientes para verificar su corrección, por lo tanto, tendremos que usar en la capa L1 la misma tecnología 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á; si Plasma se usa 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 teóricamente DAS es 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 correspondiente.
Compresión de datos
¿Qué problema estamos resolviendo?
Cada transacción en 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 no solo pudiéramos resolver problemas de moléculas, sino también problemas de denominadores, permitiendo que cada transacción en un 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:
Compresión de ceros, utilizando dos bytes para reemplazar cada secuencia larga de ceros, indicando cuántos ceros hay. Además, aprovechamos las propiedades específicas de la transacción:
Agregación de firmas: cambiamos de firmas ECDSA a firmas BLS. La característica de las firmas BLS es que múltiples firmas pueden combinarse en una única firma, esta firma puede probar la validez de todas las firmas originales. En la capa L1, debido a que incluso con la agregación, el costo computacional de verificación es alto, no se considera el uso de firmas BLS. Pero en un entorno L2, donde los datos son escasos, tiene sentido usar firmas BLS. La característica de agregación 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 con un puntero de 4 bytes que apunte a una posición en el historial.
Serialización personalizada de valores de transacción: La mayoría de los valores de transacción tienen pocos dígitos, por ejemplo, 0.25 Ether se representa como 250,000,000,000,000,000 wei. Las tarifas base máximas y las tarifas prioritarias son similares. Por lo tanto, podemos utilizar un formato decimal de punto flotante 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 que pueden aumentar la seguridad. Se puede utilizar un encapsulamiento ZK-SNARK con otros esquemas de firma como alternativa.
Compresión dinámica ( Por ejemplo, reemplazar direcciones ) con punteros hará que el código del cliente se vuelva más complejo.
Publicar las diferencias de estado en la cadena en lugar de las transacciones reducirá la auditabilidad, lo que hará que muchos softwares ( como los exploradores de bloques ) no puedan funcionar.
¿Cómo interactuar con otras partes de la hoja de ruta?
Adoptando ERC-4337, y finalmente incorporando parte de su contenido.