Smart wallets complete for Launch

[michaelfig]

Organization

This epic is the last in a sequence of milestone epics.

Acceptance criteria

• On-chain wallets validated to be working well enough for MN-1 release

Background

Why?

• Avoid users having to manage client state (“I bricked my machine” Ag Solo wallet recovery plan #2629)
• Making an electron app (cf. exo) is risky
• Asking users to install an electron app is burdensome (though not beyond market norms)
• reduce round-trips (Ag-solo wallet slow to deploy: 25 round-trips #3802 )

ledger integration

@warner to research JSON blob details etc. what can be signed? Hash? JSON blob?

Originally posted by @dckc in #2629 (comment)

Design notes

Normalised data model

For a given user-specific wallet, the backend's data records each have:

• a meta property consisting of { id, createdAt, modifiedAt }, where id is unique for the specific wallet instance, and the *At stamps are fodder for new Date(somethingAt)
• an actions presence that allows the manipulation of that record

Every collection of data records is enumerable and presents a notifier that is updated with the entire collection's contents as any changes are made.

If there are any wallet entities that don't conform to this data model (i.e. currently petnames and dapps), they should be updated to conform.

Private data

User annotations on data (e.g. the assigned petnames, and any comment fields) should be private, that is they should be encrypted in such a way that the user's HD signer or recovery phrase can decrypt them.

It may be advantageous to represent this encrypted data as a single normalised record mapping from id to associated data so that it can be decrypted and re-encrypted in bulk. Because it contains timestamps in its "meta" property, we will know when it applies (as suggested by @JimLarson).

Cosmos chain integration

Pluggable storage of normalised records is an important feature of the wallet. For a strawman implementation, the storage system would use the IAVL tree, to be able to expose them via Cosmos-idiomatic queries, events, and transactions.

The wallet backend and wallet frontend need an agreed-upon wallet middleware to encode and decode messages to and from the chain, without affecting the ocap programming model of either the frontend or backend.

Pervasive sturdyrefs

If the normalised data model is adopted throughout the user's wallet, the user's wallet admin facet can provide a way to look up a given data record (including its actions presence) via its id. This corresponds to a sturdyref whose contents can only be mutated by signed transactions to the appropriate wallet service.

Queries

The @agoric/marshal-serialised wallet records should be queriable from RPC nodes without causing a transaction or any SwingSet mutation. Ideally, the storage system would be able to provide proofs for the query results as well.

Events

Every wallet backend data record update will result in a Cosmos "event" such as:

wallet.owner=agoric1...
wallet.id=NNN
wallet.update={"meta":{"id":NNN,"createdAt"...},"foobar":"baz"...}

where the wallet.update value is the @agoric/marshal serialised record (mapping known presences to ids). The wallet frontend-middleware can subscribe to the wallet.owner=agoric1... corresponding to their owner and receive updates over a WebSocket without needing to poll. Such update events would be converted into the usual notifiers for the wallet frontend.

agoric.wallet.MsgPerformAction

To preserve ocap integrity, the generic data records would only be updateable by sending a message to its action presence. On the wallet frontend, normal E calls would translate into a chain transaction message containing (@agoric/marshal-serialised):

• the id to look up as the target,
• the method to call on its action presence
• any arguments to that method (which may also consist of id lookups).

This message would be @agoric/marshal-serialised by the frontend-middleware and deserialised into an actual method call by the backend-middleware. That way, we avoid the potential incompatibilities with other data formats such as pure JSON.

[samsiegart]

• Making an electron app (cf. exo) is risky
• Asking users to install an electron app is burdensome (though not beyond market norms)

I might be wrong, but in a regular web app browser addons/extensions/profiles seems like a risk users have to manage on their own. Giving them a dedicated electron app makes this a non-concern. Given this is not mutually exclusive with on-chain wallets, and eliminates concerns while adhering to market norms, I think this is something we should still consider (what are the main risks?)

I have used online wallets such as blockchain.com, which generates and shows your keys in the webpage. It's definitely a risk level that's acceptable to some, but I think many would prefer an electron app. We'd probably also want to show a warning like:

[michaelfig]

We'd like to manage a throw-away key as part of the web wallet, use it with CosmJS, and then have the user's Keplr to authz grant that key to access the user's on-chain wallet.

[dckc]

chatting with @michaelfig notes in progress:
cc @rowgraus

current flow:

Bob visits treasury.agoric.app
dapp UI contacts wallet bridge and asks for purses and balances
Bob chooses to trade 100 frotzes for 20 widgets
dapp UI contacts contract public api (via wallet bridge). ouch: fees come out of Bob's fee purse
dapp UI gets invitation
dapp UI deposits invitation in wallet (via wallet bridge)
dapp UI submits proposal, naming the invitation, trade parameters ouch round trip
wallet notifies Bob about the proposal
Bob accepts the proposal
wallet makes corresponding offer to zoe
zoe sends payout to wallet

to address ouch round trip:
dapp UI relays proposal to the wallet

to address ouch fees for all on-chain actions by dapp UI:

would like to split dapp so it talks to both the dapp back-end and the wallet (bridge); but those are separate capTP connections, so, for example, we can't take an invitation we get from one and send it on the other: these capTP connections don't do shortening.

perhaps rendezvous service? maybe use the sharing service? on-chain wallet makes up a high-entropy name and calls createSharedMap(name); dapp front-end gets name via wallet bridge, sends to dapp back-end. and the dapp back-end calls grabSharedMap(name)

note: back-endless dapps also did away with the "which chain is this? test / dev / main?" issue.
idea: have the wallet tell the dapp which is the relevant chain.

wallet and ocaps

for example, a creatorFacet for a dapp back-end

see also #3901, though we may need to go beyond simple data-only args

perhaps where we are using deploy scripts and scratch to deploy contracts, we could use an on-chain wallet; that wallet could then hold creatorFacets and such. Maybe use a simpler client (cosmjs signing, faucet/src/gift.js) than ag-solo.

[dckc]

Clarifying authority around purses / assets

@katelynsills notes lib-wallet is a first draft with the intent of further work to organize around POLA. (#4488 )

@michaelfig says he considers that one of the goals of the on-chain wallet, which will go through an architecture review once he has something to propose that we can iterate on.

[Tartuffo]

@michaelfig i took the cosmic-swingset label off of this because it was messing up my graph.

[samsiegart]

After having my wallet running for a few minutes and doing an AMM swap, the :published.wallet.<address> follower in the page encountered the following error:

follower-cosmjs.js:225 PROOF VERIFICATION FAILURE; crashing follower Error: Alleged value "[Uint8Array]" did not match proof "[Uint8Array]"
  at Function.makeError [as error] (lockdown.umd.js:1159:17)
  at follower-cosmjs.js:74:1
crash @ follower-cosmjs.js:225
(anonymous) @ follower-cosmjs.js:74
Promise.then (async)
optimistic @ follower-cosmjs.js:68
await in optimistic (async)
tryQueryAndUpdate @ follower-cosmjs.js:319
(anonymous) @ follower-cosmjs.js:265
queryAndUpdateOnce @ follower-cosmjs.js:236
queryWhenKeyChanges @ follower-cosmjs.js:365
await in queryWhenKeyChanges (async)
getIterable @ follower-cosmjs.js:369
getEachIterable @ follower-cosmjs.js:383
localApplyMethod @ local.js:125
(anonymous) @ handled-promise.js:453
dispatchToHandler @ handled-promise.js:163
doDispatch @ handled-promise.js:483
(anonymous) @ track-turns.js:66
win @ handled-promise.js:503
(anonymous) @ handled-promise.js:519

After refreshing the page the follower works again normally.

[turadg]

Smart Wallet is complete now for PSMO launch. More testing to do but no known issues.