Development resources at your finger tips
Build with the coolest Web3 projects
Recurring funding for Open Source
Ethical ads to power Open Source
Learn about Web3 & earn rewards
Show appreciation for each other
Meet fellow developers, designers, futurists and more. Collaborate and BUIDL awesome projects together.
Discover great web3 organizations, work on meaningful projects and build relationships with like minded people. Browse Tribes
Meet the top hunters and contributors from our community.
KERNEL is an 8-week, invite-only program for top tech talent looking to build relationships, products, and companies in blockchain and Web 3. 100 tal…
Heyo Gitcoiners! With an entire city of hackers, coders and blockchain innovators relocated on our platform, the atmosphere is just buzzing with crea…
Type in [[ 2- term.length]] more characters to get results
[[ result.title ]]
[[ result.description | truncate(70) ]]
No matches found
Gitcoin is GDPR complaint. Learn more in
Gitcoin's Terms & Conditions.
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.