---
id: 24
title: "El mecanismo del gas en detalle: unidades de medida, mercado de comisiones y detención de la ejecución"
slug: 0-7-gas-mechanics
date: 2026/09/25
summary: "El gas es la unidad de medida de recursos de la EVM, y su precio lo determina el mercado de comisiones; confundir ambos planos lleva a juzgar mal las fronteras de la escalabilidad y de la detención de la ejecución. A continuación se desglosan el costo intrínseco y el costo dinámico, se explica qué devuelven out-of-gas y REVERT, y a quién va cada parte de la comisión base y de la comisión de prioridad de EIP-1559."
keywords: medición del gas,EIP-1559,costo intrínseco,out-of-gas,EIP-2929
heroImage: /images/articles/photos/0-7-gas-mechanics.jpg
---

Una transferencia de ETH mínima consume 21 000 gas fijos (el Gtransaction del apéndice G del Yellow Paper); lo que consume una transferencia de ERC-20 depende de la implementación del contrato y del estado frío o caliente de los slots, y suele situarse en la decena de miles de gas, una estimación de orden de magnitud y no un valor medido. Estas cifras las fija el protocolo y solo cambian con una bifurcación dura; en cambio, cuánto ETH paga de verdad una misma transacción puede multiplicarse por más de diez en unas horas. Lo primero es una unidad de medida; lo segundo, un precio. Solo separando ambos conceptos se puede hablar con claridad de comisiones, de relatos de escalabilidad y del comportamiento de una detención de ejecución.

El mecanismo del gas asume a la vez tres tareas: convertir el cómputo y las operaciones sobre el estado en una unidad común, repartir un espacio de bloque limitado mediante un mercado de precios y ofrecer una frontera de reversión determinista cuando se agotan los recursos. El texto se desarrolla según esas tres líneas: qué incluyen el costo intrínseco y el costo dinámico, cómo se tarifican los accesos fríos y calientes, qué devuelve una transacción en los tres tipos de detención —inválida, REVERT y out-of-gas—, dónde quedan las fronteras entre comisión base, comisión de prioridad y gas de la capa de ejecución después de EIP-1559, y por qué el gas hace que un DoS sea tarificable, aunque no consigue que el precio sea siempre correcto.

## El gas es la unidad de medida del cómputo y del almacenamiento; el precio del token es otra cosa

El gas es una unidad de tarificación abstracta que corresponde a la cantidad abstracta de recursos que consume ejecutar una instrucción, leer o escribir una vez el estado o ampliar una palabra de memoria. Su valor lo dan constantes del protocolo, por ejemplo 3 gas por una suma (Gverylow), 100 gas por un SLOAD en acceso caliente después de la actualización Berlin (bloque 12 244 000, 15 de abril de 2021) o 20 000 gas por un SSTORE de cero a un valor distinto de cero. Estas constantes solo cambian con una bifurcación dura y no tienen nada que ver con la oferta y la demanda del mercado.

El precio del gas se expresa en wei, y la unidad de uso habitual es el gwei: 1 gwei equivale a 10⁹ wei. La comisión de una transacción es igual a gas_used multiplicado por effective_gas_price; lo primero lo determina el proceso de ejecución y lo segundo, el mercado de comisiones junto con la puja que va en la firma de la transacción. Esa relación multiplicativa es la base de todo lo que viene después.

Distinguir estos dos niveles tiene varias ventajas directas. Al hablar de «bajar el gas», hay que confirmar primero si el objetivo es reducir el gas_used o el precio del gas: lo primero exige recortar operaciones, optimizar la disposición del almacenamiento o modificar las reglas de tarificación de la EVM; lo segundo depende de la demanda del momento y de la forma del mercado de comisiones, y EIP-1559 hizo más predecible esto último, pero no cambió el precio de ninguna instrucción. Al preguntar «quién cobra la comisión», hay que recordar que la parte de comisión base la destruye el protocolo, no tiene receptor, y solo la comisión de prioridad llega a la cuenta del validador. Al hablar del «tope de la transacción», hay que tener claro que gas_limit es un tope de capacidad y no de costo: el tope de costo es max_fee_per_gas, y son campos distintos.

## El costo intrínseco: lo que ya se ha descontado antes de que empiece la ejecución

Toda transacción paga primero el costo intrínseco (intrinsic gas), que se descuenta antes de que la EVM ejecute la primera instrucción. La fórmula (64) del Yellow Paper lo escribe como g₀: un precio base fijo de 21 000 (Gtransaction), más 4 gas por cada byte cero y 16 gas por cada byte distinto de cero del campo de datos (EIP-2028 bajó el precio del byte distinto de cero de 68 a 16 en la actualización Istanbul, bloque 9 069 000, 8 de diciembre de 2019), más 32 000 si la transacción crea un contrato (Gtxcreate); después de EIP-2930 (actualización Berlin, bloque 12 244 000, 15 de abril de 2021), 2400 gas por cada dirección y 1900 gas por cada clave de almacenamiento de la access list; y después de EIP-3860 (actualización Shanghai, bloque 17 034 870, 12 de abril de 2023), 2 gas más por cada palabra de 32 bytes del initcode de creación de contrato.

Es fácil malinterpretar el 21 000 como «la comisión de una transferencia». La formulación precisa es que representa el precio base de «que exista una transacción», con independencia del importe transferido. La transferencia de ETH más simple lleva el calldata vacío, la parte de datos no genera costo adicional, y por eso sale exactamente 21 000.

EIP-2929 (actualización Berlin, bloque 12 244 000, 15 de abril de 2021) fijó además el conjunto caliente con el que arranca la transacción: la dirección del emisor, la del receptor (o la dirección creada, si la transacción crea un contrato) y todas las direcciones de contratos precompilados ya están en accessed_addresses, y no se les cobra acceso frío. Por eso, cuando una transferencia se dirige a una dirección normal, el acceso a la cuenta del receptor no genera ningún cargo extra.

El costo intrínseco se descuenta antes de la ejecución, y de ahí salen tres fronteras de comportamiento. Una transacción cuyo gas_limit quede por debajo del costo intrínseco es directamente inválida: no se incluye en el bloque ni consume gas. Cuando la ejecución se detiene a mitad por out-of-gas, el costo intrínseco no se devuelve. Los 2400 y 1900 de la access list (precios posteriores a Berlin) son un pago por adelantado: se recorren las direcciones y los slots a los que se va a acceder para dejarlos calientes de antemano, pero si la ejecución real no los visita, ese dinero no se recupera.

## El costo dinámico: cómo se acumulan la ampliación de memoria y los accesos fríos y calientes

El costo de la fase de ejecución es la suma de una parte estática y una parte dinámica. La parte estática es el precio fijo del opcode, que la tabla de tarifas del apéndice G del Yellow Paper expresa con varios niveles: Gverylow 3 gas (ADD, SUB, MLOAD, MSTORE, la familia PUSH, etc.), Glow 5, Gmid 8, Ghigh 10, Gbase 2, Gjumpdest 1.

La parte dinámica depende del tamaño de los operandos y de si el acceso al estado es frío o caliente. La ampliación de memoria se tarifa con C_mem(a) = 3a + ⌊a² / 512⌋ (fórmula (328) del Yellow Paper, Gmemory = 3), donde a es el número de palabras; el cobro real es la diferencia entre antes y después de ampliar, y este término es casi lineal hasta 704 bytes (22 palabras), a partir de donde empieza a notarse el término cuadrático. Las operaciones de copia añaden 3 gas por palabra sobre el precio base (Gcopy); KECCAK256 cobra 30 gas (Gkeccak256) más 6 gas por palabra (Gkeccak256word); LOG cobra 375 gas (Glog) más 375 gas por cada topic (Glogtopic) y 8 gas por byte (Glogdata); EXP cobra 10 gas (Gexp) más 50 gas por byte de exponente (Gexpbyte).

Los accesos fríos y calientes los define EIP-2929 (actualización Berlin). El primer acceso a un par (dirección, slot) es un acceso frío y SLOAD cobra 2100 gas; volver a acceder dentro de la misma transacción es un acceso caliente y cobra 100 gas. En los accesos a cuentas el precio frío es 2600 gas y cubre CALL, CALLCODE, DELEGATECALL, STATICCALL, BALANCE, EXTCODESIZE, EXTCODECOPY y EXTCODEHASH. Este conjunto tiene el ámbito de la transacción: cuando el ámbito se revierte, el conjunto se revierte con él.

