allow Wallets to invoke no-return functions

[Chris-Hibbert]

What is the Problem Being Solved?

Getting updated prices from Oracles is currently expensive to operate on chain. With Upgrade-18, we've addressed a number of issues, and performance should continue to improve as vats are slowly cleaned up. It's still the case that most of the activity on chain is due to price updates. When the chain has had performance issues in the past, we could see that it deteriorated further when the oracles supplied price updates. Since our plans will lead to increased load generally, we should address this bottleneck before it causes further issues.

Description of the Design

The goal is to reduce the number of round trips, contract invocations, and middlemen involved in providing updates. Currently, the design of smartWallets only supports interacting with contracts by invoking a continuing invitation. This requires asking the smartWallet to request an invitation from the contract, which has to be exercised via Zoe before a response comes back to the smartContract

sequenceDiagram
  Participant Oracle
  Participant SmartWallet
  participant Contract
  participant Zoe

  Oracle ->> SmartWallet: new price
   SmartWallet -->> Contract: sendInvitation 
   Contract -->> Zoe: create Invitation
   Zoe -->> Contract: invitation
   Contract -->> SmartWallet: invitation
   SmartWallet -->> Zoe: make offer
  Zoe -->> SmartWallet: offer result
   Zoe -->> Contract: invoke offer
   Contract -->> Zoe: offer results

Loading

If SmartWallets allowed contracts to provide a second type of message that can only return data, the request could go directly to the contract, with a much simpler flow:

sequenceDiagram
  Participant Oracle
  Participant SmartWallet
  participant Contract

  Oracle ->> SmartWallet: new price
   SmartWallet ->> Contract: updatePrice
   Contract ->> SmartWallet: success | failure

Loading

The proposal is to prototype this, and build out the APIs that oracles would need to use

Security Considerations

There shouldn't be any security consequences.

Scaling Considerations

It is hoped that this will improve chain performance on what may be our most frequent operation at present.

Test Plan

extensive tests.

Upgrade Considerations

This would have to be rolled out in stages, since there would be changes to smartWallet, fluxAggregators, and Oracles.