- Tema
24k Popularidad
56k Popularidad
6k Popularidad
16k Popularidad
30k Popularidad
742 Popularidad
112k Popularidad
26k Popularidad
26k Popularidad
7k Popularidad
- Anclado
24k Popularidad
56k Popularidad
6k Popularidad
16k Popularidad
30k Popularidad
742 Popularidad
112k Popularidad
26k Popularidad
26k Popularidad
7k Popularidad
Ethereum expansión nuevo capítulo: The Surge podría lograr 100,000 TPS
Futuro posible de Ethereum: The Surge
La hoja de ruta de Ethereum inicialmente incluía dos estrategias de escalado: sharding y protocolos de Layer 2. A medida que la investigación avanzó, estos dos caminos se fusionaron, formando una hoja de ruta centrada en Rollup, que sigue siendo la estrategia de expansión actual de Ethereum.
La hoja de ruta centrada en Rollup propone una división de trabajo simple: Ethereum L1 se enfoca en convertirse en una capa fundamental fuerte y descentralizada, mientras que L2 asume la tarea de ayudar a escalar el ecosistema. Este modelo es omnipresente en la sociedad: la existencia del sistema judicial (L1) no es para buscar super velocidad y eficiencia, sino para proteger los contratos y los derechos de propiedad, mientras que los emprendedores (L2) construyen sobre esta sólida capa fundamental, impulsando el progreso humano.
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 máquinas virtuales de Ethereum (EVM) Rollup han entrado en la primera fase. Cada L2 existe como un "shard" con sus propias reglas internas 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 y resolver estos problemas, mientras mantenemos la robustez y descentralización que son propias de Ethereum L1.
The Surge: Objetivos Clave
Contenido del artículo
La 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: la descentralización (, el bajo costo de los nodos de operación ), la escalabilidad ( que permite procesar un gran número de transacciones ) y la seguridad ( que requiere que un atacante comprometa una gran parte de los nodos en la red para hacer que una sola transacción falle ).
La paradoja del triángulo no es un teorema, proporciona un argumento matemático heurístico: si un nodo amigable y descentralizado puede validar 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) tu nodo se volverá poderoso, mientras que tu cadena no será descentralizada.
Durante años, algunas cadenas de alto rendimiento han afirmado que resuelven el trilema sin cambiar fundamentalmente la arquitectura, generalmente optimizando nodos mediante técnicas de ingeniería de software. Esto siempre es engañoso, ya que operar nodos en estas cadenas es mucho más difícil que operar 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 verificar que una cierta cantidad de datos está disponible y que una cierta cantidad de pasos de cálculo se ejecutan correctamente, al descargar solo una pequeña cantidad de datos y realizar muy pocos cálculos. Los SNARKs son de confianza cero. El muestreo de disponibilidad de datos tiene un sutil modelo de confianza few-of-N, pero conserva las características fundamentales que tiene una cadena que no se puede escalar, 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 problema de los tres cuerpos es la arquitectura Plasma, que utiliza técnicas ingeniosas para trasladar la responsabilidad de la disponibilidad de los datos de supervisión a los usuarios de una manera compatible con los incentivos. 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 SNARKs( pruebas de conocimiento cero concisas y no interactivas), la arquitectura Plasma se ha vuelto más viable para un rango más amplio de escenarios de uso que nunca.
Avances adicionales en el muestreo de disponibilidad de datos
¿Qué problema estamos resolviendo?
El 13 de marzo de 2024, cuando se active 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 de aproximadamente 375 kB por slot. Suponiendo que los datos de las transacciones se publiquen directamente en la cadena, una transferencia ERC20 ocupa aproximadamente 180 bytes, por lo que 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), entonces se convierte en 607 TPS. Usando PeerDAS, la cantidad de blobs podría aumentar a 8-16, lo que proporcionará de 463 a 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 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 sobre el campo primo (. 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 de ) según los parámetros propuestos actualmente: cualquiera de los 64 de 128 posibles muestras ( puede recuperar el blob.
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 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 una perspectiva teórica, podemos escalar un "muestreo 1D" a un tamaño considerable: si aumentamos la cantidad máxima de blobs a 256) con un objetivo de 128(, entonces podemos alcanzar un objetivo de 16 MB, y en el muestreo de disponibilidad de datos, cada nodo toma 16 muestras * 128 blobs * 512 bytes por muestra por blob = 1 MB de ancho de banda de datos por slot. Esto está justo 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, queremos ir un paso más allá y realizar un muestreo 2D )2D sampling(, este método no solo realiza muestreo aleatorio dentro del blob, sino también entre blobs. Utilizando las propiedades lineales del compromiso KZG, se amplía un 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 este enfoque es esencialmente amigable con la construcción de bloques distribuidos. Los nodos que construyen realmente los bloques solo necesitan tener el compromiso KZG de los blobs, y pueden confiar en 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 con la construcción de bloques distribuidos.
![Vitalik nuevo artículo: Ethereum posible futuro, The Surge])https://img-cdn.gateio.im/webp-social/moments-40311fde406a2b6c83ba590c35e23a7c.webp(
) ¿Qué más se necesita hacer? ¿Qué consideraciones hay?
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, este es un proceso gradual. Al mismo tiempo, esperamos más trabajo académico para regular PeerDAS y otras versiones de DAS y su interacción con temas de seguridad como las reglas de selección de bifurcación.
En etapas más lejanas 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 cuánticamente segura y sin necesidad de un entorno confiable. 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, usando 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)( hash( usando STIR), en realidad un STARK es casi del mismo tamaño que el blob completo.
El camino de realidad a largo plazo que considero es:
Por favor, ten en cuenta que, incluso si decidimos expandir la ejecución directamente en la capa L1, esta opción tambié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 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 logra la compresión de datos, la demanda de DAS 2D disminuirá, o al menos se retrasará; si Plasma se utiliza ampliamente, la demanda disminuirá aún más. DAS también presenta 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 los mecanismos de selección de bifurcación que la rodean.
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 del protocolo Layer. Cada slot 16 MB, obtenemos:
16000000 / 12 / 180 = 7407 TPS
¿Qué pasaría si pudiéramos no solo resolver el problema de los numeradores, sino también el problema de los denominadores, permitiendo que cada transacción en un Rollup ocupe menos bytes en la cadena?
( ¿Qué es y cómo funciona?
En la compresión de ceros, se reemplaza cada secuencia larga de ceros por dos bytes que indican cuántos ceros hay. Más allá de eso, aprovechamos las propiedades específicas de las transacciones:
Agregación de firmas: hemos pasado de firmas ECDSA a firmas BLS. La característica de las firmas BLS es que múltiples firmas pueden combinarse en una única firma, que 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 la verificación es alto, no se considera el uso de firmas BLS. Pero en L2, en un entorno con escasez de datos, el uso de firmas BLS tiene sentido. La característica de agregación de ERC-4337 proporciona un camino para implementar esta función.
Reemplazar direcciones con punteros: Si se ha utilizado previamente una dirección, podemos reemplazar la dirección de 20 bytes con un puntero de 4 bytes que apunta a una posición en el historial.
Serialización personalizada del valor 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. La tarifa base máxima y la tarifa prioritaria son similares. Por lo tanto, podemos usar un formato decimal de punto flotante personalizado para representar la mayoría de los valores monetarios.
) ¿Qué más se necesita hacer, qué consideraciones hay?
Lo que hay que hacer a continuación es implementar realmente el plan mencionado anteriormente. Las principales compensaciones incluyen: