Performance issues in MainNet contracts

[Chris-Hibbert]

What is the Problem Being Solved?

We have observed performance issues in mainNet contracts. Upgrade 18 dealt with some of them, but others remain to be addressed. This issue provides an overview of some problems we foresee and discusses some possible approaches to addressing them. Each approach will get a separate issue as we consider pursuing it.

History

There are two major performance challenges that we have observed on MainNet that we haven't sufficiently addressed yet.

• ERTP support for NFT uses CopyBags. The KREAd dApp made it clear that performance of insertions and deletions is linear in the size of each purse.
• The price update system, from Oracles using smartWallets to update priceFeeds to the use of QuotePayments, to Notifiers is a performance drag. We've relieved some pressure by removing QuotePayments from RecoverySets, so we no longer see address spaces growing quickly, but there are reasons to believe further work may be called for.

Non-Fungibles

KREAd demonstrated that our representation for non-fungible tokens performs very poorly. According to the analysis in #8862, the work to add or remove an item grows linearly with the size of the collection. KREAd was an especially egregious example of this, since its storefront had two purses with copies of every character and item for sale. We should expect similar needs in other dApps. We need a more performant implementation.

This won't be a serious problem until someone wants to add a dApp that uses non-fungibles, and the dApp succeeds and gets a moderate amount of interest.

I think the fix will be straightforward, but it'll take some design time.

Issue: #10920

PushPrices

There are a number of performance issues with the way we get updated prices from Oracles. We've addressed a few of them, with changes to ERTP handling of recoverySets and installing new priceFeed vats. There are still known problem areas. At the moment, price updates are still the main cause of load on our chain. Before those fixes were added, we noticed that whenever there was any load on the system, priceUpdates would exacerbate the situation. We're planning to add load for fastUSDC and orchestration generally. It might be worth improving the performance of price updates before there's a problem.

QuotePayments

Delivering quotes packaged as payment objects doesn't solve a problem anyone has currently. It's more heavyweight than is necessary and provides no extra value. The simplest change would be to switch to an API that provides only the quoteAmount. None of the current uses of quotes needs to be able to prove to anyone else that the quote is valid, so this is sufficient for now. If there were clients that needed to share their quotes with others, a new feature for ERTP that supported branded amounts would be a better solution.

Payments can be consumed by anyone who holds them, so they aren't great for sharing. branded quotes could be immutable, and could be verifiable.

Wallets & Continuing Invitations

Each time an Oracle wants to provide a price update, it exercises a continuing invitation, which sends a message to the contract, and then sends a message to Zoe, which sends another message to the contract. The return value from the contract is returned through Zoe, though Zoe doesn't add anything valuable. We can design a less expensive mechanism that should be less work for the Oracles to interact with.

One approach to simplifying this would be to extend continuingInvitations to support methods that can only return data. Once we can do that, we would add a method on the fluxAggregator that the Oracles could call directly.

Issue: #10926

fluxAggregator plus scaledPriceAuthority

The current way of processing price updates requires two separate contracts, one of which doesn't do more than multiply the quote by a constant and re-wrap the priceQuote from a different issuer. This could be simplified to drop the extra vat and scale the results when first providing a quote.

Cosmos-level oracle support

There is apparently support for oracles providing price information directly at the Cosmos level. This would presumably be much cheaper to process, since it wouldn't involve Zoe or contracts, and might even avoid the smartWallet. It's not clear how easy it would be to plumb the quotes back up to the contract level. The main drawback is our preference is for javascript solutions, as they're more maintainable for us. I include the idea here only for completeness.

Recommendations

The heavyweight quote objects are much less of an obstacle now than when we were unintentionally retaining them in
recoverySets. Garbage collecting them requires work, but with N priceQuotes going to two contracts about once every 5 minutes,
it's not a huge deal. As the number of collaterals in vaults grows over time, this work keeps growing.

If we provided lighter-weight quotes, the changes to auctions and vaults are completely within our control, so we could take
advantage of the savings in the next release. Adding support for branded Issuers wouldn't be a lot of work, and changing the way quotes are provided would require a couple of releases to do the version migration release dance, but would be easy to code.

My instinct is that oracles providing prices happens much more often and is more expensive than prices being published to contracts. This makes me suspect that the biggest bang would come from adding something to smartWallets to allow us to avoid continuing invitations.

In order to add an alternative to continuing Invitations, we would first make the change to wallets, then upgrade
fluxAggregators to make a new API available to Oracles, and then modify the oracle code. I'll investigate the oracle code to
see how much wrok would be required to allow oracles to invoke an API directly rather than via continuing invitations.