You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The current proposal builder architecture allows the specification of bundles, core-eval manifests, and their parameters.
These builders can be executed:
directly by validators as part of the chain bootstrap
by any user, to generate bundles and core-eval governance to submit to the chain
It would be useful also to enable the execution of proposal builders by validators as part of a software upgrade.
Description of the Design
Specify the proposal builders to execute as part of the "upgrade plan" submitted to governance. The plan is just a JSONified object, so we can add a "coreProposals": [...] property to it, using the same data structure as in our SwingSet configuration files (packages/vats/decentral-*-config.json).
Parse any upgrade plan information from agd's first AG_COSMOS_INIT message
After SwingSet initializes, use a variant of the genesis coreProposals handling to run each proposal builder and:
a. extract the bundle entrypoint specifiers
b. bundle the specified entrypoints
c. controller.installBundle each of the bundles (idempotent)
d. pass through the bundle specifiers
e. create the core-eval scripts configured with the coreProposal options and the appropriate bundle specifiers
commit the swing-store so that the bundles are available for the core-evals
push each created core-eval action on the back of cosmic-swingset's highPriorityQueueStorage
return control to agd, and let normal chain scheduling promptly process the core-evals
Security Considerations
No more dangerous than genesis core-eval, and easier to audit than individual user-submitted core-evals from non-SDK sources.
Scaling Considerations
n/a
Test Plan
Test the software upgrade coreProposals via the Docker deployment upgrade test, using it to install or upgrade a new feature (such as the network and IBC vats).
Upgrade Considerations
Designed to assist upgrade.
The text was updated successfully, but these errors were encountered:
What is the Problem Being Solved?
The current proposal builder architecture allows the specification of bundles, core-eval manifests, and their parameters.
These builders can be executed:
It would be useful also to enable the execution of proposal builders by validators as part of a software upgrade.
Description of the Design
"coreProposals": [...]
property to it, using the same data structure as in our SwingSet configuration files (packages/vats/decentral-*-config.json
).agd
's firstAG_COSMOS_INIT
messagecoreProposals
handling to run each proposal builder and:a. extract the bundle entrypoint specifiers
b. bundle the specified entrypoints
c.
controller.installBundle
each of the bundles (idempotent)d. pass through the bundle specifiers
e. create the core-eval scripts configured with the coreProposal options and the appropriate bundle specifiers
cosmic-swingset
's highPriorityQueueStorageagd
, and let normal chain scheduling promptly process the core-evalsSecurity Considerations
No more dangerous than genesis core-eval, and easier to audit than individual user-submitted core-evals from non-SDK sources.
Scaling Considerations
n/a
Test Plan
Test the software upgrade coreProposals via the Docker deployment upgrade test, using it to install or upgrade a new feature (such as the network and IBC vats).
Upgrade Considerations
Designed to assist upgrade.
The text was updated successfully, but these errors were encountered: