Introduction
Staking Phase 4.0, part of the Vega Upgrade (v1.7.0), marks an important enhancement to the validator mechanism in MultiversX Network, building on the foundation laid by the Sirius Upgrade (v1.6.0). Staking Phase 4.0 will contribute to the improvement of the network security, efficiency and decentralization. It will introduce key modifications to the staking process, particularly in the methods of selecting and managing validators that will participate in consensus (part of the active set of validators).
Improvements Down The Road
1. Soft Auction Mechanism vs. Fixed Staking
- Current: Validators need a minimum stake of 2.5k EGLD and they have to wait in the queue until someone frees a position in the active set of validators.
- v4 Enhancement: A dynamic auction system allows validators to bid for positions, creating a market-driven entry mechanism.
2. Node Selection Algorithm: Static vs. Dynamic
- Current: selection is fixed, when a node is jailed or unstaked, a new node from top of the queue is selected.
- v4 Enhancement: Incorporates a comprehensive algorithm considering top-up value for node selection.
3. Validator Management: Rigid vs. Adaptive
- Current: Limited flexibility in managing the entry and exit of validators.
- v4 Enhancement: Introduces automated, real-time management of validators based on continuous performance and network health metrics.
4. Network Scalability and Security
- Current: Limited scalability due to fixed node cap and potential security risks from centralization.
- v4 Enhancement: Increased network scalability and improved security through a diversified and dynamic validator base.
How will the upgrade happen?
A phased rollout is planned to ensure a smooth transition, each phase introducing key elements of the new system.
Letâs consider Epoch n - activation epoch of the upgrade.
Phase 1 â Epoch n: Introduction of Auction List and Removal of Staking Queue
-
Objective: To transition from a static staking queue to a dynamic auction-based system.
-
Implementation: Replace the fixed staking queue with an auction list where validators can bid for positions.
-
NOTE:
During the test phase on Testnet, we encountered an exploitable loophole regarding the maximum cap on nodes per Staking Provider (SP). Specifically, an SP could circumvent the cap by queuing additional nodes right before the activation of Phase 1 in the staking v4 mechanism. This tactic allowed SPs, regardless of their current node count, to potentially start staking v4 with an excessive number of nodes by leveraging any available eGLD, thus bypassing established rules.
To address this issue and ensure fair play, an update ( PR #6042 ) on the MultiversX GitHub repository, Vega rc/v1.7.0 branch has been implemented. This update introduces a mechanism that automatically unstakes all nodes in the queue list at the onset of Phase 1 of staking v4 activation. Consequently, every SP will commence staking v4 with only their eligible nodes, adhering to the prescribed limit. This change safeguards the integrity of the staking process, ensuring compliance with established node limits. PS: staking v4 with full feature implementation is being used for Battle of Stakes Testing Campaign.
[NOTE ADDED ON 08.04.2024]
Phase 2 â Epoch n+1: Redistribution of Shuffled-Out Nodes and Waiting List Adjustment
- Objective: To refine the waiting list management, ensuring fair opportunities for all validators.
- Implementation: Nodes shuffled out from the active validator set are moved to the auction list, not automatically to the waiting list.
- NOTE: As of Phase 2 of Staking V4, the network will have a total of 1280 nodes in the waiting validators list, distributed across 4 shards (320 nodes per shard - groups of 80 nodes per waiting epoch). This is a decrease from previous total of 1600 nodes (400 nodes per shard - groups of 80 nodes per waiting epoch). Previously, nodes would wait for 5 epochs before transitioning to the âeligibleâ status. Now, while the transition to the eligible state still requires 4 epochs, the additional epoch has been shifted for nodes when in auction list.
Phase 3 â Epoch n+2 : Full Implementation of Soft Auction Mechanism and Node Limit Adjustment
- Objective: To fully implement the soft auction mechanism and adjust the maximum node count for each validator based on the top-up threshold.
- Implementation: Apply the soft auction selection process for all validators, adjusting the top-up threshold based on the average top-up in the network. This threshold determines the maximum number of nodes a validator can use to qualify for consensus, number which is being dynamically adapted.
What is the Soft Auction Mechanism?
The soft auction selection mechanism is designed to dynamically select nodes from the auction list to be distributed in the waiting list. This process is based on the top-up of each validatorâs nodes, aiming to maximize the participation of different validators and their nodes in the network. Hereâs a step-by-step breakdown and some examples:
Step 1: Assessing the Auction List
- Auction List Compilation: Nodes that are not currently active (i.e., in the eligible list) are placed in the auction list. This list includes nodes from validators who have staked more than they currently need for their active nodes.
- Validatorâs Total Top-Up: Each validatorâs total top-up is calculated. The top-up is the additional stake that an owner/delegator has put into their nodes above the minimum required stake.
Step 2: Calculating Top-Up Per Node
- Minimum and Maximum Top-Up Per Node: For each validator, the mechanism calculates the minimum and maximum possible top-up per node. This calculation considers different scenarios where either all or only a portion of the validatorâs auction nodes are selected.
- Example: Consider a validator with a total top-up of 3000 EGLD spread across 4 nodes (1 active and 3 in auction). If all three auction nodes are selected, the top-up per node would be 750 EGLD (3000 / 4). If only one auction node is selected, the top-up per node would be 1500 EGLD (3000 / 2).
Step 3: Determining the Qualified Nodes
- Setting a Top-Up Threshold : The algorithm gradually increases a threshold for the minimum required top-up per node. This threshold is determined by gradually increasing the minimum top-up from the lowest possible value to the highest, in steps, ensuring the available slots are filled.
- Example: In this node selection algorithm, we incrementally raise a threshold within a specified range to filter nodes from the auction list. At each step, we compare the number of qualifying nodes against the available slots, and when we first encounter fewer nodes than slots, we revert to the previous stepâs threshold. In cases where there are competing nodes with same top-ups a XOR-based sorting method is applied.
- Qualifying Nodes for Selection: For each validator, the system calculates how many of their auction nodes can be qualified based on the current threshold of top-up per node.
- Example: Consider a scenario with a top-up (average) threshold of 1216 EGLD and two validators. The first validator has a single auction node with a top-up of 1222, exceeding the threshold and hence qualifying. The second participant owns three nodes in totalâtwo in the auction and one activeâwith a collective top-up of 2555 EGLD. When considering all three nodes together, the average top-up per node is 851 EGLD, disqualifying them due to falling below the threshold. However, if we select only two of these nodes (one from the auction and the active one), the average top-up per node rises to 1277 EGLD, making both nodes eligible. In this example, first validator qualifies with one node and the second validator with two nodes.
Step 4: Final Selection
- Sorting and Selecting Nodes: The qualified nodes are sorted based on their top-up per node, and the nodes are selected to fill the available slots. If multiple nodes have the same top-up, the selection is random but deterministic, based on a XOR operation between the validatorâs public key and the current blockâs randomness.
- Example: The final selection might include one node each from Validator1, Validator2, and Validator3, based on their qualified top-up per node and the available slots.
Conclusion
As we approached the Vega upgrade to Staking Phase 4.0, our primary objective is to enhance network decentralization and address the Nakamoto coefficient challenge. This upgrade is a strategic step towards the fostering of a more evenly distributed staking landscape. Phase 4.0 introduces mechanisms to incentivize smaller staking providers and diversify participation, thatâs why it is important in our roadmap for a progressively decentralized architecture, setting the stage for future iterations that will further this goal.
Central Challenges and Proposed Measures:
- Limiting Provider Dominance: With the MultiversX Network already hosting over 100 distinct staking providers, we are well on our way to achieving a decentralized ecosystem. Our goal is to further enhance this decentralization by encouraging the growth of professional staking services while preventing the dominance of a few entities. To approach this intention, we propose introducing protocol-level limitations on the number of nodes a staking provider can have. The first cap that we propose is of 50 nodes. How will this impact the actual staking providers? Staking providers that are above this number will simply not be able to add new nodes, but wonât get their surplus nodes removed by the protocol.
- Supporting Small Providers: These limitations aim to reduce the growth of large providers and create space for smaller entities to flourish. Itâs about creating a balance between competitive growth and maintaining a healthy, decentralized ecosystem.
- Ensuring Network Security: From a security standpoint, these measures are designed to discourage any single provider from gaining excessive influence, which could lead to malicious activities. High top-up values for nodes act as an economic deterrent, aligning with game theory principles to prevent abuse.
- A Call for Community Engagement: We recognize that these measures may seem somewhat restrictive, yet they are proposed in the spirit of preserving the networkâs decentralized nature. This is an invitation for the community to engage here in a robust discussion. Your insights, perspectives, and suggestions are very important in shaping a more equitable and secure staking environment.