Table of contents
Zero Knowledge Proofs are driving the latest waves of blockchain innovation. In this article, I will be giving you a basic overview of what ZKPs are, what they do, how they are utilized in the real world, and how Polygon uses this technology to build and scale its products.
What are ZKPs?
Zero-knowledge proof is a cryptographic mechanism used to "prove the truth of a statement without revealing the statement itself." This procedure comprises two parties: the prover and the verifier. The prover is the party attempting to prove the validity of a statement, they transmit this along in the form of a ZKP to the verifier, who will determine whether or not the prover's statement is true.
Usecase
One popular application is in the setting of identity. Assume you're riding your motorbike and a police officer stops you along the route to check your licence. You must then show the police officer your license, which contains important information about yourself such as your blood group, parents' names and home address rather than just your date of birth, which most people would prefer not to give to a stranger.
This is where ZKP comes into play. For the above-mentioned ZKP example, we would just send along a ZKP that passes the verifier's requirements to declare yes or no what I want to know is either true or untrue, and no sensitive information is ever given away.
Types of ZK Proofs
ZK Proofs are broadly classified into 2 types:
Interactive ZK Proofs.
Non-Interactive ZK Proofs.
Interactive proofs are ZK Proofs in which multiple communications occur between the Prover and the Verifier, whereas Non-Interactive proofs are ZK Proofs in which only one round of communication occurs between the Prover and the Verifier to verify proof.
Interactive ZK Proofs
The initial iterations of Zero-Knowledge Proof were interactive, which means they required numerous rounds of discussion for the Verifier to reach a decision. The Prover responds to the Verifier which includes two crucial components: a challenge and an answer. Now, once the verifier checks the response, it may be dissatisfied with the answer it received, so it will send a new challenge to the prover and request another response, and this will continue until the verifier is completely happy. When the Verifer is completely satisfied with the response, he returns a ZKP to the Prover.
But the Interactive proofs also did have certain downsides like,
Unavailable for independent verification.
Not suitable for blockchains.
So, Non-Interactive Zero-Knowledge Proofs were made.
Non-Interactive ZK Proofs
ZK that is Non-Interactive Proof is a single round of communication in which the Prover generates a response for the Verifier and the Verifier determines whether or not the Prover has satisfied their requirements based on the response received.
Types of Non-Interactive ZK Proofs
The primary distinction between Interactive and Non-Interactive ZKP is the number of rounds of communication between the Prover and the Verifier. This brings us to the two most commonly used ZKP in the context of blockchain, which are ZK SNARKs and ZK STARKs.
ZK-SNARKs VS ZK-STARKs
| SNARKs | STARKs | |
| Size | Succinct, quickly verifiable. | Scalable: bigger, but more efficient with large data. |
| Security | Requires a trusted environment. | No trusted environment is required. |
| Post-Quantum | Not secure, although potentially upgradable. | Post-quantum secure. |
So that's all there is to Zero-Knowledge Proofs and how they're used in the ZK-EVM. Now, let's go deeper into the Polygon ZK-EVM and see how it uses these ZKPs to validate batches of transactions.
Polygon zk-EVM
Let's begin our exploration of Polygon ZK-EVM by looking at what's beneath the hood from Polygon, explaining how transaction,
submit to the Polygon ZK-EVM.
carried out instantly.
encrypted and then batched together.
sequenced and sent to Ethereum, Layer 1.
using the power of ZK proofs, achieve consolidated finality on Layer 1.
Polygon ZK-EVM is required today because Ethereum and all other blockchains suffer a problem known as the blockchain trilemma. In this case, blockchains must pick between three potential strengths: scalability, decentralization, and security. Ethereum has a strong sense of decentralization and security, but it is not scalable. For example, Ethereum provides decentralized storage, which is not managed by a single entity, as well as decentralized computing, which allows you to run your code on the Ethereum Virtual Machine, which is capable of running and executing your code in a decentralized and permissionless manner. But even now, it can only handle 15 to 60 transactions per second, making it unsuitable for the adoption of WEB3 technologies because it cannot handle high day-to-day user transactions.
So Polygon ZK-EVM was created to address the scalability issue that Ethereum encounters in the blockchain trilemma while retaining the strong sense of decentralization and security that Ethereum gives and by utilizing that as the base layer for all transactions to kind of live on.
Working Principle
In the picture above, we can see that several transactions pass through Layer 2 before being batched together and sent as a single transaction to Layer 1. We'll go deeper down the rabbit hole to discover what gets transmitted and how all of this happens under the hood by investigating the process of a transaction being sent to layer 2 all the way to layer 1.
This process happens logically in 5 steps,
Submitting Transactions.
Executing Transactions.
Batching Transactions.
Sequencing Batches.
Aggregating Batches.
Submitting Transactions.
The first step is to submit transactions. In this example, we'll utilize the Matamask wallet to send the Layer 2 transaction via JSON RPC to the trusted sequencer, Polygon ZK-EVM. Add the Polygon ZK-EVM testnet by clicking here and then go to the faucet and claim 0.02 ETH for testing transactions. Other than Ethereum, Polygon has two major advantages. The first is that it has lower gas fees, and the second is that it has instant transaction speed, as the state of the ZK-EVM is updated without any information being sent to Ethereum, Layer 1.
Executing Transactions.
Step 2 begins when you click the confirm button, and the transaction is routed via JSON RPC into a Pending Transaction Pool. The sequencer, a piece of software, then takes up these pending transactions and chooses whether to execute or discard them.
There are a few crucial factors that influence whether a transaction is executed or discarded.
If the sender has sufficient funds to complete the transaction.
If the called smart contract exists and has valid/correct bytecode.
If the transaction does not contain a duplicate.
If the transaction is not a "double-spend," to confirm that the sender's funds have not been spent in another transaction.
Once the transaction is considered to be valid, the sequencer updates the Polygon ZK-EVM state, at which point the user experiences the transaction going through almost instantly.
Bridging & Withdrawals.
However, the user must be aware of when they wish to withdraw funds from the ZK-EVM and return them to Ethereum. It effectively means that to pay for these transactions on layer 2, i.e., Polygon ZK-EVM, the user must bridge funds from Ethereum to Polygon ZK-EVM, which takes about 10 to 15 minutes on the Mainnet. Then you can experience all of the advantages of rapid transaction speeds and inexpensive gas prices.
However, if you wish to withdraw funds, say, to make a transaction on Ethereum, you must transfer your funds back to Ethereum. It simply means that transactions that occurred on Layer 2 must go through this behind-the-scenes procedure in which we transmit all of this information back to Ethereum and after receiving all of those transaction data, we use Zero-Knowledge Proof to validate it. At this moment, Ethereum has been confirmed to be right, and what happened in Layer 2 has been verified in Layer 1. Only then may the user transfer from Layer 2 to Layer 1.
Batching Transactions.
Moving on to the next phase, batching transactions, after entering the Layer 2 state, the transaction is broadcasted to all other zkEVM nodes on the network and is ready to be batched together with other transactions. To batch transactions together, they are concatenated into a single binary set of bytes. BatchData is a struct, Solidity data-type in the Polygon ZK-EVM smart contract issued on Layer 1. A transactions field of data-type bytes is defined within this struct, which includes the encoded batch of transactions concatenated together.
Concerning the remaining three fields:
globalExitRoot: The global exit (Merkle) tree's root, which contains information regarding asset transfers between L1 and L2.
timestamp: The batch's creation time.
minForcedTimestamp: Only applicable if the user is not using a trusted sequencer (useful for censorship resistance). Usually set to 0.
As you can see, the transactions are encoded using "RLP",that stands for Recursive-Length Prefix Serialization. It's a data serialization method that Ethereum uses to encode the structure of any arbitrarily nested arrays of data into binary.
Multiple batches are formed based on some size rules defined on the L1 smart contract, which we'll specify in the following section.
Sequencing Batches.
Once the batches of transactions have been received, they can be "sequenced". To accomplish this, the sequencer invokes the PolygonZkEVM smart contract's sequenceBatches function (on L1) and sends numerous batches of transactions to it.
On the Ethereum mainnet, this transaction is an example of a sequenceBatch transaction. We can view the 52 batches of transactions that were included in this function call by inspecting the input data.
Each batch also includes the previously mentioned transactions field (the concatenated bytes), which concatenates as many RLP encoded transactions recieved by the Polygon ZK-EVM smart contact containing a constant value that can fit:
MAXTRANSACTIONS_BYTE_LENGTHthat determines 1,20,000 transactions can be concatenated together in that field.MAXVERIFY_BATCHEScan accomodate 1000 batches that can be sent as one transaction.
The 3 States of Finality.
The multiple states that a transaction can be in the Polygon zkEVM are determined by the various stages of finality that transactions go through:
Trusted State: On L2, the state is updated. L1 has not yet been reached. This is what state consumers engage with the majority of the time.
Virtual State: The batches have been sequenced, and the data is now available on L1. Data is currently available on L1 for anyone to prove, but it has not yet been proven.
Consolidated State: A ZK proof is now available on L1. The data is now validated and inherits Ethereum's security.
Aggregating Batches.
When all of the sequenced batches have arrived at L1, the final step is to construct a ZK proof that validates the transactions. The sequenced batches are collected by aggregator nodes and delivered to the ZK prover, which generates a final SNARK using the fflonk protocol. As a result, the aggregator receives a ZK proof that is concise enough to be stored on the Ethereum L1.
Once the aggregator node obtains the proof, it invokes the PolygonZkEVM smart contract's verifyBatchesTrustedAggregator function, passing the proof it just received as well as other parameters to the function.
The batches of transactions are now in the final "consolidated" state, and this is how Polygon zkEVM inherits Ethereum's security, by submitting and proving all transaction data back to Ethereum L1.
Conclusion
In conclusion, Polygon's adoption of zero-knowledge proofs in their ZK-EVM blockchain offers users an unprecedented fusion of speed and security. With near-instant transactions on Polygon zkEVM, complemented by the robust security of Ethereum, this innovative approach provides the best of both worlds. The article has explained the entire transaction life cycle, emphasizing the efficiency and security inherent in ZK-EVM. The ability to bridge funds back to Ethereum within an hour, powered by zero-knowledge proofs, further highlights the practicality of this cutting-edge technology. Polygon's ZK-EVM represents a transformative solution, harmonizing speed and security to deliver a seamless and trustworthy blockchain experience for users.
References
Socials
If you enjoyed this article ❤️, recommend sharing this article with your peers and don't forget to check my social-media handles.