Consensus — 2
In the earlier article, a glimpse of consensus was provided to educate the community about the start of our educational stream.
So let's do a scouting to the content of consensus on How Why and What.
We all know that blockchain technology in common terms referred to as distributed ledger but a very small percentage of users are aware that this is again quarantined into a private and public blockchain. Before we proceed further on consensus, let's try to make ourselves go deeper into multiple aspects of the mechanism.
Private Blockchain: As the name refers, this is private to the users and its is specific to the entity. The private approach refers to companies running for a specific idealogy such as logistics data, flight details, military and much more towards aiming to be confidential.
Public Blockchain: Distributed and public. This blockchain is mainly and widely used in crypto ecosystem for all the applications to be made available public and to interact with the users and its community. Ethereum, Polygon, Solana are some of the classics of this category.
Now since we are able to understand on the private and public blockchain, we also need to go beyond a little extent to understand different consensus mechanism each uses.
In generic, consensus refers to a common agreement between 2 or multiple entities. Proof of Stake ( POS ), Proof of Work ( POW ) and Delegated Proof Of Stake ( DPOS ) are some of the common consensus mechanism for a public blockchain.
Recent Ethereum upgrade from POW to POS has ensured there is a very minimum to bare in terms of fault tolerance. Delegated POS was earlier introduced during the era of Crypto initially. When made a comparison between the available public blockchains tolerance mechanism, POS is widely accepted, as this ensures the proof to be submitted before any user or community to become a part of the validator or to remain consensus in the ecosystem. This proof ( Stake of Tokens ) will eradicate the need of the unwanted situation when taught about in future.
Practical Byzantine Fault Tolerance (pBFT), Istanbul BFT (iBFT), and federated BFT (fBFT) are more popular in private blockchains. This popularity is due to its in-effectiveness to achieve the scalable solution and till date there are many sub tolerance aspects that are being architected.
IBFT are driven by phases, meaning there are a series of rounds that takes place before a block is committed unless like PBFT which uses a node structure for the commit of a block. IBFT phases are driven by PREPREPARE, PREPARE and COMMIT and as these phases suggests, any block on IBFT is prepare for its initial staging and then passes onto the prepare stage if all the details are valid and then finally the block is committed.
PBFT uses a similar way but there are validators involved for the completion of commit. Validators fetches the block and understand the need and then the validators are moved thorough a series of rounds. If a block is not committed in that round, block is moved to a next round for commit.
In PBFT, validators are static and cant be removed or added at any given point whereas in IBFT, its dynamic and nature in terms of validators.
Overall, can IBFT/PBFT mechanism be involved along with POS? As the technology evolves, this should be more towards an achieving goal.
About Pontoon: Pontoon is one click liquidity mirror cross chain solution that aims to solve the concern of fragmentation and composability in a completely trustless way. Pontoon does not MINT or BURN any assets or tokens which is solution to a decentralised transactions.
