Understanding Finality — Part 2| Blockchain for Dummies

In the previous part of this article, we had discussed the different types of finalities that can be achieved by a blockchain protocol based on their synchronicity and probability. We also looked at how Ethereum and Near blocks achieve finalities in their respective networks. In this article, we will look at the process for three more popular blockchains — Solana, Polkadot and Cosmos.

Solana

Solana, another very popular blockchain, also uses a version of BFT called Tower BFT, along with PoH (Proof of History). Solana relies heavily on PoH as it puts a timestamp on every block(to get more information on PoH, please read our article on Consensus Mechanisms). The PoH ledger itself acts as a network clock. (5) All the nodes in Solana need to have a common understanding of the passage of time due to the application of timestamps in the protocol. The network clock is nothing but a synchronised and consistent timekeeping mechanism that helps maintain order and coordination across different nodes or participants in the network.

Tower BFT is the PoH version of PBFT or Practical Byzantine Fault Tolerance. PBFT is an algorithm designed to address the challenges of achieving consensus where some nodes may be faulty or malicious. It can tolerate up to 1/3rd of nodes being malicious and achieves this by operating in multiple phases. During the process of achieving consensus, very often a node has to wait for a predefined period to receive responses from other nodes in the network. This period is called a PBFT time-out. Since the Solana ledger works as a reliable network clock, PBFT time-outs can be encoded in the ledger itself. This means that the timeouts taken by PBFT when nodes are waiting for responses from other nodes can be included in the PoH hashing itself.

There is no separate gadget to achieve finality. Instead, it makes use of the consensus mechanism itself. We had explained in the article on consensus mechanism that in Solana, PoH operates by creating a sequence of hashes, where each hash is linked to the previous one. This provides proof of the passage of time between hashes and by extension, provides security. When validators check this proof of passage of time, they vote for the block if they are confident of its validity.

Firstly, a vote starts with the time-out of N hashes i.e. the node will wait for all the responses till the PoH hashing function does not produce N hashes. The validators need to vote for a specific hash which is a reference to a certain point in the PoH ledger. This certain point is the PoH hash corresponding to the time the block was produced. Here ’N’ stands for the number of hashes and can vary according to Solana’s protocol design and configuration.

It is important to note that a PoH hash is different from a block hash. When a validator votes, he guarantees that once a vote for PoH hash has been cast, the validator will not vote for any PoH hash that is not a child of that vote, for at least N hashes. The above statement can come off as a bit complicated so let us go back to PoH once. In our consensus mechanism article, we have discussed through an example how a block leader produces hashes and includes transactions in the input hashes and gets output hashes. These input and output hashes can be used to verify when a transaction has taken place in the PoH ledger.

Now if another block leader was trying to maliciously make another block when it was not his turn, his hashes, both input and output, would have been different and hence, the hashes for their succeeding blocks would also be different (the input-output sequence keeps getting passed on from one leader to another). When the validators commit to voting only for the child of a PoH hash they have already voted for, they are committing that they will not vote for any blocks that are not the children of the block they had already voted for before, as seen in the figure below. But this is only applicable for N hashes. The figure below simplifies the theory above.

Secondly, the time-outs for all the predecessor votes double. Voting is restricted to a fixed period, which are called slots of 400ms and the goal is to have these N hashes completed before 400ms. These hashes can be assumed to be computational work that has to be completed within this time limit. Every 400ms, the network has a potential rollback point in case there is a network delay and no majority is achieved or if there are conflicting transactions. A rollback point allows the network to revert to its previous state but every subsequent vote doubles the amount of real time the network would have to stall before it can unroll that vote.

So if a validator has voted 32 times during the last 12 minutes, the vote 12 seconds ago now has a timeout of 232 slots which is equal to 54 years. Effectively, this vote will never be rolled back by the network. As new blocks are added to the ledger, old blocks are increasingly likely to be confirmed because the number of slots old votes are committed to doubles every slot, or every 400ms. (1) The rough work for this calculation is shown in the diagram.

This explanation might make it seem that Solana achieves probabilistic finality. But that is not true. Solana actually achieves deterministic finality as once 2/3rd of the validator set has voted for a particular PoH hash, that hash cannot be rolled back.

Solana is not the only blockchain to use BFT, Polkadot uses it too.

Polkadot

Polkadot blockchain network uses BFT along with the GRANDPA finality gadget for the finalisation of blocks. GRANDPA stands for Ghost-based Recursive Ancestor Deriving Prefixing Agreement which allows for finality of not just a single block but chains. (2) In Polkadot, finality is achieved by consecutive rounds of voting by the validator nodes. These rounds are ‘pre-vote’ and ‘pre-commit’. The gadget works independently of the block production mechanism in the network and works in a partially synchronous network model as long as ⅔ of the nodes are honest and can cope with ⅕ of the Byzantine or malicious nodes in an asynchronous setting.

We shall understand each term that makes up the abbreviation ‘GRANDPA’ to comprehend its functioning. The first word in the abbreviation is ‘Ghost’. Ghost in itself stands for ‘Greediest Heaviest Observable Sub-tree’. Ghost is a fork selector that helps the blockchain decide which fork should be considered as the main chain. We can see in the diagram below that forking has occurred and A is the parent block for all the other blocks. The question is which block is considered to be part of the main chain. One validator, called the ‘primary’, is chosen who will initiate the Ghost protocol and then the validators vote on which subchain they think should be added (BC or DEF). Post-voting, they broadcast their votes to the network.

The protocol, once the voting has been completed, checks the number of votes that every sub-tree has received. These votes are weighted in nature i.e. the weight that a vote carries is dependent on the stake that has been deposited by the validator. We can see that the votes of the descendants have also been added to give the total weight of the first block in the sub-tree. Since D has 60% of the total weighted votes, DEF becomes the sub-tree to become a part of the main chain. This explains why the protocol uses the term ‘heaviest observable sub-tree’. This does not mean that the longest fork will always have more votes. If C had 60% votes or the total of EFG had been lesser, BC could have become part of the main chain.

The GRANDPA protocol is Ghost-based, which means that it also asks the validator set to vote for a set of blocks or a chain instead of just one block for finality and chooses the sub-tree with the maximum weightage of votes. As mentioned above, this is done in two different steps. The first step is called ‘pre-vote’. This is where all the validators find the highest block they consider to be valid in a chain. Now this block may vary from one validator to the next, so the protocol finds the highest block that more than 2/3rd of the validators set has voted for. This highest common block along all its ‘ancestors’ forms the longest common chain (identified by the ‘g’ function). The g function finds the common prefix or the chain of ancestor blocks of the highest common block voted. (3)

Suppose the range of blocks that are considered for finality, ranges between the height of 542 and 555 (refer the figure below). According to validator A, the highest block to be finalised is 555, according to B, it should be 551, according to C, it should be 553 and according to D, it should be 549. The highest common block in this round would be 549. This entails that 549 including all its ancestor blocks till 542, the longest common chain, would be considered for the second round.

The second round is known as ‘pre-commit’. As the result from the first round shall be used in this round, the process becomes ‘recursive’ in nature. The same process is repeated. All the validators again vote for the heaviest block between 542 and 549. Again the validators may vote differently and the highest common block, imagine it to 547, gets voted as the highest common block. Now the blocks between height 542 and 547 (all these blocks together, forming a chain, are called a ‘prefix’) all get finalised together. Here as well, the g function identifies the longest prefix with the most 2/3rd of the votes. The pre-vote round is similar to an expression of faith while the pre-commit round is similar to an expression of confidence.

Thus GRANDPA identifies a common highest block in two different rounds to finalise it along with its ancestors or prefix, forming a chain, based on the weighted votes of the validators in these rounds.

Cosmos

Unlike all the blockchains we have discussed above, the only blockchain that achieves instant finality is Cosmos by using the Tendermint protocol. Users can be sure that their transactions are finalised as soon as the block is included. The reason for this is the use of Byzantine Fault Tolerance for achieving consensus while validating the block itself. A block can only be added to the chain if it gets a supermajority in all the rounds — pre-vote, pre-commit and commit phase. Once it receives a supermajority, the block cannot be reverted and the block becomes finalised, thus making it deterministic finality. BFT also allows for the protocol to function even if ⅓ of the validators are malicious. You can read about this in our article on Consensus Mechanism. In all the above blockchains, BFT has not been used to validate the block but to finalise it.

Conclusion

Achieving finality in blockchains is a process in moving towards transparency and immutability. The notion that once a transaction is confirmed, it is irrevocable, brings immense value to a lot of industries such as finance, healthcare, supply chain management and voting systems.

References —

1. https://medium.com/solana-labs/tower-bft-solanas-high-performance-implementation-of-pbft-464725911e79
2. https://wiki.polkadot.network/docs/learn-consensus#protocol
3. https://research.web3.foundation/Polkadot/protocols/finality

Understanding Finality — Part 2| Blockchain for Dummies was originally published in Aerius Labs on Medium, where people are continuing the conversation by highlighting and responding to this story.

The concept of “finality” plays a big role in establishing immutability and reliability in a blockchain network. Finality refers to the point at which a block and the included transactions are irrevocably confirmed and added to the blockchain’s immutable (unchangeable) history. While different blockchains employ different protocols to achieve finality, the end goal is the same — to provide a trustless and secure environment where all honest participants agree on the current state of the chain. In this article, we delve into the difference between deterministic and probabilistic finality, synchronous and asynchronous finality and how blockchains achieve it in their environments.

After a block is built, first it achieves consensus and then achieves finality. To understand the basics of different consensus mechanisms, you can refer to the consensus article— https://blog.aeriuslabs.org/decoding-consensus-blockchain-for-dummies-part-1-c9cb71609e11

Byzantine Fault Tolerance
In any decentralised network, there is always a probability that some validators may behave maliciously or attempt to disrupt the proper functioning of the network. Such validators are known as Byzantine validators. Byzantine Fault Tolerance is a property that ensures that a system can function correctly even when a certain number of participants are acting maliciously (usually any network with BFT is prepared to tolerate up to 1/3rd of the validators acting maliciously).

Malicious behaviour can consist of multiple scenarios. These include -

• The inclusion of invalid transactions in a block by the proposer or multiple validators trying to create a block together at the same time i.e. in the same slot. This would create a conflict as to which block should be the next one to be added to the chain. When this happens, during voting, validators may get confused and vote for more than one block to be the next in the chain.
• Malicious validators may also collude with each other to vote for a block containing invalid transactions or for multiple blocks.

Probabilistic and Deterministic Finality
In probabilistic finality, a block is considered final once it has been included in the blockchain and has a subsequent number of blocks on top of it. Probabilistic finality implies that the probability of a block reverting lowers as more blocks are added on top of it, because the amount of resources, computational or economical, that are required to chain increase as the block gets deeper into the chain.

There always remains a small probability of reversal, though this probability reduces as time passes. Probabilistic finality assumes that simple majority of validators are honest and hence, all the transactions in the block that have achieved consensus shall be deemed finalised as the chain in front of it gets longer and longer.

On the other hand, deterministic or absolute finality, achieved through Byzantine Fault Tolerance (BFT) mechanisms provides a stronger guarantee of permanence, as once a block is added to the chain, it becomes finalised. BFT mechanism ensures that the chain shall sustain if less than 1/3rd of the validators in the set are malicious. While deterministic finality offers faster block finalization, the number of validators required to halt consensus are much less than probabilistic models. Furthermore, validator sets for chains with deterministic finality are smaller because multiple rounds of consensus are required to deem a block ir-revertable (this is due to partial synchrony assumptions required, which is discussed later)

It may seem that deterministic finality is more desirable than probabilistic finality but certain tradeoffs make probabilistic finality the first choice for many blockchains. Eric Brewer’s CAP theory suggests that in case of network failure, a distributed system, such as a blockchain, can only preserve either its consistency or its availability. A consistency-preserving system would rather halt than let inaccurate transactions through whereas an availability-preserving system would continue even if it lets inaccurate transactions through. Deterministic finality is preferred by consistency-favouring systems and availability-favouring systems provide probabilistic finality. In the case of making payments, users favour constant availability over consistency. (1)

Synchronous and Asynchronous finality
In the former, the network operates in rounds with known and fixed time intervals for each round. Once a block is validated, it is considered final. There is no time lag between the block validation and finality and these two steps are sequential. Synchronous finality is more deterministic and offers strong guarantees about the state of the blockchain. It is often used in blockchain networks which have applications such as real-time payments or critical financial transactions.

Asynchronous finality, on the other hand, does not rely on time intervals. It allows for a more continuous process of reaching an agreement on block confirmation. Blocks can be confirmed and finalised at different times and do not have to be sequential. It allows for more flexibility in dynamic environments, such as when a lot of validators are offline or there is a network failure.

