Elrond Staking (Mainnet)
Waiting list for Validators and more
Elrond Validator-Channel — Discussion on Sunday 16th August 2020 —Summary
One of the first topics we have as today’s topic is the staking waiting list.
With the current setting of the protocol we have a MaxNumberOfNodesForStake = 2169 meaning that the network will only allow for the first phases with the current network configuration a fixed amount of validator nodes.
From the 2169 Nodes, 1454 are running with the Elrond Community Delegation and the rest of 715 Nodes are from the validator community.
Now given the numbers and running an experiment for the upcoming months one of the very first steps will be to enable the stake/unstake process for everyone.
Another clear milestone for us will be to distribute the 1454 nodes with their stake to the trustworthy validators that will be running and providing open staking services on top of the Elrond protocol.
And now we get to the the process, what comes next and how do we achieve all these milestones in simple steps that everyone can follow and everything goes smooth.
As the MaxNumberOfNodesForStake have a clear position into the new economic proposal that can not be exceeded without a very reasonable proposal for a better version of the entire ecosystem well being, or we’re at the point where 15.000 transactions per second are not enough, then we can discuss about increasing the max number.
Therefore the waiting function might be pretty much a very well welcomed feature that will allow both the community to get a in the line for the 2169 consensus slots but also to maintain the security and the smooth transition from a “waiting list” to a active validator without any user interaction, once a validator decides to unstake his node.
So just to recap, once we’ll have the stake/unstake enabled during the next weeks, the user interaction should not be just a REJECTED message on the stake transaction, but rather a message like “ok, we’re full right now, but there’s a waiting list ongoing in case you might still be interested to becoming a validator, so you’ll get your seat once someone will decide to unstake”
And now putting this into the bigger picture with the 1454 nodes that will be distributed, things might look even better for the end-user / validator. We might be actually coming up with deadlines when and how the distribution process will happen and when the waiting validators will have a chance to get in for sure, and not depending on the stake/unstake process of the other validators.
If you want to get a new validator node onboard, and you have been preparing everything with all the skills you need to run one, you actually want to start validating on Elrond, you just go and do the staking transaction, right?
But at the moment when you send the transaction, the network is full and can not accept more validators right away.
What would be the desired action from the protocol?
Should it just reject you and say, sorry but we’re full at the moment and send you your money back? Or should it say, “sorry, we’re full but I can put you into a waiting list?”
And once a seat becomes free, you’ll be the first to be automatically swapped into an active validator node.
To make it clear for everyone again, let’s do a recap where we are right now:
1. Auction disabled (fixed price)
2. Stake/unstake enabled
3. Waiting list eligible nodes are kept under the 100% staking price in order to be swapped at into active validators at any point of time
4. Jailing function is a strong incentive for everyone to make sure they are ready for going into production with their setups and we should be the enforcement for that message with everyone coming along.
The initial timeline is tight to the Staking as a Service Smart Contract templates that are being developed and proposed for our validator community in order to allow everyone to provide the best services with the most interesting business models for the delegators. What I can say right now is that we are already working on the contracts and as well on auditing every proposed contract for deployment into production and first thing first, it needs to come as close as possible to you as validators and to the delegators as well.
Once we’re ready to deploy the first ones and enforce it by trustworthy providers in order to provide a competitive and interesting approach as delegating to us, as a next step will be to enforce the undelegation from Elrond and redelegation to the community validators and the end result will be to unstake the Elrond hosted validators.
The number of validators is not fixed on high level architecture, but the opposite, depending on the network load and the economic sustainability of the protocol. If the average load on the network exceeds 50% than more nodes are ready to be added into the network which will result into more shards, more throughput, more performance and increase of security.
With the current network configuration, we will stick to a maximum number of nodes at 2169, representing 400 active validations into each shard and a 569 nodes shuffling between shards at each epoch change.
This is next on our To-Do list, the process will be reviewed and proposed to a medium article as a guide how to do it with all the tools available.
I guess everyone has at least an idea about the staking waiting list, and this will be tested and proposed for review for everyone into the upcoming Testnet versions.
If the validator staking list is capped at 2169 for the first phase of the network and we will go for the waiting list implementation. Once a validator has staked the fixed amount of 2500 eGLD into the protocol and is now the first one on top of the waiting list. If a active validator node from the 2169 gets jailed, from a high level perspective, the jailed nodes are not helping the protocol maintaining the security and productivity of the network. Right?
If you start as a brand new validator, you have ~10–12 hours where you need to be 100% offline after the first epoch change, in order to get jailed, and around a full epoch or I guess around 36 hours starting with 100 rating in order to get jailed. So if you can’t get a software back to life in 36 hours that takes around 30–60 minutes of configuration… that should be a decent limit to consider, right?
Now if we agree that the jailed validators do have enough time to get their setups back at work, and also we agree that keeping jailed validators for unlimited time in there will just harm the security and the efficiency of the protocol. Does it make sense to allow the swapping of jailed validators with the new nodes coming from the waiting list?
Once the node unjails, it’ll be back on top of the list waiting to replace the available next seat.
1. The economic incentives and the 12h of inactivity should be enough to put the responsibility in place and align the incentives in the first place.
2. The new staked nodes that are into the waiting nodes can not be jailed and are not subject to jailing unless they become active validators.
3. For the already staked nodes that have been jailed and replaced, only once the validator node sends the unjail transaction and pays the fee, the validator node will become active on top of that waiting list, otherwise it will just stay jailed. Also sending the transaction paying the fees, the validator is aware of the event happened and by nature it will take action to prevent it from happening, right?
Now going back to the debugging procedure, let’s take a short break into it.
1. We have enabled by default the *:DEBUG logging into all the validator nodes and implemented a collect log function that will make the process as simple as possible for the validator node to reach out to us with its problem.
2. We are aware that there is no perfect software, not even coming from Elrond, therefore in order to come as close to you every single one of you in case you get jailed and you think that it wasn’t your fault, we would request the logs from that machine, and if the log-level was not changed on purpose, we would be able to debug and walk trough the entire lifecycle of that node and see if it was a software or a hardware / host problem.
3. If it was a software problem, and the logs provided are proving that, we would be more than happy to provide you the funds for the unJail transaction.
We are talking about only activities that are subjected to user mistake after a 100% right setup configuration. Double singing or double block proposal with the same validator key is another hot topic. That’s not something the software can do by default. It needs to be configured like that by the node operator, so that’s more like a on purpose action, because the software would never ever do it by itself.
So the double sign or double block proposal in the same round is subjected to jailing instantly because its damage can delay other blocks for being produced after its action has been finished, so that should be solved ASAP, not over a longer timeframe.
I hope that this reproduction of the content of the discussion will shed light on the subject and provide all interested parties with more knowledge about Elrond.
If you have any questions, please feel free to contact us at any time via the Validator or the other telegram channels.
