jakiro
Autor: Vitalik, fundador de Ethereum;
En Ethereum, hasta hace poco, los recursos son limitados, y se utiliza un solo precio de recursos llamado «gas».El gas es la cantidad de «cálculo» requerida para una transacción o bloqueo determinado.Gas integra varios tipos de «esfuerzo» juntos.
-
Cálculo original (como ADD, Multiply)
-
Lea y escriba en Ethereum Storage (como Sstore, Sloadeth Transfer)
-
Ancho de banda de datos
-
El costo de generar ZK-Snark para generar bloques
Por ejemplo, la transacción que envié (https://etherscan.io/tx/0xc5195b64cc333b8098d71fbd032e05d4545917e3be8d123ab06e1ad7998e)))))))> «>Se gastaron un total de 47,085 gas.Este es un «costo básico» dividido en (i) 21000 de gas.La tarifa de transacción que los usuarios deben pagar es directamente proporcional al gas consumido por la transacción.> «>Un bloque puede contener hasta 30 millones de gas, y el precio del gas se ajusta continuamente a través del mecanismo objetivo EIP-1559 para garantizar que el bloque contenga un promedio de 15 millones de gas.
Este método tiene una eficiencia principal: debido a que todo se fusiona en un recurso virtual, conduce a un diseño de mercado muy simple.Las transacciones optimizadas son fáciles de minimizar los costos.
pero> «>También hay un problema ineficiente importante en este método: considera diferentes recursos como conversión mutua, pero el límite potencial real que la red puede manejar no es el caso.Una forma de entender este problema es ver esta imagen:
Limita las siguientes restricciones: x1*Datos+x2*Computation & lt;Las restricciones de seguridad subyacentes reales suelen estar más cerca de Max (X1*Data, X2*Computation) & lt;Esta diferencia hace que el gas restringiera la exclusión innecesaria de los bloques de seguridad reales, o acepte los bloques inseguros reales, o una cierta mezcla de los dos.
Si hay un recurso con diferentes restricciones de seguridad, ¿entonces el gas único puede reducir el rendimiento de hasta un factor?Por lo tanto, las personas han estado interesadas durante mucho tiempo en el concepto de gas multidimensional durante mucho tiempo.Este artículo analiza los beneficios de este método y las perspectivas de mejorar aún más este método.
Blobs: gas multimensional en Dencun
A principios de este año, el tamaño promedio del bloque de Ethereum fue de 150 kb.Una gran parte de este tamaño son los datos rollup: por razones de seguridad, el protocolo de segunda capa almacena los datos en la cadena.Estos datos son muy costosos: aunque el costo de las transacciones enrollables es aproximadamente 5-10 veces más bajo que las transacciones correspondientes en el Ethereum L1, este costo sigue siendo demasiado alto para muchos casos.
¿Por qué no reducir el costo de CallData (actualmente 16 gas por byte sin número y 4 gas por número de bytes), por lo que ese acurrucado es más barato?Hemos hecho esto antes, y podemos hacerlo nuevamente.La respuesta aquí es: el tamaño del bloque en el peor de los casos es de 300,000/16 = 1875000 bytes que no son de número, y la red es casi imposible de manejar el bloque de este tamaño.Si el costo se reduce en 4 veces, la capacidad máxima se incrementará a 7.5 MB, lo que traerá enormes riesgos de seguridad.
Este problema finalmente se resuelve introduciendo un espacio de datos separado (llamado «blob») introduciendo un espacio de datos de acumulación fácil separado en cada bloque.Estos dos recursos tienen diferentes precios y diferentes restricciones: después de la bifurcación dura de Dencun, un bloque Ethereum puede incluir un máximo de (i) 30 millones de gas, y (ii) 6 blob puede incluir aproximadamente 125 kb de datos.Ambos recursos tienen un precio separado.
Como resultado, el costo de los rollups se ha reducido en 100 veces, y el volumen de transacción en los rollups ha aumentado en más de 3 veces, y el tamaño del bloque máximo teórico solo ha aumentado ligeramente: de aproximadamente 1.9 MB a aproximadamente 2.6 MB.
La tarifa de negociación enrollada es proporcionada por Growthepie.xyz.Dencun Fork ocurrió el 13 de marzo de 2024 e introdujo la blob de precios multi -dimensional.
Cliente de gas y estado multiDimensional
En el futuro cercano, también se producirán problemas similares con los certificados de almacenamiento sin un cliente libre de estado.Un cliente sin estado es un nuevo tipo de cliente que puede verificar la cadena de bloques sin tener que almacenar mucho o ningún dato localmente.El cliente sin estado implementa esto aceptando la prueba de la parte específica de Ethereum de la transacción en el bloque.
Un cliente libre de estado recibe un bloque y prueba la prueba del valor actual de la parte específica del estado (como el saldo de la cuenta, el código, el almacenamiento) involucrado en la ejecución de la ejecución del bloque.Esto permite que los nodos verifiquen el bloque sin ningún almacenamiento en sí.
Se necesita 2100-2600 gas para almacenar la lectura a la vez, dependiendo del tipo de lectura, y el costo de escritura de almacenamiento es mayor.En promedio, un bloque ejecutará alrededor de 1,000 almacenamiento y lectura (incluida la verificación de saldo ETH, SLOAD de llamadas de Sstore, lectura de código de contrato y otras operaciones).Sin embargo, el valor máximo teórico es 30000000/2100 = 14285 Leer.La carga de ancho de banda de un cliente libre de estado es proporcional al número.
Hoy, el plan se transfiere del árbol de Merkle Patricia al árbol Verkle diseñando el árbol de estado de Ethereum para apoyar al cliente sin estado.Sin embargo, el árbol Verkle no tiene resistencia cuántica, y no es la mejor opción para el sistema actualizado de prueba de Stark.Por lo tanto, muchas personas están interesadas en apoyar a un cliente libre de estado a través del árbol dual de Merkle y omitir a Verkle por completo, o después de las transiciones de Verkle durante algunos años, una vez que el Stark se vuelva más maduro, se actualizará.
Stark del árbol de hash binario tiene muchas ventajas, pero tienen una debilidad clave que lleva mucho tiempo generar: aunque el árbol de Verkle puede probar que más de 100,000 valor por segundo, el Stark basado en el hash suele ser solo solo Solo el Stark basado en el hash generalmente es solo solo que solo puede probar miles de hash por segundo, demuestra que cada valor requiere una «rama» que contiene muchos valores hash.
Teniendo en cuenta que del sistema de certificación súper optimizado (como Binius y Plonky3) y el hash especial (como Vision-Mark-32), es probable que estemos en un período de tiempo en menos de un segundo. No es 14,285.Cada bloque no es un problema, pero el peor de los casos (puede ser publicado por un atacante) destruirá la red.
El método «predeterminado» que tratamos con esta situación es volver a precio: hacer que la lectura del almacenamiento sea más costosa, para reducir el valor máximo de cada bloque a un nivel más seguro.Sin embargo, lo hemos hecho muchas veces.> «>Un mejor método es el gas multimensional: restricciones y cargas de acceso al almacenamiento, respectivamente, mantenga el uso promedio de 1,000 acceso de almacenamiento en cada bloque, pero establezca el límite de cada bloque a 2,000 veces.
Gas multi -dimensional más común
Otro recurso que vale la pena considerar es el crecimiento del estado: aumentar la operación del estado de Ethereum, y todo el nodo deberá tener un estado completo.La singularidad del crecimiento del estado es que la razón para restringir el crecimiento del estado es exactamente el uso continuo a largo plazo, no el pico.Por lo tanto, agregar una dimensión de gas separada para el aumento en la operación de aumento de la escala de estado (por ejemplo, de cero a no cero, la creación de contrato) puede ser valioso, pero el objetivo es diferente: podemos establecer el precio flotante para un uso promedio específico , pero no se establece en absoluto.
Esto muestra una de las potentes características del gas multivitamínico: nos permite hacer las siguientes preguntas: ((> «>i) ¿Cuál es el uso promedio ideal de cada recurso y el uso máximo de seguridad de (ii) cada bloque?No establecemos el precio de gas en función del valor máximo de cada bloque, pero el uso promedio.
Los casos más complicados, como algunas consideraciones de seguridad acumuladas de dos recursos, se pueden procesar haciendo que el código operativo o el recurso cuestan un cierto número de gas (por ejemplo, desde cero a cero Sstore SSTORE puede costar 5.000 gases de estado de cliente apátridos y 20000 Gas de almacenamiento).
El valor máximo de cada transacción: la forma más débil pero más simple de obtener el gas multimensional
Deja que X1 sea el costo de los datos, y x2 es el costo de gas calculado.
En el nuevo plan, definimos el costo de gas de la transacción como: Gas = Max (X1*Data, X2*Computación)
En otras palabras, la transacción no se cobra en función del cálculo de Data Plus, sino que se cobra más en función de los recursos de los dos recursos que consumen.Esto puede expandirse fácilmente para cubrir más dimensiones (por ejemplo, max (…, x3*storage_access)).
Debería ser fácil ver cómo esto aumenta el rendimiento al tiempo que garantiza la seguridad.La cantidad máxima de datos en un bloque sigue siendo GASLIMIT/X1, que es exactamente la misma que la solución de gas única.De la misma manera, la cantidad de cálculo máximo teórico es Gaslimi/X2, que es exactamente lo mismo que la solución de gas única de manera única nuevamente.Sin embargo, el costo de cualquier datos consumidos y calculados se reducirá.
Se trata del esquema propuesto en el EIP-7623 propuesto para reducir el tamaño máximo del bloque y aumentar aún más el recuento de blob.El mecanismo preciso en EIP-7623 es ligeramente más complicado: mantiene el precio actual de los datos de llamadas de 16 gas, pero agrega el «precio de reserva» de 48 gas por byte) más alto.Por lo tanto, EIP-7623 reduce los datos de llamadas de transacción máxima en el bloque de aproximadamente 1.9 MB a aproximadamente 0.6 MB, mientras se mantiene el costo de la mayoría de las aplicaciones sin cambios.La ventaja de este método es que ha cambiado muy poco en comparación con la solución de gas de una dimensión actual, por lo que es muy fácil de lograr.
Tiene dos desventajas:
1. Incluso si todas las otras transacciones en el bloque usan solo un recurso muy poco, una gran cantidad de transacciones que ocupan un recurso aún no necesitarán cobrar muchas tarifas.
2. Inspira transacciones densas intensivas en datos y calculadas a un paquete de paquete para ahorrar costos.
En mi opinión, las reglas del estilo EIP-7623 pueden traer suficientes beneficios a los datos de llamadas de transacciones u otros recursos, incluso si existen estas deficiencias, vale la pena.Sin embargo, si estamos dispuestos a invertir esfuerzos de desarrollo (significativos y más altos), existe un método más ideal.
EIP-1559 multidimensional: Estrategia más difícil pero ideal
Primero revisemos el principio de funcionamiento del EIP-1559 «convencional».Nos centraremos en la versión introducida por Blob en EIP-4844 porque es más elegante en matemáticas.
Hacemos un seguimiento de un parámetro, excess_blobs.Durante cada período, configuramos:
Excess_blobs & lt; – max (excess_blobs + len (block.blobs) -Target, 0)
Aquí Target = 3.En otras palabras, si el número de bloques de un bloque es más que el objetivo, excess_blobs aumenta, y si el número de bloques en el bloque es menor que el objetivo, disminuirá.Luego configuramos blob_basefee = exp (excess_blobs / 25.47), donde exp es un valor aproximado exp (x) de la función de índice.
En otras palabras, cada vez que excess_blobs aumenta aproximadamente 25 veces, el costo básico de Blob aumentará aproximadamente 2.7 veces.Si el blob se vuelve demasiado costoso, el uso promedio disminuirá y luego excess_blobs comienza a disminuir, reducido automáticamente el precio nuevamente.El precio de Blob se ajusta constantemente para garantizar que el bloque esté medio completo, es decir, cada bloque contiene un promedio de 3 blobs.
Si la cantidad de uso aparece a corto plazo, habrá restricciones: cada bloque solo puede contener hasta 6 blob.Sin embargo, en circunstancias normales, cada blob solo necesita pagar blob_basefee y agregar una pequeña tarifa de prioridad adicional como inspiración.
Este precio de gas ha estado en Ethereum durante muchos años: ya en 2020, el EIP-1559 introdujo un mecanismo muy similar.A través de EIP-4844, ahora tenemos dos precios de gas y manchas que flotan.
El costo básico del gas dentro de una hora el 8 de mayo de 2024, la unidad es GWEI.Fuente: Ultrasonic.Money
En principio, podemos agregar más costos en solitario a la lectura de almacenamiento y otros tipos de operaciones, pero hay una advertencia de que lo explicaré en detalle en la siguiente sección.
Para los usuarios, esta experiencia es muy similar a la actualidad: ya no paga una tarifa básica, sino que paga dos costos básicos, pero su billetera puede abstraerla, solo le muestra que puede esperar que espere los gastos esperados del pago y los gastos máximos .
Para los constructores de bloques, la mayoría de las veces la mejor estrategia es la misma que hoy: incluir cualquier contenido efectivo.La mayoría de los bloques no están llenos, ya sea gas o blob.Una situación desafiante es que cuando hay suficientes gas o blobs suficientes para exceder las restricciones de bloque, el constructor necesita resolver potencialmente el problema de mochila multimensional para maximizar sus ganancias.Sin embargo, incluso si hay un algoritmo de aproximación bastante bueno, en este caso, los beneficios obtenidos al optimizar las ganancias al formular el algoritmo patentado son mucho más pequeños que usar MEV para la misma operación.
Para los desarrolladores, el principal desafío es rediseñar las funciones de EVM y su infraestructura periférica actualmente se diseñan alrededor de un precio y un diseño restringido, y el diseño para adaptarse a múltiples precios y restricciones múltiples.Un problema que enfrentan los desarrolladores de aplicaciones es que la optimización se vuelve ligeramente difícil: en algunos casos, ya no puede decir claramente que A es más eficiente que B, porque si A usa más llamadas Data y B se usa más ejecución, luego más ejecución, luego más ejecución, luego, luego más ejecución. Cuando CallData es barato, es más caro cuando CallData es costoso.Sin embargo, los desarrolladores aún pueden obtener resultados bastante buenos al optimizar el precio promedio histórico a largo plazo.
Precios multidimensionales, EVM y subcalls (subcalls)
Un problema no aparecerá en Blob, ni aparece en EIP-7623, o incluso en la implementación de precios multidimensionales «completos» de CallData, pero si intentamos fijar el estado de fijación de precios o cualquier otro recurso, intentamos fijar el estado de fijación de precios o Cualquier otro recurso.
El gas en EVM se limita a dos lugares.En primer lugar, cada transacción se establece con un límite de gas, que limita la cantidad total de gas que se puede usar en la transacción.En segundo lugar, cuando un contrato llama a otro contrato, la llamada puede establecer su propio límite de gas.Esto permite que el contrato llame a otros contratos en los que no confían, y aún así garantiza que todavía tienen el gas restante después de llamar para realizar otros cálculos.
El rastro de la transacción de resumen de la cuenta, una de las cuentas llama a la otra cuenta, y solo proporciona a la persona que llama un número limitado de gas para garantizar que incluso si la llamada consume todo el gas asignado, la llamada externa puede continuar funcionando .
El desafío es: el gas se vuelve multidimensional entre los diferentes tipos de ejecución.
Esta es una de las razones por las cuales la propuesta de gas multimensional generalmente permanece en dos dimensiones: datos y ejecución.Los datos (si el comercio es CallData o Blob) solo se asignan fuera del EVM, por lo que no es necesario cambiar el contenido dentro del EVM para hacer que los datos de call o el blob sean por separado.
Podemos crear una «solución EIP-7623» para resolver este problema.Esta es una implementación simple: durante la implementación, el costo de cargar la operación de almacenamiento es 4 veces;Al final de la transacción, el reembolso min (7500 * Storage_Operations, Execution_Gas).Como resultado, después de deducir el reembolso, el usuario debe pagar los siguientes gastos:
Ejecution_gas + 10000 * storage_operations -min (7500 * storage_operations, ejecution_gas)
Esto es igual a:
Max (ejecutor_gas + 2500 * storage_operations, 10000 * storage_operations)
Esto refleja la estructura de EIP-7623.Otro método es rastrear el almacenamiento_operations y Execution_Gas en tiempo real, y la cantidad de 2500 o 10000 gas se carga mediante el Código de operación de llamadas Ejecution_GAS + 2500 * Storage_Operations, 10000 * Storage_Operations) según el código de operación de llamadas.Esto evita la transacción que requiere una asignación excesiva de gas cielo, y estos gases se recuperan principalmente por los reembolsos.
No hemos obtenido una licencia de granos grasas para subcalls: las sub -llamas pueden consumir todas las «asignaciones» de transacciones para operaciones de almacenamiento baratas.Pero tenemos suficientes cosas buenas.
La «solución de fijación de precios multi -dimensional más simple» en la que puedo pensar es: consideramos el subcall del niño que llama al gas como una proporción.En otras palabras, suponiendo
?Suponiendo el punto de ejecución actual, el gas restante
Para?Suponiendo que la llamada llame a un código operativo con un límite de gas sub -llamativo S.Sea S1 = S, y luego S2 = S1/G1*G2, S3 = S1/G1*G3, etc.
En otras palabras, consideramos el primer tipo de gas (de hecho, la ejecución de una máquina virtual) como una «unidad de cuenta» de privilegios, y luego asignamos otros tipos de gas para que el niño pueda ser llamado en cada tipo.Esto es un poco feo, pero maximiza la compatibilidad hacia atrás.Si queremos que el esquema sea más «neutral» entre los diferentes tipos de gas, a costa de sacrificar el retroceso, simplemente podemos dejar que el niño llame al parámetro de límite de gas represente una pequeña parte del gas restante (por ejemplo [1 .. .
> «>Sin embargo, en cualquier caso, vale la pena enfatizar que una vez que la introducción de la ejecución multi -dimensional de gas, la fealdad inherente aumentará, lo que parece difícil de evitar.
Por lo tanto, nuestra tarea es hacer un complejo comercial: si aceptamos algunas de las cosas feas en el nivel EVM, para liberar de manera segura el ingreso significativo de la escalabilidad L1.
Es probable que no sea nadie que mencione anteriormente, y todavía hay espacio para cosas más elegantes y mejores.
Gracias por los comentarios y la revisión de Ansgar Dietrichs, Barnabe Monoton y Davide Crapis.
