Few Thoughts about Keeping L2 Data Off-Chain: A Trade-Off between L2 Efficiency and Data Availability

Few Thoughts about Keeping L2 Data Off-Chain: A Trade-Off between L2 Efficiency and Data Availability

We are thankful to Matter Labs’ open question on partial L1 data were made available on-chain. We always value community’s voice and willing to make amendments to meet community demand. And we appreciate the chance for us to share our sincere thoughts behind the diligent work delivered by the ZKSwap developing team.

It was a careful and throughout decision ZKSwap has made to keep L2 transactions offchain — for efficiency reasons in respect to TPS and gas fee. With ZKSwap’s design, L1-related data is on-chain, while L2-related data like transactions and swap, is not. L2 related data, however, will be published with real-time by validators.

For instance: L2 block 7831 https://api.zkswap.info/block/7831/pub-data

Having parts of the data onchain was a difficult trade-off we made between L2 efficiency and data availability, so we can ultimately deliver our promise of high TPS and low gas fee.

Three Transaction Types:

A block can conclude three types of transactions with ZKRollup protocol approach:

Type 1 — Deposits from L1 and transactions for pair creation under AMM feature;

Type 2 — Transactions initiated at L2 that can only be verified by L1. Eg. Pub key transactions will need L1 signature to ensure key owner of L1 account can associate the account to their L2 account as our circuit can NOT check and verify L1 signatures.

Type 3 — L2 signed and verified transactions that cannot be verified at L1.

ZKSwap Security Model

L2 transactions recorded in the one block are ‘restricted’ in L1. Only a summary of block information is chained in L1：

· Block Hash (Commitment)

· New Merkle Root

· Block Height

· Etc

When a block of transactions is committed to L1, a block is created and the block hash is verified. Due to the fact sha256 calculation is built-in on Ethereum; the block hash is usually calculated using sha256 algorithm.

To keep data available, all transaction data should be committed to L1, which is called “Pub data”. The pub data of one transaction is NOT exactly the same as transaction in L2. The signature and nonce information in L2 are NOT necessarily pubed. The system will be in exodus mode using pub data so that anyone can restore the latest verified merkle state.

The Circuits

The circuits in L2 and smart contract in L1 can work together and ensure ZK-rollup protocol’s functionality. The circuit in L2 ensures:

· Correct signature for L2 transactions

· Correct execution on L1/L2 transactions

· Correct block info calculation (for both Block Pub Data and its commitment)

· Timely and effective update on account information — Merkle Root, Account Merkle Tree and fee information.

· Etc.

Two “Verfication” Modules

Verification modules are critical for security and those are the foundations for ZK-Rollup protocol.

Pub Data Verification — verifies Type1 and Type2 transactions on its transactional content and sequence. For example, verification on deposit needs to ensure the deposit amount and information is identical to the one recorded in L1 and that the sequence is in correct order

Block Verification — verifies transactions are correctly operated in one block and the Merkle Root of Account Merke Tree in L2 is updated timely and properly through zk proof. Once one block is verified, the updated merkle root is finalized

To summarize, the whole security assumption follows:

The pub(raw) data of all transactions in one block is on-chain

Verifies Type1/Type2 transactions in one block are correctly operate

· ZK Proving system of L2

- Proof all transactions in one block are properly executed; account Merkle Tree is updated correctly; and the pub data of all transaction in one block is matched

- Proof of all pub commitment data of the block are calculated correctly

- The block pub data committed to L1 is identical to the ones proved by ZK proving system

What Happens when Pub Data is NOT on-chain?

If the pub data is NOT on chain, the security assumption for “The pub data of one block committed to L1 is identical to the one proved by ZK proving system” can NOT be validated. In the scenario when ZK proving system in L2 proves all transactions, which have been executed and merkle tree were updated correctly, it only proves that transactions in “one” block are valid, but not for other transactions from “specified” blocks.

Most Type3 transactions are safe. But for withdraw cases, the withdraw receiptor is NOT verified and can NOT be proved by ZK proving system.

For Type1 transactions, all possible Type1 transactions can be proved, but not verified. For example, ZK proving system can prove some deposit transactions, which are NOT issued from L1.

Due to the fact that only validator can submit pub data or block proof, the community has to trust the honesty of validator. When validator is honest, all above risks are not of concern. For ZKSwap, all pub data are published in explorer simultaneously. Anyone can check the pub data and onchain commitment for any block.

Again, it was not an easy decision for ZKSwap team make, keeping pub data offchain. The main reason is about our commitment of low GAS fee and scalability.

GAS! GAS! GAS!

Gas is sore point to keep a ZK-rollup protocol running. To submit one block to L1, the following gas limit are consumed (referring to the typical cases — only L2 transactions (Swap) are demonstrated in one block):

For one block, the maximum 120 swap transactions can be included.

To commit and verify one block in L1, around 230,000 gas limits is consumed and the call data fee is around 31%.

Scalability(TPS)

Scalability, aka TPS, is another concern. Assuming one L2 transaction consumes 1,850.7 gas and 10% Ethereum block gas would be taken by ZKSwap, with an outcome of overall 51.5 TPS.

We have to keep in mind that only one block could cost 1,850.7 gas per transaction for swaps without considering withdraws. In that case, more gas will be consumed with a much lower TPS.

Conclusion

Keeping users fund safe is very important for all Blockchain projects and has been THE CORE value of ZKSwap. When pub data of transaction is NOT submitted on chain, the security relies on zk circuits. When validator is honest, the users’ assets are secured. And technically speaking, if validator is NOT honest, security could be an issue and there is the tradeoff for lower gas and higher tps.

Considering the gas consumption and scalability, ZKSwap made the difficult decision of keeping pub data offchain and honoring our commitment to bring a decent TPS and affordable gas consumption for every single L2 user.

However, we are open to developer’s and user’s feedback to make ZKSwap system better . Also we can put all data on chain any time. In fact, Before we release ZKSwap we already implemented a 100% data availability version (all layer1 and layer2 transactions was on chain, so we can upgrade to this 100% zk-rollup version any time and it will cost higher Gas and bring lower tps but for sure, better security!

(All ZKSwap code will open source soon, the whole smart contract code will open source on 1st of March and the ZK-Circuit code will open source after the Auditing Report out.)