Consensus

Find out how iov42 achieves security through our unique consensus approach.

Summary

• iov42 has developed its own consensus mechanism, DRME (Distributed Random Master Election).

• DRME randomly assigns which node leads the coordination of any given consensus decision on a per transaction basis.

• The randomness of DRME ensures bad actors cannot manipulate a iov42 network.

Overview

DRME is divided into three key phases:

1. Distributed Random Master Election (DRME) algorithm For each transaction, one of the zone’s nodes is randomly elected to be the “master” that will coordinate the voting process amongst all zone participants.

2. Voting to reach consensus Every node operator participates in the master-coordinated voting process to determine the validity of a transaction.

3. Committing the transactions to the network Based on node operator votes, the master decides if the transaction is valid and can be committed to the network’s immutable ledger, or if it is invalid and must be rejected.

Phase 1: Distributed Random Master Election (DRME)

1. iov42’s consensus process begins with each network participant generating and broadcasting DRME fragments—random chunks of data of a known length—at regular time intervals

2. The received order of these messages is identical across the network, so each participant has the same understanding of the state of the system.

→ In the example above:

• The three network participants are sending DRME fragments to each other at regular intervals.

• The order in which the fragments are received is random, but deterministic, and reflected in a message log.

• The message log shows that the fragment from Participant 2 was received first across the network followed by the fragments from Participant 0 and Participant 1.

• The participants will continue to transmit DRME fragments at regular intervals.

1. Incoming transactions are broadcast to the network participants through the same path that DRME fragments are broadcast. DRME fragments and incoming transactions are thus interspersed, ensuring the participants continue to have the same understanding of the state of the system.

2. When a transaction arrives, the latest fragment from each node is joined together with a unique value from the transaction.

3. This combined fragment is hashed using SHA-256.

The hash value is passed through a modulus function—The result determines which participant will act as the master for that transaction.

→ In the example above:

• A new transaction has been received.

• The latest DRME fragment from each participant is ordered and combined.

• The unique data from the transaction—in this case, "asdgeevd"—is added to the string of combined fragments.

• This combination is passed through a hash operation to produce a value that is then passed through a modulus function.

• The fictitious result of the modulus function is a value of 2, indicating that participant 2 will be the master for this single transaction.

Phase 2: Voting to reach consensus

1. The elected master asks all participants, master included, to vote on the validity of the given transaction.

2. Each participant checks that the request is valid based on its understanding of the state of the system (e.g. “is there enough balance to perform the transaction?”).

3. If the transaction is valid, participants will reserve the appropriate balance though the DAAL process and send back its signed vote to the master.

Note: During this phase, integrity is ensured by the use of digital signatures at each step:

1. Each submitted transaction must be signed by the identity that submitted it.

2. The master signs its instructions before sending them out to the participants to prove it was the source of these instructions. Next, each voting participant signs its vote to prove it has voted. Finally, all signed votes are collated by the master.

Phase 3: Committing the transaction

1. The master node collects enough votes and attaches these as a part of the proof for the transaction. Some transactions may require a majority, some may require full participation.

2. The master issues a commit message (in the case of a valid transaction) that tells all nodes to commit the transaction to the immutable store. This message takes the form of a transaction proof that contains all of the steps and signatures associated with the transaction.

3. This proof is signed by the master to prove it is the collator of the proof.

4. The proof is committed to the network’s immutable distributed ledger.

5. This proof (rendered below for demonstrative purposes) is then signed by the master to prove it is the collator of the proof. Finally, the proof is committed to the network’s immutable distributed ledger.