I have configured a private network in which I can assign different roles to different nodes (machines).
Before starting the test I generate the DAG for the block number 0 with the command:
geth makedag 0 myethashdir
And so I generate the dag for the epoch 0 (i.e. from block 0 to block 30000). My problem is that whenever I start the miner(s), they try to generate the DAG for epoch 1.
I read in the geth help message that there is the additional option
--ethash.dagsondisk which's default value is 2. Therefore I pass to geth the option
--ethash.dagsondisk 1, but geth tries to generate the new DAG.
Since I run my test on cheap HW (and do not want to use PoA, I need to work with PoW for a University project). I wonder if there is the possibility to prevent geth to generate the second DAG which is a time consuming task.
A possible workaround, that I want to possibly avoid is to generate two DAGs with the
geth makedag command.
I'm using geth v1.8.11-stable
According to this Ethereum wiki entry "Dagger Hashimoto" the dag for this epoch and for the next one should be generated to avoid slowdowns when we are switching to a new epoch:
In a full client, a double buffer of 2 DAGs produced by the above formula is used. The idea is that DAGs are produced every epochtime number of blocks according to the params above. The client does not use the latest DAG produced, but the previous one. The benefit of this is that it allows the DAGs to be replaced over time without needing to incorporate a step where miners must suddenly recompute all of the data. Otherwise, there is the potential for an abrupt temporary slowdown in chain processing at regular intervals and dramatically increasing centralization and thus 51% attack risks within those few minutes before all data is recomputed.