Node Economics Concerns/Discussion of Recent Events


Please post your questions, proposals, and thoughts about the most recent node runner update.

After taking a deep dive into 3/26/2019 Telegram discussion there seems to be a variety of concerns largely centered around 7 pieces.

  1. The Genesis Game favors large holders of Enigma to the point that the Enigma network is in danger of centralization

  2. Wealthy traders will buy large amounts of Enigma only until the “snapshot” and then immediately sell off ENG -> The purpose being to have the power of owning one of the limited nodes without actually carrying the burden of staking real wealth.

  3. The Genesis Game is not prioritizing node uptime and number of days staked as much as it should.

  4. The Genesis Game due to sqrt (avg_staked_amount) * number_of_days_staked * percentage_uptime because of the 50 node model hurts individuals who were led to believe 25k ENG was going to be the minimum requirement to run a node right off the bat. These individuals are frustrated with communication.

  5. Concerns that the Enigma teams decisions are changed and or manipulated by large holders of ENG

  6. Individuals wanting clarity about open-sourcing code as it pertains to competitive advantage

  7. Timeline disappointments


I second every single point @RiskSC made



  1. I do not see how it favours large holders. 25k minimum is for staking. Anyone it favours would be those who have experience keeping a beta product available 100% of the time and making version updates in parallel.

  2. Why would wealthy traders run testnet nodes and see this as lucrative business versus their own discipline - Trading! Only to pick up a few block rewards until the hard fork, really? Im sure they would put their money into a better cause like making money from trading. I doubt they would even stake after the hard fork. Maybe if they could make more money staking then yes, but as you said they are wealthy and any trader worth their salt will just trade.

3&4) This is worth debating but only if there is a better model for the Genesis game to give an overall result of 50.
Some question to aid debate:
a) How is percentage_uptime calculated?
b) How does the public auditability of genesis score and most importantly, percentage_uptime work?
c) How can everyone verify the integrity of the metrics?
c) Is 50 a must or a number close to it acceptable also?

  1. I can see how that concern can manifest if you focus on one aspect. But having a good understanding of software development lifecycles and releases of beta products would greatly change ones perception.

  2. What needs clarifying? Open-source technology is what drives decentralisation. More transparency, more devs come onboard, greater contribution overall. Yeah sure, a competitor can copy code but they’re not going to have a worldwide community supporting and maintaining their efforts. Competitors who seek the easy way like this do not have what it takes to succeed.

  3. I shared this also, but the team is delivering so it’s ok. People can be disappointed about things. You cannot please everyone, as you well know. What matters most is that the team delivers on their their roadmap and the community grows. So far so good :slight_smile: (I just hope MPC is not put back another year because of delays to date, then I might be a little disappointed.)

1 Like

Team delivers on their roadmap.
So far so good… how long have you been following eng?


This is a very useful summary, thanks @RiskSC!

I’ll do my best to respond point-by-point.

  1. It’s important to first understand our line of thinking, which we reached to through countless of discussions with people internal and mostly external to the project. Essentially, as outlined in the blog post, we were looking for a number of nodes that is unquestionably decentralized, especially compared to other networks in the space, but that is still relatively manageable if swift decisions (such as an urgent hard-fork) need to be made.

The exact figure we reached in these discussions - 50, is already substantially larger (and therefore more decentralized) than many well-known networks out there (e.g., NEO, EOS, Loom, and many others…).

As to favoring large stakes - that’s (quadratically) discounted compared to commitment and participation, which feels like a reasonable balance. Additionally, it’s important to remember that proof-of-stake was invented with the premise in mind that higher stakers, having a larger stake, are less likely to attack the network. So from a network health perspective, ignoring that metric completely would be damaging to the network.

Finally, there’s a reason we call these Genesis Nodes - as the network grows and improves, we’d like to see tens of thousands of nodes participating.

  1. There are ways to counteract that, and we’ve spend some time on it. For example, if selected, you’ll need to stake the same amount of tokens through your mainnet wallet. We’re open to getting more feedback and ideas here.

  2. We’re open to feedback here as well. A quadratic relationship seems good to us, but we’re happy to consider others. The best way to do this is to back this up with simulation data.

  3. I’m referring back to my explanation in #1. Once we all establish that the health of the network is the most important factor, then the logic of starting with 50 nodes makes sense. From here, it was a matter of finding the fairest way to select those 50 nodes, in a way that we don’t control (hence the formula and lottery) and can’t add bias to the results. It may very well be that 25K tokens will be enough for day 1 staking, provided you support testnet enough. Even if it isn’t, these tokens would be sufficient post hard-fork, so it’s not like that usefulness is lost.

  4. Baseless. We gathered feedback from people who expressed interest running nodes, alongside industry experts that may not even hold ENG. There are much easier ways to favor large holders (for example, we could have simply set the formula to be based on # tokens and that’s it - or would have selected the list entirely ourselves).

  5. That’s true for every open source project. I have yet to see one example where this was an issue. On the other hand, showing our work and hopefully - getting more outside contributors are two extremely important goals for the project, which led to this decision.

  6. What matters is quality. Once people realize how much work has been put in the 6+ months (easy to ascertain through the code), I’m sure these concerns would be alleviated. I’m so extremely proud of what we’ve been building as a team.