Comprenda el costo del gas del contrato después de "Berlín"

La bifurcación dura "Berlín" se activará el 15 de abril, y dos de los EIP incluidos en la bifurcación dura (EIP-2929 y EIP-2930) afectarán el costo de las transacciones del gas. Este artículo explicará cómo se calcula el consumo de gas de algunos códigos de operación antes de que se active-kepj "Berlín", cómo EIP-2929 afecta esto y cómo se debe usar la función Lista de acceso introducida en 2930. Este artículo es muy largo, si solo desea conocer la conclusión, puede cerrar la página después de leer esta parte: la bifurcación dura de Berlín cambió la sobrecarga de gas de ciertos códigos de operación. Si codifica la cantidad de gas que algunas operaciones pueden usar en su aplicación, estas operaciones pueden congelarse. Si esto sucede y su contrato inteligente no se puede actualizar, los usuarios deberán usar la función de "lista de acceso" para usar su aplicación. La función de lista de acceso puede reducir ligeramente los gastos generales de gas, pero a veces puede aumentar el consumo total de gas. El cliente geth presenta un nuevo método RPC llamado  eth_createAccessList  para simplificar la generación de listas de acceso. Cada código de operación ejecutado por el EVM tiene un consumo de Gas correspondiente. El costo de la mayoría de los códigos de operación es fijo: PUSH1  siempre cuesta 3 de gasolina, mientras que  MUL  cuesta 5 de gasolina, etc. Algunos códigos de operación tienen un costo variable: por ejemplo, el costo del código de operación SHA3 está determinado por la longitud del valor de entrada. Veamos primero los códigos de operación  SLOAD  y  SSTORE , ya que estos dos códigos de operación están más influenciados por "Berlín". Más adelante hablaremos sobre esas operaciones dirigidas a direcciones, como todos los códigos de operación de clase  EXT*  y los códigos de operación de clase  CALL* , porque sus costos de gas también cambian. Antes de la implementación de EIP-2929, el método de cálculo de los gastos generales de SLOAD era simple: consumir siempre 800 de gas. Entonces, no hay nada que expandir. Cuando se trata del cálculo del consumo de gas, el código de operación SSTORE es probablemente el más complicado. Porque cuánto consume depende del valor actual de la ranura del elemento de almacenamiento, el nuevo valor que se escribirá y si el elemento de almacenamiento se ha modificado. Solo analizaremos algunos escenarios para tener una idea aproximada. Si desea obtener más información, lea el enlace EIP adjunto al final de este artículo. Si el valor del elemento de almacenamiento cambia de 0 a 1 (o cualquier valor distinto de cero), el consumo de gas es 20000. Si el valor del elemento de almacenamiento cambia de 1 a 2 (o cualquier valor distinto de cero), el El consumo de gas es 5000 Si el almacenamiento El valor del artículo cambia de 1 (o cualquier valor distinto de cero) a 0, y el consumo también es 5000, pero obtendrá el subsidio de gas después de que finalice la ejecución de la transacción. Tampoco discutimos el mecanismo de retorno de gas aquí, porque no se verá afectado por Berlín. En una transacción, si el elemento de almacenamiento no se modifica por primera vez, cada  SSTORE  subsiguiente consumirá 800 de gas. Los detalles son no se menciona aquí Importante, importante, SSTORE  es caro, y la cantidad de gas que consume depende de varios factores. EIP-2929 cambia todos estos valores. Pero antes de comenzar, hablemos de un concepto importante introducido por el EIP: la dirección visitada y la clave de almacenamiento del elemento de almacenamiento visitado. Cuando una dirección o una clave de un elemento de almacenamiento se "utiliza" en una transacción, la dirección (o clave) se considerará "accedida" durante el resto de la transacción. Por ejemplo, si LLAMA (llama) a otro contrato en una transacción, la dirección de ese contrato se marcará como "visitada". Del mismo modo, si SLOAD o SSTORE pasó algunos espacios de elementos de almacenamiento, también se considerará que se ha accedido a esos espacios para el resto de la ejecución de la transacción. No importa qué código de operación se use, incluso si solo  SLOAD  un espacio, el espacio se tratará como visitado cuando use  SSTORE  a continuación. Nota: Las claves de los elementos de almacenamiento son "intrínsecas" en ciertas direcciones, como se explica en este EIP: Al realizar transacciones, mantenga un conjunto: direcciones_accedidas: Conjunto[Dirección]  y claves_de_almacenamiento_accedido: Conjunto[Tupla[ Dirección, Bytes32] ] Es decir, cuando decimos que se ha visitado un determinado espacio de almacenamiento, en realidad queremos decir: (dirección, clave de almacenamiento)  se ha visitado. Después de descifrar este concepto, hablemos del nuevo modo de cálculo de consumo de gas. Antes de la actualización, el consumo de gas de SLOAD  se fijó en 800. Pero después de la actualización, el consumo de gas depende de si se ha accedido a la ranura de almacenamiento. Si aún no has visitado el consumo es de 2100 gas, si has visitado consume 100 gas. Por lo tanto, si una ranura de elementos de almacenamiento ya está en la colección de "claves de elementos de almacenamiento visitados", puede ahorrar 2000 combustibles. Comparémoslos uno por uno. Después de la implementación de EIP-2929, los ejemplos anteriores cambiarán: Si el no se ha accedido a la clave del elemento de almacenamiento, consume 22100 de gas; si se ha accedido, consume 20000 de gas; si no se ha accedido a la clave del elemento de almacenamiento, consume 5000 de gas; el valor del elemento cambia de 1 (o cualquier valor que no sea valor cero) a 0, el consumo permanece sin cambios, y el mecanismo de retorno de gas permanece sin cambios. En una transacción, si el elemento de almacenamiento no se modifica por primera vez, cada SSTORE posterior consume 100 de gas. Se puede ver que si un espacio ha sido visitado antes, la primera operación en él SSTORE ahorrará 2100 de gasolina (en comparación con nunca visitado). El texto anterior es muy extenso, hagamos directamente una tabla y resumamos todos los valores mencionados anteriormente: Atención a la última línea: en este momento ya no es necesario distinguir si se ha accedido, porque si se ha escrito antes es porque se ha accedido.Otra actualización "Berlín" contiene EIP 2930. Este EIP agrega un nuevo tipo de transacción que puede incluir una "lista de acceso" en la carga útil de la transacción, lo que significa que puede declarar qué direcciones y espacios deben considerarse "visitados". Por ejemplo, ejecutar  SLOAD  en un espacio no visitado cuesta 2100 de gasolina , pero si el slot está incluido en la transacción En la "lista de acceso", el consumo de la operación se reducirá a gas 100. Sin embargo, si la dirección y el slot se consideran "visitados", el consumo de gas de la operación puede reducirse; y la lista de acceso puede marcar la dirección y el espacio como "Visitado". ¿No significa eso que podemos poner todas estas cosas en la lista de acceso para obtener una reducción en el consumo de gas? ¡Impresionante, gas enviado por Dios! Bueno , no exactamente, porque cada vez que agregas una dirección o almacenas la clave del artículo, tienes que pagar Gas extra. Por ejemplo. Supongamos que queremos enviar una transacción para contratar  A . Hemos escrito una lista de acceso como esta: ¿Significa esto que cada vez que usamos la lista de acceso podemos ahorrar gasolina? Desafortunadamente no, porque llenar la dirección en la lista de acceso también necesita pagar la gasolina (es decir,  "<dirección de A>" ; en nuestro ejemplo) Hasta ahora, solo hemos discutido los códigos de operación  SLOAD  y  SSTORE , pero la actualización "Berlin" también cambió otros códigos de operación. Por ejemplo, CALL  El consumo de gas original del opcode se fija en 700, pero después de la implementación de 2929, si la dirección llamada no está en la lista de acceso, el consumo aumentará a 2600; si lo está, se reducirá a 100 . Además, al igual que las claves de almacenamiento a las que se accede, no importa qué código de operación accedió a esa dirección (por ejemplo, si el usuario primero llama a  EXTCODESIZE, el costo de esta operación es de 2600, pero las llamadas posteriores, siempre que sea para el misma dirección, ya sea  EXTCODESIZE, CALL  o  STATICCALL , solo consume 100 gas.¿Cómo afecta este diseño a las transacciones con listas de acceso?Supongamos que enviamos una transacción al contrato A, y el contrato A llama al contrato B, y escribimos en la lista de acceso: primero debemos pagar 2400 de gasolina por agregar esta dirección a la lista de acceso de esta transacción, pero el primer código de operación utilizado por B solo necesita consumir 100 de gasolina en lugar de 2600 de gasolina, lo que deja 100 de gasolina Si B también necesita usar sus elementos de almacenamiento, y sabemos qué llaves usará, también podemos incluir estas llaves en la lista de acceso y luego ahorrar 100 o 200 de gas para cada operación de llave (dependiendo de si el primer código de operación es  SLOAD  o  SSTORE). Pero, ¿por qué necesitamos agregar otro contrato como ejemplo? ¿No podemos escribir así? Por supuesto que puede hacer esto, pero no vale la pena, porque EIP-2929 especifica que el contrato al que llama inicialmente (es decir, el destino de  tx.to ) debe estar incluido en la lista de  direcciones_accedidas , por lo que solo gasta 2400 de gasolina extra y no obtiene ningún beneficio. ejemplo que dimos anteriormente: esto es realmente un desperdicio, a menos que agregue algunas claves de elementos de almacenamiento más. Si asumimos que todas las claves de elementos de almacenamiento La primera operación de todas es  SLOAD, entonces necesita al menos 24 claves para ganar El cliente Geth (desde 1.10.2) incluirá un nuevo método RPC  eth_createAccessList RPC, que puede usar para generar una lista de acceso, al igual que usar  eth_estimateGas , excepto que en lugar del consumo de gas estimado, el los datos devueltos se ven así: Estimo que a medida que pasa el tiempo, sabremos más y más cómo usar esta función, pero personalmente, estimo que la forma de pseudocódigo del método se verá así: Evitar que el contrato se bloquee vale la pena recordar que el objetivo principal de la función de lista de acceso no es ahorrar Gas. Como se establece en el propio EIP: Mitigar el riesgo de bloqueo de contrato presentado por EIP-2929, porque las transacciones pueden predesignar y prepagar sus propias cuentas y slots de almacenamiento, en ejecución real, SLOA Tanto los códigos de operación D como EXT* solo cuestan 100 de gas: lo suficientemente bajo como para evitar que 2929 rompa ciertos contratos y para "dessellar" los contratos sellados por EIP-1884. Originalmente, siempre que un contrato preestablezca el costo de ejecución del gas, los cambios en el consumo de gas del código de operación pueden hacer que se bloquee. Por ejemplo, si un contrato presupone que  someFunction  de otro contrato solo usará 34500 gas, por lo que siempre se usa  someOtherContract.someFunction{gas: 34500}() para llamar a ese contrato, este contrato puede cambiar de bloque. Pero siempre que agregue la lista de acceso adecuada a la transacción, el contrato seguirá funcionando. Si desea probarlo usted mismo, clone este repositorio, hay muchos ejemplos en él, que se pueden ejecutar con clientes Hardhat y Geth. Lea atentamente el LÉAME.

Tags：

Huobi App Download