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

Configurable chain config (duh) #240

Closed
1 task done
cchudant opened this issue Sep 2, 2024 · 1 comment · Fixed by #255
Closed
1 task done

Configurable chain config (duh) #240

cchudant opened this issue Sep 2, 2024 · 1 comment · Fixed by #255
Assignees

Comments

@cchudant
Copy link
Member

cchudant commented Sep 2, 2024

Is there an existing issue?

  • I have searched the existing issues

Motivation

Last week with @Mohiiit we talked about where to put new configuration params - sometimes the line between what should be put in ChainConfig vs what should be put in cli arguments is a bit blurry
Let's fix that!

Request

I believe the difference should be related to how the user uses madara, not about technical details or whatnot.

CLI args should be how node operators (people running madara nodes) configure madara, and chain config should be how appchain developers (kakarot pragma & cie) configure their chain.
This means that block times, and other details like pending block tick time should be in chain config - even though it may be a debatable. The batch size for block production should also be in chain config instead of cli arguments as it is very related to pending block tick time -- we should expect people to tune both at the same time. This may seem a bit strange because this is a performance setting though.

In addition,

  • Chain config should be configurable from a .yml (or .toml?) file that we pass as argument --chain-config ./chain.yml.
  • The docs should provide an annotated (with comments) example file
  • Sometimes we would like to override some of the chain config via cli args -- for example, to set a special chain_id for a devnet or e2e test. It would look like --chain-config-override chain_id=MADARA_TEST.
    • technical details: this is easy to do, we would just need to load the chain config as a serde_yaml::Value, override the value we want by writing fields into that untyped Value, and then use serde_yaml::from_value to get a ChainConfig struct. This means that this would reuse the same code for deserializing Felts and stuff as the config file, the deserialization is done by serde.
    • stuff like versioned_constants may require more thought to deserialize from cli args - let's just not support that because I don't really see any usecase for that

Plus,

  • We may want "presets" in the future, to configure in a single cli arg a devnet/full node syncing from mainnet/other chains
    • i don't know how this would really look in practice, maybe we can get away with just switching between different preset chain configs? the question is whether presets should affect cli arg config.

Thoughts? :)

I am not sure if yml is better than toml, I think starknet people are more familiar with toml? what do you think?
I don't want json as it can't have comments.

Solution

No response

Are you willing to help with this request?

Yes!

@azurwastaken
Copy link
Contributor

Hi, would like to take it :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: Done
Development

Successfully merging a pull request may close this issue.

2 participants