| Operación (criterio posterior a la actualización Berlin) | Acceso frío | Acceso caliente |
|--------------------------|--------|--------|
| SLOAD | 2100 | 100 |
| Familia CALL, BALANCE, EXT* | 2600 | 100 |
| Recargo por acceso frío de SSTORE | 2100 | No se añade |

El mecanismo de frío y caliente viene directamente de la lección que dejaron dos ataques DoS. EIP-150 (Tangerine Whistle, bloque 2 463 000, 18 de octubre de 2016) ya había subido SLOAD de 50 gas a 200, CALL de 40 a 700 y SELFDESTRUCT de 0 a 5000 después de los ataques de septiembre y octubre de 2016. La motivación de EIP-2929 cita una medición del artículo de 2019 arXiv:1909.07220: al reproducir el historial de Ethereum en el hardware de sus autores, el mismo lote de transacciones maliciosas tardaba de 20 a 80 segundos, mientras que una transacción normal tardaba solo unos milisegundos, lo que indica que los opcodes de lectura de estado seguían tarifados por debajo de su costo. Es una medición puntual, que solo representa el hardware y la carga de 2019, y no sirve como criterio de seguimiento continuo.

## Los tres desenlaces de una detención de ejecución: transacción inválida, REVERT y out-of-gas

Una transacción puede terminar en tres fases distintas, y el alcance de la reversión y el tratamiento de la comisión son diferentes en cada una.

La primera es la transacción inválida, que incluye casos como un nonce que no coincide, una firma errónea, un saldo insuficiente para cubrir el pago anticipado del gas o un gas_limit por debajo del costo intrínseco. Este tipo de transacción no llega a entrar en el bloque y no consume gas; es un rechazo fuera de cadena y no tiene nada que ver con una detención de ejecución.

La segunda es REVERT, que disparan la instrucción revert, un require que falla o un revert de ensamblador en línea. Todos los cambios de estado del marco actual se revierten, el gas restante vuelve a la capa superior y lo ya consumido se paga igual; el contador de reembolsos también se revierte al estado anterior a entrar en ese marco. REVERT es un «fallo con motivo»: puede devolver datos de error y encaja en escenarios en los que quien llama necesita distinguir la causa del fallo.

La tercera es la detención excepcional (exceptional halt), que incluye out-of-gas, opcode ilegal, desbordamiento de pila, escritura de estado dentro de una llamada estática, initcode por encima del límite, etc. El estado también se revierte, pero todo el gas que le quedaba al marco actual se destruye. Si la excepción ocurre en el marco de nivel superior, el gas_used de la transacción es igual al gas_limit y la comisión se cobra íntegra, sin parte devuelta. Ese es el significado exacto de «después de un OOG se consume todo el gas»: el gas restante del marco actual cae a cero, y eso no tiene relación con el saldo de la cadena entera.

```solidity
// REVERT: el estado se revierte, el gas restante vuelve, lo consumido se paga igual
function guarded(uint256 x) external pure returns (uint256) {
    require(x != 0, "zero");
    return 1e18 / x;
}

// Detención excepcional: un bucle infinito dispara out-of-gas y destruye todo el gas que le quedaba al marco actual
function oog() external pure {
    while (true) {}
}
```

