-
Notifications
You must be signed in to change notification settings - Fork 208
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
Conversation
48d8ae7
to
cd19304
Compare
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.
Go changes LGTM.
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.
LGTM, just a couple of minor comments where I lacked a clear understanding of the code.
golang/cosmos/app/app.go
Outdated
m := swingsetkeeper.NewMigrator(app.SwingSetKeeper) | ||
err = m.MigrateParams(ctx) | ||
if err != nil { | ||
return fromVm, err |
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.
Why return fromVm
? The prior return does mvm
even on error. Maybe consider leaving an explanatory comment?
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.
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.
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.
Use mvm
since it's less confusing and doesn't matter.
packages/deployment/upgrade-test/upgrade-test-scripts/unreleased-upgrade/actions.test.js
Outdated
Show resolved
Hide resolved
892c6d3
to
d9cee0a
Compare
closes: #8558
refs: #8574
Best reviewed commit-by-commit
Description
This change implements smart wallet auto-provisioning by:
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:
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
CheckAdmissibility
unit test infrastructure that could be extended to directly test the auto-provision fee behavior.msg_server
unit test infrastructure that could be extended to directly test the generation of auto-provision action.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.