Resolviendo el problema de gas de Bitcoin (sin un fork) | Opinión

Cada plataforma de contratos inteligentes tiene un activo de tarifas incorporado. Por ejemplo, Ethereum (ETH) tiene ETH, Solana (SOL) tiene SOL, pero con Bitcoin (BTC), sin embargo, las cosas se complican. Si quieres aplicaciones expresivas, generalmente terminas adoptando la economía de una segunda red.

Resumen

• Bitcoin no valora la computación, solo el espacio en bloque. A diferencia de Ethereum o Solana, el mercado de tarifas de BTC se basa en sat/vB para la inclusión de transacciones, no en medición de la ejecución de contratos inteligentes.
• La ejecución puede realizarse fuera de la cadena mientras la liquidación permanece en Bitcoin. Sistemas como OpNet ejecutan la lógica del contrato en una VM Wasm, mientras anclan los pagos y cambios de estado finales mediante transacciones normales de BTC.
• BTC puede funcionar como el activo de gas sin un token nuevo. Al valorar los costos de ejecución en satoshis y liquidar las interacciones mediante transacciones de Bitcoin, las aplicaciones evitan crear una segunda economía de tarifas.

Por ejemplo, en Stacks, pagas tarifas en STX. En capas de Bitcoin estilo EVM, puede que te digan que BTC es el token de gas, pero generalmente es una representación nativa de L2 con convenciones similares a EVM (incluyendo 18 decimales), y aún operas dentro de ese entorno L2. Bitcoin en sí ya tiene un mercado de tarifas limpio, donde los usuarios pujan por espacio en bloque en sat/vB, y los mineros priorizan las tarifas más altas.

Con esto en mente, ¿qué pasaría si una interacción de contrato inteligente pudiera iniciarse y pagarse como una transacción normal de Bitcoin, con tarifas en términos de BTC (sin un token de gas adicional o bifurcación), mientras la parte inteligente se ejecuta en otro lugar y permanece vinculada de manera comprobable a Bitcoin? OpNet busca ofrecer una respuesta.

Bitcoin no mide la computación (ese es un problema)

El mercado de tarifas de Bitcoin es excelente en una cosa: valorar el espacio en bloque. Compites en sat/vB, los mineros eligen las tarifas más altas, y la red se mantiene simple y resistente a ataques. Lo que Bitcoin no hace es ejecutar un entorno de ejecución de propósito general donde la cadena pueda medir y cobrar por cálculos arbitrarios. Bitcoin Script está deliberadamente sin estado y no es Turing completo, específicamente carece de bucles o goto, para que cada nodo pueda validar scripts de manera predecible sin abrir la puerta a cálculos ilimitados.

Por eso, la mayoría de los enfoques de contratos inteligentes en Bitcoin terminan colocando la ejecución en un sistema separado que puede medir la computación y tener su propio mercado de tarifas. Una vez que tienes esa capa de ejecución separada, generalmente viene con un activo de tarifa separado (por ejemplo, Stacks cobra tarifas en STX).

Esto no es ideal, y sería preferible un sistema donde puedas mantener el pago dentro del mercado de tarifas nativo de Bitcoin mientras mueves la ejecución a otro lado.

La ejecución no es lo que Bitcoin necesita hacer

Una vez aceptas que Bitcoin Script está intencionadamente limitado (sin estado y no diseñado para cálculos ilimitados), empiezas a pensar en cómo hacer que Bitcoin liquide los resultados y los pagos.

De hecho, la ejecución puede ocurrir en una máquina virtual dedicada diseñada para ejecutar la lógica de contratos inteligentes de manera determinista, mientras Bitcoin permanece como la capa base que marca la hora, ordena y valora las interacciones a través de su mercado de tarifas existente. En el diseño de OpNet, la lógica del contrato se evalúa mediante una VM orientada a Wasm (OP-VM), mientras que la pila de nodos más amplia está explícitamente construida para gestionar y ejecutar contratos inteligentes usando la mecánica de transacciones y UTXO de Bitcoin.

Lo crucial es que esto no se combina con un nuevo activo de tarifas. Bitcoin no necesita medir la computación para ser la moneda de gas. Necesita ser la capa de liquidación final en la que todo paga y que ancla las transacciones.

Cómo se ve una llamada a contrato pagada en BTC

Nuestro modelo de interacción sigue un flujo de simular-antes-de-gastar en lugar de un patrón convencional de ejecución de contratos inteligentes, con el paso final de ejecución ocurriendo como una transacción real de Bitcoin. Primero, tu aplicación llama a un método del contrato en modo de simulación. Esa solicitud pasa por un proveedor a un nodo OPNet, que ejecuta el contrato en su VM y devuelve un CallResult (incluyendo estimaciones de gas/tarifa) sin transmitir nada a Bitcoin.

Si la llamada cambia el estado, tomas ese CallResult y lo envías como una ejecución. En ese momento, la biblioteca construye una transacción de Bitcoin, la firma y la transmite a la red de Bitcoin. Dos puntos importantes:

• Las tarifas de los mineros son nativas de Bitcoin. Eliges una tarifa en sat/vB, opcionalmente añades una tarifa de prioridad en sats, y estableces un límite máximo en el gasto de tarifas mediante maximumAllowedSatToSpend (el parámetro se llama literalmente maximumAllowedSatToSpend).
• El destino del contrato se expresa como una dirección de contrato estilo P2OP. La instancia del contrato expone su formato de dirección p2op, y las transacciones hacen referencia a una “dirección de contrato p2op” como destino del contrato.

Mientras tanto, la medición de computación propia de OpNet todavía existe. Pero se valora en satoshis (estimaciones de SATS Gas, reembolsos en SATS, etc.), por lo que la unidad nunca se desvía hacia una economía de tokens separada.

Menos fricción, incentivos más claros

Los usuarios ya no tienen que adoptar una segunda economía de tarifas solo para interactuar con aplicaciones. En Bitcoin, las tarifas ya son una subasta por espacio en bloque, valoradas por byte y pagadas a los mineros. Cuando las llamadas a contratos son solo transacciones de Bitcoin, vuelves a un terreno familiar (con tarifas en sat/vB, movimiento en mempool e incentivos para los mineros), sin tener que aprender un mercado separado de tokens de gas.

Además, las herramientas se apoyan en flujos de trabajo estándar de Bitcoin, como la gestión de UTXO, conexiones con proveedores e incluso firma en frío/offline. Los contratos viven en un entorno Wasm y están escritos en AssemblyScript, buscando una expresividad similar a Solidity sin pretender que Bitcoin Script se convierta de repente en una VM.

Bitcoin como gas, sin un segundo token

La afirmación de que BTC no puede funcionar como gas generalmente se basa en la suposición de que la capa base debe medir la computación para valorarla. Bitcoin no mide la computación; mide el espacio en bloque y liquida valor.

La solución es permitir que una máquina virtual maneje la ejecución de manera determinista, y luego enrutar cada interacción que cambie el estado a través de una transacción estándar de Bitcoin, donde las tarifas se expresen en términos familiares como sat/vB y se limiten en satoshis. En nuestro caso, esto se implementa a nivel del cliente mediante parámetros como feeRate y maximumAllowedSatToSpend.

Así que quizás, BTC como gas, sea realmente plausible. Las tarifas permanecen nativas de BTC de principio a fin, mientras que el entorno de ejecución del contrato se mantiene en WebAssembly (AssemblyScript → Wasm), lo que mantiene la lógica expresiva sin cambiar la moneda de tarifas.

Frederic Fosco

Frederic Fosco, también conocido como Danny Plainview, es cofundador de OP_NET y ha estado involucrado en Bitcoin desde 2013. Lanzó OP_NET para hacer que Bitcoin sea nativamente programable, desbloqueando contratos inteligentes y primitivas DeFi directamente en la capa 1. Su enfoque es construir funcionalidad real en cadena sin puentes, custodios, wrapping o Bitcoin sintético, manteniendo la autogestión y la descentralización como prioridades.