Uno de los principales argumentos para no aumentar el tamaño del bloque en Bitcoin es el hecho de que un tamaño de bloque más grande significa una propagación más lenta.
La sección que más espacio ocupa del bloque Bitcoin son los datos de las transacciones. Suponiendo que una gran parte de los nodos son nodos completos, existe una gran redundancia en los datos del bloque.
Cuando un minero extrae con éxito un bloque, debe enviarlo a los otros nodos de la red. Muchos de esos nodos ya poseen la mayoría de los datos de transacciones que se incluyen en el bloque.
Tal vez sea mejor enviar un hash de cada transacción en lugar de los datos en sí. En caso de que el nodo receptor no disponga de estos datos, puede solicitarlos al nodo emisor.
Esto podría comprimir el tamaño de un bloque entre 5 y 10 veces (dependiendo del tamaño del hash) y permitir un tamaño de bloque significativamente mayor.
Mi preocupación sería que, en el caso de que el destinatario no tenga todas las transacciones, las solicitudes adicionales para obtenerlas terminarían tomando más tiempo que simplemente enviarlas en primer lugar. Los mineros están dispersos por todo el mundo, pero es probable que puedan pagar por conexiones rápidas, por lo que esperaría que las conexiones entre ellos tuvieran una latencia alta y un ancho de banda alto. En tal caso, es mejor enviar de manera preventiva una mayor cantidad de datos (rápido debido al alto ancho de banda) que arriesgarse a un viaje de ida y vuelta de solicitud/respuesta (lento debido a la alta latencia).
Además, los mineros suelen incluir transacciones que ellos mismos originaron, o que se les enviaron de forma privada, o que no se transmitieron en la red de igual a igual. Considere los pagos del grupo de minería, las transacciones no estándar, las transacciones de bajo costo que el minero acordó "acelerar", etc. Por lo tanto, creo que este protocolo de solicitud adicional sería necesario la mayoría de las veces.
Esta podría ser una optimización razonable para nodos completos que no son mineros y, por lo tanto, no necesitan recibir el bloque con urgencia. Podrían ahorrar algo de ancho de banda de esta manera. Pero por otro lado, dado que no necesitan recibir el bloque con urgencia, no nos preocupamos tanto por ellos, y es difícil justificar un cambio de protocolo p2p importante solo por esto.
No estoy seguro de cómo esto no se respondió de manera más completa anteriormente.
Bitcoin no ha enviado el bloque completo como método de propagación principal desde hace un par de años, consulte BIP 152 . Lo que se envía es el encabezado del bloque, 6 bytes por transacción y la transacción de la base de monedas. Opcionalmente, se pueden enviar transacciones adicionales que el remitente predijo que el receptor no conocería.
El hash muy corto es posible porque cada nodo transmisor salta claramente el hash. Esto hace que sea imposible que un atacante cree colisiones intencionalmente, y cualquier colisión que ocurra por casualidad se 'enruta' en la propagación de la red en virtud del hecho de que los bloques simplemente fluyen más rápido en los enlaces donde no hubo una colisión.
Debido a que este mensaje es tan pequeño, BIP152 puede eliminar con frecuencia un viaje de ida y vuelta al no realizar un INV. Por lo tanto, el hecho de que a veces se necesite un viaje de ida y vuelta adicional para completar las transacciones faltantes solo lo deja con la misma cantidad de viajes de ida y vuelta que el protocolo original.
También hay fibra que reduce incondicionalmente la transmisión a 0,5 viajes de ida y vuelta, pero a costa de desperdiciar una cantidad considerable de ancho de banda. Para enlaces rápidos, esto es lo más rápido que se puede hacer.
En lo que respecta a la seguridad y la estabilidad de la red, no se trata solo de qué tan lenta es la propagación en promedio, sino qué tan lenta puede ser hecha por un minero en el primer caso. BIP152 hace un gran trabajo en promedio, pero en realidad no mejora el peor de los casos Además, la cantidad de datos en un bloque también controla la cantidad de datos fuera de los bloques, como mucho, los bloques compactos solo pueden reducir el ancho de banda total de un nodo a la mitad del esquema original.
El diseño de BIP152 se seleccionó como una compensación entre muchos factores: latencia, ancho de banda, carga computacional, complejidad de implementación. La fibra representa una compensación diferente (que favorece el retraso absoluto más bajo en lugar de menos ancho de banda). Sabemos cómo reducir los bloques a unos 500 bytes por lo general, con una implementación y un cálculo considerablemente más complejos, pero no parece que haya muchas razones para hacerlo en relación con la importancia de mejorar otras áreas del protocolo. Esto es doblemente cierto porque estas mejoras no ayudan en el peor de los casos. Creo que FIBER ya se acerca mucho al mejor rendimiento posible en el peor de los casos.