#### Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

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

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

• Member Posts: 75 ✭✭
I think a shorter blocktime would allow us to do more on-chain. Certain types of real-time apps are hard to do with chain reads and writes taking one min.
• Administrator Posts: 84 admin
That's exactly the reason why I'm trying so hard to push the time down.

Update: https://github.com/ethereum/economic-modeling/blob/master/5ghost.py

A fifth-generation uncle strategy achieves even better performance and avoids a serious selfish-mining risk.
• Member Posts: 83
One of the reasons why I like Ripple so much is the 5 second transaction time. After that, everything else seems sloooow. It'd be great if you can get the block time down below 10 seconds.
• Administrator Posts: 84 admin
Sergio Lerner claims to have managed 5s here:

http://bitslog.wordpress.com/2014/02/17/5-sec-block-interval/

I think that this particular analysis underestimates centralization risk as described in my post but his technical suggestions are sound and might just get us there. But I also do value caution, especially in cryptography/cryptoeconomics.
• Member Posts: 83
Interesting article. Thanks for posting. I see you are speaking at the conference in Chicago this weekend. I'll be at it too. I'll stop by and shake your hand. I admire the work you've been doing for a while.
Sign In or Register to comment.