Skip to main content

Validator Committee

A set of independent validators participate on the IOTA network, each running its own instance of the IOTA software on a dedicated machine or virtual server. Each validator handles read and write requests sent by clients, verifying transactions and updating on-chain information.

To learn how to set up and run an IOTA validator node, including how staking and rewards work, see IOTA Validator Node Configuration.

IOTA uses Delegated Proof-of-Stake (DPoS) to determine which validators operate the network and their voting power. Validators are incentivized to participate in good faith via staking rewards, which are slashed in case of misbehavior.

Epochs​

Operation of the IOTA network is temporally partitioned into non-overlapping, approximate fixed-duration (~24-hour) epochs. During a particular epoch, the set of validators participating in the network and their voting power is fixed. At an epoch boundary, reconfiguration might occur and can change the set of validators participating in the network and their voting power. Conceptually, reconfiguration starts a new instance of the IOTA protocol with the previous epoch's final state as genesis and the new set of validators as the operators. Besides validator set changes, tokenomics operations such as staking/un-staking, and distribution of staking rewards are also processed at epoch boundaries.

Quorums​

A quorum is a set of validators whose combined voting power is greater than two-thirds (>2/3) of the total during a particular epoch. For example, in an IOTA instance operated by four validators that all have the same voting power, any group containing three validators is a quorum.

The quorum size of >2/3 ensures Byzantine fault tolerance (BFT). A validator commits a transaction (durably store the transaction and update its internal state with the effects of the transaction) only if it is accompanied by cryptographic signatures from a quorum. IOTA calls the combination of the transaction and the quorum signatures on its bytes a certificateA certificate is the mechanism proving a transaction was approved or certified. Validators vote on transactions, and aggregators collect a Byzantine-resistant majority of these votes into a certificate and broadcasts it to all IOTA validators, thereby ensuring finality.. The policy of committing only certificates ensures Byzantine fault tolerance: if >2/3 of the validators faithfully follow the protocol, they are guaranteed to eventually agree on both the set of committed certificates and their effects.

Write requests​

A validator can handle two types of write requests: transactions and certificates. At a high level, a client:

  • Communicates a transaction to a quorum of validators to collect the signatures required to form a certificateA certificate is the mechanism proving a transaction was approved or certified. Validators vote on transactions, and aggregators collect a Byzantine-resistant majority of these votes into a certificate and broadcasts it to all IOTA validators, thereby ensuring finality..
  • Submits a certificateA certificate is the mechanism proving a transaction was approved or certified. Validators vote on transactions, and aggregators collect a Byzantine-resistant majority of these votes into a certificate and broadcasts it to all IOTA validators, thereby ensuring finality. to a validator to commit state changes on that validator.

Transactions​

When a validator receives a transaction from a client, it first performs transaction validity checks (validity of the sender's signature). If the checks pass, the validator locks all owned-objects and signs the transaction bytes, then returns the signature to the client. The client repeats this process with multiple validators until it has collected signatures on its transaction from a quorum, thereby forming a certificateA certificate is the mechanism proving a transaction was approved or certified. Validators vote on transactions, and aggregators collect a Byzantine-resistant majority of these votes into a certificate and broadcasts it to all IOTA validators, thereby ensuring finality..

The process of collecting validator signatures on a transaction into a certificateA certificate is the mechanism proving a transaction was approved or certified. Validators vote on transactions, and aggregators collect a Byzantine-resistant majority of these votes into a certificate and broadcasts it to all IOTA validators, thereby ensuring finality. and the process of submitting certificates can be performed in parallel. The client can simultaneously multicast transactions/certificates to an arbitrary number of validators. Alternatively, a client can outsource either or both of these tasks to a third-party service provider. This provider must be trusted for liveness (it can refuse to form a certificateA certificate is the mechanism proving a transaction was approved or certified. Validators vote on transactions, and aggregators collect a Byzantine-resistant majority of these votes into a certificate and broadcasts it to all IOTA validators, thereby ensuring finality.), but not for safety (it cannot change the effects of the transaction, and does not need the user's secret key).

Certificates​

After the client forms a certificateA certificate is the mechanism proving a transaction was approved or certified. Validators vote on transactions, and aggregators collect a Byzantine-resistant majority of these votes into a certificate and broadcasts it to all IOTA validators, thereby ensuring finality., it submits it to the validators, which perform certificateA certificate is the mechanism proving a transaction was approved or certified. Validators vote on transactions, and aggregators collect a Byzantine-resistant majority of these votes into a certificate and broadcasts it to all IOTA validators, thereby ensuring finality. validity checks. These checks ensure the signers are validators in the current epoch, and the signatures are cryptographically valid. If the checks pass, the validators execute the transaction inside the certificateA certificate is the mechanism proving a transaction was approved or certified. Validators vote on transactions, and aggregators collect a Byzantine-resistant majority of these votes into a certificate and broadcasts it to all IOTA validators, thereby ensuring finality.. Execution of a transaction either succeeds and commits all of its effects or aborts and has no effect other than debiting the transaction's gas input. Some reasons a transaction might abort include an explicit abort instruction, a runtime error such as division by zero, or exceeding the maximum gas budget. Whether it succeeds or aborts, the validator durably stores the certificateA certificate is the mechanism proving a transaction was approved or certified. Validators vote on transactions, and aggregators collect a Byzantine-resistant majority of these votes into a certificate and broadcasts it to all IOTA validators, thereby ensuring finality. indexed by the hash of its inner transaction.

If a client collects a quorum of signatures on the effects of a transaction, the transaction is final. This means the effects will persist on the shared database and be permanently recorded in a checkpoint within a few seconds. The epoch boundary serves as an upper bound, but in practice, the effects certificate can be used immediately to prove finality, access results, and trigger new transactions. Clients may share the certificate directly with others or use a third-party service to help propagate it.