All you need to know about the gas consumption issue.
The main issue
In the previous version of Master Universe, each user had a buffrate, it was supposed to evolve with time, increasing by 50% for each 24h period after the user starts staking.
This buffRate was used to calculate the plasmaPower of each user and so, to calculate the totalPlasmaPower.
The plasmaPower and totalPlasmaPower were then needed to calculate the proportion of each user in the pool, and so calculate the rewards.
In the first contract, the solution to update and calculate these values was done by a loop.
This loop worked well in a test environment with a few users. However, it didn’t scale. As you can guess and as we all saw, with several dozens of users this loop started to need a lot of resources to browse all the users. And since the more resources an action requires, the more gas it costs for the user, the system soon becomes inoperable.
Before finding a new solution, we questioned ourselves, we lacked the tools that would have allowed us to detect this and we followed the standard debugging approach: reproduce, understand, fix.
We thought it was really important to know how to reproduce the problem in our test environment so we found new tools and were able to get gas consumption audits for each function using eth-gas-reporter.
We integrated this in our automated test system (it’s like a script that can simulate multiple actions from different addresses that run on a local blockchain).
And the result was obvious, $26 for a withdrawal with the old code for only 100 users.
It brings us to the next step: thinking differently about the plasmaPower and buffRate to remove these loops.
A new algorithm
To solve this, we redesigned the system as a whole and created a new logic, which needs low gas consumption and of course no loop.
It works with a new whales status detection based on the amount on LP. This detection gives the user a buffRate which will be updated after each operation, withdraw or deposit. This buffrate is stored in the contract state.
The buffRate split users in 4 categories : tiny, medium, huge, whales.
As before, the buffRate continues to impact the plasmaPower of each user and so his reward (PlasmaPower = user staked amount * buffRate).
Of course this new contract keep our others main features:
- Cycle and Halving on NOVA mint
- Redemption Fees
We’ve made a deep gas consumption audit on this new contract to be sure it can handle several thousands of users. And in addition, we’ve worked hard on details which can reduce a little more gas usage (typing, function visibility ..).
New security feature to prevent DDOS attack
That’s not all! Thinking about these performance issues, we realized the old contract could have been vulnerable to a distributed denial of service attack. As the contract state grows with time, we had to add security to prevent people from creating thousands of accounts with very little LP tokens.
Therefore we installed a new threshold of minimum LP token required.
NOVA v1 to NOVA v2
We had 93 staking addresses before the team turns the staking on standby. Few already had used Emergency Withdraw (not a lot) and will not receive any NOVA.
For the others, we will setup a simple way to recover your NOVA v1 and to transform them into NOVA v2.
1 NOVA v1 = 1 NOVA v2 (1:1 swap)
Create a new contract to:
- Help our users to move from the old to the new staking
- Swap the old NOVA to new NOVA
- Contracts Audit
- Run the new contracts on testNet
- Run on mainNet
The team is aware that stopping the staking 26 hours after its start may have been frustrating for some users.
This is why we have decided that the addresses still “blocked” in the NOVA v1 staking process will receive 2x their NOVA staked.
We would like to take this opportunity to thank you once again for all your support and dedication to the project. The integrity of our code and user experience stays paramount to our mission at Komet Finance.
We are convinced that this step has made us grow and that it will be very beneficial for the project and future developments.