Una transacción blockchain es una solicitud autorizada para cambiar el estado de la red
Una transacción blockchain no es valor atravesando un túnel invisible. Es un conjunto estructurado de datos con el que se solicita a la red un cambio concreto: transferir una moneda nativa, invocar un contrato inteligente, mover un token, crear un activo o actualizar alguna otra parte del registro.
Primero, la cartera construye la transacción. Después, los firmantes necesarios la autorizan con firmas digitales. Los datos firmados se difunden entre los nodos, que comprueban de forma independiente su conformidad con el protocolo y pueden seleccionarlos para incluirlos en un bloque aceptado o en un lote ordenado.
Solo una ejecución aceptada cambia el estado compartido. Antes de ese momento, la transacción sigue siendo una propuesta. Puede resultar visible, válida y ampliamente propagada sin haber modificado todavía saldos, derechos de control ni almacenamiento de contratos en el historial canónico.
En Bitcoin, las transacciones consumen salidas anteriores y crean otras nuevas. Ethereum las define como instrucciones firmadas criptográficamente que parten de una cuenta. Solana reúne firmas y una o varias instrucciones; en TON, una transacción se registra cuando una cuenta procesa un mensaje y modifica su estado. Las estructuras varían, pero el patrón de fondo es el mismo.
El usuario expresa una intención; la cartera crea el objeto de transacción
Los usuarios piensan en órdenes sencillas: enviar 0,01 BTC, transferir 50 USDT, intercambiar un token o interactuar con un contrato. La blockchain no procesa directamente esa intención humana. La cartera o aplicación debe convertirla en una estructura precisa que comprenda la red seleccionada.
Esta conversión encierra decisiones técnicas que no aparecen en la instrucción visible. Una cartera de Bitcoin selecciona salidas disponibles y calcula el cambio; una de Ethereum asigna un nonce y estima el gas; las de Solana y TON preparan las cuentas, referencias de bloque y mensajes requeridos por sus respectivos modelos.
El resultado buscado, como pagar a una dirección o llamar a una aplicación.
Estructura de datos propia de la red que expresa el cambio solicitado.
Prueba de que las claves necesarias aprobaron exactamente esos datos.
Cambio de estado producido al procesar una transacción aceptada.
Por tanto, una transacción no es solo una orden de pago: describe de forma interpretable por máquinas qué debe cambiar, quién lo autorizó, qué recursos puede utilizar y qué reglas de la red debe satisfacer.
Las redes usan campos distintos, pero toda transacción debe aportar información verificable
No existe un formato universal de transacción blockchain. Sin embargo, la mayoría contiene los mismos conceptos: recursos disponibles, resultado solicitado, autorización necesaria, protección contra repeticiones o secuencias indebidas y coste de ejecución aceptado por quien envía.
| Componente | Función | Ejemplos habituales |
|---|---|---|
| Recursos de origen | Indican qué puede gastarse o qué cuenta inicia la operación. | Entradas de Bitcoin; remitente de Ethereum; lista de cuentas de Solana |
| Resultado solicitado | Describe la transferencia, instrucción o llamada a un contrato. | Salidas, destinatario e importe, instrucciones de programa, contenido del mensaje |
| Protección del orden | Evita reproducciones no deseadas o establece una secuencia válida. | Outpoints, nonce, hash de bloque reciente, número de secuencia |
| Límites y comisiones | Limitan el trabajo computacional o remuneran el procesamiento. | Tarifa por unidad, límite de gas, comisión prioritaria, presupuesto de cómputo |
| Firmas | Demuestran la aprobación de claves privadas sin revelarlas. | ECDSA, Schnorr, Ed25519, verificación en contratos |
La guía de transacciones de Bitcoin explica cómo las entradas remiten a salidas anteriores y cómo las nuevas salidas definen condiciones futuras de gasto. La documentación de Ethereum detalla destinatario, valor, datos, nonce, límite de gas y parámetros de comisión.
La firma digital autoriza datos exactos; no mueve fondos por sí sola
Una cartera firma una representación de la transacción con una o varias claves privadas. Los participantes comprueban la firma usando la clave pública correspondiente o la condición de gasto, sin conocer la clave secreta que la produjo.
Esto demuestra autorización, no identidad personal. Una firma válida acredita el control de una clave que exige el protocolo; no revela quién es la persona firmante ni demuestra que exista un acuerdo comercial o que el destinatario sea la empresa esperada.
También importa qué datos están cubiertos por la firma. Modificar una cantidad protegida, una dirección de destino, una instrucción u otro campo firmado invalida esa autorización. Por eso un intermediario normalmente no puede editar una transferencia firmada y conservar la firma original.
UTXO y cuentas representan de manera distinta el estado que puede gastarse
El formato de transacción depende del modelo de libro mayor. Bitcoin usa salidas de transacción no gastadas, o UTXO. Una transacción consume salidas anteriores concretas y crea otras nuevas. La red no actualiza un saldo global de cuenta Bitcoin; la cartera calcula lo disponible a partir de las salidas que sus claves pueden gastar.
Ethereum se basa en cuentas. Una cuenta controlada externamente posee saldo y nonce. Las transacciones se aplican en el orden impuesto por ese nonce y pueden modificar balances, código y almacenamiento de contratos. La documentación de cuentas de Ethereum explica cómo el nonce impide ejecutar repetidamente la misma transacción firmada.
En Solana, las transacciones identifican las cuentas que una instrucción lee o escribe. Los programas procesan instrucciones y actualizan cuentas escribibles. Un hash de bloque reciente limita el período de validez. La guía oficial de Solana describe firmas, instrucciones, claves de cuenta y ese hash.
TON funciona mediante mensajes. Un mensaje entrante puede activar una transacción en una cuenta, cambiar su estado y emitir mensajes destinados a otras cuentas. La documentación de mensajes y transacciones de TON detalla esa relación.
Consume salidas gastables individuales y produce nuevas salidas.
Aplica cambios ordenados a saldos, nonces y almacenamiento.
Ejecuta instrucciones que consultan y modifican cuentas declaradas.
Procesa mensajes por cuenta y emite otros para operaciones posteriores.
La difusión distribuye una transacción candidata; no crea consenso
Una vez firmada, la cartera envía la transacción serializada a un nodo o servicio. Ese par comprueba requisitos preliminares y decide aceptarla y retransmitirla. Otros nodos repiten el proceso y la transacción se propaga por la red.
La propagación no es instantánea ni uniforme. Los nodos tienen conexiones, políticas de software, límites de recursos y vistas locales diferentes. Un explorador puede mostrar una transacción pendiente antes que otro servicio, y algunos nodos pueden rechazar una transacción que otros conservan.
La guía de la red entre pares de Bitcoin describe cómo intercambian transacciones los nodos completos. Así, «difundida» significa que ha empezado la distribución, no que toda la red haya aceptado un resultado canónico.
Los nodos comprueban tanto los datos como el estado en que se ejecutarían
Verificar la firma es solo una parte de la validación. Un nodo examina serialización, valores, recursos referenciados y condiciones de secuencia; después comprueba la solicitud frente a su visión actual del libro mayor.
En Bitcoin, las salidas referenciadas deben existir y no haberse gastado. Los datos de desbloqueo han de cumplir las condiciones de gasto y la suma de entradas debe cubrir salidas más comisión implícita. Intentar consumir una salida ya gastada es inválido en ese estado de la cadena.
En Ethereum, la firma debe identificar al remitente y el nonce respetar el orden de la cuenta. El remitente debe disponer de fondos para el valor y el coste máximo de ejecución; además, el tipo de transacción debe seguir las reglas activas. La ejecución contractual puede efectuar comprobaciones adicionales y revertirse.
Solana verifica firmas, hash reciente, bloqueos de cuentas, estructura de instrucciones, fondos para comisiones y reglas del entorno de ejecución. TON valida el mensaje entrante y ejecuta las fases previstas por el protocolo para la cuenta.
Transacción candidata ├─ ¿estructura válida? ├─ ¿firmas requeridas válidas? ├─ ¿entradas o estado de cuenta disponibles? ├─ ¿secuencia / nonce / hash aceptables? ├─ ¿comisiones y recursos suficientes? └─ ¿operación permitida por el protocolo? ├─ no → rechazar o no retransmitir └─ sí → conservar como candidata para inclusión
La validez depende del contexto. Una operación válida al firmarse puede resultar inutilizable antes de incluirse: otra puede gastar la misma salida de Bitcoin, faltar una transacción previa con menor nonce en Ethereum o caducar el hash reciente de Solana.
Una transacción pendiente válida está admitida localmente, no registrada de forma canónica
Muchas redes mantienen conjuntos locales de transacciones que superaron controles de admisión, pero todavía no se incluyeron. Se habla del «mempool», aunque normalmente no existe un único conjunto global: cada nodo mantiene candidatos según su perspectiva y políticas.
Los productores de bloques seleccionan las transacciones que conocen. Capacidad, incentivos de comisión, dependencias, secuencia de cuentas y limitaciones de ejecución influyen en la selección. Una transacción válida puede quedar pendiente, sustituirse, caducar o desaparecer de algunos mempools.
El artículo de OxaPay Mempool explicado analiza la competencia por capacidad y los cambios de tiempo de inclusión. Aquí se trata solo su función en el ciclo de vida: el mercado de comisiones y la disputa por espacio de bloque requieren otro análisis.
La inclusión en un bloque sitúa la ejecución dentro de un historial aceptado
Un minero, validador, líder o secuenciador selecciona transacciones y propone un bloque o lote ordenado. Los demás verifican la propuesta conforme al protocolo. Al aceptarse, pasa al historial canónico actual o a una candidata aceptada que puede obtener un compromiso más firme con el tiempo.
El orden importa porque cada transacción depende del estado previo. Dos operaciones pueden competir por un mismo recurso, las llamadas a contratos producir efectos distintos si cambia el orden, los nonces exigir secuencia y los bloqueos de cuentas de Solana condicionar la ejecución en paralelo.
Por ello, incluir no es solo añadir una marca de tiempo. Es asignar una posición dentro de la secuencia de cambios de estado: la transacción se evalúa después de las operaciones anteriores y antes de las posteriores.
La ejecución convierte el estado anterior en el posterior mediante reglas deterministas
Al llegar a su posición, la red aplica las reglas pertinentes. Conceptualmente se expresa mediante una función de transición:
post_state = transition(pre_state, ordered_transaction, protocol_rules)
En Bitcoin, la validación correcta elimina las salidas consumidas del conjunto UTXO y añade las nuevas. En Ethereum, la ejecución puede modificar saldos, incrementar el nonce, desplegar contratos, actualizar almacenamiento y emitir registros. Las pruebas de especificación de ejecución de Ethereum comparan explícitamente el estado anterior y el posterior esperado.
En Solana, cada instrucción invoca un programa con cuentas declaradas; las modificaciones son atómicas: la transacción tiene éxito como unidad o se revierten sus cambios. En TON, procesar un mensaje puede modificar una cuenta y generar mensajes que activen transacciones posteriores en otras.
Los tokens ilustran por qué transacción y movimiento de valor no son conceptos idénticos. En muchas redes, la transacción nativa llama al contrato del token, que actualiza los balances almacenados y puede emitir un evento de transferencia. No existe un objeto token independiente viajando entre direcciones.
Recibos, logs, eventos y trazas aportan pruebas de ejecución, pero no todos equivalen al estado. Una aplicación puede reconocer transferencias por eventos; aun así necesita saber qué resultado representa el cambio autoritativo que busca.
Rechazo, descarte, reemplazo, caducidad y reversión son fallos de capas distintas
«Transacción fallida» resulta demasiado impreciso. Una operación mal formada o no autorizada puede rechazarse antes de propagarse; otra válida puede quedar pendiente porque no se selecciona, sustituirse por una competidora o caducar. Una llamada a contrato puede incluirse y revertirse al ejecutarse.
| Resultado | Qué ocurrió | Efecto sobre el estado |
|---|---|---|
| Rechazada | No superó reglas de admisión o consenso. | Sin cambio canónico |
| Pendiente o descartada | Siguió siendo candidata pero no se incluyó o mantuvo. | Sin cambio canónico |
| Reemplazada o en conflicto | Otra operación consumió el recurso o lugar de secuencia. | Solo la alternativa aceptada cambia el estado. |
| Incluida y correcta | Se completó la ejecución conforme al protocolo. | Se confirma el estado resultante. |
| Incluida pero revertida | La operación contractual empezó y falló. | Se revierten cambios de aplicación; pueden mantenerse costes o secuencia. |
Esta distinción es esencial al consultar exploradores. Una transacción de Ethereum puede estar incluida, marcar ejecución fallida y consumir gas. Una de Bitcoin ausente de la cadena aceptada puede reaparecer si sigue siendo válida y se retransmite. Una de Solana puede caducar cuando su hash reciente deja de ser utilizable.
El hash identifica los datos, pero no explica todo el significado de la transacción
El identificador se deriva habitualmente de los datos serializados y permite a nodos, carteras, exploradores y aplicaciones referirse a la operación sin repetir la carga completa. Las reglas de identificación y hashing varían según la red.
La guía de OxaPay sobre el identificador de transacción criptográfica explica cómo utilizan los comercios los TXID para verificar y prestar asistencia. Un explorador blockchain puede mostrar direcciones, importes, comisiones, posición en el bloque, estado de ejecución y confirmaciones.
Sin embargo, el hash no sabe si la operación corresponde a un pedido: desconoce el activo y red esperados, importe de factura, vencimiento, cliente y reglas de entrega. Es una referencia de red, no un registro comercial completo.
Comparten el ciclo de vida, pero la semántica y las garantías dependen de cada cadena
Todas las redes progresan de una operación propuesta a un estado aceptado, pero sus mecanismos difieren. Bitcoin gasta salidas; Ethereum transfiere ETH o invoca contratos; Solana agrupa instrucciones sobre cuentas explícitas; TON procesa mensajes y transacciones por cuenta.
Estas diferencias afectan al cálculo de comisiones, tamaño, orden, paralelismo, caducidad, detección de tokens y significado del éxito. También afectan a la interpretación de una infraestructura de pagos: un pago ERC-20 se reconoce por ejecución y logs del contrato, uno nativo de Bitcoin por salidas, y una transferencia jetton de TON puede requerir seguir mensajes entre contratos.
El nombre del activo no basta; hay que identificar activo y red. La documentación de monedas admitidas de OxaPay recoge las monedas con sus detalles de red. Un mismo símbolo puede necesitar interpretaciones de transacción diferentes según dónde se utilice.
Una transacción blockchain es un registro dentro de un sistema de pagos completo
Una solicitud de pago empieza con un contexto comercial: pedido, importe, activo, red, destino, vigencia y referencia empresarial. La transacción en blockchain registra lo que realmente envió el pagador; el sistema de pagos compara ese hecho con las condiciones esperadas.
El endpoint Payment Information de OxaPay ejemplifica la separación. Un registro de pago puede incluir identificador de seguimiento, contexto del pedido y estado general; los datos de transacción incluyen hash, importe, moneda, red, dirección, estado y confirmaciones.
El estado de red y el estado del pago están relacionados, pero no son equivalentes. La tabla de estados de pago de OxaPay contempla en espera, pagando, pagado, importe insuficiente, reembolso en curso, reembolsado y caducado. La blockchain no crea por sí misma esos significados empresariales.
Solicitud comercial
pedido + importe esperado + activo + red + plazo
↓
Transacción blockchain
hash + entradas/cuentas + instrucciones + firma + ejecución
↓
Interpretación del pago
conciliación + política de confirmación + excepciones + estado empresarialPor eso comprender las transacciones resulta útil para los comercios incluso si la pasarela gestiona el protocolo. Permite distinguir pruebas de red de pago completado y diagnosticar red incorrecta, importes erróneos, retrasos de inclusión, ejecución fallida y transferencias sin correspondencia.
Un modelo de siete pasos para entender cualquier transacción blockchain
- Intención: el usuario o la aplicación define el resultado deseado.
- Construcción: la cartera lo convierte en un objeto específico de red.
- Autorización: las claves requeridas firman datos exactos o condiciones de gasto.
- Propagación: los nodos reciben, comprueban y retransmiten la candidata.
- Admisión y selección: las candidatas esperan según políticas, capacidad, orden y comisiones.
- Inclusión y ejecución: la operación obtiene una posición y se aplica sobre el estado anterior.
- Estado aceptado: el resultado entra en el historial y gana firmeza con el tiempo.
Muchos confunden «enviado» con «estado modificado». Este modelo recuerda que son necesarias construcción, autorización, validación, ordenación y ejecución antes de que el libro refleje un resultado.
Documentación de los protocolos utilizada en este análisis
- Guía para desarrolladores de Bitcoin — Transacciones
- Guía de Bitcoin — Red entre pares
- Documentación de Ethereum — Transacciones
- Documentación de Ethereum — Cuentas
- Pruebas de ejecución de Ethereum — Transiciones de estado
- Documentación de Solana — Transacciones
- Documentación de TON — Mensajes y transacciones