High priority economic elements (e.g., oracles) can have priority execution

[rowgraus]

We need to identify all the messages involved in the core economy and make sure they get priority. This includes:

• cosmos transactions containing price updates from oracles
• device (possibly including vattp/comms) messages that deliver those updates to a vat handling economic activity
• sale orders to liquidate vaults that are below their collateral threshold
• reactions such as promise resolutions from all of those

The "cosmos transactions" part happens before swingset sees anything. @dtribble suggested that the price oracles' addresses be treated specially by cosmic-swingset: we want any txns signed by those addresses to get pulled from the mempool and into a block first, then look for txns by other senders. I don't know quite where this would need to get implemented, @michaelfig has mentioned that the priority of mempool txn selection isn't easy to control.

It should be possible to funnel these messages into SwingSet through dedicated devices, with their handling vat running at high priority, thus bypassing contention with other non-priority messages going through mailboxes/vattp/comms. As long as the reaction from that point all target high priority vats, it should grant the ability to complete processing of high priority economic messages before regular / low priority messages.

The following steps are part of this goal:

• Constraint decider changes to simplify promise enqueuing logic #5023
• syscall.send to resolved promise should run-queue to object, not to promise #4542
• Place "async" vat operations onto outbound queue #5024
• Per vat inbound and outbound queues #5025
• Per vat priority (was: two run queues) #3465
• Mechanism to create vats with higher priority #5026
• Ability to disable low priority processing #5027
• Chain recovery startup allows economic recovery first #4317

[Tartuffo]

@warner For proper project planning and tracking, this needs an area label covered by one of our weekly planning meetings. Please pick the appropriate one from: agd, agoric-cli, agoric-cosmos, amm, core economy, cosmic-swingset, endo, ertp, getrun, governance, installation-bundling, metering, oracle, pegasus, run-protocol, ses, staking, swingset, swingset-runner, tc39, token economy, tooling, ui, wallet, xsnap, zoe, zoe contract

[mhofman]

If cosmic-swingset is able to extract a priority from a message when grabbing it from the mempool, we may be able to have a different mailbox device queue per priority on the swingset side.

Regardless, it seems that swingset will need its own notion of sender based priorities since the comms vat has per remote receiver objects. We'll need to keep the list of priority sender in sync with cosmic-swingset in that case.

@warner did I get that right?

[Tartuffo]

@warner @michaelfig @mhofman you should probably all sync on this to determine what work needs to happen in the various levels: swingset, cosmic swingset, and the interchange between the two, and break out that work into separate tickets.

[Tartuffo]

This is related to #3465

[mhofman]

I would like to make this issue the overarching epic. Will update the main description

[dckc]

discussion w/ @turadg , @michaelfig ...

does the inter-vat cost of the continuing invitation pattern compete with goals here?

MFig notes prioritizing at the cosmos-level based on sender address can be used regardless.

with continuing offers:
bridge -> walletFactory -> zoe -> oracle aggregator

vs. using offer results more direcly:
bridge -> walletFactory -> oracle aggregator

using continuing offers seems feasible for now.

[warner]

cc @gibson042