Block time < 15 seconds

Research and Development
#1

At present Tezos block time is around 1 minute. But many other blockchains have faster block times or finality guarantees, both in the order of seconds.

What are the current bottlenecks related to lowering the block time to < 15 seconds? Or can we safely set it to a lower number?

For DeFi usecases(exchange, lending, etc…) - 1 minute blocktime feels a bit too long. For simple transfer usecases, 1 minute should work. But I feel for DeFi, it would be good to have faster blocktimes.

What are your thoughts on this topic?

1 Like
#2

My ‘feeling’ is that anything that requires a faster block time should move to L2 anyway since it can’t scale on L1.

Also I prefer stability and decentralisation over speed.

3 Likes
#3

Thanks for your response.

Stability, decentralisation - good points. We should not sacrifice this.

But from the point of view of UX, 1 minute is too long, considering the attention span of users. I mean- people would pay a little more to see their exchange happening faster(~10 seconds) than wait 1 minute to see a confirmation. Somehow Ethereum’s 12 second block time seems perfect from UX point of view. I’m curious what are the bottlenecks that prevent Tezos to lower block times while not sacrificing decentralization.

My question is- is 1 minute the ultimate final lower bound for producing blocks or can it go more lower? When Tezos was envisioned- there was little to no competition, so a 1 minute block time would have been a great improvement over Bitcoin/Litecoin etc…, now with several chains offering different configurations, are we going to stick with 1 minute or is there scope for improvement here?

Further, what kind of applications do you envision in L1 if those usecases belong in L2? What about the applications that are in development already/launched? - Dexter, Quipuswap etc…?

1 Like
#4

Not a dev, so take what I say with a grain of salt.

I’m going to use Solana as an example because they claim to have a 400ms block time without sharding. Two big factors that impact this is are the amount of validator nodes(the more you have the slower, but better security/decentralization) and system requirements for the validators.(more computing power = more throughput)

Solana has a maximum of 150 nodes, whereas Tezos has no cap.

For a low-end system Solana recommends a AMD Ryzen 3950x, 32GB Ram, 2 Tb SSD, and a Nvidia 1660ti. (Not very low-end in my opinion)

For Tezos I’ve heard of people running a baking node off a Raspberry Pi (probably not ideal though)

I don’t think raising system requirements are too unreasonable. If you can afford a roll (~$24,000 rn), chances are you can afford a decent server. But raising system requirements come with a lot of its own consequences, and probably requires its own discussion topic. Plus I’m not sure how efficiently blockchains will scale if you just throw more computing power at it.

#5

Regarding faster finality, there are two ongoing efforts in what concerns the consensus algorithm:

#6

I think my question is being misunderstood.

My question concerns only block times, not processing more transactions a minute or faster finality.

So we could decrease the block times, but still keep transaction capacity per minute the same or finality time the same. The idea is to have atleast one confirmation faster for a transaction, which is good for many usecases - especially DeFi. With one minute block times, there is scope for more manipulation in DeFi usecases.

2 Likes
#7

I don’t think you can decouple so easily block times from finality: what good to produce a block, say, every second if the probability of a fork is, say, 90%?

#8

@astefano thanks for your response. I agree with that to an extent, block times and finality are inter-related. But having some confirmations soon is better than having to wait 1 minute from the UX point of view.

My question: is 1 minute block time the best choice or can it be lower than that. But I’m looking at Emmy* and Tenderbake, may be the proposal is to have better block times, I’ll check.

#9

With Emmy* the block times will be 30 seconds (if blocks are at priority 0 and they have at least half of all endorsements).

With Tenderbake, the block times are given by the duration of the first round, which is a parameter of the algorithm, and is not yet fixed.

One thing to keep in mind is that block times should be bigger (at least most of the times) than the time to propagate blocks between any two nodes. Currently, a block is propagated only after it is validated. With the current gas limits per block, validation may take up to 10 seconds, when the block is “full”. Given that a block might need 4-5 hops to propagate over the p2p network, we are forced to set block times bigger than 40-50 seconds. (That is why Emmy* in order to reduce block times from 60 seconds to 30 seconds also halves the gas limit per block.) To improve block propagation times, a direction that is being explored is to remove the dependency on validation. That is, a node could propagate a block before fully validating it.

1 Like
#10

Good idea, only a very light validation can be preformed before propagation in order to reduce block times. But how to prevent DDoS attack with fake transactions?

#11

I fully agree with @sgn

UX is mainly what drives adoption.
I have been using tzcolors for last couple of days. This is a great project and I’d like to congratulate the Airgap team for their work. However, in this context where block time interval is approx 1 minute, it makes it way too slow.

In this current architecture/algorithm, I do not think that Tezos is able to compete with other blockchain like Polkadot where block time interval is approx 6 seconds.
Auctions need to be responsive, quick. Waiting for 1 minute before knowing if my bid has been confirmed or not is really impossible and bring bad UX.

On another hand, i also fully concur with @Paisley

In my opinion, if Tezos wants to compete with Polkadot (6 seconds block interval) or ETH2.0 (12 seconds block interval) in the NFT / Auctions market, we should seriously think at reduce our block time interval.

#12

I agree on 15 sec block for better UX especially it’s crucial for dex trades.
But your example seems bad cause every bid on tzcolors resets the timer to 4 min so you have enough time to place your bid

#13

In an event of bad luck, if you bid in the last 30 seconds and the last block just got created, then you would have to wait 1 more minute for your bid to be confirmed. So you lose your color.
To be 100% safe, you need to bid before it get to under 1 minute.

To be fair, I do not mind about if I miss a color, i’m just saying in general, for NFT/Auction market, 1 minute interval is not acceptable in term of UX (in my opinion).

I also understand that there must be a balance between UX (block time interval), transaction fees and security.
I understand that Tenderbake or Emmy+ are coming soon, so I am assuming that it will resolve it.

But it’s an interesting topic and proves that as perfect as Tezos is, there are still rooms for improvements! :smiley:

#14

We can exaggerate it to less than a second blocktime cause in an event of bad luck if you bid in the last second etc :wink:
There’s no reason to bid in the last 30 sec really
However no doubt it’s better UX to have 15 sec block time

#15

I don’t understand why would be an issue for auctioning. This can easily be avoided by setting the countdown timer to 1 or 2 minutes after the bid was made or like on tzcolors to 4 minutes.

Home Learn
Get Started Wiki
Developers Stack Exchange

Be part of the conversation