You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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!
The text was updated successfully, but these errors were encountered:
Is there an existing issue?
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 blurryLet'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 ./chain.yml
.--chain-config-override chain_id=MADARA_TEST
.serde_yaml::Value
, override the value we want by writing fields into that untypedValue
, and then useserde_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.Plus,
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!
The text was updated successfully, but these errors were encountered: