Erlay

Anunciar transacciones es el mayor consumo individual del ancho de banda de un nodo, y el costo crece con cada par que se añade. Gleb Naumenko y Pieter Wuille redactaron el diseño como BIP330, donde sigue siendo un borrador: ninguna versión de Bitcoin Core lo activa. Importa porque decide hasta qué punto puede abaratarse ejecutar su propio nodo.

Cómo funciona

Erlay ataca una redundancia que salta a la vista en cuanto se cuenta: actualmente, un nodo informa a cada uno de sus pares de cada transacción de la que se entera, y la mayoría de esos pares ya la conocía.

El método actual es la inundación. Cada transacción nueva se anuncia en un mensaje inv que lleva un código de tipo y un identificador de 32 bytes, es decir, 36 bytes por anuncio y por par. Bitcoin Core abre por defecto 8 conexiones salientes para la retransmisión de transacciones y acepta pares entrantes hasta un total de 125, así que una máquina bien conectada envía y recibe el mismo mensaje corto decenas de veces por algo de lo que iba a enterarse de todos modos. El desperdicio es proporcional al número de conexiones, lo que penaliza precisamente el comportamiento que hace más difícil dividir la red.

Erlay conserva un poco de la inundación y reemplaza el resto por la reconciliación de conjuntos. En cada conexión entre dos pares, cada lado lleva la cuenta de los anuncios que todavía no ha intercambiado con el otro. Periódicamente, uno de los lados solicita un sketch de ese conjunto. Un sketch es un resumen algebraico de tamaño fijo cuya longitud depende de cuántas diferencias se esperan y no de cuántas transacciones conserva cualquiera de los dos lados, y combinar dos sketches da exactamente los elementos que un par tiene y al otro le faltan. La biblioteca minisketch, que Bitcoin Core lleva años incluyendo en su árbol de código fuente mientras el protocolo de retransmisión que la rodea seguía sin integrarse, implementa la construcción y la decodificación.

Adivinar mal el tamaño del sketch no es fatal. Cuando la decodificación falla porque la diferencia era mayor de lo estimado, los pares amplían el sketch y vuelven a intentarlo en lugar de empezar de cero, así que una mala estimación cuesta un poco más de ancho de banda en lugar de una resincronización completa.

Dónde aparece

Erlay todavía no se ve, y esa es la respuesta honesta para quien lo busque en el panel de un nodo.

Lo que sí se ve es el problema al que apunta. Ejecute la llamada RPC getnettotals en su propio nodo y los contadores de bytes mostrarán que el tráfico de retransmisión domina todo salvo la descarga inicial de la cadena. Los operadores con conexiones con límite de datos ya reaccionan restringiendo la subida con la opción maxuploadtarget o reduciendo el número de pares que mantienen, y ambas decisiones debilitan un poco la red para reducir una factura.

Esa es la disyuntiva que Erlay pretende disolver. Si el ancho de banda dejara de crecer con el número de conexiones, un nodo podría mantener sin riesgo muchos más pares, y una red densamente conectada es mucho más difícil de particionar o de aislar con un ataque de eclipse. Para quien solo quiere verificar sus propias monedas en lugar de confiar en un explorador de bloques, la promesa es acotada y real: la misma verificación con una conexión más barata.

Erlay frente a retransmisión de bloques compactos

Erlay se ocupa de las transacciones antes de que se minen; la retransmisión de bloques compactos, de los bloques una vez minados. Los dos responden a cuellos de botella distintos y se han juzgado con relojes distintos. La propagación de bloques es un problema de latencia, porque cada segundo que un bloque pasa en tránsito es un segundo que algún minero dedica a minar sobre una punta de la cadena que ya no existe, y la solución se publicó en 2016. El anuncio de transacciones es un problema de volumen, que se mide en gigabytes a lo largo de un mes y no en milisegundos, así que nadie ha tenido prisa, y por eso la propuesta lleva años como borrador.