¿Por qué afirmar gasta gas mientras que requieren no? (Mi intuición dice que lo contrario es cierto)

Dado que assertcorresponde a condiciones que nunca deben ocurrir si el código del contrato inteligente es correcto, mi intuición me dice que alguien que llama a un contrato inteligente que genera una afirmación nunca debe ser "castigado" con el gasto de gasolina, ya que la persona que llama no tuvo la culpa. (Tal vez los nodos deberían incluir en la lista negra los contratos inteligentes que generan aserciones y/o establecer un mecanismo que permita redirigir nuevas versiones/contratos parcheados sin aserción).

Por el contrario requirecorresponde a comprobaciones de los datos de entrada a las funciones , por lo que mi intuición me dice que la invocación con datos incorrectos debe ser sancionada.

Creo que hay algo que NO entiendo, o simplemente no entendí completamente la intención original de assertvs.require

¿Podría dar más detalles sobre "Además, tal como lo veo, un atacante de Ethereum consciente del código que se evalúa como falso para un requisito para un rango de valores de entrada, puede preparar fácilmente una especie de DoS"? ¿Qué forma tomaría tal ataque DoS? ¿Quién se beneficiaría y quién resultaría perjudicado?
@smarx, eliminaré esta parte para que mi publicación original sea más específica

Respuestas (1)

Una transacción fallida siempre le cuesta gasolina al remitente. Si no fuera así, cualquiera podría montar un ataque de denegación de servicio contra la red enviando muchas transacciones fallidas de forma gratuita.

La diferencia entre asserty requireestá en la cantidad de gas que se consume. assert(o throw) consume el resto del límite de gas establecido en la transacción, mientras que require(o revert) solo consume la cantidad de gas ya utilizada.

En cuanto a cuándo usar cuál: requiresiempre es más amigable en términos de consumo de gas. No he visto una razón convincente para usar assert.

El argumento (débil) que he visto es que es bueno diferenciar entre las cosas que se espera que sucedan y las cosas que no lo son. El análisis de código estático puede ayudar a demostrar que es imposible alcanzar asserts (pero no requires) en el código. Y si los asserts son realmente inalcanzables, no hay inconveniente en el consumo adicional de gasolina.