cosmic-swingset "flow escalators"

[michaelfig]

What is the Problem Being Solved?

Refs #3517

@michaelfig will have a separate ticket for the cosmic-swingset code to match.

The goal of this work is to provide a minimal set of queries and transactions needed to monitor a particular ag-solo's messages as they go through the chain's scheduler and back and forth on SwingSet. This is just a first step towards full-fledged escalators and is expected to change as our implementation grows more sophisticated. However, implementing some policy as a starting point is a better thing than no policy at all.

Description of the Design

These queries and transactions will be implemented under the x/swingset Cosmos module.

This code will:

• during provisioning, call allocateFlow to associated a swingset flowid with the client's address
  • this mapping will be stored in the cosmos state vector

We will track clients addresses to chain flowids. The key will be clientFlows.${clientAddress} whose value will be a chain ${flowid}. There is no need to future-proof this usage, because the x/swingset storage allows any path to be a leaf (maybe later we'll have something like clientFlows.${clientAddress}.${localFlowId}).

• the RPC client will be augmented to provide a CLI command that translates client address into flowid

ag-cosmos-helper query swingset flow ${clientAddress} query will look up and return clientFlows.${clientAddress}.

• when receiving solo-to-swingset messages, provide the flowid to deliverInbound

The solo will provide a localFlowId to ag-cosmos-helper tx swingset deliver, which will look it up and provide the chain flowid to deliverInbound. Additional scheduler.flows.${flowid} information will augment the return result.

• after the block is complete, call getSchedulerState and write the result into the cosmos state vector, under a well-known key.

The key will initially be scheduler.fullState. It will eventually be necessary to partition the state for more efficient querying and updating, but until the scheduler also gets such an ability, x/swingset will also be naive.

• the RPC client will be augmented to provide a CLI command to fetch+validate this data,

This will be ag-cosmos-helper query swingset scheduler.

look for a specific flowid, and report the Flow's place in the queues

• by following this data over time, the user should be able to track their progress through the queue

This can be done outside of the chain by parsing the above query swingset scheduler.

• the RPC client will be augmented to produce a new signed transaction type named "boost", which takes a flowid and a number of boost points

  • the cosmic-swingset handler for "boost" will deduct a fixed amount of RUN per boost point (perhaps 1000 uRUN) and call controller.boost() to increase that flow's boost points

"boost points" will be deferred, or possibly never implemented, as per the meeting of 2021-07-26.

SwingSet Cosmos parameters

The number of messages to be processed at the head of a queue should be a configurable chain param, app_state.swingset.params.queue_head_messages_quantum, default to something like 10.

Security Considerations

Test Plan

Golang unit tests