Confirming Blocks: How Validators Operate

IOTA 2.0 Introduction Part 7

TL;DR:

Validators are crucial for IOTA’s consensus mechanism and are rewarded with Mana for their contribution to the security of the ledger. The consensus mechanism selects a committee of validators for each epoch, but anyone who registers to validate is considered a validator regardless of whether they are selected.

As essential nodes in the network, validators uphold the integrity and security of the DLT system by validating transactions and maintaining consensus. But who are they, what exactly do they do, and how do they benefit IOTA 2.0?

This blog post provides an overview of the subject: For a more detailed description, we recommend the Wiki article on this subject, to be published on October 19th.

What are validators and validator committees?

Validators are a vital part of the IOTA 2.0 protocol that upholds the integrity and security of the DLT system by validating transactions and maintaining consensus. Anyone can become a validator.

To do this, they participate in committees formed for a specific period known as an “epoch”. Committee members issue special validation blocks, resolve double spends, determine block inclusion, finalize slot commitments, and are rewarded for their work with Mana at the end of the epoch. The size of the committee is limited to avoid slowing down confirmation time.

How do validators and validator committees benefit IOTA 2.0?

Validators and their committees bring important properties to IOTA 2.0.

They ensure security by preventing double spending and manipulation of the consensus. All nodes accept blocks and transactions approved by the committee members and follow the slot commitment chain adopted by a majority of the committee.

They help the ledger progress efficiently by promptly approving blocks (any validator in the committee that deviates from this expected behavior will get fewer rewards, if any). The bounded size of a committee reduces computational costs and confirmation time, making consensus efficient.

Also, they promote decentralized democracy by not requiring a minimum stake to become a validator, allowing for easy participation by many nodes. In addition, users can also participate implicitly by delegating their stake to a trusted validator, increasing their chance of being elected to the committee. This promotes a more democratic and inclusive validation process.

How do I become a validator?

Anyone who runs a node can become a validator through a one-time registration process. Once the registration is successful, the node has a chance of being selected to become a validator node.

Delegation is also an option for token holders who don’t want to or can’t be validators themselves yet still want to contribute to the security of the network. They assign their voting power to a validator node maintained by someone they trust and get rewarded with Mana. Token holders can change their chosen validator at any time.

How are validator committees formed?

To join a committee, you must first register as a validator before the start of the epoch and be active during a specific period. (By “being active”, we mean that one of your blocks must be accepted; in other words, at least 67% of the online validator’s committee have referenced it). During this period, a limited number of active stakeholders with the largest measured stake (that’s both locked and delegated stake) will be included in the committee.

Once an epoch ends, its committee of validators automatically disbands.

The committee selection process is planned to be temporary until we have installed random selection, thus further improving the decentralization of the network.

What do validators do in IOTA 2.0?

Validators’ primary responsibilities include:

• Regular block issuance: Validators should issue blocks within a specific time frame to maintain consensus. Their rewards depend on the number of accepted blocks and the expected number of validation blocks per slot.
• Proper referencing: Validators in the committee must reference the latest validation blocks in the slot commitment chain and randomly select valid blocks from their tip pool.
• Correct voting: The opinion expressed by a validation block should be aligned with the preferred reality of the block issuer. For example, validation blocks should not represent a vote for two transactions that conflict with each other.
• Regular commitment to slots: Committee members must commit to a slot once it becomes committable. This ensures that the slot commitment chain is consistently updated and finalization of transactions functions properly.

How are validators rewarded?

Validators are rewarded for their work with Mana. The size of the reward depends on the size of the validator’s stake, the rate at which they issued validation blocks, and how much voting power was delegated to them by third parties.

If the user has delegated voting power to a node, they also earn Mana rewards whenever their chosen validator gets selected for the committee and performs their duties. The percentage of rewards shared by validators with delegators is defined by the validators.

To promote fairness, quality, and decentralization, we’ve designed the IOTA 2.0 reward system around the following properties.

