Fee design & per-contract validator set fee negotation

[cwgoes]

(ported from https://github.com/anoma/anoma/issues/51#event-6001719136)

To prevent spam and appropriately price execution costs, the base ledger's trade settlement system must charge fees proportional to the database read/write and compute costs incurred by transaction execution (all phases). Fees merely proportional to transaction execution costs, however, misalign long-term interests of system users and stakeholders, since proof-of-stake consensus security must be greater than (and thus proportional to) the amount of value transacted, since this is what could be gained by subverting intended operations (e.g. by bribing validators). For this reason, we should aim to architect a fee model which is at least in part proportional to the value of a settled trade (more similar to existing custody institutions, in a sense). That way expected long-term value accrual of the staking token will end up being proportional to trade volume (in an approximate sense) instead of execution volume, which is more likely to fund the requisite security.

Note: One could object to this argument on the basis that transaction fees will converge to trade value as block space becomes scarce - as one sees happening on Ethereum at the moment, to some extent - however we do not wish to rely on this, as it requires constraining system throughput (artificially, assuming we could do otherwise) and thus also prevents many otherwise-possible (and otherwise fee-paying) transactions from being settled.

What exactly the proportion is we can determine later - likely it will be quite small - but the tricky part from the design perspective is to measure the value of a trade in the first place. This problem certainly cannot be solved in general for a ledger which supports arbitrary state transitions and places no constraints on data semantics (i.e. value), and privacy features exacerbate the difficulty, e.g. private MASP transactions provide no information about the value transacted, and any attempt at a proportional charge by circuit change will result in data leakage if the fraction is known and the fee is sent to a public address. That said, it is much less critical to charge value-proportionally for transfers (though we should keep thinking about this), and much critical to charge value-proportionally for trades, which may often have partially public data (e.g. price, amount, tokens) by necessity of counterparty negotiation at the intent discovery layer. If there is some roughly proportional relation between trade volume and value of custodied assets, charging proportionally for most trades should be sufficient to achieve the value-capture / security proportionality which we need (this is a hand-wavy argument that should be formalised).

To that end, keeping in mind the additional design constraints of avoiding hardcoded order semantics on the base ledger and assuming that market conditions will change rapidly, one idea I have is to enact a kind of collective negotiation between the validator set and particular contracts (with particular validity predicates) on a sort of "fee-sharing" based on the particular semantics of that contract. The basic setup is as follows:

1. The "validator set", as a collective entity, has a special validity predicate on the ledger which is called for every transaction and enforces fee payments. This validity predicate code is mutable and can be altered at any time by a 2/3 majority vote of the validator set (this does not change the security model, since 2/3 of validators can sign anything anyways, and they can also threshold commit with individual validity predicates, no complex procedure is necessary).
2. When a new contract becomes relatively popular, the validator set can inspect this contract and choose a fee sharing model based on its particular semantics. For example, suppose an AMM contract - maybe even partially private - starts becoming popular. The validator set reads the contract and notes how it calculates fees for each trade.
3. The validator set then alters their collective validity predicate to require some trade-value-proportional fee sharing (in this example, that 1% of the fee paid to the AMM LP is instead directed to the stakers). The validator set may also elect to reduce or eliminate computational-cost-associated fees if they can be bounded in advance.
4. Transactions which use this contract (e.g. AMM) are now subject to the new fee requirements (which clients must track).

This process can happen quite rapidly and requires no ledger upgrades, although we should keep UX in mind. Another point to consider is the particulars of how contracts ought to "fee share" and whether they need to build in some flexibility in advance with this system in mind.

This is just brainstorming, thoughts welcome.