¿Cuánto tiempo lleva la validación de bloques?

Hay varias preguntas aquí.

Corríjame si me equivoco: el minero valida el bloque recién recibido antes de usarlo y enviarlo a sus otros pares conectados.

Si y no. Tenga en cuenta que por minero estamos hablando de personas que construyen bloques ellos mismos, eso incluye mineros en solitario, operadores de grupos y usuarios de p2pool. Los hashers que solo se conectan a un grupo y realizan trabajo no forman parte de ese grupo.

Los mineros pueden, ya veces lo hacen, construir un nuevo bloque antes de que hayan procesado por completo el anterior (incluso si es propio), para evitar que el tiempo no se extraiga. Desafortunadamente, como aún no saben qué UTXO se gastan en el bloque recién recibido, no saben qué transacciones de seguimiento son válidas y, por lo tanto, no pueden incluir ninguna transacción nueva. Debido a esto, estos bloques estarán vacíos aparte de la base de monedas.

En la práctica, estos mineros tendrán dos mecanismos para actualizar el bloque propuesto que sus hashers están procesando:

1. Se anuncia un nuevo mejor hash de bloque dentro de su propia red (o se detecta en la red de otro grupo, por ejemplo, escuchando la interfaz de su grupo o mediante un acuerdo para enviarse información). Cuando esto sucede, se les dice a todos los hashers que comiencen a trabajar en un bloque vacío.
2. Se recibe un nuevo bloque a través de ellos bitcoind(a través del protocolo P2P, a través del submitblockcomando RPC para sus bloques o a través de redes de retransmisión separadas como FIBER ). bitcoindluego construye un nuevo conjunto de transacciones válidas en la parte superior (a través del getblocktemplateRPC), y actualizan sus hashers para comenzar a trabajar en un bloque con estos bloques.

La suposición es que cuando sucede (1), el mismo bloque pasará rápidamente por (2), y cambiaremos de trabajar en un bloque vacío en la parte superior a un bloque normal en la parte superior. Hubo una vez un incidente en el que esto no sucedió.

Cuando BIP66 se activó, algunos mineros que ejecutaban bitcoindversiones habilitadas para BIP66 estaban escuchando bloques enviados por grupos anteriores a BIP66. Un minero anterior a BIP66 produjo un bloque no compatible con BIP66 (números de versión incorrectos) y los mineros habilitados para BIP66 escucharon y comenzaron a producir bloques vacíos en la parte superior. Por supuesto, bitcoindnunca aceptaron el bloque completo ya que no era válido de acuerdo con las nuevas reglas, reglas que los mismos mineros acordaron. El resultado fue una secuencia de muchos bloques vacíos en la parte superior, con muchos mineros construyendo encima de los bloques no válidos anteriores, todos los cuales no fueron aceptados por la red.

Así que para responder a tu pregunta:

Entonces, ¿por qué mantener la minería encima del bloque anterior?

Porque el nuevo puede no ser válido. Es poco probable que suceda intencionalmente debido a los costos de extraer un bloque no válido, pero puede suceder como resultado de errores de software o manuales. Además, no debemos construir una infraestructura que dependa de que esto no suceda, ya que hacerlo podría abaratar con el tiempo tales ataques.

¿Cuánto suele tardar este proceso? ¿De qué depende?

En su proceso, solo está contando la validación de bloques. Pero todo el proceso consiste en todo entre (A) la creación de un bloque válido en la red y (B) los hashers que cambian para construir un bloque encima. Esto incluye:

• El creador del bloque anterior sacando el bloque a la red . Puede haber retrasos no intencionales aquí, o incluso retrasos intencionales (como un ataque de minería egoísta).

• Los bloques deben propagarse a través de la red . Los nodos normales bitcoindsolo se propagan después de una validación completa y requieren ráfagas de gran ancho de banda para transferir todos los bloques. La tecnología más reciente, como los bloques compactos (BIP152) y FIBER, evitan el reenvío completo o incluso la espera hasta que se complete la validación.

• Los bloques necesitan ser validados .

• Se debe crear un nuevo conjunto de transacciones válidas en la parte superior .

La validación depende de muchos factores:

