- Tema
2k Popularidad
4k Popularidad
32k Popularidad
29k Popularidad
496 Popularidad
111k Popularidad
26k Popularidad
26k Popularidad
7k Popularidad
14k Popularidad
- Anclado
2k Popularidad
4k Popularidad
32k Popularidad
29k Popularidad
496 Popularidad
111k Popularidad
26k Popularidad
26k Popularidad
7k Popularidad
14k Popularidad
Ethereum El plano de The Surge: Rompiendo el dilema de la escalabilidad y mejorando el rendimiento de L2 a 100,000 TPS
Futuro posible de Ethereum: The Surge
El mapa de ruta de Ethereum originalmente incluía dos estrategias de escalado: fragmentación y protocolos Layer2. Estos dos caminos finalmente se fusionaron, formando un mapa de ruta centrado en Rollup, que sigue siendo la estrategia de escalado actual de Ethereum.
La hoja de ruta centrada en Rollup propone una división de trabajo simple: Ethereum L1 se enfoca en ser una capa base fuerte y descentralizada, mientras que L2 asume la tarea de ayudar a expandir el ecosistema. Este modelo es común en la sociedad: la existencia del sistema judicial (L1) es para proteger los contratos y la propiedad, mientras que los emprendedores (L2) construyen sobre esta base, impulsando el desarrollo.
Este año, la hoja de ruta centrada en Rollup ha logrado importantes avances: con el lanzamiento de los blobs EIP-4844, el ancho de banda de datos de Ethereum L1 ha aumentado significativamente, y múltiples Rollups de la máquina virtual de Ethereum 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 forma de implementar fragmentos 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, mientras mantenemos la solidez y descentralización de Ethereum L1.
The Surge: Objetivos Clave
En el futuro, Ethereum puede 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.
Contenido de este capítulo
Paradoja del triángulo de escalabilidad
La paradoja del triángulo de escalabilidad sostiene que existe una contradicción entre las tres características de la blockchain: descentralización (, bajo costo de operación de los nodos ), escalabilidad (, gran cantidad de transacciones procesadas ) y seguridad (, donde un atacante necesita 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. Ofrece un argumento matemático heurístico: si un nodo amigable y descentralizado puede verificar N transacciones por segundo, y tienes una cadena que puede procesar 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) tu nodo se volverá fuerte, mientras que tu cadena no se descentraliza. El propósito de este artículo no es probar que romper la paradoja del triángulo es imposible; más bien, tiene la intención de mostrar que romper la paradoja ternaria es difícil y requiere, de alguna manera, salir del marco de pensamiento implícito en el argumento.
Durante años, algunas cadenas de alto rendimiento han afirmado que resuelven el trilema sin cambiar fundamentalmente la arquitectura, a menudo mediante la aplicación de técnicas de ingeniería de software para optimizar 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 con SNARKs realmente resuelve la paradoja del triángulo: permite a los clientes validar 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 few-of-N, pero conserva las características fundamentales que tiene una cadena no escalable, es decir, que incluso un ataque del 51% no puede obligar a que bloques malos sean aceptados por la red.
Otra forma de resolver el dilema de los tres es la arquitectura Plasma, que utiliza una técnica ingeniosa para trasladar la responsabilidad de la disponibilidad de los datos de monitoreo a los usuarios de una manera compatible con los incentivos. Ya en 2017-2019, cuando solo teníamos la prueba de fraude como medio para expandir la capacidad computacional, Plasma estaba muy limitado en la ejecución segura, pero con la popularización de los SNARKs, la arquitectura Plasma se ha vuelto más viable para una gama de casos de uso más amplia 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 de Ethereum tendrá 3 blobs de aproximadamente 125 kB en cada slot de 12 segundos, o un ancho de banda de datos disponible de aproximadamente 375 kB por slot. Suponiendo que los datos de transacción se publiquen directamente en la cadena, una transferencia ERC20 es de aproximadamente 180 bytes, por lo tanto, el TPS máximo de Rollup en Ethereum es: 375000 / 12 / 180 = 173.6 TPS.
Si añadimos el valor máximo teórico de 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 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 grados en un campo primo de 253 bits. Transmitimos las shares del polinomio, donde cada share contiene 16 valores de evaluación en 16 coordenadas adyacentes de un total de 8192 coordenadas. De estos 8192 valores de evaluación, cualquier 4096 de ( de acuerdo con los parámetros propuestos actualmente: cualquier 64 de 128 posibles muestras de ) se puede recuperar el blob.
El funcionamiento de PeerDAS consiste en que cada cliente escucha un número reducido 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 de 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.
En teoría, podemos escalar un tamaño de "muestreo 1D" 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 la muestreo de disponibilidad de datos tiene cada nodo con 16 muestras * 128 blobs * 512 bytes por muestra de cada blob = 1 MB de ancho de banda de datos por slot. Esto apenas está 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 incrementará el costo de reconstrucción.
Por lo tanto, al final queremos ir un paso más allá y realizar muestreo 2D. Este método no solo realiza muestreo aleatorio dentro de los blobs, sino también entre los blobs. Aprovechando la propiedad lineal del compromiso KZG, se expande el conjunto de blobs en un bloque a través de un conjunto de nuevos blobs virtuales que codifican de manera 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 de los blobs, sino también entre ellos de manera aleatoria. La propiedad lineal del compromiso KZG se utiliza para expandir el conjunto de blobs dentro de un bloque, que contiene una nueva lista virtual de blobs que codifican redundancia de la misma información.
Es crucial que la expansión del compromiso de cálculo no requiera blobs, por lo que este esquema es fundamentalmente amigable para la construcción de bloques distribuidos. Los nodos que realmente construyen bloques solo necesitan tener el compromiso KZG del 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é compromisos hay?
A continuación, se completará la implementación y el lanzamiento de PeerDAS. Después, se incrementará continuamente la cantidad de blobs en PeerDAS, mientras se observa detenidamente la red y se mejora el software para garantizar la seguridad, este es un proceso gradual. Al mismo tiempo, esperamos que haya más trabajo académico para normar PeerDAS y otras versiones de DAS y su interacción con cuestiones de seguridad como las reglas de selección de bifurcación.
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 eventualmente pasar de KZG a una alternativa que sea segura cuánticamente y que no requiera una configuración 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 recursivos para generar pruebas de validez para reconstruir filas y columnas, no es suficiente para satisfacer la demanda, porque aunque técnicamente el tamaño de un STARK es O(log(n) * log(log(n)) valor hash ( utilizando STIR), en realidad el STARK es casi del mismo tamaño que todo el blob.
El camino de realidad a largo plazo que creo 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 L1 se volverán muy grandes, y los clientes deseará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 logra la compresión de datos, la demanda de DAS 2D se reducirá, o al menos se retrasará; si Plasma se utiliza de manera generalizada, la demanda se reducirá 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 sus mecanismos de selección de bifurcación circundantes.
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 Layer. Cada slot 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, 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 cero bytes, se reemplaza cada secuencia larga de ceros con dos bytes que indican cuántos ceros hay. Además, aprovechamos 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 ya que, incluso con la agregación, el costo computacional de la 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.
用po