I have a new strategy that _might_ just reduce the block time to 10-15s

VitalikButerinVitalikButerin Administrator Posts: 84 admin
http://vitalik.ca/files/sim.py

Basically, the idea is to take GHOST, and require every block to have 4 uncles. The time between PoW solutions would be normalized to 2s, so each block would be roughly every 10s. The reason why this works is that even with simple GHOST, there is a substantial centralization risk since a large miner or pool is more likely to produce 2 blocks immediately one after the other, having a 0% stale rate on the next block whereas everyone else has the same positive stale rate as usual. With every "block" coming from five places, this risk essentially disappears.

The simulation script above can be used to test this theory; setting UNCLES to 0 simulates simple GHOST and 4 simulates my new strategy. Here are my outputs:

[email protected] 05:21:11 Work/ethereum: cat 1
### PRINTING GROUPINGS ###
1 1.0
10 9.98021234204
25 26.5024291056
5 5.00017740659
15 15.3588389421
[email protected] 05:21:12 Work/ethereum: cat 2
### PRINTING GROUPINGS ###
1 1.0
10 11.1665639762
25 30.0503183405
5 5.33251180941
15 16.8494557404%

In the first case, my new strategy, a miner with 25% gets 26.5x as much as a miner with 1% (a mining pool might get something like 25.7% because the pool still needs to communicate with individual miners so it's not really a solo miner), and in simple GHOST a miner with 25% gets 30x as much. This all assumes a 10s target block time (which actually turns into 15s because every block ends up having an average of 6.5 uncles despite the minimum of 4) and a network communication time of 10s.

I am looking for review and feedback before adding this to PoC6.

Comments

Sign In or Register to comment.