A deep dive into ZK-sync
The ethereum ecosystem is the leading frontier in blockchain transactions and other related decentralised activities. Ever since its inception by Buterin Vitalik in 2014, it has served as home for many DAPPS and various inventions.
This growth, however, does not come without a defect, the population of participants on the ethereum network has skyrocketed over the years, making transactions to be much slower and most essentially gas fees became very inflated.
This had a threatening stance against the grounds on which ethereum stands as a major blockchain network. It is to this effect that ethereum, in conjunction with various research labs, invented the idea of layer2 scalability.
This paper will be an eye-opener to the opportunities presented by ZK-rollups and how it can be effectively utilised by crypto enthusiasts.
What is a roll-up?
A rollup is a blockchain scalability solution that transports data off-chain (outside the main network) to process and ensure authenticity through the generation of validity proof, while maintaining data integrity and security by ensuring that the data is also present at the mainchain for monitoring against malicious practices.
Transactions are moved back to the main network; they are bundled up in order to save gas fees, these transactions are also accompanied by the generated proof of validity, the proof of validity acknowledges the fact that the bundle(s) of the transaction has been checked and confirmed.
That it has been weighed on a scale and not found wanting.
Why do we need layer2 rollu-ps?
Imagine you are a business owner, you sell jewellery in Dubai and due to the luxurious lifestyle present in the country, your shop is always packed with customers every hour of the day.
To render a fast service and also to prevent the influx of competitors , you can open another shop, this shop will only be in charge of collecting money (either cash or transfer), a receipt will be issued (proof of validity) and then the customers will return to the main shop, show you the proof and they get their jewellery.
By doing this, we have applied what is called “Division of labour.” The above hypothetical case applies in the very same way to the ethereum network.
Because the ethereum network is flooded we distribute the work to another chain called “layer 2 or offline chain”.
Instead of keeping customers on the line, the work has been distributed, it saves time, energy and most importantly. It ensures decentralisation in the ethereum network.
There are two major types of layer2s : Optimistic rollups and ZK-rollups (Zero knowledge).
What is ZK-sync
ZK-rollups require that Participants initiating transactions provide proof of validity, when this is done, it is bundled up by the Operator and submitted to the ethereum mainnet. Proof of validity is the bulk of the issue and its provision signifies the 99% success chances of a transaction.
Zero Knowledge rollups are invented by a group of computer enthusiasts called “Matter lab.”
The main concept behind ZKsync and proof of validity is that participants should be able to prove the authenticity of their transactions without revealing some very important pieces of information.
Stages of Evolution of ZK-sync
First, there was the production of ZKsync lite, this can be described as the very first stage, ZKsync lite is a trustless protocol for scalable, low-cost payment on ethereum.
The main issue with this version of ZKsync is that it is not ethereum-compatible, due to this, it suffered a high level of limitation.
Despite this limitation, ZKsync lite was able to actualize $80million dollars in Total Value Locked (TV). But this can not be assumed to be as a result of transactions made on the protocol, rather some investors probably lock up funds to take advantage of future airdrops and incentives.
Then, there is the propagation of the current ZKsync rollup called “ZKsync era” just like its predecessor, it offers a very high level of scalability with minimal gas fee, its components, advantages and demerits are well dissected in this paper.
Components of ZK-sync
A typical ZK rollup is made up of:
Node implementation
This is responsible for receiving transactions from users, processes them and bundles them up after the proof of validity has been generated. It sends the bundles back to the main network for fins validation.
ZK circuits
They can be simply explained as complex mathematical constructs that represent verifiable computation logic.
They are responsible for verifying valid proofs, they ensure that validity proofs are generated as a result of executed transactions and not arbitrarily generated by malicious entities.
Prover
This is the generator of the validity proof, it uses complex cryptographic encryption strategies to show that a piece of data is authentic without exposing the contents of the data. This is very essential to the security of the ecosystem.
Smart contracts
Smart contracts are the core of any web3 project, they are the pillars on which every protocol is built.
Architecture of ZK rollups
Onchain transaction
ZK-rollup is controlled by smart contracts running on the ethereum mainnet. There is the main contract, which stores rollup blocks, track deposits and monitor state updates.
Another on-chain contract (the verification contract) verifies the proof of validity submitted with the blocks. Thus, ethereum serves as the control tower for ZK-rollups.
Off-chain transaction
Though ethereum serves as the light house for layer2 ships. The process of compiling, verification and state storage are done on another virtual machine before they are finally transported back on-chain.
Therefore, ZK-rollups help reduce traffic congestions by carrying some of the transactions and processing them off-chain before redirecting to the mainnet.
ZK-rollups depend on ethereum for security.
Data Availability
ZK-rollups publish data for every transaction processed off-chain. This is done to increase accountability, record-keeping and security.
The availability of data also ensures that Individual participants can also engage in the process of validating or discarding transactions.
Transaction finality
Ethereum acts as the main layer of layer2s, it is important to note that any transaction that has been finalised on the ethereum mainnet can never be reversed. All transactions receive their execution at layer1
Censorship resistance
Several ZK-rollups use what is called a “Supernode” (A centralised Operator) to execute transactions, produce batches and submit blocks to L1.
In a case whereby a participant is feeling unjustly delayed or he/she perceives that the Operator is being unjust, the participant can add their transactions directly into the rollup contract if they feel they are being treated unjustly.
How transactions work on using ZK-rollups
Transactions
This is how transactions work on L2s
A participant will sign and submit their transaction (mostly) to a centralised entity called “a Sequencer” This entity will compile and bundle up the transaction, dump it in the layer2 protocol and be ready for processing.
To ensure efficiency and absence of negligence, ZK-rollups make use of an initiative similar to the proof-of-stake system, the Operator will stake some funds which will be slashed in the case of negligence or maliciousness. This ensures a high level of accountability.
State commitments
The ZK-rollup state which includes the L2 accounts and balances is represented as a merkle tree. A cryptographic hash of the merkle tree’s root is stored in the on-chain contract, after every transaction the Operator has to submit the validity proof and also update the merkle tree, compute a new state root and then submit to the on-chain contract.
In compliance with the data availability of ZK-rollups, an Operator must always ensure to submit the “Branch root” which comprises all the transactions in a batch.
Validity proofs
The validity proof submitted by an Operator must be as a result of updates to the rollup states. Proposed states will only be accepted when the proof of validity is shown.
Validity proof is very essential to the security and integrity of L2s. They help to confirm the authenticity of a statement without revealing the contents of the statement itself.
Types of validity proof
ZK-SNARK
ZK-SNARK - Zero-Knowledge Succinct Non-interactive Argument of Knowledge. For this proof of validity system to work, there must be the creation of a “CRS - Common Reference String” This serves as the security house of the validity proof.
This CRS will be in charge of producing public parameters for the verification of validity proofs.
These public parameters must not fall into malicious hands as it would aid in the production of a validity proof where no transaction has actually been executed.
To solve this problem, some ZK rollups attempt to stop this threat to security by using a “Multi-party computation ceremony (MPC)”.
Where trusted individuals are gathered and used by the rollup to generate public parameters for ZK circuits, these parameters called “Toxic waste” are immediately deleted when the verification of validity proof has been completed.
ZK-STARK
ZK-STARK - Zero-Knowledge Scalable Transparent Argument of Knowledge. This is a pure improved version of ZK-SNARK. It doesn’t depend on CRS, it is faster, more secure against quantum computers unlike the Elliptic Curve Cryptography (ECC) used in ZK-SNARK.
Key takeaway
Layer2s help ethereum with scalability
With ZK-sync, you don’t have to rely on Validators, al you need is maths (proof of validity)
ZK-sync helps make transactions faster and gas fees a lot cheaper
Proof of validity is the core of ZKsync
Subscribe to my newsletter
Read articles from Fawole Joshua directly inside your inbox. Subscribe to the newsletter, and don't miss out.
Written by
Fawole Joshua
Fawole Joshua
I am a Web3 technical writer who loves to educate developers and crypto users. I work with Web3 protocols to update their technical content marketing game!