Smart wallet middleware

[michaelfig]

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 delegate from interactive signer to background signer for low-privilege actions #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]

@turadg to split out read-write as a separate issue

[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 #5701 (comment)

[dckc]

tldr: It looks like the walletFactory (aka multi-tennant wallet) should register for BRIDGE.WALLET events, look up the relevant wallet by address, and forward actions there.

Some of the "actions" and "schema" stuff is still fuzzy to me; here's hoping it becomes clear as we code it up.

Detail

We have keplr offlineSigner integration in https://github.com/Agoric/agoric-sdk/blob/master/packages/wallet/ui/src/util/SuggestChain.js
(another example: https://github.com/Agoric/faucet/blob/cosmjs-rpc/src/gift.js )

@samsiegart asked: how do I map something like E(purse).deposit(...) into a payload like in client.signAndBroadcast(fromAddress, payload, Agoric.fee);?

We know address. payload is a serialized protobuf thing; Looks like WalletAction / WalletSpendAction are the relevant ones.

agoric-sdk/golang/cosmos/proto/agoric/swingset/msgs.proto

Lines 14 to 17 in 21eb21d

	// Perform a low-privilege wallet action.
	rpc WalletAction(MsgWalletAction) returns (MsgWalletActionResponse);
	// Perform a wallet action that spends assets.
	rpc WalletSpendAction(MsgWalletSpendAction) returns (MsgWalletSpendActionResponse);

That raises a question of the action field:

agoric-sdk/golang/cosmos/proto/agoric/swingset/msgs.proto

Lines 60 to 61 in 21eb21d

	// The action to perform, as JSON-stringified marshalled data.
	string action = 2;

on receipt, the go code seems to do:

agoric-sdk/golang/cosmos/x/swingset/keeper/msg_server.go

Lines 99 to 103 in 2f9eb8b

	func (keeper msgServer) WalletSpendAction(goCtx context.Context, msg *types.MsgWalletSpendAction) (*types.MsgWalletSpendActionResponse, error) {
	ctx := sdk.UnwrapSDKContext(goCtx)
	action := &walletSpendAction{
	Type: "WALLET_SPEND_ACTION",

then I think we get to:

agoric-sdk/packages/cosmic-swingset/src/block-manager.js

Lines 104 to 105 in 98d3580

	case ActionType.WALLET_SPEND_ACTION: {
	p = doBridgeInbound(BRIDGE_ID.WALLET, action);

[dckc]

marshaling public + private stuff

@samsiegart I broke ground on the problem, starting with a failing test:

https://github.com/Agoric/agoric-sdk/blob/dc-smartwallet-marshal/packages/wallet/api/test/test-union-marshal.js b4db2c4
pls excuse lack of branch discipline just now; it's stacked on unrelated work

background

The design sketch above includes:

• 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.

The notifier records include things like brands that are also published by the AMM, and we want to recognize them as equal.

See also Jan 21 discussion
#3756 (comment)

[dckc]

Currently we have MsgWalletAction and MsgWalletSpendAction with a single action field (aside from owner); I wonder how this relates to the json, trivial, zoe, capdata, and unsafe from an internal wallet.proto I just found.

The related Wallet Legibility doc has an example: E(purse.actions).deposit(myPayment) becomes ['applyMethod', receiver, purse.actions, 'deposit', [myPayment]].

It looks like receiver and purse.actions are supposed to collapse, and myPayment is actually an amount:

marshalData1 = JSON.stringify({
  body: [
    'applyMethod',
    {"@qclass":"slot", index: 0},
    'deposit',
    [
      {
        amount: {“@qclass”:”bigint”, digits: “3000000”},
        brand: {"@qclass": "slot", index:1 },
      }
    ]
  ],
  slots: [[‘purse’, ["MyPurse"]], [‘brand’, ["IST"], {decimalPlaces:6}]],
});

[michaelfig]

wallet.proto is the evolution and replacement of WalletAction and WalletSpendAction.

…

-- Michael FIG Software Engineer, Agoric

On Sun, Jul 31, 2022, 17:29 Dan Connolly ***@***.***> wrote: Currently we have MsgWalletAction and MsgWalletSpendAction with a single action field (aside from owner); I wonder how this relates to the json, trivial, zoe, capdata, and unsafe from an internal wallet.proto I just found. The related *Wallet Legibility* doc has an example: E(purse.actions).deposit(myPayment) becomes ['applyMethod', receiver, purse.actions, 'deposit', [myPayment]]. It looks like receiver and purse.actions are supposed to collapse, and myPayment is actually an amount: marshalData1 = JSON.stringify({ body: [ 'applyMethod', ***@***.***":"slot", index: 0}, 'deposit', [ { amount: ***@***.***”:”bigint”, digits: “3000000”}, brand: ***@***.***": "slot", index:1 }, } ] ], slots: [[‘purse’, ["MyPurse"]], [‘brand’, ["IST"], {decimalPlaces:6}]], }); — Reply to this email directly, view it on GitHub <#4398 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AADPUHEQYEKCNZHVCVKWY4DVW4D7LANCNFSM5M4E5SOA> . You are receiving this because you were assigned.Message ID: ***@***.***>

[dckc]

road not taken: needs pipelining / shortening

one of @michaelfig 's ideas turns out to be a bridge too far.

See also #5933

[dckc]

I started asking @erights about a puzzle in this space, and he asked for a diagram.

got started using http://www.webgraphviz.com/ but it's time for a meeting... so this is WIP

digraph g{
  rankdir=TB;
  subgraph cluster_dapp_amm {
    label="dApp\norigin=amm.agoric.app"
    ammBoot
  }
  ammBoot -> bridgeBoot
  subgraph cluster_wallet_bridge {
    label="wallet bridge\norigin=wallet.agoric.app"
    bridgeBoot -> localStorage
  }
  subgraph cluster_keplr {
    label="keplr extension"
  }
  subgraph cluster_wallet_ui {
    label="wallet UI\norigin=wallet.agoric.app"
    localStorage -> X
  }
  subgraph cluster_smart_wallet {
    label="smartWallet"
    X -> smartWallet
  }
}

[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.