El mito de los múltiples servidores stratum:
¿Ayuda realmente minar más cerca?

Datos reales de la red

Todos los números de este análisis se basan en datos reales de la mainnet de C64Chain, pero las conclusiones se aplican a cualquier moneda CryptoNote o RandomX con tiempos de bloque similares.

Las 3 operaciones sensibles a la latencia

1. Entrega de trabajo — Nueva plantilla de bloque

Cuando alguien en la red encuentra un bloque, el pool debe enviar a los miners un nuevo trabajo para que dejen de minar el bloque anterior (ahora stale). Esta es una de las principales causas de stale shares y shares rechazados.

Trabajo stale adicional: ~200ms. Relativo a un tiempo de bloque de 300s: 200ms / 300.000ms = 0,067% de hashrate desperdiciado.

2. Envío de shares — El caso normal (99,999% de los shares)

El miner encuentra un share → lo envía al stratum → el stratum valida localmente → registra en la base de datos.

3. Envío de solución de bloque — La ruta crítica (pero rara)

Esta es la única operación donde la latencia podría teóricamente costar dinero real. Cuando un share cumple con la dificultad de la red, el stratum debe enviarlo al daemon lo más rápido posible.

¿200ms de retraso adicional realmente causan orphans?

Un orphan ocurre cuando dos miners encuentran bloques válidos casi al mismo tiempo y solo uno sobrevive. Calculemos la probabilidad usando datos reales de la red:

// Valores reales de la red C64Chain
Hashrate de la red:      1.000.000 H/s
Dificultad de la red:    300.000.000
Tasa de bloques (λ):    1.000.000 / 300.000.000 = 0,00333 bloques/seg

P(bloque competidor en 200ms) = 1 - e(-0,00333 × 0,2)
                                = 1 - e(-0,000667)
                                ≈ 0,000667
                                = 0,067%

Daemon local vs. daemon remoto

¿Se beneficia el miner de 20ms vs 300ms de ping?

La pregunta central: ¿un miner en Asia se beneficia de conectarse a un servidor stratum en Asia (20ms de ping) frente al servidor EU (300ms de ping)?

Impacto en el hashrate: cero

while (true) {
    nonce++
    hash = RandomX(blob, nonce)
    if (hash < share_target) {
        send_share(nonce)    // no bloqueante, dispara y olvida
    }
    // continúa inmediatamente — NO espera por "aceptado"
}

Impacto en stale shares: despreciable

Cuando aparece un nuevo bloque, el trabajo llega al miner 280ms después con una conexión de 300ms frente a 20ms. Durante esos 280ms, el miner hashea el bloque anterior (stale).

Tiempo stale adicional:      280ms
Tiempo de bloque:            300.000ms
Aumento tasa de stale:       280 / 300.000 = 0,093%

Un miner a 10 KH/s produce aproximadamente 2,8 hashes stale adicionales por transición de bloque. Con 288 bloques/día, eso son ~806 hashes desperdiciados de un total de 864.000.000 hashes/día.

Retraso en descubrimiento de bloque

Si el miner encuentra un bloque, la solución viaja por el sistema con latencia adicional de ida:

Diferencia en el peor caso: 239ms. Probabilidad de orphan por ese retraso adicional: sigue siendo solo ~0,067%.

¿Cuándo importa realmente la latencia?

La regla general: la latencia importa cuando es una fracción significativa del tiempo de bloque. Para más contexto sobre tiempos de bloque y cómo se relacionan con mining, consulte nuestra guía para empezar. Para C64Chain con bloques de 5 minutos, incluso la latencia intercontinental es un error de redondeo.