Compact Blocks permite transmitir bloques de Bitcoin según BIP 152 repitiendo menos datos. No reduce el bloque ni relaja sus reglas: quien lo recibe debe recuperar el contenido completo y verificarlo antes de aceptarlo.
Ana quiere enviar un bloque nuevo a Pedro, pero él ya tiene muchas de sus transacciones. Un bloque agrupa transacciones en un lote que se añade al historial compartido. Enviarlas todas sería repetir información. El mecanismo Compact Blocks entrega la cabecera y una lista de etiquetas cortas para localizar las transacciones conocidas. La cabecera es una parte breve del bloque con datos básicos, entre ellos una referencia al bloque anterior y una huella de las transacciones. Para lectores técnicos: las etiquetas tienen 48 bits, es decir, 6 bytes, y se obtienen recortando el resultado de la función SipHash-2-4. Sus parámetros se derivan de la cabecera y de un número adicional para esta transmisión, llamado nonce. La etiqueta no es un nombre permanente de la transacción para toda la red Bitcoin. [1] [2] [7]
Una lista no puede sustituirlo todo. Ana envía ciertas transacciones completas con su posición en el bloque. El ejemplo habitual es la Coinbase Transaction, la primera transacción del bloque, que asigna la recompensa minera; no tiene relación con la plataforma del mismo nombre. Se crea para ese bloque concreto, así que Pedro normalmente no la tiene entre sus transacciones pendientes. Las entradas completas y las etiquetas se complementan durante la reconstrucción. [1] [2]
El Mempool de Pedro es su colección local de transacciones conocidas que aún no se han confirmado en la cadena aceptada. Calcula las mismas etiquetas cortas para las transacciones disponibles y busca coincidencias con la lista de Ana. No da por hecho que todos tengan la misma colección. Como una etiqueta puede corresponder ocasionalmente a varias transacciones, la coincidencia no es una prueba definitiva de que el contenido sea correcto. [1] [2]
Si quedan posiciones vacías o ambiguas, Pedro solicita las transacciones por su posición. El mensaje de petición se llama getblocktxn y la respuesta que lleva las transacciones, blocktxn. No hace falta memorizar esos nombres: lo importante es pedir datos reales, no adivinar el contenido. Otro viaje de ida y vuelta por la red añade tiempo. Si no puede reconstruirse, se puede descargar el bloque completo. [1] [3]
Pedro debe recuperar exactamente las transacciones en su orden correcto y comprobar su vínculo con la cabecera. Merkle Tree es una estructura que resume las transacciones en una huella de comprobación y ayuda a verificar ese vínculo. Pero montarlas bien no sustituye la revisión de las reglas. Un Full Node es un programa con el que Pedro comprueba por sí mismo las reglas de Bitcoin, como la autorización para gastar fondos y el importe de la recompensa. Una firma digital acredita la autorización de un pago mediante una clave privada, un valor numérico secreto, sin revelar esa clave. La transmisión compacta no concede excepciones a bloques inválidos. [1] [8]
Los nodos vecinos acuerdan el modo mediante sendcmpct. En la opción rápida, el mensaje cmpctblock, con los datos de reconstrucción, anuncia directamente el bloque. Tras las comprobaciones preliminares exigidas, el emisor puede empezar a transmitir antes de finalizar todos los controles de las transacciones. Debe comprobar, entre otras cosas, el enlace con la cadena validada, Proof of Work como prueba del trabajo de cálculo y el vínculo de la cabecera con las transacciones. El receptor verifica igualmente todo el bloque antes de aceptarlo en su historial. [1] [4]
La otra opción anuncia primero un bloque ya validado mediante inv o headers. Pedro solicita después los datos compactos si los necesita. Así puede evitar un envío innecesario de un bloque que ya recibió por otra vía, a cambio de un paso más de comunicación. Ambos modos pueden ahorrar frente a reenviar todas las transacciones; cambian el momento del envío y la necesidad de pedirlo antes. No son dos niveles distintos de validez. [1] [7]
Dos transacciones diferentes pueden tener la misma etiqueta corta. Eso se llama colisión. Es como dos personas con las mismas iniciales: la abreviatura ya no basta para distinguirlas. Según dónde surja el problema, el programa pide datos adicionales o recurre al bloque completo. Una colisión no rompe las firmas de Bitcoin ni convierte un bloque inválido en válido. Hay que comprobar el contenido real, no solo que coincidan etiquetas. [1] [2]
La versión 2 del protocolo compacto admite SegWit, que separa firmas y otros datos de verificación en la parte witness. Utiliza wtxid, un identificador que incluye esos datos, en lugar de txid, que no los incluye. Las transacciones completas se transmiten con los datos witness necesarios según BIP 144. No se descartan para aparentar un envío menor. Además, la versión del protocolo de transmisión no es el número de versión del bloque. [1] [6]
Si Ana y Pedro conocen muchas transacciones en común, el bloque circula con muchos menos datos repetidos. Eso también ayuda a una conexión doméstica ante la llegada repentina de un bloque. Si comparten pocas transacciones, aumentan las peticiones y se reduce el ahorro. El objetivo principal es ahorrar datos transmitidos; una entrega más rápida es un posible beneficio, no una garantía de espera nula ni de tamaño fijo del mensaje. Esto no introduce un nuevo límite de tamaño de bloque en Bitcoin. [5] [7]
Para obtener la imagen más completa, lee esta entrada junto con Block Propagation, Initial Block Download, Eclipse Attack, vByte, Bitcoin, Transacción coinbase. También enlazan con esta entrada Stale Block, Eclipse Attack, Selfish Mining, Block Propagation.