Mastering Bitcoin
8. La Red Bitcoin » Intercambiando «Inventario»
Página 53 de 98
Intercambiando «Inventario»
La primera cosa que un nodo completo hará una vez que se conecta a los compañeros es tratar de construir una cadena de bloques completa. Si es un nodo nuevo y no tiene cadena de bloques en absoluto, entonces solo conoce un bloque, el bloque génesis, que está integrado de forma estática en el software del cliente. Comenzando con el bloque #0 (el bloque génesis), el nuevo nodo tendrá que descargar cientos de miles de bloques para sincronizar con la red y volver a establecer la cadena de bloques completa.
El proceso de sincronización de la cadena de bloques comienza con el mensaje versión, porque contiene la BestHeight, que es la altura actual de la cadena de bloques de un nodo (número de bloques). Un nodo verá los mensajes versión de sus compañeros para saber cuántos bloques tiene cada uno, y ser capaz de comparar con el número de bloques que tiene en su propia cadena de bloques. Los nodos intercambiarán el mensaje getblocks que contiene el hash (huella digital) del bloque de la parte superior de su cadena de bloques local. Uno de los compañeros será capaz de identificar el hash recibido como perteneciente a un bloque que no está en la cima, sino que pertenece a un bloque más antiguo, deduciendo de esta manera que su propia cadena de bloques local es más larga que la de su compañero.
El nodo que tiene la cadena de bloques más larga, tiene mayor cantidad de bloques y puede identificar qué bloques necesita el otro nodo para «ponerse al día». Identificará los primeros 500 bloques a compartir y transmitirá sus valores hash utilizando un mensaje inv (de inventario). El nodo al que le falten estos bloques podrá luego recuperarlos mediante la emisión de una serie de mensajes getdata, solicitando los datos del bloque completo e identificando los bloques solicitados mediante los hashes del mensaje inv.
Supongamos, por ejemplo, que un nodo solo tiene el bloque de génesis. A continuación, recibirá un mensaje inv de sus pares que contiene los hashes de los próximos 500 bloques en la cadena.
Comenzará solicitando bloques de todos sus pares conectados, repartiendo la carga y asegurando que no abrume sus peticiones a ningún par. El nodo mantiene un registro de cuántos bloques están «en tránsito» por cada conexión de pares, es decir, aquellos bloques que ha solicitado pero que aún no ha recibido, comprobando que no exceden un límite (MAX_BLOCKS_IN_TRANSIT_PER_PEER). De esta manera, si necesita una gran cantidad de bloques, solo solicitará otros nuevos a medida que se completan las solicitudes anteriores, permitiendo a los compañeros controlar el ritmo de las actualizaciones y no sobrecargar la red. A medida que se recibe cada bloque, se va agregando a la cadena de bloques, tal como veremos en el capítulo sobre el blockchain. A medida que la cadena de bloques local se va construyendo gradualmente, se solicitan y se reciben más bloques, y el proceso continúa hasta que el nodo se pone al día con el resto de la red.
Este proceso de comparar la cadena de bloques local con los compañeros y la recuperación de todos los bloques que faltan sucede cada vez que un nodo se desconecta por cualquier período de tiempo. Ya sea un nodo que ha estado desconectado durante unos minutos y faltan pocos bloques, o un mes y faltan unos pocos miles de bloques, se inicia mediante el envío de getblocks, recibe un inv de respuesta, y comienza la descarga de los bloques que faltan.
Figura 6. Nodo sincronizando la cadena de bloques pidiendo bloques a un par