Conditions for Consensus Flags
The following table summarizes the required conditions used by all nodes in the network to determine the status of blocks and transactions. Every condition represents a specific validation block pattern that occurs within the structure of the Tangle. Once a node detects a new pattern, the node marks the corresponding object with the respected flag.
|Confidence Level||Block||Conflicting Transaction|
|Pre-Acceptance||Online supermajority of blocks approving block||-|
|Acceptance||Online supermajority of pre-accepted blocks approving block||Online supermajority of pre-accepted blocks voting for transaction *|
|Pre-Confirmation||Total supermajority of blocks approving block||-|
|Confirmation||Total supermajority of pre-confirmed blocks approving block||Transaction is accepted and block is confirmed|
|FinalizationThe irreversible operation where blocks receive sufficient approval and consensus, ensuring their permanence.||Confirmed block containing the slot commitment**||Confirmed block containing the slot commitment**|
\*\*Finalization is defined on the slot commitment level. A block or transaction is finalized if it is committed into the slot commitment and this commitment is finalized.
To pre-accept blocks, nodes make use of the weight of the online committee . This preliminary status is defined for blocks only.
In the following example, committee members have equal weight, and only are online. Different colors are used to distinguish distinct block issuersEntities responsible for creating and issuing new blocks into the network.. Block is pre-accepted because an online supermajority of the committee approves this block. Note that the block is pre-accepted even though no total supermajority of blocks approve .
Image: Pre-acceptance of a block.
To pre-confirm blocks, nodes make use of the weight of the total committee . In principle, the same methodology as for the pre-acceptance flag is used for this flag. However, the weight of nodes approving a block (or voting for a transaction) is compared with the total weight . This preliminary flag is defined for blocks only.
Block is pre-confirmed in the following example because a total 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 nodes approves this block.
Image: Pre-confirmation of a block.
To define acceptance for blocks and transactions, nodes use the weight of the online committee .
Once a block or transaction is accepted, it stays accepted in the perception of a node unless the node switches its slot commitment chain. In other words, accepted blocks and transactions issued in a slot become committable, i.e., they are used to generate the commitment for the slot.
Acceptance of Blocks and Non-Conflicting Transactions
In the following example, the online committee consists of nodes with equal weight. The block is accepted since pre-accepted blocks are approving this block.
Image: Acceptance of a block.
Acceptance of Conflicting Transactions
Any transaction that conflicts with an accepted transaction becomes rejected and gets removed from the reality-based ledger.
In the following example, the transaction is accepted since an online 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 pre-accepted blocks vote for .
Note that the blue node initially voted for transaction because it was delivered before . However, the blue node changes its stance in the following validation block, as it has received and processed both validation blocks that voted for . According to the blue node's local perception, now receives support from the majority of the network. This means that the preferred reality of the blue node now contains , and the branch of the next validation block is aligned with the preferred reality.
Image: Acceptance of a conflicting transaction.
Confirmation of Blocks and Non-Conflicting Transactions
A block is confirmed if there is a total supermajority of pre-confirmed blocks approving . In addition, these pre-confirmed blocks must be issued within
optsConfirmationRatificationThreshold=2 slots after the slot at which is issued. If the transaction in the block is non-conflicting, it is also confirmed.
optsConfirmationRatificationThreshold is set to a low value to guarantee the irreversibility of 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 and the finalization flag, which utilizes confirmation. The safety property is achieved because honest nodes do not switch their adopted 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. commitment chain until their current slot concludes. This means that the decision in the voting process is achieved in a short period while a total supermajority of nodes stays on the same slot commitment chain.
In the following example, the block is confirmed as a total supermajority of pre-confirmed blocks approve .
Image: Confirmation of a block.
Confirmation of Conflicting Transactions
In the following example, is confirmed as it first was accepted, and then the block containing gets confirmed.
Image: Confirmation of a conflicting transaction.
Finalization in the IOTA 2.0 consensus protocol works on the slot commitment level. This means that to finalize a block (a transaction), which is issued at a slot , two conditions should hold:
- The block or transaction is committed to slot commitment of slot ;
- The commitment for slot is finalized.
This means finalization of the commitment implies that all blocks and transactions committed into and all the previous commitments in the slot commitment chain that ends at are finalized as well.
A slot commitment is finalized if a block contains the commitment , and this block gets confirmed.
In the following example, slot commitment is finalized, thanks to the confirmation of the block containing . Consequently, all blocks and transactions committed into , are finalized.
Image: Finalization of a slot commitment.