Smart wallet middleware

What is the Problem Being Solved?

The existing Wallet UI is very close to using a model that is possible to implement via CosmJS-based middleware directly to the on-chain backend. This issue is to track the pieces needed for an end-to-end.

Description of the Design

On-chain, per-account state is accessible via Cosmos queries, events, and simple marshalled eventual sends can be made via transactions.

• on-chain notifiers are published by middleware both as updates to queriable state, and susbcribable Cosmos events containing notifier records serialised in the context of the account. This is possible with the x/swingset storage API.
• UI middleware subscribes to events, then issues initialisation queries to obtain and deserialise those records.
• replace ocaps with a Presence that submits a MsgWalletAction Cosmos transaction to do a semantic operation (i.e. only one message needed per UI action)
• these actions are powerful, so may need confirmation from an external signer (Keplr or MetaMask)
• an “authz” designation from that signer to a password-protected, per-wallet-UI key can cut down on confirmations #4406
• any state changes will be published via the notifiers, so that multiple client UIs can be kept consistent
• the async result of a MsgWalletAction is also published as a Cosmos event, but is designed only to report success or failure to the (single) calling UI initiating it (if any)

NOTE: the wallet backend implementation is specifically not included in this item. For now, the backend will be a stub that produces:

type WalletBackend = Notifier<{
  contacts: Notifier<{
    meta: {
      id: string,
    },
    name: string,
    lastReceivedMessage: any,
    actions: ERef<{
      sendMessage: (data: any) => void,
    }>,
  }>,
}>

E(contact.actions).sendMessage('Hello, world!');

Security Considerations

Key management is important. Will need to be reviewed by our security experts.

Test Plan

Integration testing, probably manual for now.

[dckc]

I’d like to keep using the checklist here, so I’m re-opening this.

In particular, our initial choice of marshaller for the wallet state publishes purses etc. so it needs work, as discussed in https://github.com/Agoric/agoric-sdk/pull/5701#discussion_r917077689

[dckc]

As noted in #3901 , we found the continuing invitation pattern sufficient for voting and for submitting oracle price updates. I’m not inclined to track this issue further. If there’s anything important left in here, here’s hoping we can scope it more clearly.