-
Notifications
You must be signed in to change notification settings - Fork 16
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Dynamic fees V1 #1
Conversation
Co-authored-by: sugargoat <sara.drakeley@mobilecoin.com>
Co-authored-by: sugargoat <sara.drakeley@mobilecoin.com>
Co-authored-by: sugargoat <sara.drakeley@mobilecoin.com>
Note that following enclave-upgrade restart procedures will prevent pending transactions from being lost.
|
||
Choosing to simply accept that if any node has accepted a proposed transaction at a lower fee, that fee is (or would have been) valid for all nodes is an option, but this does make the ability to enforce fees dependent on the union of all SGX functionality, which is a change from our ad-hoc norms around the use of SGX as a privacy-enhancement technology, rather than a security-critical technology. | ||
|
||
The second option is to only check fees lazily, which will produce the scenario where a client could submit a transaction, and have it appear to "time out" later, because it was accepted into the queue at a low fee, then later judged to have an insufficient fee. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In practice:
- there should be an expectation in the ecosystem about how much the 'lazy' minimum fee can vary over short timespans
- 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)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
actually, both of those points apply to any solution, lazy or otherwise
Chat transcript: @mfaulk 11:46
@jcape 12:41
12:41
12:42
12:43
12:44
12:46
@UkoeHB 12:47
@jcape 12:47
@UkoeHB 12:47
james 12:47
koe 12:49
@jcape 12:50
12:51
@UkoeHB 12:51
@jcape 12:52
@UkoeHB 12:52
@jcape 12:53
@UkoeHB 12:54
@jcape 12:54
12:57
|
...and explain why we should move forward without it for now.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thoughts on cloud options wrt preventing any effective ddos
|
||
The "restart for each change" system will have similar properties for users as an emergency restart to introduce new fees---when a node is restarted without following the upgrade procedure, any pending transactions it has are lost---but is dramatically simpler to implement, and does not require special thought about validity periods of a particular transactions' fee-paid status. | ||
|
||
## Alt: Allow Divergent Fees |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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 :-)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
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. |
* Implementation of mobilecoinfoundation/mcips#1 in consensus * Add dynamic fee support to mc-connections, mobilecoind, and slam.
A simple proposal for start-time configurable fees.
Rendered RFC