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 (sin confianza, abierto, resistente a la censura);
Ethereum debería sentirse como un ecosistema unificado, no como 34 blockchains diferentes.
Contenido de este capítulo
La 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
Escalar la ejecución en L1
La paradoja del triángulo de escalabilidad
La paradoja del triángulo de escalabilidad es una idea propuesta en 2017 que sugiere que hay una contradicción entre tres características de la blockchain: descentralización (más específicamente: bajo costo de operación de los nodos), escalabilidad (gran cantidad de transacciones procesadas) y seguridad (los atacantes necesitan comprometer una gran parte de los nodos en la red para hacer que una sola transacción falle).
Es importante señalar que la paradoja triangular no es un teorema, y las publicaciones que introducen la paradoja triangular no incluyen pruebas matemáticas. Sin embargo, presenta un argumento matemático heurístico: si un nodo amigable con la descentralización (por ejemplo, una computadora portátil de consumo) puede verificar N transacciones por segundo, y tienes una cadena que procesa 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 realizar 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 no es demostrar que romper la paradoja triangular es imposible; por el contrario, su objetivo es mostrar que romper la paradoja ternaria es difícil y requiere, en cierta medida, salir del marco de pensamiento implícito que conlleva este 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 con 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 un número mínimo de cálculos. Los SNARKs son sin 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, es decir, incluso un ataque del 51% no puede forzar a que bloques malos sean aceptados por la red.
Otra forma de resolver el dilema de la trinidad es la arquitectura Plasma, que utiliza una tecnología ingeniosa para trasladar la responsabilidad de monitorear la disponibilidad de datos a los usuarios de manera compatible con los incentivos. Ya en 2017-2019, cuando solo teníamos pruebas de fraude como medio para expandir la capacidad de cómputo, Plasma estaba muy limitado en su ejecución segura, pero con la proliferación de SNARKs (pruebas no interactivas de conocimiento cero compactas), la arquitectura Plasma se ha vuelto más viable para un rango más amplio de casos de uso que nunca.
Avances adicionales en la muestreo de disponibilidad de datos
¿Qué problema estamos resolviendo?
El 13 de marzo de 2024, cuando se implemente la actualización Dencun, habrá 3 blobs de aproximadamente 125 kB cada 12 segundos por slot, 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, una transferencia ERC20 ocupa aproximadamente 180 bytes, por lo que el máximo TPS en el Rollup es: 375000 / 12 / 180 = 173.6 TPS
Si añadimos el calldata (valor máximo teórico: 30 millones de Gas por slot / 16 gas por byte = 1,875,000 bytes por slot), esto 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 el calldata.
Esta es una mejora significativa para 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á aproximadamente ~58000 TPS.
¿Qué es? ¿Cómo funciona?
PeerDAS es una implementación relativamente simple de "muestreo 1D". En ella, cada blob es un polinomio de 4096 grados en un campo primo de 253 bits. Transmitimos las partes del polinomio, donde cada parte contiene 16 valores de evaluación de 16 coordenadas adyacentes de un total de 8192 coordenadas. De estos 8192 valores de evaluación, cualquier conjunto de 4096 (según los parámetros propuestos actualmente: cualquiera de los 64 de 128 posibles muestras) puede recuperar el blob.
El funcionamiento de PeerDAS es hacer 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 otros blobs en diferentes subredes a través de preguntas a pares en la red p2p global (quienes escucharán diferentes 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 es permitir que los nodos que participan en la prueba de participación usen SubnetDAS, mientras que otros nodos (es decir, 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 (el objetivo es 128), entonces podemos alcanzar el objetivo de 16MB, donde cada nodo en la muestreo de disponibilidad de datos tiene 16 muestras * 128 blobs * 512 bytes por blob por muestra = 1 MB de ancho de banda de datos por slot. Esto está apenas dentro de nuestro rango de tolerancia: es viable, pero significa que los clientes con ancho de banda limitado no pueden muestrear. Podemos optimizar esto hasta cierto punto reduciendo la cantidad de blobs y aumentando el tamaño de los blobs, pero esto aumentará el costo de reconstrucción.
Por lo tanto, finalmente queremos ir un paso más allá y realizar un muestreo 2D (2D sampling), este método no solo realiza muestreo aleatorio dentro de los blobs, sino también entre los blobs. Aprovechando la propiedad lineal de los compromisos KZG, se expande el conjunto de blobs en un bloque mediante 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 realiza muestreo aleatorio dentro de los blobs, sino también entre ellos. La propiedad lineal del compromiso KZG se utiliza para expandir el conjunto de blobs en un bloque, que contiene una nueva lista de blobs virtuales con codificación redundante de la misma información.
Es crucial que la expansión del compromiso de cálculo no requiera un blob, por lo que esta solución es fundamentalmente amigable para la construcción de bloques distribuidos. Los nodos que realmente construyen bloques solo necesitan poseer el compromiso KZG de blob, y pueden depender de la muestreo de disponibilidad de datos (DAS) para verificar la disponibilidad de los bloques de datos. El 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 llevará a cabo la implementación y el lanzamiento de PeerDAS. Después, se aumentará continuamente el número 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 más trabajos académicos para normar PeerDAS y otras versiones de DAS, así como su interacción con problemas de seguridad relacionados con las reglas de selección de bifurcaciones.
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 cuánticamente y no requiera una configuración confiable. Actualmente, no está claro qué soluciones candidatas son amigables para la construcción de bloques distribuidos. Incluso usando 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 (usando STIR), en realidad un STARK es casi del tamaño de todo el blob.
El camino de realidad a largo plazo que considero 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.
Renunciar a DA y aceptar completamente Plasma como nuestra principal arquitectura Layer2 de enfoque.
Tenga en cuenta que, incluso si decidimos escalar la ejecución directamente en la capa L1, esta opción también está disponible. 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 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 implementa 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 esto debe combinarse con la propuesta de lista de inclusión de paquetes y su mecanismo de selección de bifurcación circundante.
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: la transferencia de ERC20 requiere aproximadamente 180 bytes. Incluso con un muestreo de disponibilidad de datos ideal, esto limita la escalabilidad del protocolo de 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 mi opinión, la mejor explicación es esta imagen de hace dos años:
En la compresión de ceros, se reemplaza cada secuencia larga de ceros con dos bytes que indican cuántos ceros hay. Además, aprovechamos las propiedades específicas de la transacción:
Agregación de firmas: pasamos de firmas ECDSA a firmas BLS, cuya característica es que múltiples firmas pueden combinarse en una única firma, la cual puede demostrar la validez de todas las firmas originales. En la capa L1, dado que incluso con la agregación, el costo computacional de la verificación sigue siendo alto, no se considera el uso de firmas BLS. Pero en un entorno L2, donde los datos son escasos, utilizar firmas BLS tiene sentido. La característica de agregación de ERC-4337 proporciona un camino para lograr esta funcionalidad.
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.
9 me gusta
Recompensa
9
5
Compartir
Comentar
0/400
BearMarketBarber
· 07-20 14:21
Corre tan rápido, no dejes que Solana te alcance.
Ver originalesResponder0
LiquidityWhisperer
· 07-20 07:57
¿10w tps? De todos modos, no tengo buenas expectativas.
Ver originalesResponder0
PretendingToReadDocs
· 07-17 23:14
Oh, otra vez es la fase de promesas.
Ver originalesResponder0
RunWhenCut
· 07-17 23:05
¿Finalmente vamos a To the moon? De todos modos, es solo el sonido de la guadaña.
Ver originalesResponder0
ImpermanentSage
· 07-17 23:05
Solo tienes ese aire de llevar al ejército de acciones en alza todo el día.
Ethereum La visión de The Surge: superar 100,000 TPS y la unificación del ecosistema
Futuro posible de Ethereum: The Surge
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 (sin confianza, abierto, resistente a la censura);
Ethereum debería sentirse como un ecosistema unificado, no como 34 blockchains diferentes.
Contenido de este capítulo
La paradoja del triángulo de escalabilidad
La paradoja del triángulo de escalabilidad es una idea propuesta en 2017 que sugiere que hay una contradicción entre tres características de la blockchain: descentralización (más específicamente: bajo costo de operación de los nodos), escalabilidad (gran cantidad de transacciones procesadas) y seguridad (los atacantes necesitan comprometer una gran parte de los nodos en la red para hacer que una sola transacción falle).
Es importante señalar que la paradoja triangular no es un teorema, y las publicaciones que introducen la paradoja triangular no incluyen pruebas matemáticas. Sin embargo, presenta un argumento matemático heurístico: si un nodo amigable con la descentralización (por ejemplo, una computadora portátil de consumo) puede verificar N transacciones por segundo, y tienes una cadena que procesa 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 realizar 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 no es demostrar que romper la paradoja triangular es imposible; por el contrario, su objetivo es mostrar que romper la paradoja ternaria es difícil y requiere, en cierta medida, salir del marco de pensamiento implícito que conlleva este 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 con 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 un número mínimo de cálculos. Los SNARKs son sin 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, es decir, incluso un ataque del 51% no puede forzar a que bloques malos sean aceptados por la red.
Otra forma de resolver el dilema de la trinidad es la arquitectura Plasma, que utiliza una tecnología ingeniosa para trasladar la responsabilidad de monitorear la disponibilidad de datos a los usuarios de manera compatible con los incentivos. Ya en 2017-2019, cuando solo teníamos pruebas de fraude como medio para expandir la capacidad de cómputo, Plasma estaba muy limitado en su ejecución segura, pero con la proliferación de SNARKs (pruebas no interactivas de conocimiento cero compactas), la arquitectura Plasma se ha vuelto más viable para un rango más amplio de casos de uso que nunca.
Avances adicionales en la muestreo de disponibilidad de datos
¿Qué problema estamos resolviendo?
El 13 de marzo de 2024, cuando se implemente la actualización Dencun, habrá 3 blobs de aproximadamente 125 kB cada 12 segundos por slot, 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, una transferencia ERC20 ocupa aproximadamente 180 bytes, por lo que el máximo TPS en el Rollup es: 375000 / 12 / 180 = 173.6 TPS
Si añadimos el calldata (valor máximo teórico: 30 millones de Gas por slot / 16 gas por byte = 1,875,000 bytes por slot), esto 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 el calldata.
Esta es una mejora significativa para 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á aproximadamente ~58000 TPS.
¿Qué es? ¿Cómo funciona?
PeerDAS es una implementación relativamente simple de "muestreo 1D". En ella, cada blob es un polinomio de 4096 grados en un campo primo de 253 bits. Transmitimos las partes del polinomio, donde cada parte contiene 16 valores de evaluación de 16 coordenadas adyacentes de un total de 8192 coordenadas. De estos 8192 valores de evaluación, cualquier conjunto de 4096 (según los parámetros propuestos actualmente: cualquiera de los 64 de 128 posibles muestras) puede recuperar el blob.
El funcionamiento de PeerDAS es hacer 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 otros blobs en diferentes subredes a través de preguntas a pares en la red p2p global (quienes escucharán diferentes 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 es permitir que los nodos que participan en la prueba de participación usen SubnetDAS, mientras que otros nodos (es decir, 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 (el objetivo es 128), entonces podemos alcanzar el objetivo de 16MB, donde cada nodo en la muestreo de disponibilidad de datos tiene 16 muestras * 128 blobs * 512 bytes por blob por muestra = 1 MB de ancho de banda de datos por slot. Esto está apenas dentro de nuestro rango de tolerancia: es viable, pero significa que los clientes con ancho de banda limitado no pueden muestrear. Podemos optimizar esto hasta cierto punto reduciendo la cantidad de blobs y aumentando el tamaño de los blobs, pero esto aumentará el costo de reconstrucción.
Por lo tanto, finalmente queremos ir un paso más allá y realizar un muestreo 2D (2D sampling), este método no solo realiza muestreo aleatorio dentro de los blobs, sino también entre los blobs. Aprovechando la propiedad lineal de los compromisos KZG, se expande el conjunto de blobs en un bloque mediante 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 realiza muestreo aleatorio dentro de los blobs, sino también entre ellos. La propiedad lineal del compromiso KZG se utiliza para expandir el conjunto de blobs en un bloque, que contiene una nueva lista de blobs virtuales con codificación redundante de la misma información.
Es crucial que la expansión del compromiso de cálculo no requiera un blob, por lo que esta solución es fundamentalmente amigable para la construcción de bloques distribuidos. Los nodos que realmente construyen bloques solo necesitan poseer el compromiso KZG de blob, y pueden depender de la muestreo de disponibilidad de datos (DAS) para verificar la disponibilidad de los bloques de datos. El 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 llevará a cabo la implementación y el lanzamiento de PeerDAS. Después, se aumentará continuamente el número 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 más trabajos académicos para normar PeerDAS y otras versiones de DAS, así como su interacción con problemas de seguridad relacionados con las reglas de selección de bifurcaciones.
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 cuánticamente y no requiera una configuración confiable. Actualmente, no está claro qué soluciones candidatas son amigables para la construcción de bloques distribuidos. Incluso usando 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 (usando STIR), en realidad un STARK es casi del tamaño de todo el blob.
El camino de realidad a largo plazo que considero es:
Tenga en cuenta que, incluso si decidimos escalar la ejecución directamente en la capa L1, esta opción también está disponible. 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 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 implementa 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 esto debe combinarse con la propuesta de lista de inclusión de paquetes y su mecanismo de selección de bifurcación circundante.
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: la transferencia de ERC20 requiere aproximadamente 180 bytes. Incluso con un muestreo de disponibilidad de datos ideal, esto limita la escalabilidad del protocolo de 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 mi opinión, la mejor explicación es esta imagen de hace dos años:
En la compresión de ceros, se reemplaza cada secuencia larga de ceros con dos bytes que indican cuántos ceros hay. Además, aprovechamos las propiedades específicas de la transacción:
Agregación de firmas: pasamos de firmas ECDSA a firmas BLS, cuya característica es que múltiples firmas pueden combinarse en una única firma, la cual puede demostrar la validez de todas las firmas originales. En la capa L1, dado que incluso con la agregación, el costo computacional de la verificación sigue siendo alto, no se considera el uso de firmas BLS. Pero en un entorno L2, donde los datos son escasos, utilizar firmas BLS tiene sentido. La característica de agregación de ERC-4337 proporciona un camino para lograr esta funcionalidad.