Various blockchains also assume partial synchronous networks which is a middle ground between asynchronous and synchronous networks. In this model, there is an assumption that the network eventually becomes synchronous but there is no guarantee when that transition will occur. Initially, the network may face some network failure or snag and display asynchronous behaviour. Still, over some time the network gradually transitions to smoother message delivery within a known time frame and better network behaviour.

Forking
Before we move ahead, we need to make ourselves familiar with ‘forking’. A block contains the hash of the previous or the parent block to identify the sequence of blocks in a chain. When two blocks have the hash of the same parent block, forks are made. This creates a new branch or version of the blockchain. Forking happens for two reasons — 
1. Major updates in protocol
2. Network delays or disagreements within the community such that two block proposers produce blocks in the same slot.

Forking due to disagreements can fragment the community, resources and development efforts making it harder to achieve consensus. It also compromises the security of the network and hurts the economic model of the blockchain.

Let us deep-dive into how some popular blockchains achieve finality.

Ethereum
The method of achieving finality changed for Ethereum as they shifted from Proof of Work to Proof of Stake (Eth2.0). We have already seen in the article on consensus mechanisms that Ethereum has a time system that it follows to create and validate blocks. A block is produced in every slot (one slot = 12sec) and an epoch is made of 32 such slots, which makes it 384 seconds or 6.4 minutes long. This means that every epoch has 32 block proposers and produces 32 different blocks. Every one who shall vote for these blocks in every slot is called an ‘attestor’.

Now that we have covered the basics, we can talk about the finality gadget Eth2.0 uses called ‘CASPER FFG’, where FFG stands for ‘friendly finality gadget’. It is also a BFT protocol that assumes that 1/3rd of the total number of validators are malicious. To understand it better, assume that there are 3 sequential epochs and we name them A, B and C as seen in the figure below. Before epoch A, there was an epoch N. During A, 32 blocks were produced (one in each slot) and the same follows for epoch B. We shall also suppose that epoch C has just begun so the blocks for epoch C are still being produced.

Now the job of the finality gadget starts. Finalisation does not happen for every block but for an epoch. CASPER FFG assigns the first block produced during every epoch to be a ‘checkpoint’. This means that the first block in epoch N, called N1, and the first block in epoch A, called A1, become checkpoints. During the production of blocks in epoch B, assuming I am one of the validators, I will tell the network that I believe that checkpoint A1 is valid. This means that I have broadcasted an attestation for the checkpoint of epoch A. Once I do this, all the nodes in the network start to think if they find A1 valid or not. If they do, they further broadcast their attestations or votes on the network. If more than ⅔ of the validators broadcast for the same checkpoint, the checkpoint A1 becomes ‘justified’. This is the first round which ‘justifies’ a checkpoint. When a checkpoint gets justified, all the blocks preceding the checkpoint in the previous epoch are justified. So all the blocks from N1 to N32 are now justified.

The second round leads to the finalisation of checkpoint A1. This happens when epoch C has begun. In this round, I tell the network that A1 checkpoint has been justified and the collective opinions I gained from round 1 (the attestations from my local network). Then I shall also gather the attestations from the rest of the network i.e. outside my local network. If I get more than 2/3rd of the votes from the entire network, the checkpoint gets finalised. (Refer to the figure below)

Under ideal conditions, it takes one epoch to justify a checkpoint and another epoch to finalise the same checkpoint. At the start of epoch C, we are aiming to justify checkpoint B1 and to finalise checkpoint A1. This means that while B1 checkpoint was justified during epoch C, It would only get finalised during epoch D. The finalisation also happens only if the network gives a ⅔ majority for B1.

This entire process of voting for both rounds is spread out during the entire duration of an epoch. But one can imagine that there are thousands of validators and these thousands of validators would send thousands of messages simultaneously which will create a lot of confusion. To avoid this confusion, in each slot, only 1/32 of the total validator set is scheduled to broadcast a vote. This means each validator gets to vote only once during an epoch. Also, each of these validator votes is weighted based on the amount of ETH that has been staked by them.

Finality is achieved in 12.8 minutes i.e. 6.4 minutes for the checkpoint to get justified and another 6.4 minutes for it to reach finality. But as two rounds overlap and are pipelined, the finalisation of some checkpoint always happens every 6.4 minutes. Network congestion is one of the reasons for the delay in finalisation due to which it has also taken approximately 14 minutes to finalise a checkpoint. (1) Ethereum’s CASPER FFG leads to deterministic finality in the blockchain.

NEAR
The process of achieving finality in Near protocol and Ethereum can be considered similar if not the same, one of the differences being the use of checkpoints and a round of finalisation in Ethereum. In Near, finality is achieved using ‘Doomslug’ and a finality gadget called ‘Casper NFG’ or ‘Casper Nightshade Finality Gadget’. Doomslug allows the participants that have been chosen in an epoch (epoch = one day) to produce and broadcast blocks over the network. To understand what Doomlug does, we shall assume that there is a block at height ‘h’ called A. The height of a block is a way of indicating how many blocks have been added before a certain block. So if the height of A is 1000, this would mean that 999 blocks have been added before A.

Doomslug chooses a proposer out of the validator set to produce A. Once A has been produced, it is broadcast to the entire network. All the participants who have received the block shall check the validity of all the transactions that have been included in the block and show their faith or confidence in it if they find the block to be valid. To display this confidence in block A, participants send their endorsements or signatures to the participant responsible for producing the next block which has a height of ‘h+1’. If the producer for the next block named ‘B’ has more than half the endorsements for Block A, he will produce block B. But, if after some predetermined time, the block producer for B does not produce the block, the endorsements are sent to the block producer responsible for producing the block at height ‘h+2’ or block C. Once the block producer of C receives more than half of the endorsements to proceed, he proceeds to produce C. (3)

One can conclude that every block has the endorsements of more than half the participants for the previous block. In this case, block B contains over half the endorsements for block A. Considering these endorsements, the finality gadget of the protocol declares block A to have less than full finality or as it is called, ‘Doomslug Finality’. This means that A is not 100% final but somewhere mid-way. This is considered as one round of communication. Block A is now irreversible.

Similarly, block C has more than half the endorsements for block B, thus giving Doomslug finality to B. But what happens to A? Once block C has been produced and block B has received Doomslug finality, block A reaches full BFT finality. This is considered round two of communication. The above explanation indicates that when a block at height ‘h+2’ or C is created, the block at height ‘h+1’ or B reaches Doomslug finality and the block at height ‘h’ reaches full BFT finality. By extension, if a block at height ‘h+3’ or D is created, block at height ‘h+2’ or C reaches Doomslug finality and block at height ‘h+1’ or B reaches full BFT finality. Thus, it takes a block of 2 rounds of communication to reach full BFT finality.

