Computron Estimator

[katelynsills]

If we follow a model where the contract creator is charged for all execution in the ZCFVat for that contract instance, as in #3294, then the contract creator will need to be able to pass on the costs to users. The contract creator will need to know three things in order to pass on costs:

1. The contract creator needs to know the extent to which the incoming message from the user can cause execution. In other words, there needs to be a clear understanding of how much execution the user can trigger (in the worst case? average case?) through that particular message. This will be easy or difficult depending on the complexity of the code. For example, in our simplest toy contract automaticRefund, the offerHandler is:

  const refund = seat => {
    offersCount += 1n;
    seat.exit();
    return `The offer was accepted`;
  };

This is simple to isolate and estimate. However, we also have complex examples. For instance, opening a vault loan requires scheduling a potential future liquidation, and whether that liquidation occurs depends dynamically on the price. So perhaps there needs to be a way to search through the potential branches given a particular code entry point to find the most costly path, the median/average cost of the execution path, and the cheapest path. This seems somewhat similar to code coverage tools.

2. For any particular path, the contract developer needs to know how much the meter will be deducted. This should not change often, as whether or not a meter is exhausted on-chain needs to be part of the determinism. In other words, the contract developer needs to know how many computrons an execution path will take.

3. The contract developer needs to know the price in RUN for an amount of computrons. The current price is helpful, but what the contract developer really needs to know is the future price, at the time that the user's message is being executed.

Number 3 is out of scope for a computron estimator and needs to be represented in a different issue, but I think Number 1 and 2 are in scope.

[dckc]

I wonder to what extent we owe a computron estimate on each of our APIs... And to what extent changes in computron cost constitute breaking changes.

[zarutian]

sorry, not sorry: Computrontimator