Over the first weeks of May 2019 we, Matter Labs, have performed a series of infrastructure tests to evaluate the performance of consistency of our alpha version of ZK rollup (original , thanks to for great questions). Parts of the infrastructure that were tested included:
- Ethereum events monitoring from the smart-contract to work with deposits from end-users.
- Bookkeeping server — one that actually holds the balances and performs transaction processing.
- Provers cluster — a swarm of prover instances that asynchronously generate proofs based on blocks that were created by bookkeeper.
- Committer — simple service that is responsible to send commitments to new blocks (with public data) and proofs to Ethereum network for verification by the smart-contract.
As a result of the test we concluded that “Committer” should be significantly improved as it caused delays for transaction inclusion when test was attached to Mainnet.
Simple block explorers are available for and as a historical record of all the transactions done during the test. Block size was set to 256 transactions, with some share of which was “padding” transactions that do not transfer any value, but inserted in a block if a certain time has elapsed since a previous one. Difficulty of proof generation does not depend if some transaction are only for padding or not due to the nature of zkSNARKs.
Based on the questions from the Twitter we’d like to replicate answers to those in this blog post too.
Why there are two different transactions (“Commit” and “Verify”) for each produced block?
– The system we are building should support multiple “validators” (block producers), so “Commit” transaction indicated the public data that can be used by other “validators” to update their state and be ready to come forward and process the transactions while the actual proof is being produced.
Why to commit public data on-chain?
– For an account based model (that we use for our system) there is no construction that would allow efficient resolution of the worst case scenario when network is either no longer functional (all “validators” are offline) or act maliciously by not publishing the content of the block and not processing “exit” transactions. In the latter case the global state of the system is still correct because it’s proved by zkSNARKs, but it’s not publicly known, so end-users can not prove what is their current balance and perform an “exit” by on-chain interaction with a smart contract. This is a classical “data availability” problem and it arises in most of L2 solutions.
– Enforcing “data on-chain” solves the data availability problem in this case. This also leads to an economical benefit: in case of “data off-chain” security of the network is guaranteed by the valuation of the network or security deposits from operators, along with a game-theoretical “exit” procedure that would allow users to 1) withdraw their funds 2) slash deposits from operators or value of the network. Usually such procedure also enforces a large delay for “exit” to be finalized. On the other hand, “data on-chain” ties security of the network to security of the corresponding L1 network — in this case performing an attack is as hard as breaking the consensus or censoring transactions to one of the contracts.
Proof generation time is expected to be around 5 minutes. This looks like a substantial trade-off on user experience.
– First of all, this 5 minutes delay is (almost) complete finality for our system because as soon as some block is proved to the smart-contract in network it can no longer be rolled back. We would allow blocks that are committed but not yet proved to be reorganizable (in cause if some “validator” goes offline in a middle of a process of proof generation), but proven blocks are as final as a state of itself.
– Such proof generation time is tied to the current state of the at the moment — verification of zkSNARK proof is quite expensive, so blocks should be made quite large. We expect the to be introduced in the next fork. That would, along with an efficient batch verification, allow us to have much smaller blocks with faster proof generation.
– Regardless of the outcome with EIP1108 we are working to introduce “instant confirmations” for “transfer” transactions. Such confirmation is a commitment from “validator” to include a transaction in specific block. For a transaction with a small amount user can treat such confirmation as sufficient and if this transaction is not included in a block then “validator’s” security deposit may be slashed.
Published at Tue, 21 May 2019 11:06:08 +0000