To reverse a block that has achieved full BFT finality, ⅓ of the total stake deposited by the participants would have to be slashed. (4)

There is a Part 2!
To make sure that the article does not become too difficult to read, we decided to split and serve it in two parts. The second part will discuss finality in Solana, Cosmos and Polkadot.

Stay tuned!

References
1. https://medium.com/mechanism-labs/finality-in-blockchain-consensus-d1f83c120a9a

2. https://eth2book.info/capella/part2/consensus/casper_ffg/

3. https://near.org/blog/doomslug-comparison

4. https://near.org/papers/proof-of-space-time

Understanding Finality- Part 1| Blockchain for Dummies was originally published in Aerius Labs on Medium, where people are continuing the conversation by highlighting and responding to this story.

Introduction

In today’s digital landscape, striking a balance between user privacy and safeguarding against spam and abuse is a paramount challenge. While conventional spam protection methods often compromise anonymity, privacy-preserving applications require innovative approaches to maintain user privacy while effectively combating malicious activities. One such solution is the implementation of Rate Limiting Nullifiers (RLN) using Zero Knowledge Proofs (ZK). In this article, we will explore how RLN and ZK enable a privacy-preserving approach to spam protection, ensuring the anonymity of users in applications that value privacy.

Spam Protection and Privacy: A Delicate Dilemma

In the quest for reaching a large user base, online applications constantly grapple with the issue of spam protection. Traditional techniques, such as user identification or IP blocking, prove effective in thwarting spam. However, they come at the expense of user privacy, rendering them unsuitable for applications that prioritize anonymity, such as privacy-preserving chat platforms or online voting systems.

To better understand the significance of Rate Limiting Nullifiers (RLN) using Zero Knowledge Proofs (ZK), let’s consider a straightforward example: an anonymous voting application. In this context, the primary security goals revolve around two crucial aspects:

1. Preventing Denial of Service (DoS) Attacks: Ensuring One Vote per User within the Allotted Time Frame — In an anonymous voting application, it is vital to limit users to casting only one vote within a specific time frame, often referred to as an epoch. This measure serves as a defense mechanism against spamming and potential Denial of Service (DoS) attacks. By imposing a rate limit on voting activities, the application can maintain the integrity of the voting process and prevent malicious actors from overwhelming the system.
2. Safeguarding Against Sybil Attacks: Mitigating Identity Replication — Another critical security concern in anonymous voting applications is guarding against Sybil attacks. A Sybil attack occurs when an adversary attempts to create multiple fake identities to influence the voting outcome unfairly. To maintain the integrity of the voting process, it is crucial to prevent users from easily replicating identities, thus ensuring that each individual has only one voting identity.

Rate Limiting Nullifiers using Zero Knowledge Proofs present an elegant solution to address these security goals in anonymous voting applications. By employing RLN with ZK, the application can enforce rate limits and prevent multiple votes from a single user, all while preserving the anonymity of voters.

WTF are Zero Knowledge Proofs

For someone who has reached this point but still wondering wtf are Zero Knowledge Proofs, let me explain briefly.

Zero Knowledge Proofs (ZKPs) are a clever cryptographic technique that lets someone prove they know something without revealing the actual information. It’s like showing someone you have a secret code without actually telling them what the code is. ZKPs are used to ensure privacy while still proving that someone has certain knowledge or meets certain conditions. They’re a powerful tool for building secure systems where people can authenticate themselves without giving away sensitive information.

ZKPs are awesome and there are tons of resources on them here

The Protocol: Unveiling its Three Key Components

The Rate Limiting Nullifier (RLN) Protocol comprises three fundamental parts that work together seamlessly to enable effective rate limiting while preserving user privacy and anonymity.

• User Registration
• User Interaction
• User Removal

Let’s understand each component in detail.

User Registration

Users are required to stake a valuable asset and generate a secret key. By hashing the secret key and adding it to the Registry Merkle Tree, the protocol ensures a unique and verifiable user presence. This prevents users from easily generating multiple identities, promoting fairness and integrity in rate limiting.

The Registry Merkle Tree serves as cryptographic proof of user existence within the RLN Protocol. By incorporating hashed identity commitments, the tree verifies the presence of each user in the system. This mechanism strengthens identity integrity, mitigates the risk of identity replication, and establishes a reliable foundation for subsequent interactions.

User Interaction

Each user interaction with the application requires the generation of a zero-knowledge proof. This proof assures verifiers, such as servers in centralized applications or other users in decentralized applications, that the user is a valid member with their identity commitment included in the membership Merkle tree.

Interactions vary depending on the application, such as voting in a voting application or sending messages in a chat application. To prevent spam, an anti-spam rule is introduced, often in the form of limiting the number of interactions per epoch.

For simplicity, let’s consider the rule as “Users must not send more than 1 message per second.”

The anti-spam rule is implemented using Shamir’s Secret Sharing scheme, which enables secret sharing through polynomials. By splitting the user’s secret key into shares, a minimum number of shares is required to reconstruct the original secret. In this case, a 2/2 Shamir’s Secret Sharing scheme with a linear polynomial is used, meaning the user’s secret key can be reconstructed if they send two votes per epoch.

To ensure validity, the user’s zero-knowledge proof must include shares of their secret key (the X and Y shares) and the epoch. If any of these fields are missing, the proof is considered invalid. By exceeding the allowed number of interactions per epoch, users risk full reconstruction of their secret key by the verifiers, as each interaction leaks a portion of it. This ensures the Rate Limitng factor of the protocol.

User Removal

Once a user exceeds the maximum number of interactions allowed, the protocol automatically exposes all the shares of their secret key. Since all the shares are public, anyone can recreate the spammer’s secret key. The spammer is then slashed, i.e removed from the Registry Merkle Tree and the first user to report the spammer gets the spammer’s stake as a reward.

Use Cases: Applying the RLN Construct in Anonymous Environments

The Rate Limiting Nullifier (RLN) construct has a wide range of applications in environments where user identities are anonymous. Any application that facilitates interactions among users with anonymous identities can greatly benefit from spam protection provided by the RLN construct.

Here are a few interesting use cases where the RLN construct can be applied and explored:

