When replacing priceFeeds, reset roundID in vstore

[Chris-Hibbert]

What is the Problem Being Solved?

When priceFeed contracts are replaced, the new one starts writing to vstorage at the same node the old contract was writing to, but it doesn't start writing until it gets its first price data from an oracle. The new priceFeed contract expects roundIds to start from zero, but the oracles don't know that, and vstorage continues to hold the last value of roundId, startedAt and startedBy.

Description of the Design

Either reset the node contents to empty (if the oracles can handle that) or update the record with a roundId of 0.

Security Considerations

Not much impact on overall security

Scaling Considerations

Not an issue.

Test Plan

We need to coordinate with oracle providers to ensure we choose an approach that works with them.

Upgrade Considerations

See above.

[mhofman]

Discussed alternatives:

• have the price feed accept an arbitrary gap for the first round.
  • "cleanest" as it doesn't have any externally visible changes
• use a different price feed name
  • requires operators to switch config on top of accepting new invites. Results in proliferation of price feeds in vstorage, and may possibly break some external dashboards?
• reset vstorage latestRound to 0
  • requires changes to operator software (already implemented?), and a possibly a manual intervention from operators when accepting the new invite