Consensus on a DAG
The consensus protocol is necessary to achieve agreement among the nodes of the network on the set of blocks in the Tangle and the set of transactions in the ledger.
Each node in the network maintains its local copy of the Tangle and runs the consensus protocol through logical interpretation of the directed acyclic graph (DAG). More precisely, the Tangle includes blocks that carry payloads, serving as transaction proposals intended to update the ledger. Block references serve as votes from the block issuersEntities responsible for creating and issuing new blocks into the network., expressing their support for the referenced blocks and transactions. IOTA 2.0 uses bounded-size committees whose members regularly issue validation blocksValidation Blocks is a special type of blocks that are issued by members of the Validator Committee. These block allows to reach consensus in the network. to reduce communication overhead and minimize confirmationThe stages for a block (transaction) to be secured are Pre-Acceptance, Acceptance, Pre-Confirmation, Confirmation, and Slot Finalization. Pre-acceptance (pre-confirmation) requires approval by an online (total) supermajority of the validator committee. Acceptance (confirmation) requires approval by an online (total) supermajority of pre-accepted (pre-confirmed) blocks. Slot Finalization requires Confirmation of a block that includes the corresponding slot commitment. time. To evaluate consensus flagsConsensus flags for a block represent confidence levels about whether the block is successfully gossiped and included in the Tangle by the network. They include Pre-Acceptance, Acceptance, Pre-Confirmation, Confirmation, and Finalization for blocks and transactions, nodes in the network read votes from the validation blocks and find specific validation block patterns in the Tangle.
Required Components for Consensus
The following modules are necessary to achieve agreement using the IOTA 2.0 consensus protocol:
Approval Weight Module
The approval weightMeasure of approval of each conflicting transaction using the voting power of the validation blocks "issuer". module is responsible for gathering votes from the validation blocks, finding appropriate validation block patterns in the Tangle, and evaluating the voting results to determine consensus flags for blocks and transactions.
This article does not specify which algorithms are used to find appropriate validation block patterns; it only focuses on describing the consensus flags used by the protocol.
Tip Selection Algorithm
The tip selection algorithm guides the voting and agreement process, in which the committee and other nodes partake. Consensus is achieved by logically interpreting the locally maintained Tangle, specifically its blocks and the references between them.
All nodes collectively build the Tangle by attaching their blocks to a bounded number of randomly selected eligible tips. Consensus on conflicting transactionsTransactions that consume the same UTXO. is achieved without total ordering in a leaderless way. Committee members cast their votes by regularly issuing validation blocks, encoding their opinions about conflicting payloads by incorporating suitable block references. The default number of references is increased for validation blocks to improve the time to achieve consensus for blocks and transactions.
Slot Commitment Chains
Slot commitment chains are one of the core data structures in the protocol. A slot commitment is a hash digest of the accepted blocks and transactions issued during a given slot. It is linked to the commitment of the previous slotTime interval of fixed duration. The protocol divides time into non-overlapping slots. For each slot, nodes generate a slot commitment which encapsulates all accepted blocks and transactions issued within this time interval., creating a chain that extends back to the genesis block.
Under good network conditions, nodes collectively produce the same slot commitments. Under network partitioning, there could be a divergence in the perception of the suffix of the slot commitment chain. However, the finalized part of the slot commitment chain is safe under any network conditions. When the network converges, all honest nodes eventually switch to the heaviest slot commitment chain with the latest finalized slot commitment, thanks to the chain switching rule.
The Consensus Protocol’s Two Dimensions
The consensus protocol can be divided in two separate dimensions charged with different responsibilities:
Agreement Tasks for Blocks and Transactions
The first dimension consists of the agreement tasks for blocks and transactions. It has two main tasks:
Broadcast blocks reliably
This task ensures the delivery of newly created blocks to all nodes in the network. Reliable broadcast guarantees that if an honest node includes a block in its locally maintained copy of the Tangle, all other honest nodes will eventually receive and deliver that block, including it in their locally maintained version.
Agreement on conflicting transactions
This task focuses on resolving conflicts that arise when multiple transactions in different blocks in the Tangle conflict with each other, attempting to consume the same output. By fulfilling this task, all honest nodes can reach a consensus on which conflicting transaction appears in the ledger, ensuring a consistent view across the network.
Provide Consensus Flags
The second dimension provides different consensus flagsConsensus flags for a block represent confidence levels about whether the block is successfully gossiped and included in the Tangle by the network. They include Pre-Acceptance, Acceptance, Pre-Confirmation, Confirmation, and Finalization or confidence levels about the irreversibility of blocks and transactions.
When they receive a new validation block, nodes examine the Tangle to identify distinct validation block patterns, and attribute specific flags to blocks in the Tangle or transactions contained in the blocks.
A pattern corresponds to a causally ordered set of validation blocks. For instance, if a block is approved by a supermajorityA threshold for achieving consensus flags. A supermajority is a subset of the committee that has more than two-thirds of the total voting power. of the committee (validators holding more than of the total voting powerThe influence or weight a validator in the committee has in the consensus process.), then the block gets the pre-confirmed flag. In this context, the validation blocks from these validators constitute a validation block pattern necessary for pre-confirmation.
The IOTA 2.0 consensus protocol is endowed with dynamic availabilityThe ability of the system to continue to accept or confirm transactions despite arbitrary number of validators crashing.. This attribute ensures continuous operation even when some validator committeeFor an epoch, a committee selection procedure determines a subset of validators, who will carry out the consensus protocol during the epoch. This subset is called the validator committee and the validators included in the said subset are called the committee members for the epoch. members may be offline or the network experiences partitions. During such instances, the online validator committee within each partition maintains the process of updating their available ledger, which is constructed from the transactions that have been accepted.
Once the network recovers from its divided state and a supermajority of the committee is back online, the transaction finalizationThe irreversible operation where blocks receive sufficient approval and consensus, ensuring their permanence. process recommences. The consensus flags differentiate between degrees of irreversibility. This aspect balances safety and liveness, providing different trade-offs to manage various network conditions effectively.
You can learn more about a formal description of consensus protocols supporting both safety and liveness in the Ebb and Flow Protocols: A Resolution of the Availability-Finality Dilemma paper.
The consensus flags in the IOTA 2.0 consensus protocol are outlined as follows:
Pre-Acceptance
The Pre-Acceptance flag is an internal flag used to define Acceptance. This flag is raised for a block when the block is causally referenced by a supermajority of the online committee members. It means the block is deemed valid by a significant portion of the active validators in the network, hence suggesting initial agreement on the block's validity.
Acceptance
The Acceptance flag is an internal flag that is used to generate slot commitment chains, i.e., only accepted blocks and transactions are committed.
For a block, this flag shows whether the block is acknowledged by an online supermajority of pre-accepted validation blocks.
For a transaction, the flag indicates whether the transaction has received votes from an online supermajority of pre-accepted blocks. This flag prioritizes liveness and quickly adjusts its response to varying network conditions.
Pre-Confirmation
The Pre-Confirmation flag is an internal flag used to define Confirmation. This flag is raised for a block when the block is causally referenced by a supermajority of the total committee, not just those currently online. It signifies a higher approval level than the pre-acceptance flag, but it is raised slowly under bad network conditions.
Confirmation
The Confirmation flag is a flag that is exposed to the user in the wallet. For a block, it shows whether the block has been acknowledged by a total supermajority of pre-confirmed validation blocks. This flag is raised for a transaction when it is accepted, and one of its attachments (blocks containing this transaction) gets confirmed. The confirmationThe stages for a block (transaction) to be secured are Pre-Acceptance, Acceptance, Pre-Confirmation, Confirmation, and Slot Finalization. Pre-acceptance (pre-confirmation) requires approval by an online (total) supermajority of the validator committee. Acceptance (confirmation) requires approval by an online (total) supermajority of pre-accepted (pre-confirmed) blocks. Slot Finalization requires Confirmation of a block that includes the corresponding slot commitment. flag favors safety and can be slow under bad network conditions.
Finalization
The Finalization flag is a flag that is exposed to the user in the wallet. This block or transaction flag relies on finalizing the slot commitment that commits to the block or transaction. The latter means that a block containing a given slot commitment (and all objects assigned to it) gets confirmed. This flag is safe under any network conditions.
The flag hierarchy from Pre-Acceptance to Finalization is summarized in the following diagram:
Image: Flag hierarchy from pre-acceptance to finalization.