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

add marketplace upgrade type #1850

Merged
merged 9 commits into from
Aug 14, 2024
Merged

add marketplace upgrade type #1850

merged 9 commits into from
Aug 14, 2024

Conversation

imabdulbasit
Copy link
Contributor

No description provided.

@imabdulbasit imabdulbasit changed the title add marketplace upgrade type WIP - add marketplace upgrade type Aug 13, 2024
@imabdulbasit imabdulbasit changed the title WIP - add marketplace upgrade type add marketplace upgrade type Aug 13, 2024
@imabdulbasit imabdulbasit marked this pull request as ready for review August 13, 2024 20:36
UpgradeType::ChainConfig { chain_config } => {
base_fee = std::cmp::max(chain_config.base_fee, base_fee);
}
if let UpgradeType::ChainConfig { chain_config } = upgrade.upgrade_type {
Copy link
Contributor

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!

Copy link
Contributor Author

@imabdulbasit imabdulbasit Aug 14, 2024

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

.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,
Copy link
Contributor

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.

Copy link
Contributor Author

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.

Copy link
Contributor

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.

Copy link
Contributor

@tbro tbro left a 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.

@imabdulbasit imabdulbasit force-pushed the ab/marketplace-upgrade-type branch 2 times, most recently from fbec576 to 67384e8 Compare August 14, 2024 13:52
@imabdulbasit imabdulbasit enabled auto-merge (squash) August 14, 2024 14:00
@imabdulbasit imabdulbasit merged commit c408e5e into main Aug 14, 2024
13 checks passed
@imabdulbasit imabdulbasit deleted the ab/marketplace-upgrade-type branch August 14, 2024 14:12
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

Successfully merging this pull request may close these issues.

3 participants