Le mythe des serveurs stratum multiples :
miner plus proche aide-t-il vraiment ?

Données réseau actuelles

Tous les chiffres de cette analyse sont basés sur les données réelles du mainnet C64Chain, mais les conclusions s'appliquent à toute cryptomonnaie CryptoNote ou RandomX avec des temps de bloc similaires.

Les 3 opérations sensibles à la latence

1. Distribution des jobs — Nouveau modèle de bloc

Quand quelqu'un sur le réseau trouve un bloc, le pool doit envoyer aux miners un nouveau job pour qu'ils arrêtent de miner l'ancien bloc (désormais obsolète). C'est l'une des principales causes de stale shares et de shares rejetées.

Travail stale supplémentaire : ~200 ms. Par rapport au temps de bloc de 300 s : 200 ms / 300 000 ms = 0,067 % de hashrate gaspillé.

2. Soumission de shares — Le cas normal (99,999 % des shares)

Le miner trouve une share → l'envoie au stratum → le stratum valide localement → enregistre en base de données.

3. Soumission de solution de bloc — Le chemin critique (mais rare)

C'est la seule opération où la latence pourrait théoriquement coûter de l'argent réel. Quand une share atteint la difficulté du réseau, le stratum doit la soumettre au daemon aussi vite que possible.

200 ms de délai supplémentaire causent-ils réellement des orphans ?

Un orphan se produit lorsque deux miners trouvent des blocs valides presque en même temps et qu'un seul survit. Calculons la probabilité avec les données réelles du réseau :

// Valeurs réelles du réseau C64Chain
Hashrate réseau :       1 000 000 H/s
Difficulté réseau :     300 000 000
Taux de blocs (λ) :     1 000 000 / 300 000 000 = 0,00333 blocs/s

P(bloc concurrent dans 200 ms) = 1 - e(-0,00333 × 0,2)
                                = 1 - e(-0,000667)
                                ≈ 0,000667
                                = 0,067 %

Daemon local vs daemon distant

Le miner bénéficie-t-il d'un ping de 20 ms vs 300 ms ?

La question centrale : un miner en Asie bénéficie-t-il de la connexion à un serveur stratum asiatique (20 ms de ping) plutôt qu'au serveur EU (300 ms de ping) ?

Impact sur le hashrate : zéro

while (true) {
    nonce++
    hash = RandomX(blob, nonce)
    if (hash < share_target) {
        send_share(nonce)    // non bloquant, envoyer et oublier
    }
    // continue immédiatement — n'attend PAS le "accepted"
}

Impact sur les stale shares : négligeable

Quand un nouveau bloc apparaît, le job atteint le miner 280 ms plus tard avec une connexion à 300 ms vs 20 ms. Pendant ces 280 ms, le miner hashe l'ancien bloc (obsolète).

Temps stale supplémentaire :  280 ms
Temps de bloc :              300 000 ms
Augmentation taux stale :    280 / 300 000 = 0,093 %

Un miner à 10 KH/s produit environ 2,8 hash stale supplémentaires par transition de bloc. Avec 288 blocs/jour, cela représente ~806 hash gaspillés sur 864 000 000 hash totaux par jour.

Délai de découverte de bloc

Si le miner trouve un bloc, la solution traverse le système avec une latence aller supplémentaire :

Pire différence : 239 ms. Probabilité d'orphan due à ce délai supplémentaire : toujours seulement ~0,067 %.

Quand la latence compte-t-elle vraiment ?

La règle générale : la latence compte quand elle représente une fraction significative du temps de bloc. Pour plus de contexte sur les temps de bloc et leur relation avec le mining, consultez notre guide de démarrage. Pour C64Chain avec des blocs de 5 minutes, même la latence intercontinentale est une erreur d'arrondi.