• Fairness and quality: Rewards are predetermined, and consider both voting power and the quality of service provided by validators. Validators failing to meet requirements won’t receive rewards for that epoch. To promote healthy competition, rewards are distributed among pools of participants based on various factors, not solely proportional to their voting power. Also, to attract delegators and maintain fairness, validators are encouraged to set their fixed costs at reasonable levels. If a validator’s fixed cost exceeds their share of rewards, they won’t receive any rewards, potentially leading to a lack of delegators. Validators retrieve their rewards through a regular transaction with a special Reward Input (more details here). Rewards are kept waiting to be claimed for roughly a year before expiring. No reward is given if tokens are no longer locked at the time of claiming, so one can choose to claim rewards when unlocking the staked funds or forfeiting them.
• Avoiding fund centralization: Our reward system is designed to avoid incentivizing the centralization of validator funds. Combining stakes from different validators does not lead to increased rewards, so there is no need to set a cap on validator rewards. Similarly, the reward formula discourages the concentration of delegator funds. If a large amount of stake is delegated to a single validator, the rewards for individual delegators become smaller. This encourages delegators to re-delegate to validators with less stake delegated to them. To avoid hoarding, the network has a “Mana Decay” mechanism that gradually reduces the amount of accumulated Mana.
• Promoting early contributions to network security: The reward function has two phases: a phase with high but decaying Mana rewards followed by a phase with a constant level of Mana rewards. The decaying phase is particularly relevant in the network’s early stages when participation needs a boost: In this phase, the total rewards paid out will be higher than in the more constant phase but will decrease over time, so validators and delegators that wish to save their rewards to be used or sold later (since in this early stage Mana will probably not have a high demand) are not excessively punished by the Mana decay. The later constant phase of the reward function comes into play when the network matures and reaches a stable state of high utility. At this point, the reward function remains constant, promoting a steady and fair distribution of rewards among participants.

Possible problems associated with validators

Validators may attempt to manipulate the confirmation process in the Tangle, but IOTA 2.0 has preventive measures (for more information, see the previous blog post in this series, A New Consensus Model: Nakamoto Consensus on a DAG).

• Censorship attempts: Adversarial validators may try to censor valid blocks by not referencing them. However, honest validators will still reference valid blocks, so to succeed in censorship, adversarial validators must avoid all blocks built on the censored one, leading to isolation and orphaning of their own blocks.
• Block issuance halt: Adversarial validators could stop issuing blocks, temporarily pausing confirmation and finalization. Yet, the Tangle and ledger continue growing as approval from the “online” committee is sufficient for block and transaction acceptance. The process resumes with the next committee.
• Manipulating slot commitments: Adversarial validators may create competing slot commitment chains or produce a slot commitment prematurely. However, honest nodes prioritize the heaviest chain and ignore unfamiliar commitments or commitments lacking sufficient support.

Aligning goals and incentives of network participants

DLTs generally have two conflicting groups: users who want cheap throughput and low node requirements and miners/validators who want to maximize value through block rewards and fees. The motivation and incentives of these two groups are typically at odds, with miners/validators effectively extracting value from the users.

However, in IOTA 2.0, these groups are merged into one, eliminating the need for separate service providers. Users can produce their own blocks and validator incentives don’t directly extract value from other users through inflation.

By aligning the incentives of all participants, users and validators no longer clash but instead advance their shared interests within the network.

As always, you can take a deeper dive into this subject in tomorrow’s Wiki version of this article. In the next blog post in this series, published on October 23rd, we’ll explore how congestion control happens on the communication layer of the IOTA 2.0 protocol.

IOTA 2.0 Introduction

Part 1: Digital Autonomy for Everyone: The Future of IOTA

Part 2: Five Principles: The Fundamentals That Every DLT Needs

Part 3: Data Flow Explained: How Nodes Process Blocks

Part 4: Data Structures Explained: The Building Blocks that Make the Tangle

Part 5: Accounts, Tokens, Mana and Staking

Part 6: A New Consensus Model: Nakamoto Consensus on a DAG

Source