Costes de gas Web3 en retrospectiva: comparar L1, L2 y Solana

Gas mide una carga de trabajo, no es un precio duradero en dólares. En un producto Web3, el coste depende del programa, datos, mercados de fees, precio del token, patrocinio y reglas activas. Las tablas USD o multiplicadores L1/L2 universales caducan rápido.

Este artículo sustituye porcentajes agregados y recomendaciones generales por un método reproducible: transacciones similares a producción, estimaciones RPC actuales, fórmulas oficiales y supuestos explícitos de liquidación, finalidad, datos, bridges, upgrades, custodia y operaciones.

¿Dónde se acumula el coste?

En Ethereum, gas mide trabajo computacional. La fee es gas usado por base y priority fee; quedarse sin gas puede revertir estado y aun consumirlo. Un envío simple de ETH usa 21.000 gas, mientras contratos varían según implementación y estado. Consulta la documentación oficial de gas.

• Despliegues y upgrades. Crear guarda bytecode e inicializa; proxies, migraciones y verificación suman costes.
• Escrituras de usuario. Transfers, mints, swaps, claims, approvals, validación de account abstraction y cambios de estado cuestan en cada ejecución.
• Transacciones fallidas o reemplazadas. Un fallo incluido puede cobrar fee; reintentos, nonces, slippage y patrocinio pertenecen al modelo.
• Datos y liquidación. Los rollups suelen cobrar ejecución en la child chain y recursos de datos o settlement en la parent chain.
• Servicios off-chain. RPC, indexación, relayers, paymasters, oráculos, keepers, firmas, monitorización y soporte no son gas, pero sí TCO.

Una lectura RPC no crea una transacción, aunque el proveedor puede cobrar la API. Un contrato no puede hacer una lectura RPC gratuita durante su ejecución; leer on-chain consume gas.

¿Por qué engaña una tabla estática?

El valor dólar combina entradas móviles. Registra transacción o UserOperation, gas o CU, calldata o tamaño comprimido, base, prioridad, fee de parent chain o blob, operator fee, patrocinio, fuente de precio, bloque o slot, fecha y resultado. Repite los fixtures con varios niveles de demanda.

Base documenta ejecución L2 y seguridad L1 en sus fees de red. OP Mainnet documenta ejecución, datos L1 y operator fee según upgrade en su guía de fees.

Arbitrum documenta recursos child chain y un componente poster derivado de tamaño comprimido y precio parent. Consulta Arbitrum gas and fees. Por eso un multiplicador universal para todas las transacciones L2 EVM no es una afirmación duradera.

¿Cómo comparar Polygon PoS y Solana?

Polygon describe PoS como sidechain EVM con checkpoints periódicos en Ethereum. Su documentación explica base y prioridad y ofrece estimaciones actuales. Usa la guía EIP-1559 de Polygon PoS y registra token y parámetros. No lo trates como un rollup.

Solana usa base por firma y prioridad opcional. La prioridad depende del límite CU solicitado, no del consumo real. La documentación enumera actualmente 5.000 lamports por firma, un parámetro que debe volver a comprobarse. Consulta la estructura de fees de Solana.

Fees bajas o bloques cortos no demuestran latencia de aplicación, finalidad, disponibilidad, resistencia a censura, seguridad del bridge o coste operativo. Prueba el compromiso y fallos reales.

¿Qué demuestra el historial de Wavect?

Wavect ha entregado en EVM y Solana, pero los proyectos no son un benchmark normalizado. Contratos, frecuencia, precios, patrocinio, mercados y requisitos difieren.

• Scramble Pay: pagos multichain.
• Quivr: producto de consumo en Solana.
• Account abstraction: flujos patrocinados y smart accounts.
• Lightbridge: mensajería cross-chain.
• MetaMask Snap: integración de wallet.

Es contexto, no prueba de la red correcta o más barata.

"Elegir cadena es una decisión de producto y riesgo. Mide la carga real y compara liquidación, finalidad, datos, custodia, upgrades y operación."

¿Cómo comparar redes?

1. Define resultado y settlement. Quién envía, firma, patrocina, recibe, disputa o recupera y dónde están usuarios y activos.
2. Crea fixtures de producción. Rutas comunes, peores, fallidas, batch, patrocinadas, creación de cuenta, bridge, DeFi, NFT y upgrade.
3. Primero unidades nativas. Usa simulación y fórmulas; separa gas, bytes, CU, firmas y storage de fiat.
4. Muestrea en el tiempo. Guarda bloque o slot, fecha, parámetros, precio y percentil.
5. Modela TCO. Añade RPC, indexación, relaying, patrocinio, bridges, monitorización, incidentes, upgrades, auditorías, liquidez y soporte.
6. Revisa seguridad. Compara finalidad, datos, sequencing, proof o checkpoint, admin keys, pausas, upgrade, bridge y salida.
7. Elige una ruta principal. Multichain multiplica contratos, integraciones, liquidez, monitorización y fallos.

Para blockspace dedicado, compara rollups nativos y based. Sequencing, verificación, datos, interoperabilidad, gobernanza y operación son decisiones separadas.

¿Qué incluye un benchmark fechado?

Publica fecha, red y chain ID, hashes o fixtures, contratos y estado, método RPC, gas o compute, cálculo L1, parámetros, fuentes nativa y fiat, regla de confirmación e inclusión de creación de cuenta, bridge, fallos, patrocinio y servicios.

No trates una estimación de wallet como garantía ni extrapoles un transfer a mint, DeFi o UserOperation. En patrocinio muestra precio del usuario y coste real del sponsor.

¿Ethereum mainnet puede ser el primer despliegue correcto?

No hay respuesta universal. Puede encajar si usuarios, activos, protocolos, settlement o gobernanza lo requieren. Otra carga puede preferir L2, sidechain o Solana. Fees bajas no compensan usuarios, liquidez, integración, seguridad o recuperación ausentes; fees altas no prueban seguridad de aplicación.