In order to achieve agreement on the updated states among the nodes in the ICS cluster, we use a novel consensus mechanism called Proof of Context (PoXt).
PoXt is a modulated trust-based consensus mechanism, built to improve the performance and quality of open networks by bringing in the best of Practical Byzantine Fault Tolerance (PBFT) 15, Proof of Stake 16, Proof of Identity, and Proof of Binary.
Figure: Modulated trust implemented using PoXt
As part of PoXt, nodes that satisfy the minimum criteria of Infrastructure Quotient (IQ), Performance Quotient (PQ) will be allowed to participate in ICS as a validator. If the nodes co-operate and work together in validating tesseracts, they make revenue from the fee paid by the signer. However, if a node is found guilty of malpractice, the stakes deposited by the validators will be slashed as a penalization.
In PoXt we use a gossip-based PBFT State Machine Replication (SMR) algorithm to overcome byzantine faults, and we use bonded Proof of Stake algorithm to overcome Sybil problems. Our algorithm proceeds in rounds, where each round has a dedicated proposer (also called a coordinator or leader).
The leader election is based on the round-robin mechanism, the validator with the highest priority is elected as the leader for that round, wherein the priority is calculated based on the number of MOI tokens that they have staked.
Our algorithm decides in four communication steps i.e., PROPOSE, PREVOTE, PRECOMMIT, and COMMIT. Following conditions need to be met at every phase once the leader sends a new proposal:
- The proposer should have valid proof of code and identity hash
- The proposal message should have a valid tesseract id and group hash
- This particular validator should not be locked on a different tesseract
- Should receive more than 2/3 of pre-votes for the tesseract
- Should receive more than 2/3 of pre-commit for the tesseract
- The authenticity of the tesseract should be cross verified
Let us now analyze the individual solution components of the PoXt algorithm: