Enforce xsnap version on chain start #7012
Comments
mhofman
added
enhancement
|
@mhofman What were you thinking we could use as a version number/string? If the goal is to detect when agoric-sdk has been updated but |
|
@ivanlei and I figure that it'd be nice to have this, but it's not such a huge footgun that we really need it in this release. Validators have multiple ways to fail to recompile everything, but failing to run |
|
Given that we have stricter consensus checks now (snapshot hashes, and soon computrons per delivery), and that a validator can recover by using state-sync, I agree this is not really needed anymore. |
|
Note to self:
|
This is a quick hack to embed a distinctive string into the xsnap binary, for use by the agoric `agd` command, to ensure that xsnap has actually been recompiled recently. If a validator somehow forgets to re-compile xsnap, `agd` will notice the mismatch and complain, rather than proceeding with the wrong executable. Running `xsnap -n` emits this "network upgrade version" string, currently `agoric-upgrade-10`. In the future, we'll update this string to something new (and perhaps more fine-grained than a once-per-chain-upgrade value) when we make changes to xsnap. refs Agoric/agoric-sdk#7012
This is a quick hack to assert that xsnap has been recompiled recently. `bin/agd` now runs `xsnap -n` to get the "network upgrade version", and asserts that it matches an expected value of `agoric-update-10`. If a user has somehow failed to recompile `xsnap`, their old copy won't understand the `-n` command, and `agd` will fail, rather than running a stale version (with highly confusing results). refs #7012
|
@ivanlei and @arirubinstein and I added a hack just now, in #7831 and agoric-labs/xsnap-pub#41 , to add an This is enough to solve today's problem, which is to insist that xsnap has been recompiled recently (at least after the landing of #7831). We'll need to reconsider this more carefully next week, to solve the next problem, which begins when we make any change to XS or xsnap, or when we want to introduce the
|
This is a quick hack to embed a distinctive string into the xsnap binary, for use by the agoric `agd` command, to ensure that xsnap has actually been recompiled recently. If a validator somehow forgets to re-compile xsnap, `agd` will notice the mismatch and complain, rather than proceeding with the wrong executable. Running `xsnap -n` emits this "network upgrade version" string, currently `agoric-upgrade-10`. In the future, we'll update this string to something new (and perhaps more fine-grained than a once-per-chain-upgrade value) when we make changes to xsnap. refs Agoric/agoric-sdk#7012
This is a quick hack to assert that xsnap has been recompiled recently. `bin/agd` now runs `xsnap -n` to get the "network upgrade version", and asserts that it matches an expected value of `agoric-update-10`. If a user has somehow failed to recompile `xsnap`, their old copy won't understand the `-n` command, and `agd` will fail, rather than running a stale version (with highly confusing results). refs #7012
This is a quick hack to assert that xsnap has been recompiled recently. `bin/agd` now runs `xsnap -n` to get the "network upgrade version", and asserts that it matches an expected value of `agoric-update-10`. If a user has somehow failed to recompile `xsnap`, their old copy won't understand the `-n` command, and `agd` will fail, rather than running a stale version (with highly confusing results). refs #7012
This is a quick hack to assert that xsnap has been recompiled recently. `bin/agd` now runs `xsnap -n` to get the "network upgrade version", and asserts that it matches an expected value of `agoric-update-10`. If a user has somehow failed to recompile `xsnap`, their old copy won't understand the `-n` command, and `agd` will fail, rather than running a stale version (with highly confusing results). refs #7012
closes: #9614 closes: #7012 refs: agoric-labs/xsnap-pub#49 ## Description Wire a mechanism to force rebuilds of xsnap when some build environments change, or if the xsnap binary is found to be out of date through the embedded xsnap package version. Moves the `agd build` check to depend on a version check implemented by the xsnap package, which now only depends on the package version that is dynamically inserted instead of an explicit magic string that wasn't getting updated. #7012 (comment) expressed concerns with relying on the xsnap package version, however: - any changes to `xsnap-pub` or `moddable` submodules would result in a change to the checked in `build.env` file, which would be detected by `lerna` during the publish process. While a version bump would not apply for contributors of the sdk (aka not every xsnap change results in a version change), it will apply for anyone using published versions, even if the change is in submodules only. - By having the version check look up the expected version from the `package.json` file directly, we avoid having to modify both the `package.json` file and the check itself. Only the automatically generated single publish commit will trigger a forced rebuild, and satisfy the check on its own, - At the same time we remove the dependency of `agd build` onto the the internal structure of xsnap. ### Security Considerations Forces all validators to use the expected version of xsnap ### Scaling Considerations Does a few more checks when building xsnap, and causes full rebuilds in some cases where they might not be strictly necessary. ### Documentation Considerations Should all be transparent ### Testing Considerations Manually tested by touching the xsnap package version, or reverting just the release binary to a previous copy (or deleting altogether). If the binary is meddled with like this, `agd build` checks will fail, but a manual `yarn build` will fix. I thought this was better than transparently forcing a rebuild in that abnormal situation. ### Upgrade Considerations Smoother upgrades by validators
What is the Problem Being Solved?
If an upgrade contains an xsnap-worker minor version change (the kind that is snapshot and JS execution compatible), the validator must build and use this new version. See #6361
If they don't their node will likely fall off consensus at some point. While our update instructions include
yarn install && yarn build, which will rebuild XS, the chain process would likely not fail early enough if those steps were not performed, resulting in a hard to recover state.Description of the Design
Include a check in when swingset or cosmic-swingset starts that the xsnap version is the expected one.
This check should be by-passable so that we can manually use other XS revisions that are supposed to be consensus matching.
Likely related to #6596
Security Considerations
This would ensure all nodes will run as expected after an upgrade, guaranteeing the health of the chain.
Scaling Considerations
Test Plan
The text was updated successfully, but these errors were encountered: