-
Notifications
You must be signed in to change notification settings - Fork 85
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
add marketplace upgrade type #1850
Conversation
sequencer/src/genesis.rs
Outdated
UpgradeType::ChainConfig { chain_config } => { | ||
base_fee = std::cmp::max(chain_config.base_fee, base_fee); | ||
} | ||
if let UpgradeType::ChainConfig { chain_config } = upgrade.upgrade_type { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So this Vec<&Upgrade>
holds the actions we need to perform per type per upgrade? Is that right? So we are saying that for every upgrade we need to set base_fee to the maximum base fees of all upgrades. I think implicit in this is that all base_fee can only ever increment. Just checking my understanding. thanks!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Vec<Upgrade>
is basically array of tables from the genesis toml file. Yes, we set base fee to max base fee if genesis toml file has fee upgrades (chain config upgrades) specified. This is required by builder as builder takes base_fee parameter which can not be updated as it doesn't know about validated state
types/src/v0/impls/header.rs
Outdated
.get(&version) | ||
.map(|upgrade| match upgrade.upgrade_type { | ||
match instance_state.upgrades.get(&version) { | ||
Some(upgrade) => match upgrade.upgrade_type { | ||
UpgradeType::ChainConfig { chain_config } => chain_config, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not looking for a change here, just trying to improve my understanding. These semantics are confusing to me. Why do we have an UpgradeType:ChainConfig
. Couldn't we just be upgrading between versions, and have the version define what is included in the upgrade? For example, I would imaging that the upgrade type would be Marketplace
and ChainConfig
upgrade would happen "under the hood" since it is a dependency of marketplace.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
hmm I think renaming this upgrade type to FeeUpgrade would be better. So, fee upgrade would require a new chain config that is provided in the toml file.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah! yes I think so too.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good. I've made a couple of comments but they are not to request changes, but are just to help me understand.
fbec576
to
67384e8
Compare
67384e8
to
2a0f407
Compare
No description provided.