El effort del pool explicado:
por qué solo sube

Empiece aquí: shares, rondas y bloques

Para entender el effort, primero necesita tres palabras. Mantendremos esta parte libre de jerga.

Un bloque es lo que el pool intenta encontrar. Encontrarlo significa descubrir un número (un hash) por debajo del objetivo de la red — y ese objetivo está fijado de modo que, en toda la red global, aparezca un bloque cada pocos minutos. Para cualquier máquina individual, encontrar un bloque entero directamente tardaría, en promedio, de años a siglos. Sencillamente nunca ocurriría en un plazo útil.

Por eso los pools no le piden encontrar bloques enteros. Le piden shares. Un share es una versión mucho más fácil del mismo rompecabezas — un "casi acierto" que demuestra que está trabajando de verdad. El pool fija la dificultad del share para cada minero (esto es vardiff, que ajusta la dificultad a su hardware), recoge los shares de todos, y de vez en cuando uno de esos shares resulta también superar el objetivo completo de la red. Ese share es el bloque.

Una ronda es el tramo de trabajo entre un bloque y el siguiente. Se abre en el instante en que se encuentra un bloque y se cierra cuando se encuentra el siguiente. Todo lo que el pool acumula entremedias pertenece a esa ronda.

Qué mide realmente el effort

Ahora la definición, en una línea:

Effort % = Σ ( dificultad del share / dificultad de red cuando ese share fue enviado ) × 100

Es una suma, no una instantánea. Cada share aceptado aporta su propia dificultad dividida entre la dificultad de red en el momento en que fue encontrado (un share de dificultad 16 cuenta dieciséis veces un share de dificultad 1, por eso vardiff no distorsiona el effort). Una vez que un share se cuenta, su aportación queda fijada para siempre — un cambio posterior de dificultad no puede reescribirla. Como cada término es positivo, el total solo puede crecer a medida que avanza la ronda.

Así que el effort es una barra de progreso en vivo hacia el bloque actual. En el mismo momento en que se encuentra un bloque, esa lectura final de effort es la suerte de la ronda: un bloque que aterriza con 55% de effort fue un bloque afortunado y barato; uno que solo aterriza tras 220% de effort fue caro y desafortunado. El effort es el indicador durante la ronda; la suerte es el número en que quedó congelado cuando la ronda terminó.

La parte que confunde a todos: el effort solo sube

Aquí está el malentendido que llena nuestro Discord. Un minero ve el effort subir hasta 65%, se va a por un café, vuelve, y marca 45%. No se encontró ningún bloque, sus shares siguen todos ahí — y tiene razón en molestarse, porque el effort correcto nunca debería haber caído.

Lo que ocurrió es que la dificultad de red hizo retarget hacia arriba mientras estaba fuera, y el panel dividió todos sus shares acumulados entre la nueva dificultad, más alta. Ese es el atajo ingenuo — y es incorrecto. El trabajo que representa ese 65% se realizó de verdad; un cambio en la dificultad de hoy no puede llegar hacia atrás en el tiempo y deshacerlo. (Toda blockchain reajusta la dificultad para mantener los tiempos de bloque en su horario — algunas en cada bloque — pero eso solo fija el ritmo para los shares futuros.)

Hecho correctamente, cada share se valora contra la dificultad que estaba vigente cuando fue enviado. Una subida posterior de dificultad solo cambia lo que valen los shares nuevos — hace que el effort suba más lentamente a partir de ese punto, pero el effort ya ganado se queda quieto:

// 650 unidades de effort ganadas mientras dificultad = 1000
Ganado:  650 / 1000              = 65%   // registrado; no puede cambiar

// la dificultad sube ahora a 1444.  Contabilidad CORRECTA:
Sigue   65%, luego cada NUEVO share suma dificultad/1444  // sube más lento, nunca cae

// El panel INGENUO (incorrecto) revalora TODO el trabajo pasado a 1444:
Muestra:  650 / 1444              = 45%   // "caída" espuria — un error

El pool no perdió sus shares — y la línea de meta no llegó hacia atrás a encoger el terreno que ya recorrió. Una subida de dificultad hace más largo el camino restante (los nuevos shares cuentan menos); no le hace caminar hacia atrás. De forma simétrica, una bajada de dificultad hace que sus próximos shares cuenten más — no infla retroactivamente los que ya están registrados.

Un ejemplo resuelto (el caso exacto que preguntan los mineros)

Suponga que la dificultad de red es 1.000. Cien mineros envían cada uno un share a dificultad 1, así que la ronda ha registrado 100 unidades de trabajo — effort 100/1000 = 10%. Ahora observe una subida de dificultad bajo el cálculo correcto frente al ingenuo:

El effort correcto nunca baja: los primeros 100 shares siguen valiendo 10% (se ganaron a dificultad 1.000), y los siguientes 100 shares — que ahora valen solo 1/10.000 cada uno — lo empujan hasta 11%. La columna ingenua se desploma a 1% en el instante en que sube la dificultad, puramente porque vuelve a dividir todo su historial entre la nueva dificultad. Los mismos shares; solo la columna correcta refleja el trabajo realmente realizado.

Para los amantes de las matemáticas: la paradoja del "10.000% de effort", resuelta

Mineros perspicaces plantean una objeción ingeniosa que merece una respuesta adecuada, no una evasiva. Va así:

Es una trampa genuinamente buena, y la resolución es precisa: la lectura de effort en vivo y el "número esperado de bloques" son la misma cosa solo mientras la dificultad es constante. En el momento en que la dificultad cambia dentro de una ronda, hay que valorar cada share contra la dificultad que estaba vigente cuando ese share fue enviado. Eso da la medida físicamente exacta:

Equivalente real en bloques = Σ ( dificultad del share / dificultad de red en el momento de ese share )

Pase el reto por la fórmula exacta:

// 100 shares enviados mientras dificultad = 100
100 shares × (1 / 100) = 1.0 equivalente en bloques

// 1 share enviado tras bajar la dificultad a 1
1 share × (1 / 1)   = 1.0 equivalente en bloques

// Total de bloques esperados reales para el trabajo de esta ronda:
1.0 + 1.0 = 2.0 bloques — NO 100

Así que el trabajo de la ronda valía unos dos equivalentes en bloques, y encontró un bloque. Eso es completamente normal — incluso ligeramente afortunado. La paradoja nunca existió. Vino enteramente de leer el número ingenuo en vivo (que revaloriza todos los shares acumulados a la nueva dificultad, 100× más barata) como si fuera "bloques esperados". No lo es: los 100 shares tempranos se minaron cuando un bloque costaba 100, y nunca pueden valer más que el único bloque del que eran una fracción.

La lección que comparten ambos ejemplos: valore cada share contra la dificultad de su propio momento, y el effort se convierte en una suma que solo crece. El número ingenuo de ‘shares acumulados ÷ dificultad actual’ es la herramienta equivocada — es la única razón por la que el effort llega a parecer que cae a mitad de ronda.

¿Coincide con el mundo real?

Sí — y esta es la parte que debería tranquilizar a cualquiera que tema que la métrica esté amañada. El effort es una lectura instantánea y es ruidosa por naturaleza, porque encontrar un bloque es un proceso aleatorio (de Poisson). Cualquier ronda individual puede terminar en 20% o en 400%. Pero el proceso de encontrar bloques tiene una esperanza fija a largo plazo, así que cuando promedia el effort con el que realmente se encuentran los bloques a lo largo de muchas rondas, converge a 100%.

Si la media a largo plazo del effort del pool en el descubrimiento de bloques se situara lejos de 100% — digamos un 300% constante — eso sí sería un problema real que merecería investigación (contabilidad de dificultad incorrecta, shares rechazados o un desajuste entre hashrate y dificultad). Una caída a mitad de ronda no es la métrica haciendo su trabajo — calculado correctamente, el effort no caería en absoluto; la caída es el cálculo ingenuo asomando. Para entender la oscilación en sí, vea qué es la suerte en mining y por qué fluctúan las ganancias.

Preguntas frecuentes