Skip to main content

Solution Components of PoXt

Krama Proof of Stake (KPoS)​

  • The idea of using KPoS is that the higher the stake of the validator in the underlying cryptocurrency, the less interest they have in corrupting the validation process.
  • Here we are going with Bonded Proof of Stake mechanism (BPoS) 17. BPoS is an approach in which any number of users can set aside part of their stake (I.e., bond) in order to influence block generation. They lock up part of their stake for a certain amount of time (like a security deposit), and in return, they get a chance proportional to that stake to select the next block. Their voting power in the protocol is proportional to the amount of stake they are willing to lock up.
  • The idea behind using BPoS is to avoid/mitigate Sybil attacks that are present in BFT mechanisms.
  • For example, let us consider a scenario where a validator signs two tesseracts at the same time which can be referred to as a Dual Signing mechanism. These types of faults cannot be overcome using any BFT algorithms so, in PoXt we use the KPoS mechanism to penalize the validator performing these types of malicious activities.

Proof of Identity (PoI)​

  • Nakamoto consensus mechanisms like POW failed to address the centralization completely as the miner is pseudonymous and there is no way to track if a single actor has 51% of mining power.
  • POI comes in handy by keeping track of the reputation factor of all the nodes in the network and their social and economic trustworthiness by Node Trust Quotient (NTQ).
  • For example, let us assume if a validator performs some malicious activities in the network, then our framework model is designed in such a way that the validator will be penalized as per the KPoS algorithm but if the malicious activities performed is costlier then the slashed/staked value then, in these scenarios we use Proof of Identity.

Krama Byzantine Fault Tolerance (KBFT)​

  • KBFT is a context-aware Byzantine-fault tolerant consensus algorithm that is inspired by the PBFT SMR algorithm and the DLS algorithm. KBFT is used for safeguarding against system failures by employing collective decisions made by the validators based on the context of the participants which aims to reduce the influence of faulty nodes.
  • Similar to Tendermint BFT 18, we will be having 4 steps i.e., PROPOSE, PREVOTE, PRECOMMIT, and COMMIT.
  • Although PBFT based implementations are very effective in achieving high throughput in smallsized networks, they are not scalable beyond a few tens or hundreds of nodes.
  • We acknowledge and intelligently leverage this limitation of PBFT in smaller clusters of the network to achieve secure transaction throughput. These smaller clusters are called Interaction Consensus Set (ICS). And the concept of executing the transactions and achieving consensus in an intelligent manner is called Modulated trust.
  • For example, in a network with a maximum of 2 faulty replicas, we will need 7 replicas with one of them being the primary or leader. We will get 7 replicas by applying the 2 faulty replicas to our formula: 3(2 faulty replicas) + 1 = 7 replicas. In our case with a maximum of 2 faulty replicas, the minimum message count for this replica set would be 71 (I.e. request messages: 1, pre-prepared messages: 3f = 6, prepare messages: 3f(3f-f) = 24, commit messages: (3f-f+1)(3f+1)= 35, reply messages: 3f-1 = 5).
  • If we want to have just 1 more replica that can be faulty, this number increases to a minimum of 142 messages for 1 request using 10 replicas. If we Want up to 4 nodes to be faulty? Just use 13 replicas, but the minimum messages will climb to 237 for a single request. This is why PBFT does not scale as well as other consensus algorithms but is an excellent consensus algorithm for enterprise consortiums where members are partially trusted.

Proof of Binary (PoB)​

  • We use Proof of Binary to check that all the nodes in the MOI network run the latest audited binary.
  • The primary use of Proof of Binary in PoXt is for verifying whether all the nodes in the network adhere to the latest binary release which helps to mitigate attacks caused by manipulating client code or leveraging backdoors and other vulnerabilities.
  • For example, there might be a new bug in the blockchain client code that allows hackers to flush the balance from a multi-signature contract. In this case, we impose every node to update the version of the client by patching the latest binaries released, which addresses the above vulnerability. The nodes which run on the older versions of the client will fail to execute or validate transactions in the network as they are not running the latest version of the binary.
  • Using POB, we enforce the version management by asking nodes to share the commit hash of the latest build used in their respective machines. If a majority of nodes in the ICS do not recognize themselves with the latest build, ICS creation will not be successful.

With a basic understanding of how each algorithm adds value to PoXt, let us now investigate the PoXt consensus algorithm.