Chisme peer-to-peer

Curiosidad

1. ¿Cómo encuentra un nodo nuevo en una red vacía a su primer par?
2. ¿Cómo llega un nuevo bloque a miles de nodos en cuestión de segundos sin que nadie lo coordine?
3. ¿Qué impide que un atacante aísle un nodo del resto de la red?

Explorar

1. Bitcoin funciona como una red descentralizada punto a punto en la que cada nodo completo mantiene un estado independiente. Para unirse, un nuevo nodo debe establecer conexiones TCP con los nodos existentes. La red principal utiliza el puerto 8333 para estas conexiones. El descubrimiento inicial se basa en semillas DNS, gestionadas por miembros antiguos de la comunidad y listadas en el software, además de direcciones de respaldo codificadas directamente. Una vez conectado, un nodo puede solicitar direcciones mediante ‘getaddr’ y recibirlas en mensajes ‘addr’, lo que le permite conocer a otros participantes activos y ampliar dinámicamente su conjunto de nodos asociados.
2. Bitcoin Core gestiona una topología específica: 8 conexiones de retransmisión completa salientes para la propagación de transacciones y bloques, además de 2 conexiones exclusivas para retransmisión de bloques con el fin de reducir el uso de ancho de banda. Permite un total de hasta 125 conexiones, tanto entrantes como salientes. Esta estructura garantiza la redundancia; si un nodo se desconecta o deja de responder, el nodo mantiene la conectividad a través de los demás. Las conexiones exclusivas para retransmisión de bloques no transportan transacciones ni direcciones, lo que dificulta que un observador pueda mapear la topología de la red.
3. La propagación de datos sigue un mecanismo de anuncio. Cuando un nodo recibe una nueva transacción, la anuncia mediante un mensaje ‘inv’ (inventario) que contiene el hash pero no los datos; actualmente, los nuevos bloques suelen anunciarse enviando directamente el encabezado o un bloque compacto. Los pares receptores de este anuncio reconocen que carecen del objeto y envían una solicitud ‘getdata’. El holder original transmite entonces la carga útil completa. Este proceso de dos pasos evita saturar la red con cargas útiles grandes y redundantes antes de que los pares confirmen su interés, lo que garantiza un uso eficiente del ancho de banda en todo el sistema distribuido.
4. Los bloques compactos (BIP152), introducidos en 2016, optimizan aún más este proceso. Dado que la mayoría de las transacciones en un bloque ya son conocidas por los nodos a través de la propagación desde el mempool, enviar el bloque completo es un desperdicio. En lugar de eso, un nodo envía el encabezado del bloque junto con identificadores cortos (6 bytes cada uno) para sus transacciones, además de la coinbase; el receptor reconstruye el bloque a partir de su propio mempool y solicita únicamente las pocas transacciones que le faltan. Esto reduce significativamente la latencia en la propagación de los bloques, permitiendo que la red alcance el consenso más rápidamente incluso con altos volúmenes de transacciones.
5. Los ataques de eclipse demuestran la fragilidad de la diversidad entre nodos. Heilman y colaboradores (2015) mostraron que un atacante que se apodera de todas las conexiones de un nodo puede aislarlo de la red honesta, proporcionándole una visión falsa de la cadena. Bitcoin Core adoptó sus contramedidas a partir de la versión 0.10.1, incluyendo conexiones auxiliares y un proceso más cuidadoso para eliminar direcciones de la tabla de direcciones; posteriormente se añadieron conexiones de anclaje que persisten tras los reinicios. Ejecutar el nodo únicamente a través de Tor puede hacer que sea más fácil, no más difícil, someterlo a ataques de eclipse.
6. Verifique la conectividad de su nodo ejecutando ‘bitcoin-cli getpeerinfo’ en una terminal conectada a una instancia local de Bitcoin Core. La salida muestra la dirección de cada peer, su ‘connection_type’ (por ejemplo, outbound-full-relay o block-relay-only), su versión del software y el grado de sincronización alcanzado ('synced_headers', 'synced_blocks'). Un nodo en buen estado muestra unas diez conexiones salientes: ocho de tipo full-relay y dos de tipo block-relay-only.

Datos clave

Ejercicio nueve, seis, tres, uno

Verificación de hechos

Fechas, cifras y afirmaciones verificadas con las fuentes publicadas que se enumeran a continuación.

• Bitcoin Developer Guide, 'P2P Network' section
• Heilman et al., 'Eclipse Attacks on Bitcoin's Peer-to-Peer Network' (USENIX Security 2015)
• BIP152: Compact Block Relay