Zero-Knowledge proofs for Blockchain scalling (pt. 1)
Here is the process of executing transactions in a blockchain network (Bitcoin/Ethereum):
As seen in the last (4th) image, in the blockchain network, network nodes (or simply nodes) validate not particular transactions but blocks, which in turn include transactions. The average number of transactions per block differs for different blockchains. For example, a Bitcoin block typically contains around 3000 transactions, while an Ethereum block contains around 1500 transactions on average.
Considering that each block is validated approximately every 10 minutes, validation occurs sequentially, and each block contains 3000 transactions, simple calculations yield 5 TPS (transactions per second) for the Bitcoin network. For Ethereum, the calculation is a bit more complex due to gas costs, but empirically it has been established that the average TPS for Ethereum is around 30 TPS.
Given that blocks need to be validated sequentially (due to design features, specifically the fact that each new state is stored as the root of a Merkle Tree), it is obvious that if we want to increase the average TPS for a blockchain, we must either increase the block validation speed and/or increase the number of transactions in a single block.
However, we cannot increase the block validation speed without sacrificing decentralization or security. This issue is also known as the “Blockchain Trilemma” which states that in any given blockchain network, it is impossible to simultaneously achieve three characteristics: scalability, decentralization, and security.
Therefore, the most effective way to increase the transaction throughput (TPS) in a blockchain network is to increase the number of transactions in a single block.
Let’s examine the components of a typical block using the example of the Ethereum network:
Let’s focus on the bottom center block labeled “Transactions trie” while disregarding all other details. As we can see, the block includes all transactions and their data, which makes sense as it is something many of us have encountered when building web services. However, experts in the field of cryptography wondered if it is possible to reduce the amount of transaction data transmitted without altering the blockchain network itself. It is evident that if we reduce the number of bytes occupied by each transaction in a block, we can theoretically include a greater number of transactions and increase the network’s throughput.
For this purpose, the well-known cryptographic technology Zero-Knowledge (ZK) came in handy. Its idea is that one party (Alice) can prove to another party (Bob) that a certain statement is true without revealing specific details that confirm the statement. Let’s consider this technology with an example.
Suppose Alice has discovered a secret word that opens magical doors in a cave. The cave is ring-shaped with an entrance on one side and a magical door blocking the opposite side. Bob wants to know if Alice knows the secret word. However, Alice does not want to disclose her knowledge (the secret word) to Victor or anyone else.
Let’s say the left path from the entrance is A, and the right path from the entrance is B. Bob waits at the entrance of the cave while Alice enters.
Alice chooses path A or B, and Bob cannot see which path she takes. Then Bob enters the cave and shouts a randomly chosen path for Alice to return, either A or B.
If Alice indeed knows the secret word, returning is not a problem for her. She will open the door with the magical word and return via the specified path.
Let’s assume that Alice doesn’t know the secret word. In that case, she can only return through the same path that Bob names if she constantly randomly guesses the path he names later. If they repeat this trick, let’s say, 20 times in a row, Alice’s chance of successfully guessing the path will be approximately 1 in 2²⁰, or 9.56 × 10^-7, which is extremely small.
Therefore, if Alice appears at the exit Bob names every time, he can conclude that with a high probability Alice actually knows the secret word.
This example represents an interactive variant of interaction in Zero-Knowledge technology. However, in reality, cryptography experts have also invented a non-interactive variant of Alice and Bob’s interaction, which is of primary interest for solving our problem. This algorithm is quite nontrivial and is based on the properties of elliptic cryptography. Its main feature, regarding our problem, is that instead of including the transaction directly in the block, we will use a mathematical object called a proof, which will serve as confirmation of the transaction’s validity. Moreover, this proof will occupy fewer bytes than the original transaction, allowing us to include a greater number of transactions in a block.
This approach, utilizing Zero-Knowledge technology to include a larger number of transactions in a block, is called ZK-rollups, where “rollup” denotes the aggregation of a certain number of transactions into an object that then serves as proof of their validity.
ZK-rollups are not the only technology designed to increase the throughput of a blockchain network, but they are likely the most promising and exciting at the moment. Additionally, ZK-based solutions like zkSync are already being used by users on the mainnet and are capable of achieving up to 2000 TPS in the Ethereum network, which is significantly higher than the average value of 30 TPS in the Ethereum network itself.
So, in general terms, we have discussed ZK technology applied to blockchain network acceleration and discovered that its implementation promises a significant increase in throughput. However, many details are still unclear to us, such as what this solution might look like, what code needs to be written, and what needs to be done specifically to fit more transactions into one block.
To address this, in the next article, we will try to create a simple service that allows us to transfer money between wallets on the Ethereum network using Zero-Knowledge technology. Moreover, it will require minimal usage of the Solidity language and we will build our solution by using the Go programming language, utilizing a PostgreSQL database, and everything else familiar to any web developer.