Que el fallo de una subllamada arrastre o no al marco padre lo decide la regla del «1/64 reservado» que introdujo EIP-150 (Tangerine Whistle). Al llamar a un marco hijo, el padre solo puede reenviar como máximo 63/64 de su gas restante (es decir, gas - gas // 64) y se queda con al menos 1/64; CREATE y CREATE2 también ofrecen solo 63/64. Por eso un OOG del marco hijo no provoca un OOG del padre: el padre puede capturar el fallo con el gas que se reservó y seguir ejecutando. Esta regla sustituyó en 2016 al anterior límite de profundidad de llamada y rebajó la «bomba de profundidad» de ataque estructural a un simple problema de gas.

```solidity
// Se reenvía al máximo 63/64 de gasleft() a la subllamada; el marco padre reserva 1/64
(bool ok, ) = target.call{gas: gasleft()}("");
```

Un CALL con value tiene dos elementos adicionales (apéndice G del Yellow Paper): una transferencia distinta de cero cobra Gcallvalue 9000 gas, y si la cuenta de destino no existe cobra además Gnewaccount 25 000 gas; el llamado recibe un subsidio de llamada de 2300 gas (Gcallstipend) para la lógica de recepción más simple. EIP-2200 (actualización Istanbul, bloque 9 069 000, 8 de diciembre de 2019) establece que SSTORE falla directamente con OOG cuando gasleft es menor o igual que 2300, precisamente para evitar que esa vía de subsidio se use para escribir estado.

El reembolso (refund) se liquida al terminar la ejecución de la transacción y no es visible durante la ejecución. EIP-3529 (actualización London, bloque 12 965 000, 5 de agosto de 2021) bajó de 15 000 a 4800 el reembolso por reescribir un valor distinto de cero a cero, eliminó el reembolso de SELFDESTRUCT y rebajó el tope de reembolso total por transacción a gas_used // 5. Como el reembolso no está disponible durante la ejecución, un contrato no puede contar con él para adelantar el gas que necesita a mitad de la transacción.

## EIP-1559: comisión base, comisión de prioridad y la frontera con la capa de ejecución

EIP-1559 (actualización London, bloque 12 965 000, 5 de agosto de 2021) divide la comisión de la transacción en dos tramos. La comisión base la calcula el protocolo a partir del gas_used del bloque padre y del valor objetivo (la mitad del gas_limit), se ajusta como máximo un 12,5 % por bloque y se destruye. La comisión de prioridad (tip) es el precio unitario extra que el usuario paga al validador para que su transacción se empaquete antes. La firma de la transacción da dos topes, max_fee_per_gas y max_priority_fee_per_gas, y el precio unitario que se aplica de verdad es: la comisión de prioridad toma el menor entre max_priority_fee_per_gas y (max_fee_per_gas - comisión base), y effective_gas_price es igual a la comisión de prioridad más la comisión base. El gas no usado se devuelve a ese precio unitario.

La frontera con la capa de ejecución también hay que dejarla clara. Después de EIP-1559, el opcode GASPRICE devuelve effective_gas_price, es decir, el precio unitario que paga de verdad el emisor; la parte que recibe realmente el validador no se puede leer directamente desde el entorno de ejecución. Eso implica que cualquier lógica antigua que use GASPRICE para estimar los «ingresos del minero» ya no se sostiene.

Los dos tramos de la comisión responden a preguntas distintas: la comisión base fija el umbral mínimo para entrar en el bloque y la comisión de prioridad fija la prioridad dentro de un mismo bloque. El espacio de bloque total no cambia, y cuando el uso sostenido supera el valor objetivo, la comisión base sube bloque a bloque para expulsar demanda: es un mecanismo de cola, no una ampliación de capacidad. Tomar EIP-1559 por una solución que reduce el gas_used es una lectura errónea frecuente; solo cambia la forma en que se forman los precios.

Queda una frontera más que se confunde con facilidad: la comisión de los blobs no pertenece al gas de la capa de ejecución. EIP-4844 (actualización Cancun, bloque 19 426 587, 13 de marzo de 2024) introdujo para los datos de blob una comisión base y una unidad de tarificación propias (blob gas), y EIP-7516 añadió un opcode que devuelve el blob base fee. Cuando se habla del costo de publicación de datos de un rollup, se habla del mercado de blobs, que es un libro contable distinto del gas que consume la ejecución de contratos.

## Que el DoS «tenga precio» no significa que el precio sea correcto

La propiedad de seguridad central del gas es convertir el uso de recursos en un costo. Para llenar un bloque de transacciones basura, el atacante tiene que pagar la comisión correspondiente a todo el gas del bloque: eso significa «tarificable». Frente a una red que no cobra, el costo marginal del ataque pasa de cero a ser proporcional a lo que ocupa.

Pero eso solo funciona si el precio se corresponde con el costo real. Los ataques DoS de septiembre y octubre de 2016 explotaron precisamente opcodes de lectura de estado y de llamada cuyo precio estaba subestimado, y provocaron directamente la bifurcación dura Tangerine Whistle; después, EIP-1884 (actualización Istanbul, bloque 9 069 000, 8 de diciembre de 2019) subió SLOAD de 200 a 800 y BALANCE y EXTCODEHASH de 400 a 700, y EIP-2929 volvió a dividir el acceso al estado en dos tramos, frío y caliente, y elevó mucho el precio del acceso frío, con el mismo argumento: un patrón así puede llevar el tiempo de procesamiento de un bloque a varias decenas de segundos. EIP-3860 se ocupa del análisis de destinos de salto del initcode, un trabajo que antes no se medía en absoluto. Entre las reglas de tarificación y el costo de implementación hay un retraso estructural: la disposición de la base de datos y el motor de ejecución de los clientes se optimizan de forma continua, mientras que las constantes de gas hay que revalorizarlas en la siguiente bifurcación dura.

El mecanismo de reembolsos ofrece el ejemplo contrario. En teoría animaba a los contratos a limpiar el estado que ya no usaban, pero en la práctica dio lugar a esquemas como GasToken, que usaban los slots de estado como si fueran una batería, acumulaban gas cuando la tarifa era baja y lo liberaban cuando era alta, con la consiguiente inflación de estado y una varianza adicional en el uso de gas de los bloques. EIP-3529 recortó y puso techo a los reembolsos justamente para cerrar esa vía.

Hay varios puntos en los que el mecanismo falla y conviene señalarlos por separado. La tarificación es producto de la gobernanza, y las constantes se eligen normalmente según el peor caso de cada implementación (EIP-3860 indica que sus 2 gas por palabra salen de la referencia del peor caso entre implementaciones distintas), pero clientes distintos tardan tiempos diferentes en el mismo lote de operaciones, así que el costo real de recursos correspondiente al mismo precio de gas no es uniforme. Es un juicio cualitativo; la evidencia cuantitativa que dio EIP-2929 para subir los precios es una medición puntual de 2019 sobre cierto hardware de prueba y no vale como criterio continuo. El valor del mercado de ordenación no lo sostiene del todo la comisión de prioridad: las subastas de MEV y las estrategias de los clientes también influyen en el orden de empaquetado, y una comisión de prioridad alta solo es uno de los incentivos para entrar antes en el siguiente bloque. El propio límite de gas por bloque es un equilibrio entre rendimiento y costo de verificación: subirlo eleva a la vez el umbral de hardware de los nodos completos.

El punto de esta sección es que se trata de un mecanismo que necesita calibración periódica: «la tarificación del gas es fiable» y «la tarificación del gas no es fiable» son ambas conclusiones demasiado fuertes. EIP-150, EIP-1884, EIP-2929 y EIP-3860 son acciones de calibración. En cuanto a qué disparará la siguiente, solo se puede dar una inferencia y no una conclusión: las cuatro calibraciones tuvieron como causa directa un ataque de amplificación de recursos observado públicamente, así que este artículo infiere que la próxima será con toda probabilidad un suceso del mismo tipo. Esta inferencia no tiene respaldo público y tampoco se descarta que haya una revalorización anticipada por otros motivos, como el crecimiento del estado o la capacidad de bloque.

## Límites y puntos inciertos

El criterio citado es la tabla de tarifas del apéndice G del Yellow Paper y sus fórmulas (64) y (328) (la versión descargada lleva Shanghai en el pie de página), junto con el texto normativo de EIP-150, EIP-1884, EIP-2028, EIP-2200, EIP-1559, EIP-2929, EIP-2930, EIP-3529 y EIP-3860. Las cifras concretas cambian con cada bifurcación; las bifurcaciones y alturas de bloque indicadas en el texto son: Istanbul (8 de diciembre de 2019, bloque 9 069 000), Berlin (15 de abril de 2021, bloque 12 244 000), London (5 de agosto de 2021, bloque 12 965 000), Shanghai (12 de abril de 2023, bloque 17 034 870) y Cancun (13 de marzo de 2024, bloque 19 426 587). Antes de hablar de gas en una cadena compatible con EVM hay que confirmar qué bifurcaciones tiene activadas, porque las constantes de tarificación pueden diferir de las de la mainnet de Ethereum. El bloque 2 463 000 y el 18 de octubre de 2016 de Tangerine Whistle también proceden del historial de actualizaciones de ethereum.org.

Sobre la gravedad del «retraso de tarificación» solo se pueden dar pruebas indirectas, no una conclusión cuantitativa: en el material público no hay ninguna serie temporal que siga de forma continua la relación entre las constantes de gas del protocolo y el tiempo de ejecución real, así que no se puede determinar si el retraso se está ampliando o cerrando. Esto hay que mantenerlo como una incertidumbre y no usarlo para deducir conclusiones del tipo «está empeorando» o «ya se ha cerrado».

Por otra parte, el comportamiento del mercado de comisiones está influido por el MEV y por las estrategias de los clientes; no se han desarrollado los detalles del mecanismo del mercado de ordenación ni se ha comparado el mercado de comisiones de los blobs con el gas de la capa de ejecución dentro de un mismo marco, porque después de EIP-4844 son dos sistemas de tarificación separados. Al usar estas cifras para un modelo de costos hay que confirmar primero el criterio y la versión.

## Fuentes

- EIP-1559, Fee market change for ETH 1.0 chain: https://eips.ethereum.org/EIPS/eip-1559
- EIP-2929, Gas cost increases for state access opcodes: https://eips.ethereum.org/EIPS/eip-2929
- EIP-3529, Reduction in refunds: https://eips.ethereum.org/EIPS/eip-3529
- EIP-150, Gas cost changes for IO-heavy operations: https://eips.ethereum.org/EIPS/eip-150
- EIP-1884, Repricing for trie-size-dependent opcodes: https://eips.ethereum.org/EIPS/eip-1884
- EIP-2028, Transaction data gas cost reduction: https://eips.ethereum.org/EIPS/eip-2028
- EIP-2200, Structured Definitions for Net Gas Metering: https://eips.ethereum.org/EIPS/eip-2200
- EIP-2930, Optional access lists: https://eips.ethereum.org/EIPS/eip-2930
- EIP-3860, Limit and meter initcode: https://eips.ethereum.org/EIPS/eip-3860
- EIP-4844, Shard Blob Transactions: https://eips.ethereum.org/EIPS/eip-4844
- EIP-7516, BLOBBASEFEE opcode: https://eips.ethereum.org/EIPS/eip-7516
- Ethereum Yellow Paper, apéndice G (tabla de tarifas), fórmula (64) (costo intrínseco) y fórmula (328) (función de tarificación de memoria): https://ethereum.github.io/yellowpaper/paper.pdf
- Documentación para desarrolladores de ethereum.org, gas y comisiones: https://ethereum.org/en/developers/docs/gas/
- ethereum.org, referencia de opcodes: https://ethereum.org/en/developers/docs/evm/opcodes/
- Historial de actualizaciones de red de ethereum.org (alturas de bloque y fechas de cada bifurcación): https://ethereum.org/en/history/
- arXiv:1909.07220, medición del tiempo de acceso al estado citada por EIP-2929: https://arxiv.org/abs/1909.07220

## Lecturas relacionadas

- [Glosario de métricas de rendimiento: TPS, BPS, latencia de confirmación, finalidad y tasa de conflicto](/es/blog/performance-metrics-glossary)
- [Mapear la escalabilidad de la cadena de bloques: qué resuelve cada enfoque —paralelismo en L1, L2, sharding y disponibilidad de datos](/es/blog/blockchain-scaling-map)
- [La tensión entre descentralización y rendimiento: requisitos de validadores, hardware y distribución geográfica](/es/blog/decentralization-performance-tradeoff)

Este artículo pertenece a la serie de fundamentos de la EVM; el artículo previo es el 0.5 «Tres clases de almacenamiento que no conviene confundir: Memory, Storage y Transient Storage».