The Block time is 2 minutes ! So every 2 minutes the chain (for all on the right branch)is synced. So it is clear to me that every 2 minutes the nethashrate is known to everybody synced to the chain (who is not will geht the next block an orphan block).
Because the difficulty is dependent to the nethashrate (blocks have to be finished max every 2 minutes) the nethashrate has to be known to everybody working on the blockchain.
have a nice day
The block time is only a
_target_ block time, it's what we want to achieve, on average. But achieving the desired difficulty target with a hashing function is a Poisson random process, which means you might find the desired result in less time or more time than the desired 2 minutes. Only
if hashrate and difficulty are well matched, then, in the long run the
average of the block times will be 2 minutes.
In a pure POW coin (like Bitcoin for example), difficulty adjust every so many blocks. (In bitcoins, its every 2016 blocks; if blocks come out ona average every 10 minutes, that will be 2 weeks). But if blocks have been coming out faster than every 10 minutes, then difficulty will be increased by the difficulty adjustment algorithm to slow down the rate of production. If it took longer than 2 weeks to validate the 2016 blocks then difficulty will be lowered to speed up production.
No coin controls its network hashrate (Just look at the problem of multipools suddenly joining and then leaving coin networks). The network hash rate depends on who is mining and how powerful their mining equipment is. People can point their mining rigs at a different coin in an instant!
The only thing a coin network can set and control is the difficulty factor. Most POW coins have switched to much more responsive algorithms to adjust for more drastic hash rate variations than the original bitcoin algorithm could ever handle. (These algos go by names like Kimoto's Gravity Well, Dark Gravity Wave, DigiShield, Delta, etc.) So the difficulty factor is adjusted in these newer algos sometimes as often as every block, but it is always the difficulty factor being set in response to the observed hashrate.
The equation governing this relationship is:
Hash Rate (hashes / second) = Difficulty (hashes / nonce) x [blocks_found / blocks_expected] x [size of nonce space (nonces) / target block time (seconds) ]
The size of nonce space is 2^32 = 4 294 967 296 (nonces) and target block time for DEM is 120 seconds, to equal DEM's Constant
C = 35 791 394. 13 (nonces/ second) or as Rumhocker says, about 35.8 MegaNonces/second
So let's say a real time hour has gone by, and only 20 DEM blocks have been found in that hour. If the difficulty factor has remained constant during this time, then the Hash Rate can be found with the above equation. Once you know the "effective" hash rate for this hour-long period, then you can use it to set what will be a correct difficulty factor to match the observed hash rate.
For a concrete example, POW difficulty on DEM is now: 1 673 882.67 (hashes/nonce)
If we apply this to the above hypothetical situation,
1 673 882 .67 (hashes / nonce) x [20/30] x 35 791 394 .13 (nonces/ second) = 39 . 940 396 Tera Hashes / Second
Once you know this "effective" hash rate during that hour, now you can find the difficulty factor that will balance this hashrate to produce, on average, a 2 minute block time. (Note that since we want blocks_found = blocks_expected, so that term = 1)
39.94 (TH/s) / 35.8 MegaNonces/second = 1 115 642.4 (hashes / nonce)
Which makes sense ... the difficulty is lowered, because too few blocks were found.
?