La propagación lenta y la verificación lenta no son el mismo problema
Cuando aparece un nuevo bloque, otros nodos necesitan obtener sus transacciones y verificarlo. Si el mempool de un nodo ya contiene la mayoría de las transacciones, descargarlas todas repetidamente consume ancho de banda innecesario. Los bloques compactos aprovechan esta superposición, enviando primero la información de reconstrucción necesaria. Esto optimiza la propagación de datos, pero no significa que los nodos puedan omitir las comprobaciones de transacciones, ni garantiza transmisiones más rápidas que las transferencias completas en cada ocasión.
Cómo los identificadores cortos ayudan a la reconstrucción
El bloque compacto descrito en BIP152 contiene una cabecera de bloque, un número aleatorio utilizado para generar el identificador corto, transacciones precargadas e identificadores cortos para otras transacciones. El nodo receptor intenta hacer coincidir las transacciones de su mempool local y luego reconstruye el bloque secuencialmente. El identificador corto no es un identificador de transacción completo ni una prueba de saldo; es una pista compacta diseñada para este proceso de propagación y no puede utilizarse de forma independiente para auditar la autenticidad de las transacciones.
¿Qué sucede cuando faltan transacciones locales?
Si al nodo receptor le faltan transacciones, encuentra una ambigüedad de coincidencia o no puede reconstruir el bloque, solicitará la parte faltante a su nodo par. Las políticas de red, las diferencias en el mempool y factores como el inicio reciente de un nodo pueden afectar la tasa de aciertos. Observar un registro de "solicitud para completar transacciones" no debe llevar inmediatamente a la conclusión de que la otra parte es maliciosa o que existe un error de software; es necesario considerar la proporción de transacciones faltantes, la calidad de la conexión y si se completó la verificación posterior.
Ejemplo de proceso de reconstrucción
Supongamos que un nuevo bloque contiene múltiples transacciones y que el nodo ya ha visto la mayoría de ellas en el mempool. Tras recibir el bloque compacto, puede rellenar directamente las posiciones conocidas y descargar las transacciones restantes. Si el nodo acaba de completar la sincronización y el mempool es pequeño, el coste de completar los datos aumentará. Este ejemplo solo explica el mecanismo y no debe considerarse una estadística real de la red, ni puede utilizarse para garantizar el retardo de propagación del pool de minería.
Qué deben observar los operadores de nodos
Registrar la versión del software, el tipo de conexión entre pares, la hora de recepción del bloque, los fallos de reconstrucción y el estado de finalización, y comparar el rendimiento durante los periodos normales y después de un reinicio. Los tiempos de registro también se ven afectados por el reloj local y la red. Los datos de un solo dispositivo no representan la totalidad de la red. Al solucionar problemas, primero verifique la documentación oficial de la versión y la conexión de red, y luego considere los recursos locales. No desactive las verificaciones críticas ni copie configuraciones desconocidas en busca de mayor velocidad.
Cómo evitar malentendidos al leer noticias relacionadas
Al encontrar titulares como "compresión de bloques" o "sincronización de segundo nivel", confirme si el informe se refiere a la propagación de bloques, la sincronización histórica o la finalidad del consenso. Los bloques compactos no reducen los requisitos de verificación de las transacciones en el libro mayor, ni hacen que las transacciones confirmadas sean absolutamente irreorganizables. Guarde la versión de BIP, la implementación del software y el entorno de prueba para compararlos con las conclusiones del autor; las cifras de velocidad sin estas condiciones no deben compararse directamente.