Cómo leer una transacción cripto: del hash a la confirmación

Una transferencia cripto puede tener identificador antes de recibir un número de bloque. Más tarde puede sumar confirmaciones, generar un recibo y actualizar el saldo de una cuenta. Todos esos registros pertenecen al mismo pago, pero no significan lo mismo.

La diferencia resulta útil cuando el lenguaje cripto aparece en otros servicios en línea. El registro de una cartera consultado después de usar 1x puede mostrar varias etapas de una misma transacción: el hash aparece antes que los datos del bloque y el número de confirmaciones cambia después.

La referencia al bloque llega más tarde, igual que las confirmaciones. Una transacción deja varios rastros porque cada uno responde a una pregunta distinta.

El hash de la transacción aparece antes que la referencia al bloque

Ethereum utiliza un hash de 32 bytes para identificar cada transacción. Una vez incluida en un bloque, su registro también puede contener un blockHash y un blockNumber.

Los dos hashes cumplen funciones distintas. El hash de la transacción identifica la transferencia; el hash del bloque señala el bloque que la contiene.

Antes de incluirla en un bloque falta esa segunda capa. Una transacción de Ethereum pendiente puede mostrar null en el hash y número de bloque aunque ya exista su hash de transacción.

El registro también puede incluir las direcciones de origen y destino, el importe transferido, los datos del gas y un nonce. Describen la misma transacción desde distintos ángulos, no pagos separados.

«Pendiente» es una etapa, no otro identificador

Una transacción firmada llega primero a la red. Su inclusión en un bloque ocurre después.

Bitcoin muestra bien la secuencia. Con cero confirmaciones, la transacción ya se ha difundido, pero todavía no está en un bloque. La primera confirmación llega cuando se incluye; los bloques posteriores aumentan la cuenta.

El proceso se resume en cinco pasos:

• se firma y difunde la transacción

• puede existir un registro pendiente antes de incluirla

• un bloque contiene la transacción

• los bloques posteriores añaden confirmaciones

• la cuenta del usuario o del comercio puede actualizarse por separado

Bitcoin busca un intervalo medio de unos diez minutos entre bloques. Los bloques reales no llegan con la precisión de un reloj, así que la espera concreta puede ser menor o mayor.

Seis confirmaciones suelen tomarse como una referencia más sólida para transferencias grandes. Es una convención de la red, no un requisito universal de todos los servicios receptores.

El mismo número de confirmaciones puede representar tiempos muy distintos

La cifra de seis solo sirve si se conoce la red.

Bitcoin tarda de media unos diez minutos entre bloques. Ethereum produce bloques a intervalos aproximados de 12 segundos. Por eso seis confirmaciones de Bitcoin y seis bloques adicionales de Ethereum representan periodos muy diferentes.

Sus mecanismos también difieren, así que no basta comparar la cifra para equiparar confirmaciones de distintas redes.

Es más preciso que afirmar simplemente que una cadena es más rápida: cada cifra corresponde a la cadena que la produce.

El recibo registra lo sucedido tras la ejecución

Ethereum añade otra capa cuando la transacción se procesa en un bloque.

El recibo de la transacción puede incluir el hash original y los datos del bloque. También registra el gas utilizado, su precio efectivo y el estado de ejecución.

El campo de estado es breve: 1 significa éxito y 0, fallo.

Mientras la transacción siga pendiente no habrá recibo. La diferencia es clara: primero puede existir el hash; el recibo aparece después de la ejecución.

Una cartera puede mostrar un identificador válido aunque todavía falten otros campos. No hay contradicción: los registros pertenecen a momentos distintos.

El hash de un casino cripto puede demostrar otra cosa

Los sistemas de casino pueden mostrar otra cadena hexadecimal larga que no tenga relación con la liquidación de un pago.

En un sistema provably fair, un hash SHA-256 puede comprometer una semilla secreta del servidor antes de una ronda. La semilla original se revela después y se calcula de nuevo su hash para comprobar el compromiso anterior.

Quien pasa de los juegos de 1xbet casino a los registros de transacciones cripto puede encontrar cadenas hexadecimales parecidas, aunque el hash de una semilla y el de una transacción blockchain cumplan funciones completamente distintas.

Una construcción habitual de provably fair combina una semilla del servidor y otra del cliente con un nonce. SHA-256 produce un resultado de 256 bits, normalmente presentado en 64 caracteres hexadecimales.

Las cadenas pueden parecer iguales. Sus funciones no lo son.

La distinción también separa el juego responsable de las matemáticas de verificación. Un hash puede ayudar a comprobar cómo se comprometió un resultado, pero no lo hace predecible; los límites prudentes siguen siendo necesarios al apostar.

Los registros cripto se leen mejor si cada campo se relaciona con su etapa. El hash identifica la transferencia; la referencia al bloque registra su inclusión; las confirmaciones posteriores describen lo sucedido después. Cifras parecidas pueden pertenecer a un mismo pago sin significar lo mismo.

El importe enviado no es la comisión de red

Dos cifras monetarias pueden aparecer en una transacción sin representar el mismo concepto.

En Ethereum, value registra el importe transferido. La comisión de red se calcula a partir del gas consumido y de su precio efectivo.

Un servicio receptor puede hacer después su propio registro contable, una vez completada la parte blockchain. Por ejemplo, puede comparar una factura con el importe recibido antes de actualizar la cuenta. Esa actualización no es otra confirmación de blockchain: pertenece al sistema receptor.

Por eso, la blockchain y el registro de la cuenta pueden alcanzar su estado final en momentos distintos.