3

I am trying to Google the answer but cannot find any. What is the expected average block time for Ethereum 2.0 when it comes live (on the mainnet)?

I am aware that there is cabapility to do faster-than-on-chain transactions with Raiden Network, but I hope to be able to do it on-chain.

Average block time will depend on the minig algorithm, and there will be a change in this when transition to PoS happens.

This says:

In chain-based PoS, the algorithm pseudo-randomly selects a validator during each time slot (e.g. every period of 10 seconds might be a time slot), and assigns that validator the right to create a single block, and this block must point to some previous block (normally the block at the end of the previously longest chain), and so over time most blocks converge into a single constantly growing chain.

Does this mean the average blocktime will be 10 seconds? (If yes, why not set it to less than 1?)

| improve this question | |
  • 1
    Should be identical to now, because mining will still be the process to produce blocks. Every 50th block will be regarded as a checkpoint and stakers can only vote on checkpoints. – sea212 Apr 21 at 17:58
  • Yes, good point. Surely it'll depend on the mining algorithm, so if that changes, we cannot rely on past data can we? – zabop Apr 22 at 6:34
  • 1
    There's nothing in the Eth2 specification about every 50th block being a checkpoint. This sounds like the old "sharding spec" that was deprecated by Eth2 in mid-2018. – paulhauner Apr 24 at 3:00
  • @paulhauner I have retrieved my information from an official paper from 21 March 2020: arxiv.org/pdf/1903.04205.pdf. A checkpoint is defined as any block with the number i * e, whereas e is the epoch time, which is specified as 50 blocks in that paper. I have taken this information from the section which includes the definition of a checkpoint. I have answered some quesitons in regards to block times, checkpoints and finalization times at ethereum.stackexchange.com/questions/76428/… – sea212 Apr 29 at 10:36
  • Oh I see, sorry I hadn't seen that paper yet. I understand that the 50 used in that paper is just an example for that context and won't be used in eth2. – paulhauner Apr 30 at 1:18
3

The block time for the upcoming Ethereum 2.0 (Eth2) is set to 12 seconds. This includes the beacon chain and shard chains.

This rate is defined in the Time parameters section of v0.11.1 of the Eth2 specification as SECONDS_PER_SLOT.

In Eth2, time is split up into "slots" where a single validator is randomly elected to produce a block. Therefore, the fastest rate at which blocks can be produced is one block per SECONDS_PER_SLOT seconds.

As mentioned by OP, faster transaction times can be provided by higher-layer ("layer-2") solutions (zk-rollups, etc).

why not set it to less than 1?

The block time is largely determined by the time it takes a block to propagate across a global peer-to-peer network and be processed by nodes.

If we set the block time to 1/2 second it's very likely that all nodes across the world will not have been able to receive and process block n before it's time to produce n + 1, causing a fork in the chain.

| improve this answer | |
1

The fastest deployed proof-of-stake system, EOS, can handle a block once in 7 seconds (and throughput of 8000tx/s). The EOS block producing system is highly optimized. They have only 21 block producers that are rotated in shifts around the world.

What you are hitting is network latency, lightspeed and propagation issues. If the network goes too fast, nodes around the world cannot keep synchronised. (This does not exclude local networks, like a theoretical "China blockchain" running faster.)

There is no theoretical innovation known at the moment how Ethereum could do any faster (or as fast) as EOS. Thus, I assume that sub-second blocks are impossible.

(Happy to someone prove me wrong, though)

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.