Adjusting network fees without hardforks

Ideas
#1

I just want to write this down, maybe get a discussion going. I’m not making an attempt to write a very formal proposal here. Just getting my thoughts written down.

I think we can all agree that having to hardfork everytime the price makes a bigger move sucks. Hence I am proposing to adjust the fees by introducing a voting process into the protocol, that’s let’s harvesters vote on adjusting network fees.
I realize this is not a fully decentralized approach. Think about how the fees are being adjusted right now and then think again whether this prposal would be an imporvement or not. Not fully decetrnalized does not equal bad or vulnerable for that matter.

A rough draft of a potential protocol:

Assumptions:

  • fees are only being adjusted so often e.g. once a week or month defined in blocks
  • clear price threshholds for network fees are established e.g. your “average” tx should not cost more or less than x cents (probably wanna use USD) in fees.

Step 1: Price discovery
In order to adjust the fees when the price spikes we have to know the price in the first place. Obviously the crazy volatility needs to be taken into account. I suggest to pick as many trusted sources as possible i.e. exchanges and maybe other sites like cmc if they provide APIs. Once we have all the prices we take them mean price. I know this sounds shitty but just hear me out and keep reading.

Step 2: Decision making
We don’t actually need to have an exact price in order to decide whether or not do adjust fees. Fees should only be adjusted in fixed increments anyways so all we need to decide is whether or not to do that and in which direction. I’m sure there is some variable in the fee formuar that the devs are currently adjusting up or down to raise or lower fees. The value of that variable would from this point on not be fixed in the code but proposed during this process and hence recorded on the blockchain.
So basically once we got the price (Step 1) we just compare it with our target and if our defined thresholds are crossed we decide to adjust the fees up or down and propose a new value for the aforementioned variable. Like I said earlier, there should be clear increments that this variable can be alterted in. Honest NIS’ must reject attempts to adjust the fees outside of those increments.

Step 3: Consensus
This is the ickiest part and I’m sure there’s a lot of room for improvement.
At this point every NIS can discover prices, knows whether or not fees should be adjusted and clear rules for such adjustments have been set.
If the decision has been made that fees shall be adjustet (and sufficient time has passed since the last adjustment) a harvester will issue a new kind of tx that basicaly just says that he votes to adjust the fees and includes his proposal for the new value (of that variable I was talking about ealier). The tx is signed by the harvesters key (most likely a delegate key, no sure if that’s an issue). Now yes, I get it. I’m proposing that some NIS issues a tx on behalf of an account. That does sound sketchy but it’s not that bad if you think about it. The NIS knows the key because it was given that key in order to harvest and if there is any monkey busines, the proposal tx will be rejected anyways and NIS also issues blocks on behalf of a harvesting account, so in the end it’s not that big a deal I think.
Every new NIS that sees that tx can either choose to throw it away because it aint valid or sign the transaction as well and broadcast it on further. Once that proposal tx has been signed by a suffcient number of harvesters (number tbd) it can be considered valid and included in a block. We can think of this as like a special kind of multi-sig between harvesters (it isn’t actually that tho).
Since proposal tx can only be issued (and signed) together with a new block (maybe it doesn’t have to be the latest block, maybe all recent harvesters could propose) we’re making sure that only harvesters issue such tx and that the number of harvesters required is going to have a high POI score behind them.

Some further thoughts…
If the price is right on the edge adjustmens might seem valid when the proposal issued but not to a validating NIS. I don’t think this has to be an issue. Ultimately the harvester decides whether or not to confirm the proposal. Adjustments can be attempted any number of times (if sufficient time has passed since the last successfull one). If someone signs a proposal tx they broadcast it again which will give all NIS’ multiple opportuities to validate and potentially sign it.
There is a lot of gossip being introduced here. The porposal tx is going to be broadcasted a lot and there’s not always just going to be one. It’s a race between proporals to get x amount of harvesters on board. Probably every NIS should only retain and broadcast valid proposals with the most signatures.
Maybe there would also be a way to do this similar to how the network syncronizes time. Ask your neighbouring NIS’ what they thing the fee should be and all that good stuff (I know it’s more complicated than that).
Harversters obviously have an incentive to keep fees high as that means higher payouts for them. Harvesters however also have an incentive to keep the network healthy otherwise they’re not gonna be earning anything.
If the “oracles” get compromised all at conce then oviously we’re fucked. What are the odds of that tho ? The impact of hacks are also mitigated by having fixed and sensible increments for adjustements. That way nobody can just bottom out the fees.
I don’t see why exchanges/services would collude to alter fees but sure, that would suck.

All I really wanted to do is get a discussion going. Hit me with the obvious flaws in my proposal :slight_smile:

1 Like
Trikar for NEM Foundation Council
#2

Having the fee set by voting could work. This will require constant active participation to avoid abuse which could be an issue. I would propose to add a limit like 5% on the amount of the increase/decrease from the previous fee amount or price of XEM. If XEM has increased 5% then the fee can only increase by a maximum of 5%.

