Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Collator: don't make blocks when there is no work to be done. #147

Closed
rphmeier opened this issue Dec 20, 2023 · 5 comments
Closed

Collator: don't make blocks when there is no work to be done. #147

rphmeier opened this issue Dec 20, 2023 · 5 comments

Comments

@rphmeier
Copy link
Contributor

rphmeier commented Dec 20, 2023

The default configuration of Substrate and Cumulus is to make blocks at all times. This is useful for pallets which autonomously use blockspace. The blobs runtime is purely reactive, so we can be more efficient by producing blocks only when there are transactions or events to respond to. We should alter the collator implementation to (by default) make blocks only when at least one of the following is true:

  1. There is least one transaction in the block
  2. There is an incoming downward message from the relay chain
  3. It has been at least 10 minutes since the previous block

The other approach would be to bake these rules into the runtime directly. However, rejecting blocks as invalid under such circumstances is quite dangerous in case there is an error. Later on, if there are unaligned collators, we might consider making these runtime rules. Given that there is no implicit reward for creating blocks, collators are not incentivized to diverge from the behavior of making empty blocks.

Note that this does not specifically account for runtime upgrades, which will most likely fall under rule (3) without some kind of special-casing that would require digging into the guts of Cumulus.

@pepyakin
Copy link
Contributor

This is a very good idea,

I am wondering what's the reasoning behind creating a block after 10 minutes timeout?

@rphmeier
Copy link
Contributor Author

The motivation is as a catch-all and heartbeat, basically to ensure that the chain is still obviously alive. Also, for the aforementioned runtime upgrades - without special casing, we would need to submit a blob to 'poke' the chain to react to the GoAhead signal.

@pepyakin
Copy link
Contributor

pepyakin commented Dec 22, 2023

Well, we are already checking the inbox on the relay-chain perhaps we could check goahead? The rest makes sense though.

@rphmeier
Copy link
Contributor Author

Fair! I suppose we'd just be reading a little bit more storage.

@pepyakin
Copy link
Contributor

pepyakin commented Jan 2, 2024

I assume this is closed by #156, closing. Reopen if that's not the case @rphmeier .

@pepyakin pepyakin closed this as completed Jan 2, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants