La Timechain, o Blockchain de Bitcoin, es la cadena enlazada de bloques válidos desde el Genesis Block hasta la punta actual de la red. Cada bloque posterior apunta al hash de su predecesor, su huella digital, y añade su propio Proof of Work, una prueba del trabajo computacional necesario para crear el bloque. Así, los nodos pueden verificar por separado qué historia cumple las reglas y acumula más trabajo. Aquí «tiempo» no significa un reloj exacto para cada transacción, sino ante todo un orden demostrable de los acontecimientos.
Imagina un registro contable público en la que miles de ordenadores pueden comprobar por separado cada página nueva. Una página es un bloque. Contiene un conjunto de transacciones y una referencia al bloque anterior, de modo que las páginas tienen un orden definido y no pueden barajarse libremente. La Timechain es toda esa secuencia enlazada, desde el primer bloque hasta la punta actual. No dice cuánto bitcoin posee cada persona por su nombre; conserva la historia de transacciones a partir de la cual los nodos calculan las salidas de transacciones que siguen sin gastarse. Tampoco es el servidor de una empresa. Cualquier Full Node (un nodo que verifica por sí mismo las transacciones y las reglas de la red) puede descargar y verificar una copia. [1] [3]
En el contexto de Bitcoin, ambos nombres designan la misma historia de bloques. El código previo al lanzamiento conservado de noviembre de 2008 usaba timechain en comentarios y nombres de variables o funciones. El whitepaper, en cambio, habla de sellado de tiempo, cadena de bloques y cadena de Proof of Work; la palabra exacta timechain no aparece allí. Más tarde, Blockchain se convirtió en el término habitual en todo el mundo. Hoy también es una etiqueta amplia para otras redes y bases de datos, mientras que la Timechain de Bitcoin es la cadena concreta de Bitcoin. Las dos palabras del título no nombran dos protocolos: mantienen el nombre histórico junto al término común actual. [2] [1] [8]
Una firma digital permite comprobar que una transacción fue autorizada por quien posee la clave necesaria. Por sí sola, no impide firmar dos transacciones en conflicto que intentan gastar la misma salida aún no gastada de una transacción anterior, llamada UTXO. Un nodo puede recibir primero un pago al comercio y otro, la devolución del mismo valor al remitente. La red necesita por eso una historia compartida que determine qué gasto quedó confirmado y cuál ya no puede ser válido. Los bloques dan a las transacciones un lugar verificable dentro de ese orden. No prueban qué mensaje se creó primero en el tiempo humano o de red: distintos nodos pudieron ver las transacciones sin confirmar en órdenes diferentes. [1]
El Block Header contiene los datos esenciales de un bloque. Entre ellos están el hash de la cabecera anterior y el Merkle Root, que reúne los identificadores de las transacciones del bloque en un hash. Un hash se parece a una huella digital: un cambio mínimo en los datos produce un resultado distinto. Si alguien modificara una transacción antigua, cambiarían el Merkle Root, el hash del bloque y la referencia guardada por el bloque siguiente. La modificación no quedaría en una sola línea: rompería toda la secuencia posterior. Un hash por sí solo no demuestra que las transacciones cumplan las reglas. Los nodos también deben validar las transacciones y cada bloque debe cumplir el Proof of Work exigido. [3] [1]
Un nodo no acepta una rama solo porque sea más larga o la promueva un gran minero. Primero comprueba las reglas: Proof of Work, enlaces con bloques anteriores, recompensa permitida, transacciones, condiciones de gasto y que las entradas no intenten gastar fondos ya gastados. Una rama inválida sigue siendo inválida sin importar la potencia de su autor. Solo entre candidatos válidos el nodo escoge la cadena con más trabajo acumulado. Por eso es más preciso hablar de la rama válida con más trabajo que simplemente de la «cadena más larga». El campo chainwork estima el número esperado de hashes necesario para producir la cadena según la dificultad de cada bloque; no cuenta los intentos que los mineros realizaron realmente. [4] [5] [6]
El Proof of Work consume tiempo, electricidad y capacidad de cálculo, pero su resultado se verifica con rapidez. Quien cambiara un bloque antiguo tendría que crear para él un nuevo Proof of Work válido, volver a enlazar todos los bloques posteriores y seguir alcanzando el trabajo que la rama honesta continúa añadiendo. Cuanto más profundo está un bloque bajo la punta, mayor es la ventaja de la historia ordinaria. No es una promesa matemática de que el pasado jamás cambie. Es una defensa económica y probabilística: cada bloque adicional suele encarecer con rapidez una reescritura exitosa. El atacante tampoco puede incluir un pago inválido cualquiera ni crear bitcoin por encima del límite, porque los demás nodos rechazarían ese bloque. [1] [4]
El minero introduce una marca temporal en el Block Header. Las reglas de consenso permiten cierto margen, por lo que el valor time no demuestra con exactitud cuándo se creó un bloque o una transacción concreta. La marca de un bloque ni siquiera tiene que ser superior a la de su predecesor inmediato. Para algunas reglas Bitcoin utiliza Median Time Past: la mediana de las marcas de los 11 bloques anteriores. La mediana se obtiene ordenando esas marcas temporales y tomando el valor central. Avanza de forma más estable que las marcas individuales. Tampoco el intervalo medio de diez minutos es un horario. Dos bloques pueden llegar muy seguidos y otro tardar mucho más. La altura da una posición exacta en la cadena, no una hora exacta del calendario. [4] [7]
Dos mineros pueden encontrar casi al mismo tiempo bloques válidos distintos a la misma altura. Algunos nodos verán primero una rama y otros, la contraria. Cuando el Proof of Work posterior crea una diferencia, los nodos pasan a la rama válida con más trabajo acumulado. Ese cambio se llama Reorg. Las transacciones del bloque desconectado pueden confirmarse en la nueva rama, volver al Mempool o dejar de ser válidas si la nueva historia confirma un gasto incompatible. La inclusión en un bloque es la primera confirmación y cada bloque posterior añade otra. No existe un número mágico universal para todos los pagos. La confianza adecuada depende del valor, el riesgo y la posibilidad de esperar. [1] [3]
Bitcoin permite crear una transacción que solo puede confirmarse desde cierta altura o después de un tiempo determinado. Un Timelock no ordena que se ejecute automáticamente en ese minuto. Solo fija el punto más temprano a partir del cual un bloque válido puede incluirla. Para nLockTime basado en tiempo, BIP 113 usa el Median Time Past del bloque anterior, no la marca fácil de desplazar del bloque que se está creando. La condición se apoya así en la historia de varios bloques. Incluso al cumplirse, la transacción debe difundirse, ser aceptada por los nodos y seleccionada por un minero; no está garantizada su inclusión en un bloque concreto. [7] [4]
RPC es una interfaz para dar instrucciones al nodo y leer sus respuestas. Un Full Node no tiene que confiar en que un explorador público diga que un bloque o una transacción pertenece a la historia actual. Para un hash concreto, el RPC getblock muestra altura, confirmaciones, Merkle Root, time, mediantime, hash anterior, dificultad y chainwork. Cada campo responde a una pregunta: height da la posición; previousblockhash muestra la ascendencia; confirmations indica la profundidad bajo la punta; time es el valor de la cabecera; mediantime es una mediana; y chainwork representa trabajo esperado acumulado. Ningún número basta por sí solo. El sentido de la Timechain es que el nodo comprueba su relación y todas las reglas de consenso como un conjunto. [6] [4]
Para obtener la imagen más completa, lee esta entrada junto con Genesis Block, Proof of Work, Transacción, Full Node, Difficulty Adjustment. También enlazan con esta entrada Bitcoin Whitepaper, Genesis Block, Proof of Work, Full Node.