metering dependency strategy

[dckc]

What is the Problem Being Solved?

We're considering a patch to endo, applied using patch-package in agoric-sdk. Does that entail a change of metering version?

Probably, but we haven't been evaluating metering changes at that level of detail, to date.

Description of the Design

needs-design

Some ideas... take a careful look at the ses / supervisor bundle that goes into vats... and liveslots. Figure out which of these impacts metering outcomes.

Security Considerations

?

Test Plan

We currently have a test that attempts to detect metering changes in XS; the outcome of this design is likely

cc @kriskowal

[mhofman]

From what I recall the lockdown and supervisor bundles are stored in the kv store the first time ever the kernel is started, so this is a problem only if 2 validators start from 2 different versions of the SDK. Without state sync a validator has technically to catch up, and will quickly fail if the bundles don't match (especially if we ever move the snapshot hashes into consensus in anticipation of state sync, see #5542 and #3769)

[Tartuffo]

In talking with @kriskowal, whenever we sync Endo versions, we should update the metering version, just in case.

[kriskowal]

I’ll make a note in MAINTAINERS.md with the process I’ve been using to synchronize versions from Endo and put a line item for bumping the meter version in that process.

[kriskowal]

I believe unconditionally bumping the meter each time we sync Endo is sufficient to catch all cases when syncing Endo may have caused a change in behavior, and the cases where it overreaches are tolerable. I’ve updated the process for syncing Endo and the process has worked a couple times, so I’m going to close this as addressed.

There may be a more surgical approach, but I believe that the real backstop for consistency is going to be capturing versions of swingset workers with a separate lockfile. This will probably obviate the need for meter versioning entirely. It is sufficient to know that workers under development are not consistent from hash to hash, but any vat pinned to a worker version will be consistent over time by other means.