Plan for replacing priceFeeds, redirecting oracles #8740
Comments
Chris-Hibbert
added
enhancement
|
I should also have linked #8498, which is the change to ERTP and priceFeeds to stop adding the priceQuotes to recoverySets. |
|
price-feed-proposal.js seems to have the relevant pieces. More later... |
|
To the extent I understand that script, it looks like it's doing the initial set-up of oracles and priceFeeds. I presume that the process is different if the oracles already exist. Does it make more sense to create new oracles than to redirect existing ones? |
I'm studying the code, looking for reasons why it wouldn't also work for the case where the oracles already exist, and I haven't seen one yet. It's possible that the plan is as simple as:
|
instance, installation not updating in agoricNamesbefore and after the core-eval, I see the same board id for the installation and instance: core eval detailsUsing an a3p / dapp-offer-up local chain, I submitted add-stATOM-oracles.js and add-stATOM-oracles-permit.json using the |
|
Since the existing p.s. idea: merge this with the econCommitteeCharter? maybe not... this one needs a lot of power, and that one doesn't... or does it? |
|
@dckc I created #8868 to track the tasks I need to take care of in order to upgrade Zoe, Price feeds, Auction, and Vaults for upgrade-15. When I started thinking about replacing the price feeds and providing them to the Auction and Vaults as part of the upgrade, I remembered this discussion, and took another look. Re-reading it, I see one of the steps is |
Yes.
I wonder how they (auctions and vaults) can tell what the priceAuthority does to answer their request for a quote. For all they know, doesn't it wait for operators to submit prices? |
In the steady state, all they know is the last quote they received. They could check to see how old it is, but they don't currently. During startup or after upgrade, they're dependent on getting an initial price. Without it, they don't know how much collateral is worth, when/whether to liquidate, or what prices to charge in the auction. Perhaps it would be worth making the fixes that would be required to make the auction and vaultFactory be robust in the face of missing quotes, but we haven't chosen to do that yet. In the meantime, the auction and the vaultFactory expect the priceAuthority to have started before them. |
Right... but the way they get that initial price is by making an eventual send to a price authority, right? And for all they know, the price authority is a price aggregator, and the eventual send doesn't complete until enough operators submit prices that the price aggregator reports a price, right? |
|
From today's kernel meeting:
There are three on-chain events that must happen:
And there are three off-chain events that must happen:
The dependencies mean we split the on-chain events into two phases. The first phase deploys the new price-feed vats and also starts the new auctioneer vat. The second phase upgrades the Vaults vat. The phases are separated by off-chain oracle activity, so the overall sequence will be:
The #8400 -related storage growth (Quote Payments / recovery set, roughly half of the total) will stop once the oracles stop sending data to the old price feeds. Later, after we can survive it, we can terminate the old price feed vats, to actually reclaim the DB space consumed by the earlier growth (after #8928 is implemented and deployed). Note that the two on-chain phases could either be core-eval proposals (which only require a governance vote), or as chain-software upgrades (which require a governance vote, a chain halt, and validators to install new software). Installing the bundles is slightly cheaper ($20 each) to do during a chain-software upgrade, but not enough to drive the decision. The first step is to land a PR that makes the recovery sets optional. #8418 or #8498 would do, but @Chris-Hibbert pointed out that it would be smaller/safer to make a new PR which omits the delete-the-old-set code entirely (since we can't take advantage of that feature, since we're replacing the price-feed vats instead of upgrading them). So the real first step is for him to make a smaller branch and get it landed. We also need to change the price-feed contracts to set the option correctly. We believe that the existing on-chain auctioneer vat bundle is adequate (TODO @Chris-Hibbert: are there upgrade-enabling fixes we should deploy?), so we don't need any new code for it. Therefore, once the price-feed code isn't using recovery sets, we could cut bundles and install them to chain via txns. Then, we could make a core-eval proposal to deploy those bundles, and then wait for oracles to make their changes. Interaction with Zoe-Cycle FixesWe also examined the changes we want to address #8401. We are close to having Zoe fixes that stop leaving cycles around for old (exited) seats, which will address the majority of the problem. Once deployed, this will remove the other half of the kvStore growth rate.
PR #8697 breaks these cycles upon seat exit. That has been merged into a branch that is destined (via #8682) for landing in master, and is tenatively scheduled for chain-upgrade Given the timing, it might make sense to perform both the Zoe upgrade and the price-feed/auctioneer deployments together, in upgrade-15. Then we could perform the Vaults upgrade in a core-eval proposal, after oracles accept their invitations and start sending data to the new price-feed vats. But, upgrade-15 might get commandeered for other purposes (vat-network groundwork to enable IBC orchestration features), so the Zoe upgrade might get kicked out. If that happens, we should consider doing the Zoe upgrade as part of a core-eval proposal instead of a chain-software upgrade. We're worried about validator fatigue if the chain-software upgrades happen too quickly, but we're also worried about stopping the kvStore growth as quickly as possible (especially since we just doubled the growth rate by deploying stOSMO and stTIA). Using a core-eval proposal, which requires a stakeholder governance vote but not validator involvement, might be a good compromise. After the dust has settled, we can think about how we upgrade Zoe to avoid creating cycles in the first place (even for non-exited seats). Later still, we can figure out how to remediate the existing cycles (most of which will go away when we terminate the old price-feed vats, but some will still be left from non- price-feed contracts). |
That's all true, but the consequences are that the Vaults and Auction wouldn't get a price update until the oracles are completely ready, which means that our protection from price fluctuations would be inoperable until the priceFeeds come back. I'd be fine with this theory as a product decision, but absent that, I'd like to find a way to not switch Auctions and Vaults to new feeds until the new priceFeeds are functional. |
I've looked at the transcript above, and I'm not convinced it won't work. I'd like to see if the resulting Another thing I'm looking for is a list of all the priceFeeds and the parameters used to create them. Are those collected in one place? |
One list is published.priceFeed
The parameters used to create them.... let's see... I suppose they're all in a3p somewhere... but... agoric-sdk/packages/vats/decentral-main-vaults-config.json Lines 120 to 156 in ba3b776 The others are from core-eval proposals. stATOM proposal details include: {
AGORIC_INSTANCE_NAME: "stATOM-USD price feed",
IN_BRAND_DECIMALS: 6,
IN_BRAND_LOOKUP: ["agoricNames", "oracleBrand", "stATOM"],
IN_BRAND_NAME: "stATOM",
OUT_BRAND_DECIMALS: 4,
OUT_BRAND_LOOKUP: ["agoricNames", "oracleBrand", "USD"],
OUT_BRAND_NAME: "USD",
brandInRef: undefined,
brandOutRef: undefined,
contractTerms: {
POLL_INTERVAL: 30n,
maxSubmissionCount: 1000,
maxSubmissionValue:
115792089237316195423570985008687907853269984665640564039457584007913129639936n,
minSubmissionCount: 2,
minSubmissionValue: 1n,
restartDelay: 1,
timeout: 10,
}, |
|
Thanks. I found details for |
|
brands are added to They're in addAssetToVault.js. That link goes to master. I don't think they have changed significantly, but to find the code that's on chain, we have to trace back from const manifestBundleRef = {
bundleID:
"b1-903e41a7c448a41b456298404a1c32c69302574209c6a5228723ed19e2dd99f2a693641196445bc27a90e19e1dfadfe6b3d9c9a93f080ffa33a70908e5af4fff",
};to https://github.com/0xpatrickdev/agoric-vault-collateral-proposal/tree/main/bundles |
@Chris-Hibbert , I was thinking that this would require new tooling... but I was thinking that each time they pushed a price, they specified a pair (such as But on review of our agops oracle code, I see that's not how it works. When they push a price, they specify the relevant contract using To push to both new and old price feeds, they can just accept an invitation to the new feed and use Perhaps their tooling needs to be enhanced to deal with this situation, but |
…ation. (#9093) refs: #8740 ## Description Improved description of creating proposals and submissions in a3p-integration ### Security Considerations None ### Scaling Considerations None ### Documentation Considerations That's it. ### Testing Considerations None ### Upgrade Considerations None --------- Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com>
refs: #8740 closes: #8918 refs: #8400 ## Description Add a new Auction instance in A3P, so #8757 can make use of it. Also provides upgrade proposals which can be be applied to MainNet and other chains. ### Security Considerations N/A ### Scaling Considerations This is largely in service of #8400, which reports that priceFeed vats are accumulating garbage. This PR gives a new auction which can rely on new priceFeeds. The existing auction is not upgradeable and its pricefeeds can't be updated. ### Documentation Considerations No user-visible changes to behavior. ### Testing Considerations Tested in A3P ### Upgrade Considerations Auctions are not upgradeable, so we have to replace them and update their clients.
What is the Problem Being Solved?
#8400 explains that priceFeed vats are holding onto quote payments via recoverySets, creating an uncollectible cycle. In order to stop adding to the growing amount of garbage, we need to make the Auction and VaultFactory rely on a different priceFeed. Once the clients are pointed to a different source, we can decide when to kill those vats to cause the garbage to be freed.
Description of the Design
In order to switch to new priceFeeds, we need a plan that describes what it takes to redirect the oracles so we can replace the priceFeeds in the priceAuthorityRegistry.
Replacing the priceFeeds should be simple: the priceAuthorityRegistry has
registerPriceAuthority(pa, brandIn, brandOut, force). Ifforce = true, the old one is dropped.Security Considerations
More robustness, rather than a security issue.
Scaling Considerations
Garbage is accumulating.
Test Plan
Test in a3p to ensure the new fluxAggregator is getting price data.
Upgrade Considerations
Do we need new code anywhere in order to redirect oracles?
The text was updated successfully, but these errors were encountered: