Relé de bloque compactoBIP152, es un método para reducir la cantidad de ancho de banda utilizado para propagar nuevos bloques a nodos completos.
Resumen
Usando técnicas simples es posible reducir la cantidad de ancho de banda necesario para propagar nuevos bloques a nodos completos cuando ya comparten gran parte del mismo contenido de mempool. Los pares envían “bocetos” de bloques compactos a los pares receptores. Estos bocetos incluyen la siguiente información:
- El encabezado de 80 bytes del nuevo bloque.
- Identificadores de transacción abreviados (txids), diseñados para evitar ataques de denegación de servicio (DoS).
- Algunas transacciones completas que el par emisor predice que el par receptor aún no tiene
Luego, el par receptor intenta reconstruir el bloque completo utilizando la información recibida y las transacciones que ya están en su grupo de memoria. Si todavía falta alguna transacción, la solicitará al par transmisor.
La ventaja de este enfoque es que las transacciones solo necesitan enviarse una vez en el mejor de los casos (cuando se transmiten originalmente), lo que proporciona una gran reducción en el ancho de banda general.
Además, la propuesta de relé de bloque compacto también proporciona un segundo modo de operación (llamado modo de ancho de banda alto) donde el nodo receptor pide a algunos de sus pares que envíen nuevos bloques directamente sin pedir permiso primero, lo que puede aumentar el ancho de banda (porque dos pares pueden intentar enviar el mismo bloque al mismo tiempo) pero reduce aún más la cantidad de tiempo. tarda bloques en llegar (latencia) en conexiones de gran ancho de banda.
El siguiente diagrama muestra la forma en que los nodos envían bloques actualmente en comparación con los dos modos de operación del relé de bloque compacto. El cuadro gris en la línea de tiempo del nodo A representa el período en el que realiza la validación.
-
En retransmisión heredada, un bloque es validado (la barra gris) por el Nodo A, quien luego envía un
invmensaje al Nodo B solicitando permiso para enviar el bloque. El nodo B responde con una solicitud (getdata) para el bloque y el Nodo A lo envía. -
En Retransmisión de alto ancho de banda, Usos del nodo B
sendcmpt(1)(enviar compacto) para decirle al Nodo A que quiere recibir bloques lo antes posible. Cuando llega un nuevo bloque, el Nodo A realiza alguna validación básica (como validar el encabezado del bloque) y luego comienza automáticamente a enviar el encabezado, los txids acortados y la transacción perdida prevista (como se describe anteriormente) al Nodo B. El Nodo B intenta reconstruir el bloquear y solicita cualquier transacción que aún falta (getblocktxn), que el Nodo A envía (blocktxn). En segundo plano, ambos nodos completan la validación completa del bloque antes de agregarlo a sus copias locales de la cadena de bloques, manteniendo la misma seguridad total del nodo que antes. -
En Retransmisión de bajo ancho de banda, Usos del nodo B
sendcmpt(0)para decirle al Nodo A que quiere minimizar el uso del ancho de banda tanto como sea posible. Cuando llega un nuevo bloque, el Nodo A lo valida completamente (por lo que no transmite ningún bloque no válido). Luego le pregunta al Nodo B si quiere el bloque (inv) de modo que si el Nodo B ya recibió el bloque de otro par, pueda evitar descargarlo nuevamente. Si el Nodo B quiere el bloque, lo solicita en modo compacto (getdata(CMPCT)) y el Nodo A envía el encabezado, los txids cortos y las transacciones faltantes previstas. El nodo B intenta reconstruir el bloque, solicita cualquier transacción que aún falte y el nodo A envía esas transacciones. Luego, el nodo B valida completamente el bloque normalmente.
¿Cuáles son algunos puntos de referencia útiles para esto?
El nodo receptor puede reconstruir un anuncio de bloque completo promedio de 1 MB con un boceto de bloque de 9 KB, más gastos generales para cada transacción en el bloque que no está en el mempool del nodo receptor. Los bocetos de bloques más grandes vistos alcanzan un máximo de unos pocos bytes al norte de 20 KB.
Cuando se ejecutan experimentos en vivo en modo de “gran ancho de banda” y los nodos completan previamente hasta 6 transacciones, podemos esperar ver más del 90% de los bloques propagarse inmediatamente sin necesidad de solicitar ninguna transacción faltante. Incluso sin completar previamente ninguna transacción, excepto la base de monedas, los experimentos muestran que podemos ver que más del 60% de los bloques se propagan inmediatamente, y el resto requiere un viaje de ida y vuelta de red adicional completo.
Dado que la diferencia entre mempools y bloques para nodos calentados rara vez supera las 6 transacciones, esto significa que la retransmisión de bloques compactos logra una reducción drástica en el ancho de banda máximo requerido.
Para reducir la cantidad de cosas que deben revisarse en la implementación inicial, solo se enviará de forma preventiva la transacción de coinbase.
Sin embargo, en los experimentos descritos, el nodo emisor utilizó una fórmula simple para elegir qué transacciones enviar: cuando el Nodo A recibió un bloque, verificó qué transacciones estaban en el bloque pero no en su mempool; esas fueron las transacciones que predijo que su par no tenía. El razonamiento es que (sin información adicional) las transacciones que usted no conocía probablemente también sean transacciones que sus pares no conocen. Con esta heurística básica se observó una gran mejora, lo que ilustra que muchas veces las soluciones más simples son las mejores.
¿Cómo influye la Fast Relay Network en esto?
La Red de Retransmisión Rápida (FRN) consta de dos partes:
El conjunto de nodos seleccionados en FRN ha sido cuidadosamente elegido con una mínima retransmisión en todo el mundo como prioridad número uno. La falla de estos nodos resultaría en un aumento significativo del poder de hash desperdiciado y una posible mayor centralización de la minería. Una gran mayoría del poder de hash minero actual se conecta a esta red.
El FBRP original es la forma en que los nodos participantes se comunican información de bloque entre sí. Los nodos realizan un seguimiento de las transacciones que se envían entre sí y transmiten diferenciales de bloques basándose en este conocimiento. Este protocolo es casi óptimo para la comunicación uno a uno entre servidor y cliente de nuevos bloques. Más recientemente, se ha implementado un protocolo basado en UDP y corrección de errores de reenvío (FEC), denominado RN-NextGeneration, para que los mineros lo prueben y lo utilicen. Sin embargo, estos protocolos requieren una topología de retransmisión mal conectada y son más frágiles que una red p2p más general. Las mejoras a nivel de protocolo utilizando bloques compactos reducirán la brecha de rendimiento entre la red de nodos seleccionada y la red p2p en general. La mayor solidez de la red p2p y la velocidad de propagación de bloques en general influirán en el desarrollo de la red en el futuro.
¿Esto escala Bitcoin?
Esta característica está destinada a ahorrar ancho de banda de bloque máximo para los nodos, reduciendo los picos de ancho de banda que pueden degradar la experiencia de Internet del usuario final. Sin embargo, las presiones de centralización de la minería existen en gran parte debido a la latencia de la propagación de bloques, como se describe en el siguiente video. La versión 1 de los bloques compactos no está diseñada principalmente para resolver ese problema.
Se espera que los mineros continúen usando Fast Relay Network hasta que se desarrolle una solución de menor latencia o más robusta. Sin embargo, las mejoras al protocolo p2p base aumentarán la robustez en caso de falla de FRN y quizás reducirán la ventaja de las redes de retransmisión privadas, haciendo que no valga la pena ejecutarlas.
Además, los experimentos realizados y los datos recopilados utilizando la primera versión de bloques compactos informarán el diseño de las mejoras futuras que esperamos para ser más competitivos con el FRN.
¿Quién se beneficia de los bloques compactos?
-
Usuarios de nodo completo que desean retransmitir transacciones pero que tienen un ancho de banda de Internet limitado. Si simplemente desea ahorrar la mayor cantidad de ancho de banda posible y al mismo tiempo transmitir bloques a sus pares, existe una
blocksonlyEl modo ya está disponible a partir de Bitcoin Core v0.12. El modo de solo bloques solo recibe transacciones cuando están incluidas en un bloque, por lo que no hay gastos generales de transacción adicionales. -
La red en su conjunto. La disminución de los tiempos de propagación de bloques en la red p2p crea una red más saludable con un mejor margen de seguridad de retransmisión de referencia.
¿Cuál es el cronograma para la codificación, prueba, revisión e implementación de la propagación de bloques compactos?
A la primera versión de bloques compactos se le asignó BIP152, tiene una implementación funcional y la comunidad de desarrolladores la está probando activamente.
¿Cómo se puede adaptar esto para una retransmisión p2p aún más rápida?
Se pueden realizar mejoras adicionales al esquema de bloques compactos. Estos están relacionados con RN-NG y tienen dos vertientes:
-
Primero, reemplace la transmisión TCP de información de bloque con la transmisión UDP.
-
En segundo lugar, maneje los paquetes perdidos y envíe de manera preventiva los datos de transacciones faltantes mediante el uso de códigos de corrección de errores directos (FEC).
La transmisión UDP permite que el servidor envíe datos y el cliente los digiera tan rápido como lo permita la ruta, sin preocuparse por la pérdida intermitente de paquetes. Un cliente preferiría recibir paquetes desordenados para construir el bloque lo más rápido posible, pero TCP no lo permite.
Para gestionar los paquetes descartados y recibir datos de bloques no redundantes de múltiples servidores, se emplearán códigos FEC. Un código FEC es un método para transformar los datos originales en un código redundante, lo que permite una transmisión sin pérdidas siempre que un cierto porcentaje de paquetes llegue a su destino, donde los datos requeridos son sólo un poco más grandes que el tamaño original de los datos.
Esto permitiría a un nodo comenzar a enviar un bloque tan pronto como lo reciba y permitiría a los destinatarios reconstruir los bloques que se transmiten desde varios pares simultáneamente. Todo este trabajo continúa basándose en el trabajo de bloques compactos ya completado. Se trata de una ampliación a medio plazo y el desarrollo está en curso.
¿Es esta idea nueva?
La idea de utilizar filtros de floración (como los utilizados en los bloques filtrados BIP37) para transmitir bloques de manera más eficiente se propuso hace varios años. Pieter Wuille (sipa) también lo implementó en 2013, pero descubrió que los gastos generales ralentizaban la transferencia.
[#bitcoin-dev, public log (excerpts)]
[2013-12-27]
09:12 < sipa> TD: i'm working on bip37-based block propagation
[...]
10:27 < BlueMatt> sipa: bip37 doesnt really make sense for block download, no? why do you want the filtered merkle tree instead of just the hash list (since you know you want all txn anyway)
[...]
15:14 < sipa> BlueMatt: the overhead of bip37 for full match is something like 1 bit per transaction, plus maybe 20 bytes per block or so
15:14 < sipa> over just sending the txid list
[2013-12-28]
00:11 < sipa> BlueMatt: i have a ~working bip37 block download branch, but it's buggy and seems to miss blocks and is very slow
00:15 < sipa> BlueMatt: haven't investigated, but my guess is transactions that a peer assumes we have and doesn't send again
00:15 < sipa> while they already have expired from our relay pool
[...]
00:17 < sipa> if we need to ask for missing transactions, there is an extra roundtrip, which makes it likely slower than full block download for many connections
00:18 < BlueMatt> you also cant request missing txn since they are no longer in mempool [...]
00:21 < gmaxwell> sounds like we really do need a protocol extension for this.
[...] 00:23 < sipa> gmaxwell: i don't see how to do it without extra roundtrip
00:23 < BlueMatt> send a list of txn in your mempool (or bloom filter over them or whatever)!Como se señaló en el extracto, simplemente extender el protocolo para admitir el envío de hashes de transacciones individuales para solicitar transacciones, así como transacciones individuales en bloques, terminó permitiendo que el esquema de bloques compactos fuera mucho más simple, resistente a DoS y más eficiente.
