Charge provisioning fee if smart wallet absent

[mhofman]

What is the Problem Being Solved?

Today, provisioning a wallet requires an explicit PLEASE_PROVISION message, which both charges a flat admission fee, and delivers the message to the smart wallet for actual provisioning. Since a single swingset message can be included per transaction, this ends up resulting in a poor UX where a new user must first explicitly provision the smart wallet in a first message, then perform their actual first interaction with the smart wallet.

We do need to keep charging a flat fee for now for provisioning the smart wallet to prevent spam targeted at swingset, however we don't need to do it through an explicit transaction. A charge on first time use is sufficient.

Description of the Design

• Change the CheckAdmissibility of MsgWalletSpendAction and MsgWalletAction to charge the provision fee during with chargeAdmission based on whether the sender has an entry or not in published.wallet.${agoric1address}. This is a lookup conceptually similar to the lookup done against the highPrioritySenders list in the inbound ante handler (CheckAdmissibility is performed in the vm_admission ante handler)
  • The presence of the entry is sufficient to indicate a smart wallet was previously provisioned, including in the pismo era.
  • Caveat: while a only a single tx per sender per block is allowed, and only a single swingset message per tx is allowed, the action that will provision the smart wallet may sit on the inbound queue for some time, resulting in double charges if multiple tx are submitted. One solution would be for the admission check to populate the vstorage entry with a dummy value {} when the message is admitted.
• Change the wallet factory vat to automatically provision when processing a wallet (spend) action. It can rely on the cosmos side to have charged the fee.
  • We may want to instead add a optional field to the action delivered to JS to indicate that the smart wallet should be provisioned. This allows upgrading the smart wallet vat first, before a chain software upgrade changing admission charges is deployed
  • Alternatively, the cosmos side could synthesize a PLEASE_PROVISION action and queue it before the wallet action

Security Considerations

This does not change the fee for wallet provisioning, however it allows to block swingset spam at the cosmos level instead of the smart wallet level

Scaling Considerations

None

Test Plan

TBD

Upgrade Considerations

The cosmos changes require a chain software upgrade.
For the auto-provisioning approach, the smart wallet vat must be upgraded to support auto provisioning., and must happen before or at the same time as the chain software upgrade.

[mhofman]

After talking to @michaelfig, I realized there is a complication related to the race handling of provisioning:

• Provisioning can fail. In particular the current backstop mechanism is to transfer a nominal amount from the provisionPool to the wallet's address.
• If the cosmos side writes a marker in vstorage pending provisioning, any failure in the wallet provisioning would result in a stuck state where it would assume the wallet was provisioned and allow smart wallet messages through
• At this point I can thing of 2 approaches:
  • Eschew the pending provision marker. If the user submits new wallet actions while the first one is pending on the inbound queue, charge every time the action is admitted into a block
  • Use a specific marker, and have the cosmos side match that marker to re-attempt provisioning for every admitted wallet action, but without charging the provision fee. This will result in multiple deposits from the provision pool if the chain is backed up and the user manages to submit multiple wallet actions before provisioning.

[otoole-brendan]

Agoric/dapp-psm#116 and Agoric/dapp-inter#214 tracks the UI changes to accommodate this