Decrease block time to 5 sec

[lerider]

With finality in every block, faster blocks can produce a vast increase of utility in terms of settlement.

Suggestion is to decrease block time to 5 seconds and decrease GAS release by a factor of 3 (~3 blocks in 15 sec, so GAS release should be divided by three).

At later stage, we can evaluate the impact of faster blocks and potentially reduce to 1-2 second blocks.

This is a discussion.

[shargon]

The first impact is the size, the chain will grow faster (when there are no transactions), if the size is not a problem, we need to ensure that the TX in the block is ordered by received date too (for ensure that is more spread around the network)

[igormcoelho]

I agree that time must be reduced to achieve the expected 100k TPS... I think we could do some experimentation in a near future to diagnose what could be the best timing given the current implementation. In fact, this calibration analysis is supposed to be a part of the consensus competition that we are planning to launch soon enough :)

[EdgeDLT]

Would love to see 5 second blocks given the TPS improvements (not to mention it'll really demonstrate the power of same-block finality), but I have a few questions:

• How realistic is maintaining 5 second blocks as the number of consensus nodes increases?
• Are we relying on Akka alone to resolve our issues with large blocks causing delayed block times, or are there other solutions that can help provide consistency?
• What about chain size/sync time for nodes?

[shargon]

If we have 5 seconds, we should reduce the MaxSizeBlock

[toghrulmaharram]

It is unlikely that we would be able to produce 5 second blocks as the network grows and the second agreement phase is added to the protocol (the COMMIT phase). Bare in mind that the more nodes join the network, the less eventual throughput the network can achieve.

[canesin]

There is no technical need to reduce block time, as a matter of fact it could be increased. One can do risk management by observing state of a target transaction in the network and instantaneously accept low risk transactions. One can confirm <1s txs with this method.

NEX for example is implementing this technology in its payment processing offerings.

The advantage of keeping (or increasing) block time are many: lower size of blockchain, lower communication bottleneck, improve consensus efficiency.

[lllwvlvwlll]

The overhead from block minting would decrease max TPS, but also decrease transaction latency (assuming fast syncing of full nodes). Since we don't currently saturate the network, it's reasonable from a latency perspective, but I'm curious if we would see any substantial improvement because of the additional network load.

…

On Sat, Oct 13, 2018, 10:29 AM FCC ***@***.***> wrote: There is no technical need to reduce block time, as a matter of fact it could be increased. One can do risk management buy observing state of a target transaction in the network and instantaneously accept low risk transactions. One can confirm <1s txs with this method. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#375 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AcayELlEEsLNu7lOoXP1U7NjXtMe2Sglks5ukhUGgaJpZM4Wk7eA> .

[vncoelho]

Hi @lerider, my friend.
Let's reactivate this discussion 🗡️

Bow with the success of dBFT 2.0 we gonna be able to discuss and test this in the future months.

[lerider]

Now I want to see 1 second blocks, go for it!

[lock9]

@neo-project/core so, this has a NEO 3 milestone, is there anything that should be done before this is implemented?

[vncoelho]

I think it is almost ready for that, @lock9:

• We would need to adjust GAS generation formula.

We have been discussing other crazy ideas, such just generating blocks with transactions. ahuehaueaea

But I think that reduce block time to 5s might be good, in particular, because we have block finality and it would maker experience of the Ecosystem even better.

[lock9]

This can work, as long as we avoid generating empty blocks every 5 seconds.

[EdgeDLT]

As much as I think 5 second blocks with finality would be awesome, maybe 10 seconds would be a better place to start for NEO3?

We don't want to run into a situation where 5 second blocks are stable with 7 nodes but start having problems as the total number of nodes increases.

[shargon]

maybe 10 seconds would be a better place to start for NEO3?

I think that 10 seconds is a very good time for NEO 3. At least for the testnet, and after some time, we can study the testnet and take the right decision.

[lllwvlvwlll]

Has there been any testing on privatenets to evaluate whether this will have a noticeable performance impact? It does not seem like a good idea to change this without any empirical data.

At some point, the network and block processing overhead is going to overtake the benefit from increased minting frequency. Additionally, this critical point will change as the network load changes (longer block times are more efficient with large transaction volume). Has there been any investigation into variable block times? It was discussed at the shanghai meetup and I believe that would potentially give us the best of both worlds.