Oxen Tokenomics Thoughts - The Need for Buffer and Flexibility in Staking Mechanism about oxen-core

[jagerman]

It's important to also think about the reason for the 3750 cap: we want it to be non-trivial to spin up a bunch of nodes onto the network controlled by a single entity.

To take your example, if we have an operator with a 100 stake, how does this node participate on the network in terms of pulse, lokinet routing, swarm storage? There's a risk here that if it does participate in any of them then this cheap node becomes a way for network attacks by swarming the network at relatively little cost, and then using larger numbers to circumvent the network structures that rely on difficulty in owning a large share of network nodes. And if it doesn't participate then paying it out means taking rewards away from operators who are contributing to the network.

Batching allowed us to significantly reduce contributor staking requirements but keeping operator contribution high was a necessity for privacy and security.

The one way I could see "small" stake nodes operating would be if we scaled down the requirement of such a node (for example: a node with 1000 staked with only have 1/15 reward, only be selected for routing or swarm storage 1/15 of the time, pulse would be selected just 1/15 of the time, and so on. (There are other advantages to it on the other side as well, e.g. a single heavy box could run one 150000 stake and be expected to do 10x as much). That is possible in theory, but would be a lot of work as there is quite a bit of current assumptions that each service node is "equal" across the software stack.

Thanks for the comment.

The one way I could see "small" stake nodes operating would be if we scaled down the requirement of such a node (for example: a node with 1000 staked with only have 1/15 reward, only be selected for routing or swarm storage 1/15 of the time, pulse would be selected just 1/15 of the time, and so on. (There are other advantages to it on the other side as well, e.g. a single heavy box could run one 150000 stake and be expected to do 10x as much). That is possible in theory, but would be a lot of work as there is quite a bit of current assumptions that each service node is "equal" across the software stack.

I totally agree with you, I did address exactly the same issue and proposed the same solution (discriminate lower stake nodes with lower voting power) in my previous version one year ago. I remember I posted it in Oxen community and/or Oxen Service Node community but I lost the history now.

I'm well aware of the increasing complexity of changing the voting system, that's why I planned to raise this topic again and again in 3~5 years, which might be needed before finally implement such a big change.