Dynamic fees V1

[jcape]

A simple proposal for start-time configurable fees.

Rendered RFC

[UkoeHB]

In practice:

1. there should be an expectation in the ecosystem about how much the 'lazy' minimum fee can vary over short timespans
2. the default fee used by clients can be some multiple of the minimum fee, above the potential variance over e.g. 100 blocks (current tombstone limit)

[UkoeHB]

actually, both of those points apply to any solution, lazy or otherwise

[jcape]

Chat transcript:

@mfaulk 11:46

The dynamic fees RFC looks solid to me, although it would be nice to not have to restart nodes in order to adjust the fee. Here's a simple suggestion that might help with that:
The enclave only enforces fee constraints that don't need to be adjusted, e.g. "fee > 0".
Each node maintains a minimum_fee parameter.
When a client submits a transaction to a node, that node rejects the transaction if its fee is less than minimum_fee. Otherwise, it processes the transaction as normal.
The idea here is that each node is a "gatekeeper" that enforces a fee minimum before a transaction gets into the consensus mechanism, but that once a transaction is in consensus, the fee value isn't important. In general, node operators will coordinate updating fees together, but nodes with different minimum_fee values would be able to coexist on the network together (which is nice for things like performing rolling updates). Since each node's minimum_fee value is not part of its enclave, it can be changed without restarting the node.
The obvious downside to this is that a single node could set their minimum_fee very low, but that might not actually be a problem. That node would still have to validate every incoming transaction and propose the transactions for nomination, so the impact of this would be a fraction of transactions with unusually low fees getting accepted by consensus. This behavior would be visible to all nodes, and so could be handled at the "hey, your node is misconfigured" level.

@jcape 12:41

I generally agree with that, but you could get to the same place by simply letting each node's minimum fee be independently configured.

12:41

i.e. not do kex and let SCP tx validation handle it

12:42

Like, my understanding of the transaction handling is that we do the is_well_formed() (read: is_valid()) test on all transactions we receive from clients, before we put them into the tx cache destined for SCP, and also do that on all tx received from peers.

12:43

And the validation test includes the minimum fee.

12:44

So just adjusting a particular node's fee and not telling anyone would have the same effect.

12:46

Though there is one difference: an "authenticated" node (e.g. signal's node), lets you have a low fee for trusted clients, whereas unrestricted nodes can continue to charge high fees

@UkoeHB 12:47

there is a difference between ‘ignoring a tx from client’ and ‘a tx is invalid’ - if you ignore a tx from client, you may still be ‘willing’ to accept that tx when a peer recommends it

@jcape 12:47

Yes

@UkoeHB 12:47

I think @mfaulk is recommending ‘ignore tx from client’

james 12:47

Yes, he is (or that's my read of it). (edited)

koe 12:49

let SCP tx validation handle it

ah, this looked to me like adding a locally-defined ‘tx validity’ rule, which can break SCP (edited)

@jcape 12:50

Yes, that's my mis-reading of it.
Implementing this directly means moving the fee validation out of mc_transaction_core::validation::validate() and into client_tx_propose() instead.

12:51

There is a "race to the bottom" potential by excluding it from kex, though.

@UkoeHB 12:51

race to the bottom?

@jcape 12:52

e.g. [exchange] has a commercial incentive to keep their fees near zero

@UkoeHB 12:52

oh I see, yeah it allows a perverse incentive (edited)

@jcape 12:53

I suppose that is sorted in the usual "OK, GTFO, bro" if a node operator is behaving badly.

@UkoeHB 12:54

in terms of ‘short term solutions’, it may be simpler to implement

@jcape 12:54

i.e. if someone leaves their fees low, and their node is a source of trash, other operators can just remove them

12:57

Well, the RFC as-written is already mostly implemented (but not merged), changing it to this new version is pretty trivial, though---it's removing the hacks around adding the fee to the ResponderId, and moving the fee check to happen in a different place than it does currently.

[jayzalowitz]

Thoughts on cloud options wrt preventing any effective ddos

[jayzalowitz]

Divergent fee makes a lot of sense to me. For example I may be willing to conduct transaction processing when spot instances come up for sale on aws/azure/etc but not when that is not the case. This allows me to operate at 10% of the cost. I can leave a "pilot light" up at higher costs and then spin up unlimited clusters of more expensive software when that happens.
This makes the network almost impossible to ddos as you'd have to be able to take down aws, azure, and gcloud simultaneously, and at that point why waste it on mob

[jcape]

My instincts prefer divergent fees as well, but there's a bunch of gotchas that we'd have to talk our way through in order to get it to a place that feels comfortable---IMO it's a great candidate for the next "dynamic fees" RFC, where a fuller discussion is possible without the "OMG, tx costs $0.50" overhang :-)

[jayzalowitz]

So I can speak as a global expert when I say the following: Unless you standardize deployment in such a way that all the node operators have a couple of unneeded SPOF, everybody's infra is gonna run at a different cost, and whats more, at a certain repayment level, we can easily handle more load, its pretty much a demand economy in cloud nowadays.

(I will personally audit and make recommendations to node operators to run cheaper if you @ me on socials)

[jayzalowitz]

If a tx costs 50c to run, yall arent running all of the nodes in an efficient way. The aws minimum cost for an entire hour of time on a server that can run a (virtualized) SGX is 0.192000 ... are we really running one tx every 2.5 hours per node... seems unlikely.

[jcape]

The "$0.50" refers to 0.01MOB fee at $50/MOB. Whatever the actual costs to validating node operators, it costs users $0.50 (well, $0.325 as of this writing) to conduct a transaction.

[jcape]

This has approval from consensus and the sdk and broad agreement, going to merge the RFC in 24h unless there's a big show-stopper issue in that time.