Check out the Issue Explorer
Looking to fund some work? You can submit a new Funded Issue here.
## Feature request
When used in private chains, there's a need to demonstrate ether in lower-latency settings. The main requirement for the ~17second mining time seem to be connected to the fact that "12.6 seconds is the time it takes for a new block to propagate to 95% of nodes" [(https://medium.facilelogin.com/the-mystery-behind-block-time-63351e35603a), (http://www.tik.ee.ethz.ch/file/49318d3f56c1d525aabf7fda78b23fc0/P2P2013_041.pdf)].
In a small e.g. 10 node network, with small latency (e.g. lower than 100ms) there's no reason to not mine more frequently. There's a proposed solution [here](https://ethereum.stackexchange.com/a/10634) about freezing the difficulty to the one in Genesis Block. This would likely translate to nop'ing the `calcDifficultyHomestead()` method [here](https://github.com/ethereum/go-ethereum/blob/d429a92f09e476c431830cef48690dc3784153c7/consensus/ethash/consensus.go#L382). Another alternative might be to change parameters [here](https://github.com/ethereum/go-ethereum/blob/762f3a48a00da02fe58063cb6ce8dc2d08821f15/params/protocol_params.go#L82) and especially `DifficultyBoundDivisor`.
I would like, if possible, some discussion on the subject, someone trying a proposed solution and demonstrating it with - for example - a small 5-node docker-compose - based cluster. The solution should be proved to be reasonably stable i.e. able to run successfully for e.g. a few hours.