Full Node

Imagina que la cartera muestra un pago recibido. ¿Cómo sabe que la transacción pertenece realmente al historial de Bitcoin y cumple las reglas? Puede preguntar a un servidor ajeno o usar tu nodo. Un Full Node hace posible la segunda opción: comprueba por sí mismo la validez de los datos recibidos. No pregunta a la mayoría de los ordenadores conectados cómo debe decidir. Si alguien le envía un bloque contrario a las reglas, lo rechaza. Por tanto, más conexiones no sustituyen la comprobación. Tu nodo te permite verificar los datos en los que basas tus pagos. [1] [3]

El nodo comprueba cómo se enlazan los bloques, sus cabeceras y Proof of Work, la prueba de cálculo exigida para cada bloque. En las transacciones verifica, entre otras cosas, que hagan referencia a fondos existentes, que no se gasten dos veces y que se cumplan las condiciones para usarlos. Estas condiciones se escriben en scripts, pequeños conjuntos de reglas programadas. También controla cuántos bitcoins nuevos se crean. El resultado actualizado es el UTXO set, el conjunto de salidas de transacciones no gastadas: un registro de los fondos concretos que siguen disponibles. Más trabajo acumulado puede decidir entre dos ramas válidas, pero no convertir un bloque inválido en válido. [1]

No. Un Full Node verifica bloques y transacciones; la comprobación ordinaria por sí sola no recibe una recompensa de bloque. El minero, en cambio, prepara una propuesta de bloque y repite cálculos hasta encontrar un resultado que cumpla la condición. Utiliza un hash, la huella digital de la cabecera. Ambas funciones pueden colaborar: el minero necesita saber qué historial continúa y qué transacciones puede incluir. Eso no significa que cada nodo deba minar. Verificar y competir por encontrar el siguiente bloque son actividades diferentes. [5] [1]

Un nodo nuevo necesita ponerse al día con el historial de la red. Descarga bloques y procesa sus datos: es la sincronización inicial. Hay que distinguir dos posibles aceleraciones avanzadas. Bajo ciertas condiciones, assumevalid permite que Bitcoin Core omita antiguas comprobaciones de scripts; assumevalid=0 desactiva esa optimización. AssumeUTXO permite cargar un snapshot, un estado guardado de los fondos no gastados en un bloque concreto, cuya huella se compara con un valor incluido en el código fuente. Después verifica el historial anterior en segundo plano. Poder trabajar con el estado actual no significa, por sí solo, que la comprobación histórica haya terminado. [1] [2]

Un Full Node no necesita conservar todos los archivos de bloques antiguos para siempre. Pruning elimina parte de ellos después de procesarlos, pero mantiene el UTXO set actual y los datos recientes necesarios. El nodo sigue verificando los bloques nuevos. Un nodo de archivo conserva los antiguos y puede proporcionarlos a otros o examinarlos de nuevo. Ahorrar disco no equivale, por tanto, a ser un cliente SPV, que usa verificación simplificada de pagos. Ese cliente no comprueba todas las transacciones ni su estado como un Full Node. La diferencia está en lo que verificas, no solo en cuántos archivos guardas. [3]

En una sincronización normal, un nodo podado descarga y procesa los bloques históricos antes de poder eliminarlos progresivamente. Pruning no es un interruptor para saltarse su verificación: su función es ahorrar almacenamiento. Las optimizaciones anteriores son otra cuestión. assumevalid puede omitir comprobaciones antiguas de scripts bajo ciertas condiciones, y AssumeUTXO permite usar un snapshot mientras sigue la verificación histórica. Para saber si tu nodo está preparado, comprueba el método de sincronización y su progreso real, no solo el tamaño de sus datos en el disco. [3] [2]

La cartera necesita información sobre transacciones y confirmaciones. Si la obtiene de un servidor ajeno, le envía consultas de las que ese servidor puede deducir información sobre sus pagos. Conectarla a tu Full Node permite usar datos verificados por él y evitar esas consultas al servidor externo. Sin embargo, instalar e iniciar el nodo no cambia automáticamente la conexión de la cartera. Importa qué fuente de datos admite y utiliza realmente. Tener tu nodo tampoco garantiza anonimato: la privacidad depende de otros datos de red y de cómo uses la cartera. [3] [4]

El nodo puede funcionar sin tus claves privadas. Las claves permiten firmar pagos; el nodo comprueba si transacciones y bloques cumplen las reglas. Un mismo dispositivo no tiene por qué encargarse de ambas tareas. Por eso, además de comprobar que tu nodo esté funcionando, averigua de dónde obtiene datos la cartera y cómo difunde sus transacciones. La verificación propia no sustituye una copia segura de las claves ni elimina toda la información que pueden revelar las comunicaciones. Ayuda en una parte concreta del proceso: comprobar los datos de Bitcoin de forma independiente. [3] [4]

El nodo tiene dos interfaces diferentes. Las conexiones P2P intercambian bloques y transacciones con otros nodos. RPC es la interfaz con la que las aplicaciones le dan órdenes y pueden, en su caso, controlar también su cartera. Abrir un puerto P2P entrante para intercambiar datos es distinto de exponer RPC a desconocidos. Bitcoin Core recomienda no exponer RPC directamente al internet público. Para el acceso local normalmente usa credenciales guardadas en un archivo .cookie, que acreditan la autorización de la aplicación. No es una cookie de seguimiento del navegador. [4]

Los comandos permiten comprobar más que un icono verde. En getblockchaininfo revisa la red correcta, blocks para los bloques procesados, headers para las cabeceras conocidas e initialblockdownload para el estado de la sincronización inicial. Si usas un snapshot, getchainstates ayuda a distinguir el estado actual de la verificación histórica en segundo plano. El número de conexiones no prueba una comprobación completa. Finalmente, verifica que el nodo no se haya quedado en una punta antigua de la cadena y que tu cartera obtenga realmente sus datos de él. Solo entonces su comprobación independiente beneficia al uso de tu cartera. [2] [1]