Speed up Godwoken block time to improve the user experience

Abstract

The current Godwoken block interval is about 30s ~ 40s. The long block interval causes Metamask and some other Ethereum tools to take a long time to show the transaction’s result, which brings a bad user experience. To improve the user experience on Godwoken, we propose to speed up the Godwoken block time. We also discuss a new strategy to improve the syncing and submitting of layer-2 blocks.

Motivation

In the current implementation, Godwoken block interval time is longer than Ethereum and other layer-2 chains - it’s about the 40s, which brings terrible experiments to users.

In the early version of Godwoken, we kept the long layer-2 block interval for two reasons: 1. longer block interval reduces the frequency of submitting to CKB and saves more layer-1 block space. 2. longer block interval allows us to use a simple syncing strategy - the Godwoken nodes subscribe CKB chain, read layer-2 related transactions, then apply layer-2 blocks to the local state.

In the v0 version of Godwoken, We offer the instant finality feature to improve user experience. Users can get the result immediately after they send a transaction. But unfortunately, users cannot have this experience in the v1 Godwoken. For better compatibility with the Ethereum world, we removed the web3-provider plugin in v1 to support RPC level compatibility. Users can use Metamask or other tools to directly talk to the Godwoken chain. Still, ethereum tools don’t exactly behave the same, which brings some problems: Metamask only starts to update transaction status after the chain’s tip block number is bumped. Thus, since Godwoken has a long block interval, the Metamask won’t try to query the result of the transaction even if the transaction is already processed.

To solve this problem, we decide to speed up the block time. If we can lower the block interval, the user can quickly see transactions updated in Metamask. Besides this, we have another beneficiate - the more frequent blocks also increase the layer-2 TPS.

Thus, we believe to speed up the block production of Godwoken can improve the user experience, the compatibility with the Ethereum toolchain, and the layer-2 TPS.

Overview

In the current implementation, we use a simple syncing and submitting strategy:

  1. Godwoken node subscribes rollup related layer-1 transactions from CKB, then extracts the layer-2 block from these transactions.
  2. Node applies a new layer-2 block to the local state.
  3. If the node is a block producer, it produces a new layer-2 block and submits it to CKB.

The current process has a bottleneck. After the node sends a layer-2 block to CKB, it stops producing new blocks until the transaction is submitted on CKB, and it usually takes 3 ~ 4 CKB blocks(at least 24s ~ 32s). Since CKB has its unique proposal mechanism(CKB consensus protocol) the 3 ~ 4 CKB blocks to submitting is almost best we can do.

We propose a more sophisticated strategy to separate the block syncing, producing, and submitting process.

Syncing:

  1. The node subscribes to CKB and extracts layer-2 block from CKB transactions.
  2. If the node is read-only, it receives new blocks from the block producer node via P2P protocol.
  3. Then, the node applies the layer-2 block to the local state.

Producing:

  1. Block producer node produces new blocks every few seconds.
  2. The block producer node applies the new block into the local state before sending it to CKB.
  3. The node also sends the new block to read-only nodes via P2P protocol.
  4. Then, the node pushes the new block into a local submitting queue.

Submitting:

  1. The block producer node fetches layer-2 blocks from the local submitting queue and submits them to CKB.

With this new strategy, we decoupled the layer-2 block syncing, producing, and submitting, removing CKB block time dependency. But the submitting is still constrained by CKB block space, if layer-2 produces new blocks fast enough, it will occupy more block space than CKB can supply, and the submitting queue will grow until it reaches the limitation. The node stopped submitting and waited for CKB to package transactions.

We should choose a block time that can support a good user experience and does not occupy too much CKB block space.

  • CKB block supply is 597K every 8s in the best situation (see consensus.rs)
  • An ERC-20 transaction represented in a layer-2 block is 253 bytes

If we reduce the block time to ~8s, in the best situation, we can easily reach 200 TPS (let’s ignore other factors for now).

Compatibility

This change may affect some contracts, especially Defi contracts which use block numbers to calculate interests. To fix this problem, developers need to upgrade their contracts and use block timestamps to calculate interests. Fortunately, many developers have already done this.

5 Likes

This is an awesome post!

We should also bring this kind of discussion on twitter to make more people aware of.