jakiro
Autor: John Otander, Desarrollador de Ethereum Core;
Este artículo se inspiró en las respuestas de Ethereum a Vitalik en Reddit AMA reciente.
Vitalik señaló que es razonable aumentar moderadamente el límite de gas, y el límite de gas no ha aumentado en casi tres años, que es el tiempo más largo en la historia del acuerdo.Vitalik también hizo algunos cálculos simples para aumentar el límite de gas Ethereum a 40 millones.
Este artículo dice por qué es difícil mejorar el límite de gas Ethereum.Aumente los riesgos planteados por el límite de gas Ethereum, así como las soluciones relacionadas.
1,Límite de gas(Gaslímite)
El límite de gas determina la cantidad de trabajo completado dentro de un bloque y, por lo tanto, determina cuántas transacciones se pueden ejecutar por bloque.Mejorar el límite de gas permitirá a Ethereum manejar un mayor rendimiento de transacciones o transacciones más complejas.La configuración específica del límite de gas ha sido afectado por los mineros/partes interesadas y el límite ha aumentado a lo largo de los años.La siguiente figura es de Etherscan.io, que muestra el uso histórico del gas (muy cerca del límite de gas, todos los aumentos de límite han sido digeridos por el mercado).
2,riesgo
Ahora aumentar el límite de gas implica varios riesgos.
(1) Velocidad de bloqueo de fugas
Mencioné en mi artículo anterior que la tasa del tío es el indicador más discutido al evaluar el aumento del límite de gas.Ahora, después de la fusión de Ethereum, ya no hay desbloqueos.Si queremos saber si el nodo puede manejar bien el límite de gas actual, la única forma es ver la velocidad de bloqueo que falta.Pero esta métrica es defectuosa porque solo muestra los nodos que actualmente subrayan.No nos proporciona una buena métrica para mostrar el aumento en el límite de gas, y solo muestra el caso promedio, no el peor caso que puede suceder en el ataque.
(2) Tamaño de estado
La instantánea de la cuenta del bloque 18418786 (24 de octubre de 2023) es de 10.33 GB y la instantánea de almacenamiento es de 76.59 GB, por lo que el estado general es aproximadamente 87 GB.El bloque 17419840 (6 de junio de 2023) tiene un estado de poco menos de 80 GB.Esto significa que el estado ha aumentado en aproximadamente 7 GB en 4 meses, lo que significa aproximadamente 2GB por mes.
Si usamos 87+ (2*12*# años) para inferir, el estado será de 111 GB en un año y 207 GB en cinco años.El problema aquí no es el tamaño.Todos pueden almacenar tantos datos, pero acceder y modificar estos datos se volverá más lento y más lento.
Esto es solo una instantánea, es un estado normal.Geth también necesita almacenar este estado en una forma diferente para verificar la raíz del estado.Otra forma de almacenamiento de estado (nodo TRIE) del bloque 18418786 requiere aproximadamente 180 GB.
Por lo tanto, el tamaño de espacio total utilizado actualmente para el almacenamiento de estado es de aproximadamente 267 GB.Si aumentamos el límite de gas, el tamaño del estado crecerá más rápido.
El problema con el crecimiento del estado es que, a diferencia del pasado, no tenemos un camino claro para eliminar el estado.No hay sugerencias de fecha límite estatales específicas que podamos implementar rápidamente para sacarnos de un estado en crecimiento.
(3) Escala histórica
En un artículo de 2021 mencioné que un nodo Geth completo es de aproximadamente 350 GB (recién podado).Después de unos tres años, un nodo Getth completo (en PBSS) supera los 900 GB.La siguiente figura muestra el volumen total acumulado de transacciones.Es fácil ver que el volumen de transacciones se ha más que duplicado en tres años, de aproximadamente 980 millones a más de 2.2 mil millones.
Con el aumento de L2, la escala histórica se ha convertido en un problema mayor, ya que ahora (antes de que el 4844 se vaya en vivo) la forma en que almacenan datos se denominan datos.El bloque 18418786 tiene más de 427 GB de bloqueo, mientras que el bloque 17419840 (también hace 4 meses) tiene 339 GB de bloqueo, lo que significa un crecimiento de 28 GB en 4 meses, lo que significa aproximadamente 9 GB de crecimiento por mes.Podemos usar 427+ (9*12*# años) para inferir este crecimiento, es decir, 535 GB después de un año y 967 GB después de cinco años (nuevamente suponga un crecimiento lineal).
Con suerte, este crecimiento se ralentizará después de que se lance EIP-4844, cuando L2 dejará de usar CallData para obtener la disponibilidad de datos y cambiar a blobs que caducan en unas pocas semanas.
EIP-4444 resolverá el problema de crecimiento histórico, ya que los nodos completos ya no necesitan almacenar toda la historia.La implementación de EIP-4444 requiere una red confiable para recuperar el historial, y luego podemos hacer que el servicio de datos históricos de detener el nodo completo.
(4) Tiempo sincrónico
El límite de gas puede afectar el tiempo de sincronización de muchas maneras:
· La sincronización completa se vuelve muy lenta.
· Los datos históricos simultáneos son lentos.Debido a que necesitamos descargar más datos, sincronizar la parte de datos históricos será más lenta.
· El estado de sincronización de la instantánea es más lento porque necesitamos descargar más estados.
· La recuperación de la instantánea es lenta.Dado que el punto de pivote se mueve durante la sincronización de la instantánea, tenemos muchos estados incompletos en el disco que deben arreglarse.Si el pivote se mueve con más frecuencia y hay más cambios por bloque, entonces esta fase de reparación se ralentizará.
· La sincronización con la cadena será más lenta porque los nodos deben pasar más cambios para formar encabezados de bloque.
(5) Diversidad del cliente
Construir un nuevo cliente EL es una tarea difícil en sí misma.Existe una desventaja adicional de agregar límite de gas, que es que dificultará la construcción de clientes y optimizar para su uso por el NET de Mainnet.Geth ha sido desarrollado por más de 10 años y ha sufrido muchas optimizaciones.Puede haber una visión opuesta de que los nuevos clientes puedan pedir prestado a los clientes existentes y ya no cometer los mismos errores.
Sin embargo, hemos visto el dilema principal de dos clientes (especificaciones de ejecución escritas en Python y Ethereumj escritas en JavaScript).Esto también significa que los clientes escritos en ciertos idiomas no funcionan ahora.Debido a la sobrecarga del lenguaje y la madurez de la base de código, agregar límite de gas dejará atrás a algunos clientes.
Vemos esto en KZG, y para obtener el rendimiento requerido, la mayoría de los clientes confían en llamar a C-KZG (una base de código escrita en C) en lugar de usar bibliotecas escritas en su lenguaje elegido.
(6) Peor de los casos
Al considerar el límite de gas, no podemos solo mirar la situación general.Siempre tenemos que considerar el peor de los casos.Por supuesto, los nodos pueden funcionar bien cuando la cadena está en una situación de carga promedio, pero ¿qué sucede si la E/S del disco de 5 bloques se duplica repentinamente?
El tiempo de ejecución no es la única métrica que debemos considerar, y si un atacante puede asumir otros recursos, como E/S de disco, tiempo de CPU o memoria, puede forzar a las máquinas con menor configuración a fuera de línea.Especialmente después de la fusión de Ethereum, ejecutar dos clientes en la misma máquina, atacar a uno de ellos también puede hacer que el otro cliente sea inestable.En los primeros días de las pruebas de fusión de Ethereum, hemos presenciado varias veces: una filtración de memoria en un cliente haría que todo el sistema se bloquee.
Otro peor de los casos a considerar es el tamaño de prueba.A medida que aumenta el límite de gas, los cambios potenciales en estado que pueden ocurrir entre los dos bloques también aumentan.Esto tiene un impacto en la sincronización de la instantánea discutida anteriormente, pero también afecta el tamaño de prueba del cliente de luz de la capa de ejecución.Ahora, esto no es un gran problema, la prueba del árbol de Merkle-Patricia es demasiado grande para enviar la red.Sin embargo, si queremos implementar la idea de validación cruzada de ejecutar múltiples clientes de luz en la misma máquina, entonces el tamaño de prueba es muy importante.
3, solución
¿Hemos terminado así?¿Mantendremos el límite superior de 30 mgas?¡No!
En un artículo de 2021, propuse soluciones al dilema que enfrentábamos en ese momento.Para el problema de sincronización completo que enfrentamos en 2021, Geth implementa la sincronización de instantáneas y las instantáneas.Para la poda y los problemas de diseño de la base de datos, Geth implementa PBSS.TXpool se ha vuelto más confiable en el manejo de altas cargas de transacciones, y la mayoría de las transacciones Rush MEV se transfieren a los constructores.Muchas transacciones también se han trasladado a L2, lo que a su vez ha aumentado el tamaño promedio de las transacciones principales.
La única solución que no se implementa es la regénesis.Con los años, las opiniones de las personas han cambiado un poco, y la mayoría de las personas parecen estar inclinadas a usar la fecha límite histórica EIP-4444 como una solución a corto plazo para el crecimiento de datos históricos.Para el lanzamiento de EIP-4444, necesitamos una red sólida de nodos de servicio de datos históricos para que la historia no se pierda, incluso si ya no está almacenada por todos los nodos completos (por cierto, la mayoría de los nodos de bitcoin no almacenan datos históricos en todo) .
Todavía no hemos encontrado una forma decente y realista de ir para una fecha límite estatal.
Cuando viste los ataques antes de crecer en Shanghai, hay algunos ataques conocidos que nos impiden elevar Gaslimit.(Hasta donde yo sé) Se han resuelto todas las vulnerabilidades.
Al momento de escribir, EIP-4844 se publicará en línea.Este EIP aumentará los requisitos de almacenamiento y E/S del nodo.En mi opinión, es más seguro esperar y ver el impacto de este cambio en el Netnet antes de probar cualquier tipo de adición de límite de gas.Una vez que L2 recurre a las transacciones BLOB, deberíamos aumentar los costos de los datos de llamadas (porque en mi opinión los datos de llamadas están subestimados en comparación con otras cosas que los datos deben almacenarse).Esto también se puede usar como una función coercitiva para L2 usando blobspace.
En resumen, me gustaría recordarles a todos que tengan cuidado al considerar mejorar el límite de gas, ya que afectará muchos aspectos del nodo, y algunos de los efectos serán relativamente obvios.En discusiones relacionadas, es muy importante considerar los efectos a largo y a corto plazo de los cambios de límite de gas.