Right now having the fee set by a hardfork seems ok until prices stabilize. At that point it might be possible to use the value of XEM and a percent to set the fee.

1 Like
#3

It actually won’t require active participants. Much like blocks being issued, such proposal tx would be issued without requiring the harvesters to do anything.
Yes, the limit is what I was getting at with fixed increments. I didn’t give a specific number because I wasn’t sure what would be best. 5% doesn’t sound too bad but ultimately we also need to consider how often fees would be adjusted which also hasn’t been defined yet. The more often they can be adjusted the smaller the increments can be.

#4

I proposed this months ago as the issue with NEM and the ability for NEM to lead the crypto world to fix the problem. Technically harvesters cannot manipulate the fee because they do not have a guarantee to harvest. Oracles are no different than trusting a group of people to hardfork. The main challenge is having enough exchanges to draw on for prices. You do not let exchanges set any fee, you READ the price. What are the exchanges going to do, fake a high price and everyone sells or fake a low price and everyone buys, just to get a little extra harvesting income. Simple, exchanges cannot harvest, or their importance score is not higher than most normal accounts.

You do not need to guess a number like 5% change. Use real math. Average five exchanges, throw out the top and bottom, check the price is within a standard deviation of the last block, error correct with transforms and you get a predicted price and then calculate fees.

You now add and remove exchanges from the trusted list by voting. You have emergency price fix for large fluxuations to give time for the voters to verify the exchanges.

This can be done realtime and must have consensus across the neighborhood for fees. Just like we come to agreement for time.

1 Like
#5

We may not have to but it’s a lot more robust to go in fixed increments. It also makes the system more resilient to manipulation should exchanges decide to try it.
I wen’t with the most robust system instead of a realtime system because it’s easier to find consensus for it. It’s not all that easy when you get into the details and a system where everyone calculates a fee by themselves would - without question - run into trouble. Just beacuse thigns are easy programatically, doesn’t mean they are easily accomplished in decentralized systems.

2 Likes
#6

I would like to know how exchanges can manipulate it? Say the price of XEM is $1 and we say we set the fee at $0.01 now that is 0.01 XEM. The exchange would have to double the price of XEM on the exchange to change the fee to 0.005 XEM. Or half the price of XEM on the exchange to double the fee to 0.02 XEM. How could they possibly double or half the exchange price to profit on a very small XEM change. Remember, we are talking stabilizing a fee based on market price fixed in nem code, not having the fee directly adjusted by the third party.

1 Like
#7

the main problem is, there is no way for NEM to READ anything outside of nem blockchain. For this some centralized oracles whould have to be created and who would run those oracles?

1 Like
#8

That is the point. You use every exchange that is providing price information as the oracle. The software reads those exchanges and calculates the fee. The neighborhood nodes would come to a consensus. I am not saying it would not take work, but the wallet could call the network for pricing based on a list of exchanges that were voted into the network. The exchanges would be added and removed by vote than eventually potentially a hard fork. This is a lot better than forking every time the price doubles or even goes up 30%.

#9

I was thinking about this could be achieved. @BloodyRookie told once on telegram, that no one has proposed anything so far, so this idea probably will not work for some unknown reason to me.

If I am correct, there is base_fee, which is set as variable in nis source and all other fees are based on this base_fee.

Lets say we define

  • special vote, for example 2 special addresses: fee -10% and fee +10%
  • special periods: 14400 blocks voting period, 1440 blocks adjustment period, 28800 blocks waiting periond
  • some rules, like if one address votes for both -10% fee and +10% fee, vote would not be counted (effectivelly not counting in votes from exchanges) and there would be some minimum quorum

During voting perion any address could vote for price adjustment, during adjustment period every node could evaluate the vote and at the end of adjustment period fee would be adjusted.

All the noumbers will be discussed obviously and would be hardcoced in source. There could be more voting oprions like: -50%, -5% +5%, +50% to be more flexible.

This way at any given time all nodes would know the actuall fee and fee could be adjusetd easily accoring to what community think is appropriate.

Only problems I see here are:

  • exchanges could vote with “cold storage” wallets, but I dont think that will be an issue since this would damage reputation of exchange (since their “cold storage” would not be so “cold” then)
  • nem representatives could vote with community funds. This is even smaller issue for me since long term this funds will be spent.

What do you think?

#10

I dislike letting people vote. Letting harvesters decide is imho the way to go. People can’t be trusted. Harvesters are people too, but they adhere to strict rules and they have everything to gain from a healthy network. They’re also are already regularly harvesting, there is no guarantee that people would regularly vote.

Maybe the devs could weigh in on this at some point allthough I doubt they are very fond of any of these ideas.

@BloodyRookie @gimre @Jaguar0625

#11

By voting I ment voting by importance, so people with high importance in system has high voting power.
Quorum could be set quite high since I assume devs would vote also.

#12

That’s a tricky one. Fair call.