1. Private communication channel for ETH2 validators: The RLN construct can be utilized to establish secure and private communication channels among validators in the Ethereum 2.0 network. This enables confidential information exchange while preventing spam and ensuring the integrity of the network.
2. Instant messaging applications for private and anonymous communications: By implementing the RLN construct, instant messaging applications can maintain user privacy and anonymity while effectively combating spam and abuse. Users can engage in private conversations without the fear of identity disclosure or excessive spamming.
3. Cloudflare-like service with RLN for spam protection: RLN can be employed as an alternative to traditional CAPTCHA mechanisms in services similar to Cloudflare. By incorporating RLN-based spam protection, these services can maintain user anonymity and privacy while effectively filtering out spam and malicious activities.
4. Decentralized, anonymous voting applications: The RLN construct can play a pivotal role in decentralized voting applications, ensuring fair and secure elections while preserving voter anonymity. By implementing rate limiting and anti-spam measures, the RLN construct enhances the integrity of the voting process.
5. Privacy-preserving peer-to-peer networks: Peer-to-peer networks that prioritize user privacy can leverage the RLN construct to prevent spam and abuse within the network. This enables secure and anonymous file sharing, communication, and collaboration among network participants.

Further Reading

• Technical Overview of RLN — https://rate-limiting-nullifier.github.io/rln-docs/protocol_spec.html
• Great video explaining Shamir’s Secret Sharing — https://www.youtube.com/watch?v=K54ildEW9-Q
• A great way to get coding ZK Circuits — https://github.com/ConsenSys/gnark

User Anonymity in an adversarial environment: Exploring Rate Limiting Nullifiers using Zero… was originally published in Aerius Labs on Medium, where people are continuing the conversation by highlighting and responding to this story.

Let’s dive into the second part

Polkadot

Polkadot uses something called “Nominated Proof of Stake”. It has two main actors — validators and nominators.

• Validators are responsible for validating the transactions
• Nominators nominate the validators they support

NPoS encourages everyone who holds the native token, DOT, to become ‘nominators’. A person should stake a minimum of 250 DOT to express an intention to nominate. (This value keeps on changing in every era, a specific period of time during which certain events take place). An interesting thing to note, in Polkadot, is that anyone can display an interest in being a validator. A list of all the interested validators is sent to all the nominators. Each nominator can then share a list of 16 validators they support. After this, the distribution of stake takes place where nominators allocate their tokens or their stake to the validators they support. The interested validators with the highest support or staking become active validators and the network then distributes the stake evenly amongst all the validators, maximising security.

