Topic: What are the problems associated with reducing block generation time? (Read 729 times)

Yo Jet!

I wouldn't play with the block time.

I would do this though..

1) Create your blocks as normal.

2) Now create a 'transmission-block' that only has the txn hashes in it, not the whole txn. The txns are MOST LIKELY already propagated throughout the network, and the small percentage that aren't known to your peers, can be passed on 'at-the-point-where-you-pass-the-block-on'. No need to send them twice.

3) Transmit the TINY transmission block (32 byte per txn). (plus a small amount of 'extra' data to help in the recreation of the full block, full-block hash etc.. to check)

4) Those that get the trans-block, can recreate the full-block, check it against the hash sent in the extra data, and proceed as normal.

boom. Tiny blocks. 1MB at 32 bytes per txn, could hold.. ~30000 txns / block.

 

Small miners have to wait for the network to broadcast blocks, while large miners have immediate access to their own blocks.
A short block generation time makes it easier for large miners to monopolize block creation and increases centralization.
This results in large miners controlling the blockchain and small miners constantly getting their blocks orphaned.
Ask anyone who has mined a 5s or 6s coin, they will give you a vivid description of what it feels like to have all their blocks orphaned.
Frustrated and profitless, they quit, and the large miners tighten their grip on block creation.

The actual problem doesn't have much to do with "transaction submission to block acceptance".  It has a lot more to do with the sequence of events from block submission to overwhelming number of nodes accepting the submitted block.

The problem of network incoherence arises when two (or more) different miners solve a block close enough in time to each other that a significant number of nodes hear about the blocks in different order.

With a difficulty set to AVERAGE 10 minutes per block, the variance in actual time to solve a block is significantly larger than the time to relay a solved block throughout the network.  Therefore, most of the time, the vast majority of nodes have heard about a solved block before another block gets solved.

If you reduce the time per block too much, then you run into a situation where a significant number of blocks are solved in less time than it takes to relay a solved block throughout the network.  In this situation you can have sets of nodes that each think a different block is the "next block" in the chain.  You have to wait until one of these 2 or more blocks have been built upon with another block to figure out which of these forks in the blockchain is the "real" one (the other blocks are deleted and the miners that solved them lose their block reward).  You could have a result where 2 or more of these blocks that are waiting to be built upon all have the next block (or blocks!) built on them very close in time.  Now you have multiple chains 2 blocks deep, and still no way to know which one is the "real" one.  You have to wait for one of those chains to have a third block built on top of it.  This could go on until the multiple split chains are all several blocks deep.  Then finally randomness results in having a longer than normal solving time and only one miner that solves in that time.  Finally all nodes collapse onto this one longest chain.  They all abandon any other blocks they received and all the miners that thought they might have earned a block reward discover that their broadcast block has been rejected by the network.  Some transactions that appeared to have multiple confirmations suddenly have less confirmations (or possibly go back to being unconfirmed!).

Note also that the changes in Sighash performance included as part of the Segwit fork would actually improve the viability of reducing the block interval target, but I'm not sure by what factor. There are several algorithmic improvements that could be made too, there are too many to mention. Although many of those would also need soft or hard forks, no doubt.

But none of that might be enough to decrease the interval by alot, they're just variously small risk mitigations, some may have barely measurable impact in practice.

Thanks for that explanation, I think I start to understand the problem. I need to work out the exact sequence of events from transaction submission to block acceptance. I'll do some reading and research, and perhaps I can return to this.

Guess which specific circumstances are more likely to generate a block race? That's right, when blocks are solved close together in time. If the 10 minute target was reduced, the frequency of short (say, less than 1 minute) block intervals would increase. The rate of chain re-orgs would increase commensurately, and the system couldn't take that.

The rate at which chain re-orgs happen now is acceptable, the system can absorb it with a 10 minute solution target. Trying to increase that rate without coming up with a way to mitigate the increased risk of network incoherence doesn't seem sensible, and without changing the latency performance of the internet itself, no-one currently has any ideas of a way to do that. It would be nice if it were possible though, so it obviously isn't ruled out long term.

I don't really understand why this is a problem. It seems that it's possible to generate a new block a couple of seconds after the previous block, and this doesn't seem to be a problem as long as they are both valid blocks.

The 10 minute block interval is as long as it is to reduce the frequency of blockchain reorganiations (where miners with block contention at the same height do not resolve uniformly on the network, causing the network to fork, and the consensus logic in the system to resolve the fork)


It's possible that reducing it to 5 minutes wouldn't significantly impact chain-reorg risk, but even that's debatable.

The real point is: where is this "scaling" paradigm going to get it's next iteration from, after halving to 5 minutes? Nowhere, unless you have a way of making the requisite improvements in TCP/IP network latency too.

To my simple mind it seems a fairly easy change. You reduce the difficulty, and you reduce the miners' rewards. What else is involved?

I can appreciate the problems associted with obtaining consensus.

Just as a thought. I believe there is a block type character in the header - how about having two types? A fast block would generate a lower reward, and a standard block would carry on as normal. Nodes would not need to know the difference, to them a block would be a block. Of course I'm ignoring the verification of the miners reward, because I don't understand the mechanism for that.