Identify economic messages for priority queuing

[mhofman]

What is the Problem Being Solved?

In order to support #5334, cosmic-swingset needs to identify some economic messages like oracle price updates and economic governance changes, and select them for priority processing, aka put them in a high priority inbound queue.

This identification should extend all the way to the go layer allowing an oracle message to bypass queue limits (which should only apply to lower priority messages). If possible it should also influence the selection of message from the mem pool.

Description of the Design

Oracle messages are currently proposed to be processed through the smart wallet, which would be simply provisioned with a price aggregator authority using a continuing invitation pattern. Similarly, the economic committee members have an invitation in their smart wallet.

The best approach would be to translate this ocap into a sort of ACL understood by cosmic-swingset. One possibility is that the smart wallet vat would be endowed a device allowing it to control which sender addresses are allowed to send oracle messages, and require oracle messages to use a distinct type.

However a simpler approach may be to separate this from the actual capability, and offload to an EC controlled governed parameter which would set a list of priority senders independently. That can be done through a simple chain storage write to a predetermined path.

When receiving an oracle message type, cosmos would consult the list of addresses and place messages from senders matching the list in the priority queue. Such messages would also bypass any queue limits. Once placed on the priority queue, the message does not need to be further checked, even if the list of priority senders is updated before it is processed by swingset.

Security Considerations

This authority must be revocable. If handled through a direct reflection of the ocap, revocation would result in the address being removed from the list. If handled through a governed param, the revocation must be manual.

If we're not using distinct message types this authority extends to any swingset messages sent by sender address, even if they are not considered economic messages by swingset (e.g. smart wallet messages other than oracle price updates or economic governance). We consider this trade-off acceptable.

Test Plan

TBD

[mhofman]

To avoid any kind of confused deputy issues, @dtribble suggested today in the Kernel meeting the following simplification:

• An oracle has to use a dedicated signing key (unique sender address) for a specific instance of the price aggregator authority.

This allows to easily prevent confusions such as:

• an oracle performing smart wallet operations not related to price updates
• an oracle holding multiple price authority instances, but only one instance having the right for price updates to be processed with higher priority

This makes it that the signing key is the equivalent of holding the capability for the price aggregator instance.

I am unsure if each oracle would hold a different instance of the price aggregator, of if a single instance is shared amongst oracle. In the case of the later, we would need a unique signing key per (aggregator-oracle) tuple.

How to provision a sender and exclusively link it to a specific instance also would have to be figured out.

[mhofman]

Today we decided that this prioritization at the cosmos / cosmic-swingset level being temporary (until we can carry the priority through swingset, #4318), we can take the shortcut of:

• Relying on a pure ACL of senders which messages are treated in priority (regardless of message type)
• decouple maintenance of that list from the authoritative "who's holding an invitation ocap", to a manual ec based governed param.

#7220 will write the list of EC members, and the list of oracles in 2 separate vstorage paths, which will simply be checked against when processing inbound messages in cosmos.