Stale Rate es la proporción de resultados o de trabajo ponderado clasificados como desactualizados. En la minería de Bitcoin mediante un pool suele referirse a shares: pruebas parciales de cálculo que ya no corresponden al trabajo vigente. Su definición precisa y su efecto en las recompensas dependen del sistema observado.
Un pool es un servicio que reparte trabajo entre mineros. Cuando la red encuentra un bloque nuevo, normalmente deben empezar a construir sobre él. Un resultado calculado con el encargo anterior ya no sirve para el nuevo. Stratum V2, un protocolo de comunicación entre equipos de minería, lo gestiona mediante SetNewPrevHash: el equipo empieza a buscar un bloque que continúe a partir del bloque recién indicado. Entre los encargos preparados previamente, solo sigue siendo válido el señalado por el identificador de trabajo job_id. Por eso Petra comprueba la vigencia del trabajo, no solo cuándo se envió el resultado. [1]
En un ejemplo sencillo, Petra entrega 100 resultados de igual dificultad. El pool acepta 98, rechaza 1 como stale y 1 por otro motivo. Los stale rechazados representan el 1%; todos los rechazos juntos, el 2%. F2Pool llama rejection rate a la proporción de todos los envíos rechazados sobre el total de envíos. En nuestro ejemplo, stale es solo una parte. Las cifras explican el cálculo, no un umbral operativo aceptable; una clasificación diferente puede dar otro significado al panel. [2]
La dificultad de una share determina lo exigente que debe ser el resultado presentado. Braiins contabiliza un resultado de dificultad d como d unidades básicas de trabajo. Imaginemos una share stale de dificultad 1 y una aceptada de dificultad 9. Contando envíos obtenemos el 50%; ponderando el trabajo, el 10%. Ningún cálculo es incorrecto por sí mismo, pero responden a preguntas distintas. Por ello, Petra usa la misma unidad en ambas partes de la fracción y comprueba que se emplee la misma convención de dificultad. [3]
La documentación de F2Pool distingue la categoría Staled, que genera recompensas, de las stale shares rechazadas, que no las generan. La etiqueta no basta para saber si Petra ha perdido dinero. Esta política no puede extrapolarse a todos los pools: importan las reglas del servicio concreto y la liquidación real. Al comparar proveedores, Petra averigua primero a qué categoría pertenecen los resultados. Solo entonces puede estimar su efecto en los ingresos. [2]
Al leer un registro operativo es fácil pasar por alto que Stratum V2 puede confirmar varios envíos con un solo mensaje SubmitShares.Success. El campo new_submits_accepted_count indica cuántos se acaban de confirmar, mientras que new_shares_sum suma sus dificultades. Contar respuestas del servidor no equivale, por tanto, a contar shares aceptadas. En un rechazo, SubmitShares.Error incluye sequence_number, el identificador del envío, y error_code, el motivo del error. Sin distinguirlos, Petra podría confundir cualquier fallo con trabajo tardío. [1]
La noticia de un bloque nuevo debe recorrer primero los ordenadores que verifican Bitcoin. BIP152 describe Compact Block Relay, una transmisión de bloques que consume menos datos entre nodos de la red P2P, es decir, participantes conectados directamente. Un menor volumen de datos puede reducir el retraso de transmisión. Sin embargo, se trata de propagar bloques, no de contabilizar shares en un pool. La proporción de bloques que quedan fuera de la cadena principal no mide los resultados tardíos del equipo de Petra. [4]
Braiins ofrece estadísticas del trabajo para distintos periodos: shares_5m (últimos 5 minutos), shares_60m (últimos 60 minutos) y shares_24h (últimas 24 horas). Petra no puede dividir los resultados tardíos de un intervalo corto por el trabajo de todo un día y compararlo con la estadística horaria de otro equipo. Ambas partes del cálculo deben abarcar el mismo periodo y los mismos dispositivos. Si no se observó ningún envío, la proporción no está definida: no es una pérdida medida del 0%. Tampoco un vacío en el seguimiento o una respuesta ausente demuestran por sí solos que el resultado fuera stale. [5]
Petra empieza por los cambios de trabajo, los motivos de rechazo y las condiciones de conexión durante el mismo periodo. F2Pool relaciona los resultados stale con las condiciones de la red. Otros rechazos pueden deberse a fallos del firmware, el software que controla el equipo, o a un overclocking excesivo: aumentar la frecuencia de funcionamiento de los chips para intentar realizar más cálculos. Braiins recomienda ping, una prueba sencilla para comprobar si el servidor responde a consultas de red. Una respuesta correcta no confirma que la minería funcione bien ni que se haya abonado la recompensa. Un porcentaje total menor no demuestra por sí solo que se haya eliminado la causa. Se trata de entender qué cambió y seguir el error concreto en condiciones comparables. [2] [6]
Para obtener la imagen más completa, lee esta entrada junto con Mining Share, Share Difficulty, Mining Latency, Pool Fee, Bitcoin. También enlazan con esta entrada Stale Block, Mining Latency.