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

Auto-provision smart wallet #8602

Merged
merged 5 commits into from
Dec 6, 2023
Merged

Auto-provision smart wallet #8602

merged 5 commits into from
Dec 6, 2023

Conversation

mhofman
Copy link
Member

@mhofman mhofman commented Dec 4, 2023

closes: #8558
refs: #8574

Best reviewed commit-by-commit

Description

This change implements smart wallet auto-provisioning by:

  • Checking if a smart wallet is already provisioned in vstorage during admission checks
  • Charging a new beans based fee if not
  • Generating a provision action when processing the smart wallet message based on whether the smart wallet is provisioned already or not

It does not mark whether a smart wallet provision is pending, and as such may result in provision beans fees being charged multiple times if smart wallet messages are submitted and included in new blocks before the provision message is executed by swingset.

This PR includes some necessary changes to the upgrade handler:

  • Generalizing the swingset parameters logic to always add new parameters using their default value in the upgrade handler

Security Considerations

The provision step in swingset does not change and still provides a nominal amount of IST during provisioning, for each provision message handled. As such the beans amount charged for auto-provisioning a wallet should be higher than the nominal amount transferred from the provision pool.

Scaling Considerations

None

Documentation Considerations

None

Testing Considerations

  • Added a docker upgrade-test to verify that auto-provisioning behaves as expected.
  • There is no existing CheckAdmissibility unit test infrastructure that could be extended to directly test the auto-provision fee behavior.
  • Similarly there is no existing msg_server unit test infrastructure that could be extended to directly test the generation of auto-provision action.
  • The unit test of the param migration was adapted to the new beahvior

Upgrade Considerations

Requires a new chain software consensus upgrade. This change is planned to be included in agoric-upgrade-13, and was actually first implemented against that release branch in #8574. The rebase was clean except for the renamed upgrade-test.
Added required logic to the upgrade handler for the new fee.

@mhofman mhofman added the force:integration Force integration tests to run on PR label Dec 4, 2023
@ivanlei ivanlei self-requested a review December 4, 2023 21:51
Copy link
Contributor

@JimLarson JimLarson left a comment

Choose a reason for hiding this comment

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

Go changes LGTM.

Copy link
Member

@michaelfig michaelfig left a comment

Choose a reason for hiding this comment

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

LGTM, just a couple of minor comments where I lacked a clear understanding of the code.

m := swingsetkeeper.NewMigrator(app.SwingSetKeeper)
err = m.MigrateParams(ctx)
if err != nil {
return fromVm, err
Copy link
Member

Choose a reason for hiding this comment

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

Why return fromVm? The prior return does mvm even on error. Maybe consider leaving an explanatory comment?

Copy link
Member Author

Choose a reason for hiding this comment

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

I assumed that when returning an error, the version map should be the "default" value, in this case the "from version map" even though the module manager's migration logic ran its course. I guess it's more a question of what is the best conceptual return value in this case, since if an error is returned, it panics.

Copy link
Member Author

Choose a reason for hiding this comment

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

Use mvm since it's less confusing and doesn't matter.

@mhofman mhofman added the automerge:rebase Automatically rebase updates, then merge label Dec 6, 2023
@mergify mergify bot merged commit dca42b9 into master Dec 6, 2023
70 checks passed
@mergify mergify bot deleted the mhofman/8558-auto-provision branch December 6, 2023 04:45
mhofman added a commit that referenced this pull request Dec 6, 2023
mhofman pushed a commit that referenced this pull request Dec 6, 2023
mhofman pushed a commit that referenced this pull request Dec 6, 2023
mhofman pushed a commit that referenced this pull request Dec 6, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
automerge:rebase Automatically rebase updates, then merge force:integration Force integration tests to run on PR
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Charge provisioning fee if smart wallet absent
3 participants