En sentido preciso, un Orphan Block es un bloque cuyo predecesor inmediato es desconocido para un nodo concreto. A veces también se llama así a un Stale Block, fuera de la cadena activa. Ninguna etiqueta implica por sí sola fraude o un bloque defectuoso; primero hay que saber qué datos tiene el nodo y qué significado se está usando.
Al bloque anterior también se le llama padre. En un Orphan Block auténtico, el nodo de Jana no lo conoce y no puede terminar de comprobar la conexión. Un Stale Block puede tener un padre conocido y ser completamente válido; el nodo simplemente sigue otra rama como historia activa. Bitcoin Developer Guide distingue expresamente ambos significados. Cuando Jana ve orphan en un explorador de bloques, primero pregunta si falta el predecesor o si el bloque simplemente no permaneció en la cadena principal. [1]
La diferencia también aparece en Bitcoin Core, el software para operar un nodo que comprueba los bloques y las transacciones según las reglas de Bitcoin. En Bitcoin Core 29, AcceptBlockHeader busca al predecesor mediante hashPrevBlock, la referencia a su huella identificadora. Si el índice no contiene un registro, devuelve prev-blk-not-found. Si conoce al padre y está marcado como inválido, devuelve bad-prevblk. El primer caso dice «me falta contexto»; el segundo, «te apoyas en un bloque inválido». Aportar el predecesor ausente permite continuar las comprobaciones, pero no garantiza por sí solo aceptar el bloque completo. [2]
Un bloque tiene una cabecera, un breve conjunto de datos de identificación y enlace, y un cuerpo con transacciones. Bitcoin Core 0.10.0 introdujo la sincronización headers-first: primero se obtienen y verifican las cabeceras y después pueden descargarse los bloques en paralelo. Así, el nodo de Jana puede conocer la cabecera del predecesor sin tener aún todo el bloque en disco. Que falte el cuerpo no equivale a desconocer al predecesor; confundirlos podría hacer que una descarga normal pareciera un misterio. [3]
El comando getchaintips de Bitcoin Core 29 permite a Jana ver qué extremos de ramas conoce su nodo. active indica la cadena activa; valid-fork, una rama inactiva completamente validada. valid-headers significa que los bloques están disponibles, pero no se han validado por completo; headers-only indica que faltan algunos bloques. invalid identifica una rama que contiene un bloque inválido. No es, por tanto, una lista de problemas equivalentes. Ni siquiera la expresión orphaned branches de la ayuda elimina estas diferencias. [4]
Imaginemos dos bloques distintos, A y B, a la altura 900000. Es un ejemplo propio, no el relato de un suceso concreto. La altura es una posición en la cadena y los bloques rivales pueden compartirla. Jana los distingue mediante hash, la huella identificadora del bloque, y previousblockhash, la referencia al anterior. Entre ramas válidas decide el trabajo acumulado, no solo la altura. La interfaz RPC, usada para dar órdenes al programa, lo muestra como chainwork: el trabajo esperado acumulado correspondiente a las dificultades de los bloques. [1] [5]
Cuando Jana consulta con getblock un bloque fuera de la cadena principal, Bitcoin Core 29 puede indicar confirmations = -1. Es una marca especial de estado, no un recuento normal de confirmaciones. No es una cuenta atrás ni una profundidad negativa de reorganización. Tampoco demuestra que falte el predecesor. Jana debe leer el dato junto con la identidad del bloque y el estado de la rama; además, su nodo puede no tener todos los bloques que otros participantes hayan visto alguna vez. [5]
La recompensa del bloque se crea en una transacción inicial especial llamada coinbase, sin relación con la plataforma de intercambio del mismo nombre. Una salida de transacción registra una cantidad de bitcoin y las condiciones que deben cumplirse para gastarla. En Bitcoin Core 29, COINBASE_MATURITY vale 100: una salida creada a la altura H puede gastarse por primera vez en un bloque válido a la altura H+100. Cuenta la diferencia de alturas, no los minutos transcurridos. Esta espera no sustituye la inclusión en la cadena activa. Mientras el bloque de recompensa siga en una rama inactiva, su salida no está en el conjunto UTXO activo, el registro de salidas aún no gastadas. Más bloques en otra rama no devuelven el dinero por sí solos. [6] [7] [1] [8]
Jana guarda el hash del bloque, su predecesor, el estado de la rama y la versión del programa. Añade las respuestas de getchaintips y getblock, y el momento en que las obtuvo. Registra esa hora por separado del campo time de la cabecera: la marca temporal del bloque no es el momento en que su ordenador lo observó. El registro ayuda a comparar nuevas observaciones, pero no demuestra por sí solo un ataque, un fallo concreto de red ni una tasa mundial de bloques orphan. Ante todo, describe un nodo en un momento determinado. [4] [5]
Para obtener la imagen más completa, lee esta entrada junto con Stale Block, Reorg, Block Propagation, Proof of Work, Bitcoin. También enlazan con esta entrada Stale Block.