Ppio is a decentralized storage and distribution platform for developers to make data cheaper, faster and more private. Official website
Since the birth of blockchain public chain, although the threshold of trust has been greatly reduced, it has been faced with an efficiency problem: TPS is not high. For example, bitcoin only supports 7 transactions per second, while current Ethereum only supports about 15 transactions per second. Such TPS supports large-scale applications. Therefore, many technicians in the industry try to expand the capacity of blockchain. At present, there are two types of expansion plans:
- Layer 1 expansion scheme, which directly increases the transaction processing capacity on the chain, is also called on chain expansion. Common technical solutions are: sharding and DAG;
- The expansion scheme of layer 2 is to transfer a considerable part of the workload in the chain to the downstream. Common technologies include state channel, plasma, truebit and the recently popular ZK rollup.
ZK rollup is not a new concept, @ barrywhitehat was proposed a year ago, and is currently implemented by matter lab and den3.
- So, what’s the principle behind ZK rollup?
The essence of ZK rollup is to compress and store the user state on the chain in a Merkle tree, and transfer the change of user state to the chain. At the same time, the correctness of the change process of user state under the chain is guaranteed by ZK snark’s proof. The cost of dealing with the change of user’s state directly in the chain is relatively high, but the cost of using only the smart contract in the chain to verify whether a zero knowledge proof proof is correct is relatively low. In addition, the necessary transfer information will be submitted to the contract together with the certificate, so as to facilitate the user to check the account.
Two types of roles
There are two types of roles in zkrollup system: transactor and relay.
- Transactor, i.e. ordinary user, corresponds to the external account on Ethereum. The user builds the transfer transaction and signs it with the private key, and then sends the transaction to the relay.
- Relay is responsible for collecting and verifying the user’s transaction, then packaging the transaction in batches, and generating proof of zksnark, and finally submitting the core data of user transaction, proof of of zksnark and Merkle root of new global user status to the smart contract on the chain.
Of course, the relay will not provide services for the transactor free of charge. After all, the relay needs to consume gas to submit certificates and data to the chain. Therefore, the transaction sent by the transactor to the relay must also include the corresponding handling fee.
State transfer function
When releyer receives the transaction, it must “execute.”. The execution of transaction is essentially to change the status of related accounts, and STF is the function to change the status of accounts. STF is the abbreviation of state transition function.
State is for state machines, each state machine has a state at a certain time. We can assume that the initial state of a state machine is s . When an action t  acts on the state machine, the state of the state machine migrates. We can use the following formula to represent the migration process.
`S = STF(S, T)`
Here, s  is the initial state, and s  is the state after the state machine executes action t .
Then there are several new actions t , t ,…, t [n] continue to act on the state machine, and the state of the state machine will migrate in turn.
> `S = STF(S, T) > S = STF(S, T) > ... > S[n] = STF[S[n-1], T[n]]`
Simply speaking, we can also take t , t ,…, t [n] as a whole, then the state migration process can be simplified as
S[n] = STF(S, T, T, ..., T[n])
More generally, suppose the state of the current state machine is pre_state, then n actions t , t ,…, t [n] act on the state machine in turn, and then the state machine is post_state, which can be expressed as
`POST_STATE = STF(PRE_STATE, T, T, ..., T[n])`
If the above action is replaced by transfer transaction, and the account set in the system is regarded as a state machine, then the whole process is the process of transaction execution on the chain. The execution of the transaction changes the global state of the whole chain. The global state on the chain is the state set of each account. The state of all accounts is composed into a Merkle tree. The leaf node of the tree is the account state, and the root of the tree can be used to represent the state set directly. Therefore, the pre state and post State mentioned above are the roots of the global account status tree.
**Account status model
Just now we mentioned that the account status of the whole system in the chain can be managed by a Merkle tree. The leaf node of Merkle tree is the status information of users. Similarly, ZK rollup, an offline expansion scheme, can also use a similar Merkle tree to organize its account status.
The simplest account status can include: public key, nonce and balance of the account. The leaf node has a unique location in the Merkle tree, so the index information of the location can indirectly reference the account information.
If we use three bytes to represent the index information, this Merkle tree can support a total of 2 ^ 24 = 16777216 accounts. This is enough for a general system. Therefore, for example, the account address of Ethereum can be changed from 20 bytes of address to 3 bytes of leaf node index of Merkle tree. In this way, the account address is “compressed”.
In addition to compressing the account address, we can also compress the transfer amount data. For example, in Ethereum, the amount is represented by a large integer of 256 bits, but in actual use, it is rarely used for large amount and small amount. Therefore, if we assume that the minimum unit of transfer in the system is 0.001 Eth and the transfer amount is represented by 4 bytes, we can support the transfer of 0.001 ~ 4294967.295 eth, which is enough for the general system. If it’s not enough, you can add more bytes to represent the amount, or introduce floating-point representation.
The handling fee is similar to the transfer amount, and the actual handling fee will fluctuate within a certain range, so we can also set a minimum unit for the handling fee, for example: 0.001 eth. Then 1 byte is used to represent the service charge of 0.001 ~ 0.255 eth. The handling fee here is the handling fee paid by the transactor to the relay.
Similarly, we assume that the number of transfers of an account will not reach tens of thousands under normal use environment, so it is almost enough to use two bytes to represent the nonce of an account, because the two bytes can represent a range of 0-65535.
Finally, the signature field cannot be compressed. Taking Ethereum as an example, the signature (R, s, V) requires a total of 65 bytes. However, eddsa is often used in the actual ZK rollup system.
Therefore, the format of a transaction is roughly as follows:
The length of each field in the above transaction is only for reference. When implementing the specific system, it is necessary to adjust the length of the field according to the actual situation to prevent the overflow of the field, but in principle, it can be saved. Because the less transaction data, the more transactions can be accommodated under the same storage capacity.
Certification and verification
After understanding the state migration function and account state model, let’s see what relay has done after collecting transactions.
We just mentioned that in the system of ZK Rollup, the account information of all users is managed by a Merkle tree. The root of Merkle tree is recorded in the smart contract on the chain, and the value of this root also represents the current status of all accounts in the whole system. When a user initiates a transfer transaction, the status will change. But changes must be made in accordance with the rules.
- First, you must ensure the legitimacy of the transaction:
- Whether the transfer out account has enough money to pay the transfer amount and handling fee
- Whether the nonce of the transfer out account is correct
- Whether the signature of transfer transaction is correct
- Next, relay performs the transfer transaction, modifies the transfer out account and the transfer in account leaf node in the Merkle tree, and recalculates the root of the new Merkle tree.
- Repeat the second step, the relay will process multiple transactions at one time in order, and then submit the root of the final calculated Merkle tree as a new state to the contract on the chain.
However, there are problems in the above process: if only the root to contract of the state tree is submitted, how can users believe that the new state root is calculated according to the above logic truthfully. In case relay does something wrong, how about deliberately increasing the handling fee of transaction?
One way to solve this problem is to require the relay to submit the root of the state tree to the contract, and at the same time submit all transactions to the contract, so that anyone can verify whether the relay cheats when calculating the new state tree according to these transactions. But this is equivalent to moving all the data under the chain back to the chain, without realizing the purpose of layer 2 expansion.
Using zero knowledge proof can solve this problem well. ZK in ZK rollup is the abbreviation of zero knowledge. After the relay collects a series of transactions, it needs to generate a proof with a predefined ZK circuits:
Ensure that the equivalence of nonce, value and fee in each transaction t , t ,…, t [n] is correct and the signature is correct.
Make sure the state migration process is OK, i.e. STF (pre_state, t , t ,…, t [n]) = post_state
Then, the proof is submitted to the chain contract together with post_state, t , t ,…, t [n]. Where t , t ,…, t [n] is the simplified information of transaction, excluding nonce and signature. So t [i] is smaller than t [i].
Then the smart contract only needs to verify whether the proof is correct. If the proof is correct and the state saved in the contract is equal to the pre state, the new state post state will be recorded in the contract and the original state will be replaced.
Since relay must generate proof of zksnark before submitting to the contract, if relay wrongly modifies user’s transaction, proof will not be verified.
In addition, because the transaction t , t ,…, t [n] submitted to the chain does not contain nonce and signature, the data on the chain will become smaller (in the above example, only 11 bytes of each transaction will be on the chain).
At this time, the relay cannot modify the user’s transaction due to the limitation of the certificate. However, a malicious relay can still refuse to serve a certain transactor and does not collect the transaction of the transactor. In order to prevent this kind of behavior, the contract must support on chain with rawal, that is, any transactor can lift its own token from the chain.
At present, a typical ZK rollup application scenario is a decentralized exchange, which is represented by looping DEX protocol (V3). Interested partners can have in-depth study.
In addition, the open-source ZK rollup framework includes:
matter-labs/rollup – rust
ZK rollup is a new expansion scheme of layer 2. The core idea of this technology is:
Take the main chain as the storage medium, not the consensus engine;
Compress the transaction and reach a state consensus under the chain;
Zero knowledge proof is used to ensure the security of state consensus.
At present, the most typical application scenario of ZK rollup is the decentralized exchange.
Ppio is also actively exploring ZK rollup technology and trying to apply it to the field of decentralized bandwidth and storage transactions.
ZK Rollup: scaling with zero-knowledge proofs
Transcript: Scalable blockchains as data layers | Vitalik Buterin
The Dawn of Hybrid Layer 2 Protocols
Scalable blockchains as data layers
ZK Rollup: Ethereum Scalability with ZKPs
On-chain scaling to potentially ~500 tx/sec through mass tx validation
To learn more about ppio, please go to the official website: ppio – a private, stable and affordable decentralized storage. If you want to know more about the project, welcome to join our wechat discussion group, and reply “ppio discussion group” at the background to get the group QR code