¿Cómo optimizar las opciones de gasPrice y gas en una función de envío de contrato ()? [duplicar]

Hay muchas preguntas y respuestas acerca de la estimación de la cantidad de gas consumido. Esta pregunta es sobre qué hacer con esta estimación.

¿Qué valores deberíamos proporcionar realmente a gasy gasPriceen las send()opciones, para asegurarnos de que las transacciones se realicen, pero no pagaremos demasiado?

myContract.methods.myMethod(123).send({
    from: myAddress,
    gas: myGasLimit,
    gasPrice: myGasPrice
    }, function(error, transactionHash){
    ...
});

La mayoría de la gente parece aconsejar establecer la gasopción en un 10-20% por encima estimatedGas(que se puede recuperar a través de la interfaz web3).

Pero, ¿qué ocurre en el caso de que la estimación sea incorrecta ? Debido a que se devuelve el gas no utilizado, ¿por qué no establecer el máximo en algo enorme? ¿Qué pasa con el gasPrice, deberíamos dejar eso en manos del minero o establecer un valor?

Hasta ahora, no proporcioné ningún valor para gasy gasPriceen las opciones de envío, y eso resultó en cantidades muy variables de gasolina realmente pagada entre billeteras. En el navegador con MetaMask, la implementación de un contrato cuesta 0,000633134 Ether (en Rinkeby) y la misma implementación en CoinbaseWallet cuesta 0,01268828 Ether (también en Rinkeby). Aparentemente, la gasPricetransacción de CoinbaseWallet fue de 20 GWei en comparación con 1 GWei para la transacción de MetaMask.

Editar: aclaración de esta pregunta:

Para que mi pregunta quede más clara: donde la pregunta a la que me vinculo anteriormente es sobre las limitaciones de la función getEstimate, estoy aquí preguntando sobre las mejores prácticas después de haber usado esta función para obtener una estimación.

Teniendo una estimación, ¿qué valores proporciono para los campos gasy gasPricepara limitar el riesgo de pagar demasiado y ser recogido en el primer bloque siguiente?

Supongamos aquí que el método es nuestro y sabemos que la estimación es más o menos correcta (no son posibles cambios de estado que hagan que el consumo de gas sea sustancialmente mayor).

De las respuestas actuales, puedo concluir: no establezca el límite de gas demasiado alto (¿entonces la regla del 10-20% más alta que la estimación suena bien?)

Acerca de gasPrice: Hice algunos experimentos y vi que MetaMask usa el valor que establece dapp y CoinBaseWallet lo ignora. Entonces, ¿tal vez dejar que la billetera (y si es posible el usuario final) decida es el camino a seguir?

Respuestas (2)

Ventajas y desventajas de establecer un límite alto en gas:

  • pro : es menos probable que la transacción se quede sin gasolina.
  • pro : como es un indicador del uso estimado de gas, se puede persuadir al minero para que priorice esta transacción, ya que sugiere una gran recompensa (especialmente en combinación con el precio del gas, ver más abajo) mientras que el gas no utilizado se devolverá de todos modos ( pero ver más abajo).
  • contra : la transacción puede consumir más de lo que estaría dispuesto a gastar, por ejemplo, debido a algún bucle u otro número inesperado de operaciones ejecutadas.
  • contra : en un out of gasevento, todo el gas se perderá: cuando se queda sin gas, la transacción falla, pero el éter gastado en gas no se devuelve.
  • contra : en teoría, creo que podría golpear a un minero que asigna un mayor uso de gas a ciertas operaciones de EVM, por lo tanto, usa más gas que un minero estándar.

Pros y contras de establecer (disposición a pagar) un alto gasPrice:

  • pro : su transacción se incluirá en el siguiente bloque con mayor probabilidad, ya que los mineros generalmente eligen primero las transacciones con un precio de gas alto, especialmente si el límite de gas asociado (proxy para el uso estimado de gas) es sustancial.
  • contra : en realidad pagará este precio del gas, incluso si no hay muchas transacciones compitiendo para ser incluidas en el siguiente bloque.

Entonces, para el límite de gas, desea tener una buena estimación basada en los parámetros reales de la transacción y el estado actual de almacenamiento al que accede y usa su transacción, y de hecho agregar un poco de margen para tener en cuenta el cambio de estado entre dicha estimación y la ejecución real de la transacción, ya que no desea quedarse sin gasolina (y, por lo tanto, gastar toda la gasolina en una transacción fallida) debido a un ligero aumento allí.

En cuanto al precio del gas, idealmente dejaría que el usuario final elija, en función de los promedios actuales del precio del gas para transacciones "rápidas" (siguiente bloque), transacciones "promedio" (¿en un minuto?) y "baratas". actas. Para estos promedios móviles, puede consultar ETH Gas Station .

Coinbase Wallet parece fijar el precio de la gasolina en 20 GWei, que es bastante alto. Está bien al transferir Ether o comprar un Token, pero al llamar a algunas funciones de un contrato, el costo de la transacción puede ser prohibitivo. Las billeteras deberían dar a su usuario la opción de establecer el precio del combustible, con un buen UX asociado.

Un límite de gasolina alto puede ser una estafa (a menos que pague un precio de gasolina alto). Algunos mineros prefieren transacciones con menos gas ya que son más fáciles de empaquetar con más transacciones y también son más baratas de ejecutar. Ocurrió que implementar un contrato con un límite de gas más cercano al límite de gas del bloque requería un precio de gas más alto porque los mineros no lo estaban recogiendo.

Creo que este es un tema importante.

La razón para no poner grandes cantidades es que la transacción puede revertirse y, en algunos casos, consumir todo su gas.

Además, la estimación cambiará si la función depende del tiempo de alguna manera, lo que significa que el código a ejecutar depende de las instrucciones anteriores. Dicho esto, si conoce la función que está ejecutando, puede determinar si es conveniente o no dejar que el nodo decida el gas necesario.

Espero que esto ayude

¡Gracias, @Jaime! Todos los puntos válidos y muy útiles. ¿Puede ampliar un poco lo que quiere decir con "si conoce la función que está ejecutando, puede determinar si dejar que el nodo decida el gas necesario es conveniente o no?"
Además: "Finalmente, la comparación del costo del gas (en eth) utilizado para las transacciones en diferentes redes es como sumar manzanas y naranjas". ¿No están todos en la misma red? Rinkeby en este caso? Solo la billetera es diferente.
Si conoces la función puedes ver si la ejecución depende de valores previos de algunas variables, por ejemplo, una función que devuelve el cuadrado de un número es estática y entonces siempre costará lo mismo. Sobre su segundo punto, tiene razón, leí mal su pregunta. La diferencia de precio es solo porque si el precio del gas. Eliminé mi última oración porque no es cierto que estés comparando dos redes diferentes.