PoXt Algorithm
Every interaction is executed by a node and made into a tesseract. When the tesseract is proposed to its ICS, PoXt is applied to achieve consensus among the nodes in the ICS.
Depending on the position of nodes in the priority queue, a node can be the Generator as well as the Operator. Meaning, the node might receive or pick up the interaction from the pool, create ICS, execute the interaction and also propose the tesseract in the ICS for immediate finality.
Before we get into the depths of the PoXt algorithm, let us also understand the pre-conditions of application of PoXt in an ICS:
| Condition 1 | Every validator node must have identified itself with a real identity such as FB, Twitter, Reddit, and other possible IDs supplied by government or corporations |
| Condition 2 | Every validator node must have a minimum stake of 108 MOI tokens |
| Condition 3 | Every validator node must be running the latest release/version of the go-MOI client |
| Condition 4 | Every validator node must satisfy basic SLA requirements and obtain a minimum Note Trust Quotient (NTQ) score of 0.5 |
| Condition 5 | Every validator node joining the ICS should have the same application-context/walletcontext pertaining to the accounts involved in the interaction |
| Condition 6 | Observer nodes will not participate in the voting process, they just run an evidence collection algorithm. |
If all the above conditions are met, the PoXt algorithm is applied in the ICS as follows:
| Step1: | On successful creation of the ICS by the Operator, leader election takes place andGenerator is announced based on the priority queue (as specified in POS IA document) |
| Step2: | Generator begins the execution of the interaction and creates the Tesseract |
| Step3: | The generator will now propose the tesseract to all the validators in the ICS |
| Step4: | On receiving the tesseract, each Validator verifies the identity of the Generator, and perform basic cryptographic validation on the Tesseract |
| Step5: | Upon successful basic validation, the validators pre-vote on the Tesseract by signing the pre-vote message with their private key |
| Step6: | If more than 2/3rd of the validator nodes are pre-voted, then all the validators in the ICS perform complete validation by executing the interaction(s) in the Tesseract and perform cross-verification on the state of the accounts involved |
| Step7: | If the validators are satisfied, they sign a pre-commit message with their private key |
| Step8: | If more than 2/3rd of the validator nodes are pre-committed, then the Tesseract is precommitted along with acknowledgment in the form of a polka message sent to every validator node in the ICS |
| Step9: | If the validator nodes receive the polka message, they go ahead the commit the Tesseract in their local database and broadcast the new Tesseract to its neighbors |
| Step10: | The Observer nodes scrutinize this complete process captures the evidence of malicious behavior of the validators. |
| Step11: | The neighboring nodes who may not have been in the ICS will now add the broadcasted tesseract into their local database, after performing basic cryptographic validation |
With a firm understanding of the PoXt algorithm and how it can be implemented, let us look at the last aspect of the interaction’s lifecycle.
When a Tesseract 𝜏 is proposed in an ICS by the leader to all the validator nodes in the ICS, each node is expected to validate the tesseract and vote on whether they agree or disagree with the Tesseract.
The criteria for a node to agree with the proposed tesseract and vote for it are as follows:
- The generator has a valid identity hash and proof of code hash
- All the fields in the tesseract header must be valid
- On execution of the interaction, the generated state hash and the hash of the receipt should be equal to that specified in the tesseract.
Evidence Handling
In order to penalize bad-acting nodes in the network, we need substantiate proof of malpractice. If found, any node participating in the ICS can provide this information. This runtime proof is collected, added to the tesseract. For example, any violation of liveness in the network or dual signing can be collected as evidence data. Such data is picked up by penalization voting apps used by the validator community.
Penalization
On successful validation of the evidence data, nodes vote on whether to slash the stake of the node at the question. Each node in the ICS needs to vote for or against the slashing of the node’s behavior. If a majority number of votes are gathered for slashing, the stake is slashed as per the slashing schedule, which is revised from time to time.
| Category of faults | Specific faults by nodes | Slashing fee | Description |
| Inability-based: Faults created due to lack of resources | Unavailability | 10% | When a node cannot be pinged since it is offline due to bandwidth or connectivity issues, or when the disk corrupts or other hardware components malfunction. |
| Private Key Compromised | 10% | When a key pair of a coin-based wallet is compromised. | |
| Intention-based: Faults created unnecessarily at the behest of the validator | Non-Voting | 20% | When a node purposefully won't submit his vote in time. |
| Multiple ICS Participation | 20% | When a node participates in multiple ICS and creating a race. | |
| Rejecting ICS | 20% | When a node purposefully rejects ICS requests. | |
| Dual-Signing | 20% | When a node tries to sign different blocks for the same round. | |
| Unavailability | 20% | When a node cannot be pinged since it starts refusing requests even if it is online.. |
ICS Termination
ICS is terminated when either one of the following conditions is met when either:
- finality is achieved successfully for the proposed Tesseract, or,
- consensus engine is terminated due to an error, or
- majority of the nodes disagree on the proposed Tesseract
When one of the above conditions is met, the ICS cluster is dismissed, and the context lock is revoked.
After achieving consensus, the generator node will broadcast an ICS_Dismiss message to all nodes in the ICS
If the consensus can’t be achieved before the timeout, all ICS participants will update their occupancy state to free and unsubscribe from the cluster topic. On receiving the ICS_Dismiss message, Node Nj will stop the PoXt consensus service and updates its occupancy state to free
Finality
Once the consensus is achieved on a tesseract in an ICS locally, it will be propagated across the network. All the nodes which received this tesseract updates the respective lattice of the participant after performing the following checks
- Verify the seal and commit signatures
- Validate the tesseract height and previous hash
- Validate the header fields like Interaction hash, state hash, and context hash
Since the context of the participants is locked in an ICS, no conflicting tesseract would be generated at the same lattice height of the respective lattices.
With this, we conclude that finality in MOI is local, but the truth is persisted globally.