Simple SwingSet ingress prioritization of economic elements

[mhofman]

What is the Problem Being Solved?

#4318 describes a mechanism to prioritize some work inside the kernel, and mixes in a "backpressure" concern disabling the ingress of low priority messages under some kernel states. However "backpressure" based on ingress into Swingset is actually mostly orthogonal to priority queues inside Swingset, with only the trigger states laying at the intersection.

This Epic is about enabling a simple backpressure mechanism ingress prioritization of economic messages into Swingset. These messages allowed to bypass any disablement of low priority ingress are the same as in #4318, and would be based on information such as the source address of the signed cosmos transaction, and/or the message type.

Currently actions are processed one at a time and do not compete with each other. Unprocessed actions sit on the inbound queue. An action in progress split over a block boundary may however compete with a timer triggered in a new block. Prioritization in this case means that once the kernel is quiescent, an action from the higher priority queue will be processed before any action from the normal queue, even if that message was queued after a pending lower priority one.

The following steps are part of this goal:

• add controller.getRunQueueSize() #5238
• Reserve a section of the swingstore for the host #5349
• Cosmic-swingset actions for message admission checks #5350
• Tendermint admission controls based on cosmic-swingset state #5176
• write the active EC and Oracle address lists to vstorage #7220
• Identify economic messages for priority queuing #6576
• Priority processing of cosmic-swingset actions #5966
• Chain recovery startup allows economic recovery first #4317
• Governance based mechanism to control backpressure #5335

And possibly also:

• consider running high-priority inboundQueue before doing timer.poll() #6964
• Core Eval should be prioritized above economic activity #7488

[Tartuffo]

Deprioritizing #5335 for MN-1 based on this discussion:

@Tartuffo:

@warner @mathieu: @tribble
suggested that for backpressure management, we could skip the governance control for RC0. That is, just us a default value for kernel queue length, and the economic message types that should go through. Thoughts?

@warner:

I think that could work.. it would mean that we'd need a software upgrade before we could change the behavior, but as long as that change doesn't happen within any vat, it's no more traumatic than our other upgrade plans.

So we should have useful defaults for the queue length and the economic message types that should go through when backpressure control has kicked in.

[mhofman]

Updated this epic to reflect the focus shift to a queuing approach inside cosmic-swingset instead of a filtering approach at the cosmos layer. While the later is still needed, we don't fully understand the possible impact on the tendermint protocol, and believe the former is sufficient for prioritizing economic activity.

[mhofman]

Core feature was part of agoric-upgrade-10. Remaining items are in the backlog