Der Mythos mehrerer Stratum-Server:
Hilft ein näherer Stratum wirklich beim Mining?
Eine datengestützte Analyse von Latenz, stale Shares und Orphan-Risiko in Kryptowährungs-Mining-Pools.
Für Coins mit Blockzeiten von 60 Sekunden oder mehr bietet die Verbindung zu einem geografisch näheren Stratum-Server keinen nennenswerten Vorteil. Latenzunterschiede sind im Vergleich zur Blockzeit vernachlässigbar, die Hashrate wird durch den Ping überhaupt nicht beeinflusst, und der Anstieg der stale Shares beim interkontinentalen Mining beträgt weniger als 0,1%.
Aktuelle Netzwerkdaten
Alle Zahlen in dieser Analyse basieren auf realen C64Chain-Mainnet-Daten, aber die Schlussfolgerungen gelten für jeden CryptoNote- oder RandomX-Coin mit ähnlichen Blockzeiten.
| Latenz-Szenario | Roundtrip-Zeit |
|---|---|
| Selbe Region (EU↔EU, Asien↔Asien) | ~20ms |
| Interkontinental (EU↔Asien) | ~200ms |
Die 3 latenzsensitiven Operationen
1. Job-Zustellung — Neues Block-Template
Wenn jemand im Netzwerk einen Block findet, muss der Pool den Minern einen neuen Job senden, damit sie aufhören, den alten (jetzt veralteten) Block zu minen. Dies ist eine der Hauptursachen für stale und abgelehnte Shares.
→ P2P-Verbreitung zum Daemon (~1-5s)
→ Stratum fragt Daemon ab (bis zu 1s Intervall)
→ Stratum sendet Job an Miner (Netzwerklatenz)
| Setup | Daemon-Abfrage RTT | Stale-Fenster (Worst Case) |
|---|---|---|
| Lokaler Daemon + lokaler Stratum | ~1ms | ~1,0s |
| Remote-Daemon (EU) + lokaler Stratum | ~200ms | ~1,2s |
Zusätzliche Stale-Arbeit: ~200ms. Im Verhältnis zur 300s-Blockzeit: 200ms / 300.000ms = 0,067% verschwendete Hashrate.
Stellen Sie sich vor, Sie schreiben eine 5-stündige Klausur und verlieren 0,36 Sekunden, weil die Uhr an Ihrer Wand etwas hinter der offiziellen herhinkt. Das ist die Größenordnung dieses „Nachteils“.
2. Share-Einreichung — Der Normalfall (99,999% der Shares)
Miner findet einen Share → sendet an Stratum → Stratum validiert lokal → speichert in Datenbank.
| Setup | Hash-Validierung | Datenbank-Schreibvorgang | Miner wartet? |
|---|---|---|---|
| Alles lokal | <1ms | <1ms | Nein |
| Remote-Datenbank (WAN) | <1ms (lokales RandomX!) | ~200ms | Nein |
Der Miner wartet NICHT auf den Datenbank-Schreibvorgang. Der Stratum validiert den Hash lokal mit RandomX, sendet sofort „akzeptiert“ an den Miner zurück und schreibt dann asynchron in die Datenbank. Der Miner hasht die ganze Zeit mit voller Geschwindigkeit weiter.
Wenn Sie einen Brief in einen Briefkasten werfen, stehen Sie nicht dort und warten, bis er am Ziel ankommt. Sie gehen weiter und machen Ihre Sachen. Genauso hier – der Miner wirft den Share ein und hasht weiter.
3. Block-Lösungs-Einreichung — Der kritische Pfad (aber selten)
Dies ist die einzige Operation, bei der Latenz theoretisch echtes Geld kosten könnte. Wenn ein Share die Netzwerk-Schwierigkeit erfüllt, muss der Stratum ihn so schnell wie möglich an den Daemon übermitteln.
→ Stratum validiert Hash (lokales RandomX, <1ms)
→ Stratum ruft submit_block am Daemon auf
→ LOKALER Daemon: <1ms RTT
→ REMOTE-Daemon: ~200ms RTT
→ Daemon validiert + verbreitet via P2P
Verursachen 200ms zusätzliche Verzögerung tatsächlich Orphans?
Ein Orphan entsteht, wenn zwei Miner fast gleichzeitig gültige Blöcke finden und nur einer überlebt. Berechnen wir die Wahrscheinlichkeit mit realen Netzwerkdaten:
// Reale C64Chain-Netzwerkwerte
Netzwerk-Hashrate: 1.000.000 H/s
Netzwerk-Schwierigkeit: 300.000.000
Blockrate (λ): 1.000.000 / 300.000.000 = 0,00333 Blöcke/Sek
P(konkurrierender Block innerhalb von 200ms) = 1 - e(-0,00333 × 0,2)
= 1 - e(-0,000667)
≈ 0,000667
= 0,067%Stellen Sie sich vor, Sie angeln in einem riesigen See zusammen mit einer anderen Person. Die Chance, dass Sie beide innerhalb derselben 0,2 Sekunden einen Fisch fangen, ist praktisch null. So unwahrscheinlich ist ein Block-Wettlauf bei einem Coin mit 5-Minuten-Blockzeit.
Lokaler Daemon vs. Remote-Daemon
| Aspekt | Lokaler Daemon | Remote-Daemon (WAN) |
|---|---|---|
| Job-Template-Latenz | <1ms | ~200ms |
| Block-Einreichungs-Latenz | <1ms | ~200ms |
| Stale-Share-Rate | ~0,33% | ~0,40% |
| Orphan-Risiko-Erhöhung | Ausgangswert | +0,067% |
| Benötigter Speicherplatz | Gesamte Blockchain | Keiner |
| Bandbreite | P2P-Sync-Verkehr | Nur RPC-Aufrufe |
| Wartung | Muss synchron bleiben | Keine |
| Ausfall-Szenario | Überlebt WAN-Ausfall | Tot bei WAN-Ausfall |
Ein lokaler Daemon geht nicht um Geschwindigkeit – sondern um Ausfallsicherheit. Wenn die WAN-Verbindung für 30 Sekunden ausfällt, hält ein lokaler Daemon den Stratum am Laufen. Ohne ihn führt jeder Internet-Schluckauf zwischen Kontinenten zum Totalausfall für diese Miner.
Ein lokaler Daemon ist wie ein Notstromgenerator zu Hause. Das Licht bleibt an, auch wenn die Hauptstromleitung kurz ausfällt. Ohne ihn legt jede Internet-Störung den gesamten Pool für diese Miner lahm.
Profitiert der Miner von 20ms vs. 300ms Ping?
Die Kernfrage: Profitiert ein Miner in Asien davon, sich mit einem Asien-Stratum-Server (20ms Ping) statt dem EU-Server (300ms Ping) zu verbinden?
Hashrate-Auswirkung: Null
Latenz reduziert die Hashrate nicht. Punkt.
Die Mining-Schleife läuft ununterbrochen. Ob die „akzeptiert“-Antwort in 20ms oder 300ms zurückkommt – der Miner hasht mit voller Geschwindigkeit weiter. Es gibt keine Pause, kein Warten, keine Roundtrip-Abhängigkeit.
while (true) {
nonce++
hash = RandomX(blob, nonce)
if (hash < share_target) {
send_share(nonce) // nicht-blockierend, fire-and-forget
}
// fährt sofort fort — wartet NICHT auf "akzeptiert"
}Stale-Share-Auswirkung: Vernachlässigbar
Wenn ein neuer Block erscheint, erreicht der Job den Miner bei einer 300ms-Verbindung 280ms später als bei 20ms. Während dieser 280ms hasht der Miner den alten (veralteten) Block.
Zusätzliche Stale-Zeit: 280ms
Blockzeit: 300.000ms
Stale-Rate-Erhöhung: 280 / 300.000 = 0,093%Ein Miner mit 10 KH/s produziert pro Block-Übergang etwa 2,8 zusätzliche stale Hashes. Bei 288 Blöcken/Tag sind das ~806 verschwendete Hashes von insgesamt 864.000.000 Hashes/Tag.
Block-Fund-Verzögerung
Wenn der Miner einen Block findet, wandert die Lösung mit zusätzlicher Einweg-Latenz durch das System:
| Miner-Setup | Miner → Stratum | Stratum → Daemon | Gesamtverzögerung |
|---|---|---|---|
| 20ms Ping + lokaler Daemon | 10ms | 1ms | 11ms |
| 20ms Ping + Remote-Daemon | 10ms | 100ms | 110ms |
| 300ms Ping + lokaler Daemon | 150ms | 1ms | 151ms |
| 300ms Ping + Remote-Daemon | 150ms | 100ms | 250ms |
Maximaler Unterschied: 239ms. Orphan-Wahrscheinlichkeit durch diese zusätzliche Verzögerung: immer noch nur ~0,067%.
Stellen Sie sich Mining wie eine Lotterie vor, bei der Sie ununterbrochen Lose rubbeln. Ob das Geschäft 1 Minute oder 5 Minuten vom Lotterieamt entfernt ist, spielt keine Rolle – Sie rubbeln mit der gleichen Geschwindigkeit weiter. Der einzige winzige Nachteil ist, dass Sie, wenn sich die Gewinnzahlen ändern, ein paar Sekunden später davon erfahren und vielleicht ein zusätzliches altes Los rubbeln. Aber Sie rubbeln Millionen von Losen pro Tag, daher ist dieses eine verschwendete Los bedeutungslos.
Wann ist Latenz tatsächlich relevant?
| Blockzeit | Beispiel | Stale-Auswirkung (300ms) | Orphan-Risiko | Latenz relevant? |
|---|---|---|---|---|
| 1 Sekunde | Solana | 30% | Sehr hoch | JA — kritisch |
| 10 Sekunden | — | 3% | Hoch | Ja — erheblich |
| 15 Sekunden | altes Ethereum | 2% | Moderat | Spürbar |
| 60 Sekunden | — | 0,5% | Gering | Kaum |
| 300 Sekunden | C64Chain | 0,1% | Vernachlässigbar | Nein |
| 600 Sekunden | Monero | 0,05% | Vernachlässigbar | Nein |
Die Faustregel: Latenz ist relevant, wenn sie einen signifikanten Bruchteil der Blockzeit ausmacht. Mehr Kontext zu Blockzeiten und deren Zusammenhang mit Mining finden Sie in unserem Einsteiger-Leitfaden. Für C64Chain mit 5-Minuten-Blöcken ist selbst interkontinentale Latenz ein Rundungsfehler.
Fazit
| Faktor | Auswirkung von Remote-Stratum | Optimierung lohnenswert? |
|---|---|---|
| Hashrate | Kein Unterschied | Nein |
| Stale Shares | +0,07–0,09% | Nein |
| Orphan-Risiko | 1 von 3.000 Blöcken | Nur bei sehr wertvollem Coin |
| WAN-Ausfallsicherheit | Stratum fällt bei Ausfall aus | Ja — der wahre Grund |
Für Miner: Verbinden Sie sich mit dem Stratum-Server Ihrer Wahl. Ihre Hashrate und Einnahmen sind identisch, ob Sie 20ms oder 300ms entfernt sind. Die Unterschiede sind kleiner als die normale Pool-Glücksvarianz.
Für Pool-Betreiber: Der einzige legitime Grund für regionale Stratum-Server ist die Verfügbarkeits-Ausfallsicherheit gegen WAN-Ausfälle – nicht Geschwindigkeit. Wenn Ihre interkontinentale Verbindung stabil ist, reicht ein einzelner Stratum-Standort für Blockzeiten von 60 Sekunden oder mehr völlig aus.
Der Mythos entlarvt: „Näherer Stratum = mehr Coins“ ist falsch für jeden Coin mit einer Blockzeit über 30 Sekunden. Die Mathematik lügt nicht – 200ms Latenz bei einer 300-Sekunden-Blockzeit sind ein Unterschied von 0,067%, völlig überschattet von der normalen Mining-Glücksvarianz von 10–50%.
Verwandte Artikel
Mining-Schwierigkeit verstehen
Was Schwierigkeit bedeutet, wie sie sich anpasst und warum sie für Ihr Mining wichtig ist.
Stale & abgelehnte Shares
Was stale und abgelehnte Shares verursacht und wie Sie sie beheben.
Solo-Mining vs. Pool-Mining
Die Mathematik hinter Solo- vs. Pool-Mining und wann sich was lohnt.