Currently, the minimum stake backing a validator in the active validator set is 2055241.409 DOT in the era 1269. For any node to become a validator, he should be able to stake the ‘minimum amount + 1’ DOT.
(Era is 24 hours on Polkadot) (Source — https://support.polkadot.network/support/solutions/articles/65000168050-what-is-an-era-)

Hence, the staking is not just done by the validators but by the nominators also who are backing a validator as seen in Fig.1. Both the parties have a stake in the network. They can earn rewards for their participation and a penalty is charged on both the nominators and validators in case of any malicious activities by the validator.

Nominated proof of stake is an extended version of the proof of stake consensus mechanism. When a validator is chosen and successfully validates transactions, it earns rewards in the form of additional tokens. These rewards contribute to the validator’s increased token holdings, further enhancing their chances of being selected as a validator. However, if only self staking (a validator only puts up their own tokens forstaking ) can cause relative concentration of stake and repeated selection can potentially challenge the decentralisation aspect of the blockchain.

The process of reaching consensus is very similar to that of Ethereum itself and for that reason, we are not repeating it here. While Polkadot claims that NPoS alleviates the centralisation problem to a great extent by allowing all participants (token holders) to become nominators and earn rewards by backing the desired validator, a similar problem might plague NPoS as well. Nominators with higher stakes might only support one validator again and again thus leading to centralisation and biases. NPoS may also suffer from lower participation which can again skew the mechanism towards a few validators.

Cosmos

Cosmos moves away from just using PoS by adding BFT (explained ahead) to its mechanism. Cosmos is not just one blockchain but a network of multiple blockchains that can interact with one another. One of the many things that we have learnt till now is that every blockchain has its consensus mechanism, but the same is not the case with Cosmos. From an architecture point of view, blockchains can be divided into three different layers — application layer which processes transactions, networking layer which propagates messages and consensus layer. Cosmos packages the networking and consensus layer of the blockchain into a generic engine (making it a common feature) so that developers can create new application layers on top of it. (1)

Cosmos uses ‘Tendermint’ and a Byzantine Fault Tolerance (BFT) engine to power itself. Tendermint uses the Proof of Stake algorithm to achieve BFT. Just like any other PoS blockchain, Cosmos also requires its participants to stake its native token (ATOM) to become a validator. As we have read before, a block proposer proposes a block i.e. he will validate the transactions sent to him through the network, put it inside the block, and then send this block to all the validators for voting.

What is BFT?
In any decentralised network, there is always a probability that some validators may behave maliciously or attempt to disrupt the proper functioning of the network. Such validators are known as Byzantine validators. BFT is a property that ensures that a system can function correctly even when a certain number of participants are acting maliciously. Tendermint’s consensus algorithm is designed to tolerate up to one-third of the total number of validators misbehaving. That means as long as less than one-third of the validators are acting maliciously, the system can still reach a consensus on the valid state of the blockchain.

Malicious behaviour in the cosmos network can consist of multiple scenarios. These include the inclusion of invalid transactions in a block by the proposer or multiple validators trying to create a block together at the same time i.e. in the same slot. This would create a conflict as to which block should be the next one to be added to the chain. When this happens, during voting, validators may get confused and vote for more than one block to be the next in the chain. To add to that, malicious validators may also collude with each other to vote for a block containing invalid transactions or for multiple blocks. BFT accounts for all of these malicious nodes by already assuming their existence in the network and hence, the multi-step process acts on a two-thirds majority.

How the consensus mechanism has been designed to allow for one-third of malicious actors without hampering the validation process?Tendermint’s protocol is a multi-step process, each with certain roles and responsibilities of the validators. The first is proposing where a single validator acts as a block proposer, who creates a block with all the valid transactions. The next step is ‘pre-voting’. Once the block proposer creates the block, he broadcasts it to the network. Other validators then independently validate the proposed block and cast their ‘pre-votes’. A pre-vote indicates that a validator has checked the proposed block and finds it valid based on the consensus rules of the protocol.

The third step is ‘pre-committing’. Once a proposer receives a sufficient number of pre-votes (two-thirds of the total voting power), they move to this phase. During pre-commit, the proposer broadcasts a pre-commit vote to the network. This vote includes the hash of the proposed block they pre-voted for. Essentially, a pre-commit vote means that a validator is ready to commit the proposed block to the blockchain if the block gathers enough support from other validators. Finally, if a block receives two-thirds or more pre-commits, it moves to the ‘commit’ phase. During this, the proposed broadcasts a final “commit” vote to the network, confirming the proposed block’s validity. Once two-thirds of the validators have committed to the same block, the block becomes confirmed and is added to the blockchain as the next block. At this point, it is considered the canonical version of the blockchain’s state. The diagram below is a representation of the entire process that a block has to go through.

Near Protocol

Another version of PoS is ‘Thresholded Proof of Stake’ which is being used by NEAR as its consensus mechanism. The underlying concept is very similar to the usual PoS where the participants have to stake a certain number of native tokens, NEAR tokens in this case, into their accounts to be considered to become a validator. As soon as this transaction is made, the deposits are locked for three days. In the NEAR environment, participants are known as ‘witnesses’.

NEAR also uses a time system to function smoothly which consists of slots and epochs. To increase decentralisation, the protocol is built such that a large number of participants make decisions during a specific interval of time. This interval is fixed at one day as a default. Each interval is split into a large number of block slots — 1440 slots per day i.e. one slot per minute with a large number of participants/witnesses per block, which is also fixed at a default number of 1024. With these defaults, the number of witness seats available makes up to 1,474,560 (1024*1440 = 1474560) that need to be filled for one day. (2)

A seat is the number of votes a participant can cast in the consensus protocol. Every seat is then auctioned to all the participants and there is a threshold number of tokens that have to be deposited to get a seat. This threshold amount of each seat is decided by a pre-designed formula which is a ratio of the total number of tokens staked by all the willing participants to the total number of seats. At the end of each day, all deposited tokens are counted and the calculation is done.

Let us take an example to understand the process better. Imagine there are 6 participants, A, B, C, D, E and F. (Refer to the table below). Let us assume A has staked 1,200,000 tokens, B has staked 700,000 tokens, C has staked 450,000, D has staked 450,000, E has staked 149,199 and finally F has staked 1 token. This makes the total number of tokens equal to tokens. Thus, the threshold amount per seat will be 2,949,200/1474560 which is equal to 2 tokens per seat.

According to our calculation, A has the highest number of seats and thus can vote the highest number of times. As one can notice, one block slot has 1024 seats to be filled. This means A will be allocated seats in more than one block slot and this allocation will be done by pseudorandom permutation. A pseudorandom permutation in simpler terms is a function that uses a specific algorithm and a secret key but to the observers, it seems to be completely random as they do not know the secret key being used.

Once the validator set (validators voting per block) has been chosen, the block proposer proposes a block after verifying all the transactions that are supposed to be a part of that block. This block is then broadcasted to the validator set which again validates the transactions and checks for any malicious transactions. Once the block proposer receives a supermajority i.e. a positive vote from 2/3rd of the validator set, the block is finalised and made a part of the blockchain. As an incentive for participating in the consensus mechanism, the witnesses are given an inflated reward i.e. an inflation rate is proposed to be defined as the percentage of the total number of tokens and then divided amongst the witnesses as per their deposits. In case a witness blocks two different blocks, their deposits are forfeited or slashed. One day after the witness stops being a part of the consensus protocol, his deposit is unlocked and can be used freely.

Conclusion
All the above blockchains have used PoS as the foundation to build their consensus mechanisms. The reason why PoS is used so widely is because firstly, it does not require the validators to put in extensive computing power to mine blocks, like Proof of Work did. Secondly, PoS also encourages good behaviour from the validators by rewarding them for voting for the right blocks. It also discourages malicious behaviour by introducing ‘slashing’ thus increasing accountability for validator’s actions. The various versions of PoS that have been introduced focus on increasing decentralisation in the blockchain’s consensus protocol by including as many participants as possible. These also, in certain blockchains, increase security (adding BFT) and reduce the time taken to finalise the blocks once they have been created (such as in PoH). Ultimately, each blockchain’s consensus mechanism is tailored to meet specific needs, attracting developers, enterprises and users with distinct requirements. As the blockchain industry continues to evolve, these mechanisms will drive the future of decentralised applications, bringing us closer to a more inclusive and interconnected digital world.

References -
1.https://v1.cosmos.network/intro
2. https://near.org/blog/thresholded-proof-of-stake
3. https://wiki.polkadot.network/docs/faq

Decoding Consensus | Blockchain for Dummies— Part 2 was originally published in Aerius Labs on Medium, where people are continuing the conversation by highlighting and responding to this story.

Blockchains have changed the way we access and utilise various services. We can now transfer assets directly without relying on intermediaries, establish decentralised organisations governed by participants, execute contracts automatically without intermediaries, and much more. However, the absence of a central authority raises questions about ensuring the integrity of activities and decisions regarding future blockchain upgrades. How can participants trust that actions conducted on blockchains are in good intent? Moreover, without centralised governance, how do we determine which features should be incorporated in the next upgrade? Addressing these concerns is crucial to utilise the full potential of blockchain technology. That is where the consensus mechanism, a core concept of blockchains, steps in.

What is a Consensus Mechanism?
Consensus means to agree on something. A consensus mechanism in a blockchain is like an algorithm that allows all the participants in a network to come to a mutual agreement regarding the ledger’s state. The state involves information on account balances, smart contracts, transaction history, permission and access control, metadata, etc. A state change can be as small as subtracting tokens from one account and adding to another. The state acts as a foundation for trust and security in a decentralised computer network by enabling all the nodes to reach a consensus without relying on a central authority.

Let us assume that there is a group of kids who are playing a game but have forgotten the score. An argument ensues where they are trying to decide what the current score is. To ensure that everyone agrees on the score, a consensus mechanism is decided. This is known as the Proof of Agreement as it considers everyone’s opinions to achieve a consensus. Every time a point is scored, every participant announces what they believe to be the score. For example, kid A may say that the score is 3–2 but kid B believes that the score is 4–1. Now each player announces their score one by one and they try to reach an agreement. They can share their reasons, present evidence and try to convince each other that their score is right. The discussion continues till they reach an agreement. This is the activity of consensus building. Once an agreement is reached, all the players verify the agreed-upon score. They check if it aligns with their understanding and if it makes sense to them. If everyone finds the agreed valid score valid, consensus is achieved. This is the process of verification. The last step is record-keeping where the decided score becomes the game’s current score. This score will now be used for any future reference. This is how consensus mechanisms work with the participation of all the members and without the presence of any central authority.

Before we hop onto a more technical explanation, there is a need to understand certain terms that are frequently used in this article.

Terminology

• Transaction — With reference to blockchain, a transaction is a single unit of activity. It typically involves the transfer or modification of assets or information between participants and signifies ‘state change’ in a ledger.
• Block — When a certain number of transactions are brought together, they form a block. The number of transactions in a block varies from one blockchain to another.
• Block Header — A block header is used for identifying a block in a blockchain. It contains metadata and necessary information for it to be identified and function easily. One can think of it as a fingerprint as it is unique for each block.
• Tokens — Every blockchain has a cryptographic representation of a tradeable asset. Tokens are particularly useful to become a part of the consensus mechanisms in some of the blockchains.
• Node — Nodes are essentially network stakeholders and their devices which are authorised to keep track of the distributed ledger and serve as communication hubs for various tasks. If a node participates in the consensus mechanism, they are termed as validators, else they are just referred to as ‘Full nodes’. And a network is a collection of nodes that communicate with each other to share information.
• Gossip Network — A gossip network is a communication model where nodes share information through a process of exchanging information in a peer-to-peer fashion.

Characters in the block creation and validation process

• Validator — A subset of Full Nodes that participate in the consensus mechanism by voting.
• Block proposer — A validator node that proposes the block, decides which transactions shall become a part of the new block and also, builds the block. They also propagate the block on the network to their peers. After block creation, validators vote to decide the validity of the block.

We can see in Fig.1. that a block proposer is chosen from the set of validator nodes and each validator node is also a full node. Each validator node is a full node but vice versa is not true.

All thee characters mentioned above participate in the consensus process, as seen in Fig.2. The figure also displays how transactions and blocks achieve consensus.

As we have said before, every blockchain uses a different consensus mechanism. We will now delve into the methodologies some of the popular chains use to achieve consensus.

Ethereum

In 2022, Ethereum transitioned to the “Proof of Stake” consensus mechanism. In Proof of Stake, interested participants, who wish to become validators, must stake a specific amount of ETH (native token of Ethereum) to participate in the consensus. To become a validator, the participants need to deposit ETH, currently set at 32ETH, into a deposit contract. This amount acts as collateral and demonstrates the validator’s commitment to the network. This is a mandatory requirement to become a validator. Once the ETH has been deposited, the user joins the activation queue.

Every node in Ethereum has to run two clients — a consensus and an execution client. A client is a software that participates in the Ethereum network. The description, role and function of both the clients is explained in the Fig.3. below. Both clients run in parallel and relay information and instructions during the process.

In case, a node wants to act as a validator, a third software for the validator can be run on the consensus client which allows it to attest to blocks and propose them, if chosen as a proposer. The functions of both the clients will become clearer once we see the process flow.

Process Flow

To understand the process flow, assume there are two individuals — A and B. A and B both are validators.

A receives a notice saying that he is the next block proposer.

• A’s consensus client calls ‘create block’ in the execution client.
• The execution client accesses the transaction pool (where all the transactions sent by all the validators are collected).
• The execution client bundles all in a block, executes them and generates a block hash (a unique number that will identify the block).
• The consensus client takes the transactions and the block hash from the execution client and adds them to the block.
• The consensus client broadcasts the block over the block gossip network and the consensus client of other nodes, such as B, receives it.

After B receives it from the gossip protocol,

• the consensus client in the node pre-validates the block by ensuring that it arrives from a valid sender with the correct metadata.
• The transactions from the block are sent to the node’s execution client(running in the same node) which executes the transactions and validates the state of the block header.
• The execution client passes over this data back to the consensus client. The block is now considered to be valid.
• The consensus client adds the block to the head of its own blockchain and attests to it, and broadcasts the validation vote to the network.

If validators who hold 66% of the staked ETH attest or validate the block, it gets finalised and can never be removed in the future (Finality will be discussed thoroughly in our next article). To prevent any validator from acting maliciously, a process called ‘slashing’ has also been implemented. In case any validator gives his support or confidence to an invalid transaction or a malicious translation, his stake is slashed or confiscated. This is the process followed to reach a consensus in Ethereum. Ethereum follows a time-based system. Time is divided into slots (12sec) and epochs (32 slots). Blocks are produced in every slot which also means that 32 blocks are produced in every epoch.

Various other blockchains, such as Solana, Polkadot, Near and Cosmos have taken PoS and added their own twists to change certain processes. But at the very ground level, the rules of PoS remain the same i.e. requirement of staking a certain number of tokens to become validators.

SOLANA

Solana has implemented Proof of Stake along with a new mechanism known as ‘Proof of History’ or PoH. Both these mechanisms work in tandem to give us blocks whose time of origin can be seen. The PoS mechanism used by Solana requires participants to create a ‘vote account’ which must have a reserve of 0.02685864 SOL. Any participant who wishes to become a validator has to stake SOL. Validators are chosen to become leaders or block proposers based on their staking amount, the period of time for which they have staked etc. Solana’s blockchain is broken into slots and leaders are chosen ahead of each slot to avoid confusion.

The leader will be responsible for verifying the transactions and creating a new block. They receive all the transactions through the network and verify them for their validity. If found valid, the transactions shall be added to the block and if not, the transactions shall be discarded.

Before we begin understanding the PoH mechanism, we shall look at a few terminologies utilised in this process.

• The first one is a ‘hash’ function. A hash function is a function that takes any input given to it and converts it into a unique output of a fixed length or size.
• What is special about a hash is that it is collision-resistant, which is the second term, which means that no two inputs will give the same output. The smallest amount of change in the input will change the output hash completely, thus making a hash completely secure. Let us imagine I give the function an input ‘book’ and name the output as hash0. A small change such as capitalising the first letter to ‘Book’ will change the output hash. Moreover, one can never trace back the input from the output hash.
• Third is a blockhash which is a PoH hash for a particular slot (explained ahead) that can be thought of as a timestamp.

PoH is a method for proving that transactions are in the correct sequence and found by the right leader. It uses a hash function to create hashes as fast as possible such that each output is the next input. This creates a series of loops and a snapshot of every loop is taken to record how much time was taken to create it.

The tabel given below shows the input and output in PoH. The hash of the previous block is passed from the previous leader to the current leader. The current leader continues the hashing process and keeps on adding transaction IDs.

How do these hashes (called PoH hashes) help in the consensus mechanism?
The first thing we need to know is that Solana also follows a time-based method by defining ‘slots’ which is a period during which a leader executes transactions and produces a block. Collectively slots create a logical clock. Slots are ordered sequentially and are non-overlapping

Secondly, Solana adds the time concept (in the form of PoH) to ensure security and prevent attacks related to the manipulation of the creation of blocks. The block producers hash transaction IDs into the stream of hashes to record which transactions were recorded in their block. PoH can be trusted because each hash must be produced sequentially. Each produced block contains a block hash and a list of hash checkpoints called ‘ticks’ so that validators can verify the full chain of hashes in parallel and prove that some amount of time has passed.

This proves that the block leader has taken time to correctly validate the transactions and add them to the block. It is not necessary that every input hash will have a transaction combined with it.

Every block in Solana has a timestamp. A timestamp is a recording of when a particular event or transaction had taken place. It is a combination of the previous hash (output), the index or the number of times the hash function has run (which is equal to the transaction number) and the data or the transaction itself. A timestamp allows the validators to check when a transaction has happened or whether it has even occurred or not. If a hash50 has been generated, we know that all the transactions from T1 to T50 have already been completed (according to the table above) and only then were they used to generate the hash output hash50. A timestamp allows us to go back into the past and confirm when a transaction was made and whether it was made or not.

One can think of PoH as a conveyor belt which puts a timestamp on every event that place, as is seen in Fig.4. These events can then be referred to in the future with the help of the timestamps put on them.

Now comes the work of the validators. The validators are provided the entire list of the inputs (including the transactions) and the output hashes so they know what is supposed to be the output with every input they hash. Every validator can either verify all the hashes by himself or to reduce the amount of verification time can divide the list with fellow validators and then verify it. This division can be done for a few reasons.

• The list of hash checkpoints has been provided to them which allows them to know which transactions they are verifying.
• Every validator has its core and because the one input will only give the output given in the list, they know what they are looking at.

So if Validator1 runs the list from hash0 to hash10, and Validator2 verifies from hash11 to hash20, the collision-resistant property of hashes ensures that they know if there is any change in the sequence. Plus if there are n validator cores shall reduce the verification time to (1/n)th time.

For every block that a validator agrees with, he has to give a fee of 1.1SOL. If the validators give a super majority (2/3rd majority) that the leader has spent time ‘t’ to complete the process (time taken to get the output hash), the block is formed. This entire process uses the ‘Verifiable Delay Function’ where the leader has to prove that he has spent time ‘t’ to hash all the input hashes and transactions to give a final output hash. This will be proven if the validators also get the same output hash as an output when they run the process just like the leader did. Also, the validators do not vote for just the last output hash, they vote for every hash that is an output during the process. Essentially, the validators have to agree on the order of transactions to achieve consensus.

Imagine the validators see that two blocks have been produced at the same time. Both these blocks have a different output hash. This could get confusing because obviously, one of the blocks has been produced by a malicious participant. This is again where PoH helps. First thing to remember is hashes are unique and collision resistant, we know that any change in the input will change the output. Second thing to remember is that the previous leader has passed on the last output hash to the new leader. The validators can easily check which block is valid just by starting the verification from the last output hash of the previous leader, hashing it x number of times (x being the number of times the hashing was done while block building) and checking which block matches it to the output hash.

This article has been divided into two parts to enhance the reading experience and to ensure the information is more comprehensive. In the next part, we will discuss about the consensus mechanisms of Polkadot, Cosmos and Near protocol. Stay tuned!

References — 
1. https://ethereum.org/en/developers/docs/consensus-mechanisms/pos/
2. https://ethereum.org/en/developers/docs/networking-layer/#connecting-clients
3. https://docs.solana.com/running-validator/validator-reqs
4.https://blockworks.co/news/what-is-solana-everything-you-need-to-know-about-the-ethereum-rival
5. https://solana.com/solana-whitepaper.pdf
6. https://docs.solana.com/terminology#slot
7. https://docs.solana.com/developing/transaction_confirmation#proof-of-history-refresher

Decoding Consensus | Blockchain for Dummies - Part 1 was originally published in Aerius Labs on Medium, where people are continuing the conversation by highlighting and responding to this story.

We now present a very simple walkthrough of the entire process in an attempt to make the reader understand the KZG commitment scheme.

Let g₁ = (ℤ𝟟,+) and fix G₁ = 2 as the generator of this group, similarly let g₂ = (ℤ𝟟,+) and fix G₂ = 3 as the generator and finally let the polynomial that we wish to commit be p(x) = 3x+2. The pairing that we will use for this example will be e(x, y) = 2ˣʸ modulo 7

Moving on to the setup, let for some security parameter λ the randomly sampled τ = 5 and we shall pretend to forget it once the keys have been computed. Take m (we have taken it as 3 for the example) to be any number greater than the degree of polynomial (1 in this case) that we wish to commit. Thus τⁱG₁ = {3, 1, 5} for i = {1,2,3} respectively and τG₂ = 1 . The setup phase has now concluded with the prover key as {3, 1, 5} and the verifier key as 1.

We now calculate the commitment C = 3 × 3 + 1× 2 = 11 = 4 modulo 7

Say we want to prove that p(1) = 5 ie. y = 5 and z = 1. Then we compute the polynomial q(x) = ( p(x) — 5 )/( x — 1 ) = 3 × (x — 1 ) / ( x — 1 ) = 3 and thus π = 3G₁ = 6.

Finally we just need to verify whether the pairing check holds.

Left Hand Side

e(π, vk — zG₂) = e(6, 1–3) = e(6, 5) = ²³⁰ modulo 7 = 1

Right Hand Side

e(C — yG₁, G₂) = e( 4–3, 3) = e(1, 3) = ²³ modulo 7 = 1

Since LHS = RHS, our polynomial commitment has now been verified.

Closing Notes

From the above example one might think that the KZG scheme is very easy to fool however one must remember that the example made use of groups of very small order and a cryptographically insecure pairing. The actual protocol makes use of carefully chosen groups and prime fields that have a very high order such that the probability of a wrong commitment getting verified is infinitesimally close to zero.

References

https://dankradfeist.de/ethereum/2020/06/16/kate-polynomial-commitments.html

KZG polynomial commitment - HackMD

Demystifying KZG Commitments was originally published in Aerius Labs on Medium, where people are continuing the conversation by highlighting and responding to this story.