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

feat (l2): hard fork #591

Merged
merged 19 commits into from
Nov 18, 2024
Merged

feat (l2): hard fork #591

merged 19 commits into from
Nov 18, 2024

Conversation

faultytolly
Copy link
Contributor

Description


Closes #XXX

All items are required. Please add a note to the item if the item is not applicable and
please add links to any relevant follow-up issues.

PR review checkboxes:

I have...

  • Added a relevant changelog entry to the Unreleased section in CHANGELOG.md
  • Targeted PR against the correct branch
  • included the correct type prefix in the PR title
  • Linked to the GitHub issue with discussion and accepted design
  • Targets only one GitHub issue
  • Wrote unit and integration tests
  • Wrote relevant migration scripts if necessary
  • All CI checks have passed
  • Added relevant godoc comments
  • Add an issue in the e2e-tests repo if necessary

SDK Checklist

  • Import/Export Genesis
  • Registered Invariants
  • Registered Events
  • Updated openapi.yaml
  • No usage of go map
  • No usage of time.Now()
  • Used fixed point arithmetic and not float arithmetic
  • Avoid panicking in Begin/End block as much as possible
  • No unexpected math Overflow
  • Used sendCoin and not SendCoins
  • Out-of-block compute is bounded
  • No serialized ID at the end of store keys
  • UInt to byte conversion should use BigEndian

Full security checklist here


For Reviewer:

  • Confirmed the correct type prefix in the PR title
  • Reviewers assigned
  • Confirmed all author checklist items have been addressed

After reviewer approval:

  • In case the PR targets the main branch, PR should not be squash merge in order to keep meaningful git history.
  • In case the PR targets a release branch, PR must be rebased.

@faultytolly faultytolly requested a review from a team as a code owner November 5, 2024 13:39
proto.MessageName(&vestingtypes.PermanentLockedAccount{}): {},
}

const BumpSequence = 1_000_000_000
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
const BumpSequence = 1_000_000_000
const BumpSequence = 10_000_000_000


ctx := sdk.UnwrapSDKContext(goCtx)

var allErrors error
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is weird, you're making a stack of errors
You should only call Join once

Comment on lines 147 to 161
err := m.bumpAccountSequence(ctx, account)
allErrors = errors.Join(allErrors, err)
} else {
// check if it can be handled by something custom
for _, f := range m.accountBumpFilters {
toBump, err := f(accType, account)
if err != nil {
allErrors = errors.Join(allErrors, fmt.Errorf("filter account: %w", err))
return false
}
if toBump {
err := m.bumpAccountSequence(ctx, account)
allErrors = errors.Join(allErrors, err)
break
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can refac to only call bump once


err := m.upgradeKeeper.ScheduleUpgrade(ctx, upgradetypes.Plan{
Name: fmt.Sprintf("upgrade-drs-%d", drs.DrsVersion),
Height: ctx.BlockHeight() + 1,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

agree, not sure why the upgrade is scheduled in the next block and not the same..

Comment on lines 197 to 201
func (m msgServer) updateDrsVersion(ctx sdk.Context, drsVersion uint64) {
oldParams := m.rollapParamsKeeper.GetParams(ctx)
oldParams.DrsVersion = uint32(drsVersion)
m.rollapParamsKeeper.SetParams(ctx, oldParams)
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is it easier to just leave this to the upgrade?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

no need to do it here imo

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think is better here, the upgrade handler I think is responsability of the rollapp, as it kind of case by case and it can't be generic?

@danwt
Copy link
Contributor

danwt commented Nov 11, 2024

+1 height is a blocker

Copy link
Contributor

@srene srene left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why do we have two separate consensus messages for the upgrade? bump account sequencers + updateDRS? couldnt we do it with a unique upgradedrs message and include the drs update version and bumpsequences logic in the necssary upgrade handler?


err := m.upgradeKeeper.ScheduleUpgrade(ctx, upgradetypes.Plan{
Name: fmt.Sprintf("upgrade-drs-%d", drs.DrsVersion),
Height: ctx.BlockHeight() + 1,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

agree, not sure why the upgrade is scheduled in the next block and not the same..


m.updateDrsVersion(ctx, drs.DrsVersion)

err := m.upgradeKeeper.ScheduleUpgrade(ctx, upgradetypes.Plan{
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i think besides the scheduleupgrade we need to call the SetUpgradeHandler, otherwise it the node stops necause it does not find an upgraded handler for the scheduled upgrade.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

but we dont have a way to setup a generic handler

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The way it works is that it uses the upgrade name to get the handler, I understand when the fork happens there will be a consensus on the next version of the app to use. And this version should include a handler.

@danwt
Copy link
Contributor

danwt commented Nov 12, 2024

@srene

why do we have two separate consensus messages for the upgrade? bump account sequencers + updateDRS? couldnt we do it with a unique upgradedrs message and include the drs update version and bumpsequences logic in the necssary upgrade handler?

Hey sergi

-Not all upgrades will require sequence bump
-Sometimes you want to sequence bump without upgrade

Comment on lines +199 to +206
currentParams := m.rollapParamsKeeper.GetParams(ctx)
if currentParams.DrsVersion == uint32(newVersion) {
return false
}

currentParams.DrsVersion = uint32(newVersion)
m.rollapParamsKeeper.SetParams(ctx, currentParams)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

still not sure about this but nvm


if needUpgrade {
err := m.upgradeKeeper.ScheduleUpgrade(ctx, upgradetypes.Plan{
Name: fmt.Sprintf("upgrade-drs-%d", drs.DrsVersion),
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

not sure how this name is going to work since in general you will need to upgrade from a specific version TO a specific version

// AccountBumpFilterFunc is a function signature that filters accounts whose sequence should be bumped.
// IT is passed the account proto name to avoid re-computing it, it is also passed the account in case
// casting is needed.
type AccountBumpFilterFunc = func(accountProtoName string, account authtypes.AccountI) (bool, error)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As this type is addition to the handleAccounts list
I would call it differently.
somthing like AccountBumpExtraTypes

accType := proto.MessageName(account)
_, ok := handleAccounts[accType]
i := 0
for !ok && i < len(m.accountBumpFilters) {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if a filter returns ok=true, the loop still continues instead of breaking and calling bumpAccountSequence

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the loop is for !ok..

accType := proto.MessageName(account)
_, ok := handleAccounts[accType]
i := 0
for !ok && i < len(m.accountBumpFilters) {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why not using range m.accountBumpFilters

@mtsitrin mtsitrin merged commit 55894ea into main Nov 18, 2024
7 checks passed
@mtsitrin mtsitrin deleted the tip/rdk_hardfork branch November 18, 2024 13:24
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants