how to manage metering/cost changes across upgrade?

[warner]

What is the Problem Being Solved?

The exact metering usage of a contract will be a function of several things:

• the top-level code of the contract
• the full transitive dependency graph of the contract
• the contents of the ZCF bundle (which comes from zoe, plus dependencies)
• the contents of liveslots (except for the GC-sensitive portions we put in the "unmetered box")
• the full transitive dependency graph of liveslots
• the specific version of XS (which we summarize into e.g. xs-meter-10)

Contract owners (the party who deploys the contract, by calling E(zoe).startInstance(installHandle)) are interested in how many computrons the various contract operations will cost, because they must set the prices which their instance will charge.

We need to figure out some practical way to manage this.

We expect the primary tool will be some form of simulator: a tool the potential contract owner can run locally, like a unit test, which emits a report showing the computron costs of various operations. The contract author should provide the code that gets run during this simulation.

Beyond that, we need to plan for changes in the metering usage, which is closely tied to whatever our upgrade story is going to be. If/when we have a way to upgrade Zoe, then any contracts instantiated after the upgrade will potentially use a different copy of ZCF, and will therefore have different metering numbers. If/when we have way to upgrade XS in-place (and come up with a way to deal with changes to the historical metering consumption, i.e. ignore all usage before the upgrade point), then metering after the XS upgrade will be different.

cc @katelynsills @rowgraus

Description of the Design

Security Considerations

Test Plan

[dckc]

@dtribble I heard you propose a requirement about replaying contracts without being sensitive to (some level of?) changes to zcf.

Do you consider that a requirement for treasury?

Conservatively, I'm going to set the milestone as if the answer is yes.

[dtribble]

Yes. It is likely to be a requirement for phase 1 as part of supporting upgrade of treasury after phase 1. It could be dropped if we address that differently

[dckc]

That suggests a test plan consisting of upgrading a treasury contract.

@rowgraus @katelynsills it also suggests a corresponding user story... though if we knew the details, we would address them before treasury release :) so the test is likely to be more artificial. Oh... but you might know of relevant upgrade stories from other DeFi projects that we might simulate.

[dckc]

We expect the primary tool will be some form of simulator: a tool the potential contract owner can run locally, like a unit test, which emits a report showing the computron costs of various operations.

which see #3301

[Tartuffo]

@warner Needed for MN-1? Subsumed by some other metering ticket? @rowgraus FYI