Un explorador de bloques es una web que presenta datos crudos de la cadena como páginas. Es la primera herramienta que casi todo el mundo usa para «ver» una transacción y la última que muchos aprenden a leer bien. Cada número de la página es o bien un hecho de la cadena o bien una inferencia que el explorador añadió por comodidad, y la diferencia importa cuando depuras un pago, auditas un contrato o verificas una afirmación que alguien hizo en redes sociales.

Parte 1 — Una transacción de Bitcoin

Identidad

El txid es el doble SHA256 de los bytes serializados de la transacción, excluyendo los datos de testigo (witness). Desde la actualización SegWit de 2017 existe un segundo identificador, el wtxid, que cubre también el testigo. La consecuencia práctica: un tercero no puede alterar el txid manipulando firmas, que es lo que hizo seguro construir canales de pago. Si un explorador muestra ambos, es por eso.

Entradas

Cada entrada nombra una salida anterior por txid:índice, la moneda que se gasta. Los exploradores resuelven esa referencia para mostrar la dirección y el importe de la moneda, pero ten en cuenta que la dirección de una entrada se deriva de la salida anterior, no está guardada en esta transacción. La entrada también lleva los datos de desbloqueo: una firma y una clave pública en scripts heredados, o un testigo en SegWit y Taproot. Un campo sequence por entrada indica si el emisor activó Replace-By-Fee; los exploradores suelen resumirlo como una insignia «RBF».

Salidas

Cada salida es un importe en satoshis y un script de bloqueo. El explorador traduce el script a una dirección y un tipo. Aprende a leer los prefijos:

La dirección empieza porTipo de scriptSignificado
1…P2PKHPago a hash de clave pública heredado; el más grande y caro de gastar
3…P2SHPago a hash de script; multifirma o SegWit envuelto por compatibilidad
bc1q…P2WPKH / P2WSHSegWit nativo (bech32); más barato, descuento de testigo
bc1p…P2TRTaproot (bech32m); firmas Schnorr, gasto por clave o por script

Las salidas sin dirección y con un script que empieza por OP_RETURN llevan datos arbitrarios y no se pueden gastar; así es como los protocolos anclan compromisos en Bitcoin.

Tamaño, peso y comisión

Desde SegWit, la capacidad del bloque se mide en unidades de peso con un límite de cuatro millones por bloque. Los bytes que no son de testigo cuentan cuatro unidades cada uno; los de testigo, una. Los exploradores convierten el peso a bytes virtuales (vsize = peso ÷ 4) para poder expresar comisiones en sat/vB. La comisión en sí nunca se escribe en la transacción: es la suma de entradas menos la suma de salidas. Cuando un explorador dice «comisión 2.340 sat, 14,2 sat/vB», ha calculado ambas cosas.

Campos de tiempo

locktime hace inválida una transacción antes de cierta altura de bloque o marca de tiempo; cero significa sin restricción. Combinado con los números de secuencia permite bloqueos temporales relativos. La «hora» que un explorador muestra para una transacción es la marca de tiempo del bloque que la incluyó, o el momento en que el nodo del explorador la vio por primera vez en la mempool; ninguna es el instante en que pulsaste enviar.

Confirmaciones

Confirmaciones = altura actual de la cadena − altura del bloque de la transacción + 1. Una transacción sin confirmar no tiene ninguna y vive solo en mempools, que difieren entre nodos; la vista de mempool de un explorador es la de su propio nodo.

Parte 2 — Un bloque de Bitcoin

La página de un bloque muestra la altura (posición en la cadena), el hash (que debe estar por debajo del objetivo de dificultad, de ahí los ceros iniciales), el hash del bloque anterior que lo encadena a su padre, la raíz de Merkle que compromete todas las transacciones del bloque, la marca de tiempo que escribió el minero (que puede estar algo desviada), el nonce, y la dificultad y el peso. La primera transacción es siempre la coinbase: no tiene entradas reales y crea el subsidio del bloque más todas las comisiones para el minero. El campo de datos de la entrada coinbase es donde los mineros escriben nombres de pool y señalización, que es como los exploradores saben «minado por» tal pool.

Parte 3 — Una transacción de Ethereum

Ethereum usa cuentas, no monedas, así que la página es distinta pero la regla es la misma.

  • Hash: keccak-256 de la transacción firmada. Nonce: el contador de transacciones del emisor; las transacciones de una cuenta deben confirmarse en orden de nonce, por eso una transacción atascada con comisión baja bloquea todas las posteriores.
  • From / To: la cuenta emisora y la receptora. Si «to» es un contrato, el explorador suele mostrar su nombre si el código fuente fue verificado, y descifra los datos de entrada: los primeros cuatro bytes son el selector de función y el resto son los argumentos codificados según el ABI. Un «to» ausente significa creación de contrato.
  • Value: ether transferido directamente. Las transferencias de tokens muestran aquí un valor cero; los tokens se mueven dentro del almacenamiento del contrato y aparecen como eventos.
  • Gas limit / gas used: lo que el emisor autorizó frente a lo que consumió la ejecución. Una transferencia simple de ether usa exactamente 21.000 gas. La base fee la fija el protocolo por bloque y se quema; la priority fee (propina) va al proponente del bloque. Comisión = gas usado × (base fee + priority fee).
  • Status: éxito o fallo. Una transacción fallida sigue incluida en un bloque y sigue pagando gas; solo se revierten sus cambios de estado. El explorador suele mostrar el motivo de reversión si el contrato lo proporcionó.
  • Logs / eventos: registros estructurados que emiten los contratos durante la ejecución, como el evento Transfer(from, to, amount) que emite todo token estándar. De ahí sale la sección «Tokens transferidos».
  • Transacciones internas: movimientos de ether provocados por código de contratos y no por la transacción firmada en sí. No se guardan en la cadena como transacciones; el explorador las reconstruye reejecutando la transacción con trazado activado. Distintos exploradores pueden discrepar aquí.

Desde el cambio a prueba de participación, los bloques se producen en slots fijos de doce segundos, agrupados en épocas de treinta y dos slots; los exploradores muestran tanto el número de bloque como el slot, y marcan un bloque como «finalizado» cuando el punto de control que lo contiene ha sido justificado dos veces.

Parte 4 — Lo que añadió el explorador

Los valores en moneda fiat usan la fuente de precios que el explorador eligió en el momento en que la muestreó. Las etiquetas de direcciones («Binance 14», «hackeo de Bitfinex») salen de heurísticas, informes públicos y etiquetado manual; a menudo aciertan y de vez en cuando se equivocan de forma espectacular. El «saldo» de una dirección de Bitcoin es una suma de los UTXO que el explorador indexó, correcta pero conceptualmente ajena al protocolo. Los nombres de contratos solo aparecen si alguien subió código fuente coincidente, y un contrato verificado puede seguir siendo malicioso. Nada de esto es motivo para desconfiar de los exploradores; es motivo para saber qué campo es qué.

Parte 5 — Comprobar desde tu propio nodo

Todo lo anterior se puede leer sin explorador. En un nodo Bitcoin Core con el índice de transacciones activado:

bitcoin-cli getrawtransaction <txid> true
bitcoin-cli getblock <blockhash> 2
bitcoin-cli getmempoolentry <txid>

La primera llamada devuelve entradas, salidas, scripts, tamaño, vsize, peso y confirmaciones en JSON; la comisión la calculas obteniendo la salida anterior de cada entrada. En un nodo de Ethereum, o en cualquier proveedor que exponga JSON-RPC:

curl -s -X POST -H 'Content-Type: application/json' \
  --data '{"jsonrpc":"2.0","id":1,"method":"eth_getTransactionReceipt","params":["0x<hash>"]}' \
  http://localhost:8545

El recibo lleva el estado, el gas usado, el precio efectivo del gas y los logs. Combínalo con eth_getTransactionByHash para los campos firmados y con debug_traceTransaction si quieres las llamadas internas que mostraría un explorador. Leer la salida cruda una vez es la mejor cura contra tratar las páginas del explorador como autoridad: la página es una vista, el nodo es la fuente.

Sigue leyendo: qué hacen esos bytes de datos de entrada cuando llegan a un contrato es el tema de Contratos inteligentes por dentro. Para el ciclo de vida que describen estos campos, mira Cómo funciona una transacción de Bitcoin. Nuestro informe sobre BIP-110 es un ejemplo práctico de lectura de bits de versión de bloque y datos de coinbase para identificar qué minero produjo qué bloque.

Preguntas frecuentes

¿Por qué un explorador de Bitcoin muestra una comisión si la transacción no tiene campo de comisión? Las transacciones de Bitcoin nunca declaran la comisión. Está implícita: el total de las entradas menos el total de las salidas va al minero. El explorador consulta la salida anterior de cada entrada para calcularla.

¿Qué diferencia hay entre tamaño, vsize y peso? El tamaño es la longitud en bytes. El peso cuenta cuatro veces los bytes que no son de testigo y una vez los de testigo, con un límite por bloque de cuatro millones de unidades de peso. El tamaño virtual es el peso dividido entre cuatro, y las tarifas se expresan por byte virtual para reflejar el descuento de SegWit.

¿Por qué mi transacción de Ethereum falló pero igualmente costó gas? La ejecución ocurre antes de conocer el resultado. Si el contrato revierte, los cambios de estado se deshacen, pero el cómputo hasta ese punto ya lo realizaron todos los nodos, así que el gas consumido se paga igual. La transacción queda en el bloque con estado fallido.

¿Las transacciones internas se guardan en la cadena? No. Son movimientos de ether que hace el código de los contratos durante la ejecución. Los exploradores las reconstruyen reejecutando la transacción con trazado, por eso dos exploradores pueden presentarlas de forma distinta.