• Versión de software . Hay mejoras constantes en la velocidad de validación.
• Tamaño de caché UTXO . Cuanto mayor sea la memoria caché, menos acceso a la base de datos se necesita para recuperar información sobre los productos que se gastan. Como resultado, solo obtener entradas puede llevar desde unos pocos milisegundos hasta unos pocos segundos.
• Tamaño de la caché de firmas y velocidad de la CPU . Cuanto mayor sea la memoria caché, más validaciones de firmas se pueden evitar. Estas validaciones, según la versión del software y el hardware, varían de 0,01 ms a 0,6 ms por firma (45 ms a 2,7 s por bloque).
• Correlación entre el pool de memoria y el nuevo bloque . Si un bloque contiene transacciones que un nodo no ha visto antes, es menos probable que sus entradas y firmas se almacenen en caché antes.
• ancho de banda Antes de Bitcoin Core 0.13, los bloques siempre se enviaban en su totalidad entre pares, lo que puede causar grandes picos en el momento en que se anuncia un nuevo bloque.
• Latencia de red . En partes más aisladas del mundo, incluso con un buen ancho de banda, el tiempo que tarda un paquete de red en llegar al mundo exterior puede ser significativo. Según el protocolo, se necesitan de 1 a 3 viajes de ida y vuelta para enviar un bloque. Si la latencia entre dos pares es de 200 ms, eso ya puede significar 1,2 s desperdiciados en ir y venir.
• Número de conexiones . Si un nodo tiene muchas conexiones, intentará transmitir un nuevo bloque simultáneamente a todos, lo que provocará un aumento en el trabajo de la actividad de la red. Esto puede ser demasiado para la CPU, el hardware de la red o el ancho de banda, lo que provoca ralentizaciones cuando existen muchas conexiones.

El tiempo para construir un nuevo bloque depende principalmente de la versión del software. En versiones anteriores era de unos pocos segundos, pero últimamente se ha reducido a decenas de milisegundos.

¿Se hace en hardware de minería especializado o en una CPU de propósito general?

Que yo sepa, no existe ningún hardware personalizado para la validación o construcción de bloques.

¿Es correcto que el tiempo que toma la validación del bloque sea lineal con el tamaño del bloque + testigo si segwit se activa?

Principalmente. Existe una ineficiencia en el algoritmo hash de firma actual que puede ser O(n^2) en el tamaño de las transacciones. Esto puede resultar en transacciones individuales que toman minutos para calcular el hash de la firma. Esto se solucionó en BIP144, que siempre se usa dentro de las entradas de transacciones de SegWit, lo que lo convierte en O (n) en el peor de los casos (menos de 10 ms por bloque en el peor de los casos en hardware común).

A más largo plazo, hay otros factores que juegan, como el tamaño del conjunto UTXO. Si esto creciera a varios gigabytes y no encajara en los cachés de memoria típicos, el tiempo de recuperación de UTXO para la validación podría aumentar drásticamente.

Además: ¿Cuánto tiempo se tarda en promedio para que un bloque se propague a través de la red? Sería genial si ese promedio se ponderara en los poderes de hashing de los mineros receptores.

Eso es complicado. Ciertamente, no es proporcional a la velocidad de hashing, sino que está más relacionado con la topología de la red y la tecnología utilizada. El sitio web de FIBER tiene algunas estadísticas, pero a menudo transfiere en menos de 20 ms más que la latencia de red teórica mínima (velocidad de la luz en conexiones largas) en todo el mundo. Esto solo es posible siendo una red privada que asume que sus participantes no participarán en ataques DoS en la red. La red pública es mucho más robusta, pero a menudo tarda muchos segundos en propagar un bloque a una gran parte de los nodos y decenas de segundos en llegar a los nodos menos conectados.

Creo que todos los grandes mineros tienen su propio software desarrollado para administrar el proceso de minería y pueden cambiar al encabezado de bloque recibido recientemente antes de que se complete la validación. El proceso de validación del bloque no debería llevar mucho tiempo, porque la mayoría de las transacciones del bloque ya están en mempool y ya están verificadas. La tarea de validación es verificar transacciones perdidas, verificar coinbase, verificar recompensa de bloque, verificar merkleroot. Por lo tanto, la validación de bloques debería completarse en unos segundos. Bloque a propagar a través de la red, depende de la velocidad de conexión.

Como se indicó anteriormente, muchos mineros hoy en día ya comienzan a minar usando solo el nuevo blockheader antes de que el bloque sea validado y descargado.

Esta es la razón por la que a veces ves un bloque recién generado con una sola transacción (la transacción coinbase). Un ejemplo de esto es el siguiente bloque: https://blockchain.info/block/00000000000000000a06dbd18a15a452c4dd50f662044e654f83066da2775ed8

Esto se debe a que el minero no sabe exactamente qué transacciones se incluyeron en el bloque anterior antes de descargarlo y validarlo. Debido a esto, solo incluye la transacción de coinbase hasta que se haya actualizado el mempool para evitar incluir una transacción que ya se haya incluido en el último bloque.