Will ZK Sync Solve Ethereum’s Scalability Problem?

On December 5th, Matter Labs announced the initial release of their ZK Sync framework for Ethereum. Reaction from the Ethereum community has been broadly positive, with a number of endorsements from influential figures on Crypto Twitter. Today we’ll be taking a look at the principles behind ZK Sync and assessing whether it can deliver on its promise of commercial-grade Ethereum scaling.

What is ZK Sync? How does it work?

ZK Sync is a scaling and privacy solution for Ethereum which is built on ZK Rollup. ZK Sync claims to offer ‘VISA scale’ throughput (>2000 transactions per second), private transactions and instant finality. So how does it work?

Like ZK Rollup, ZK Sync aims to speed up transactions on Ethereum by moving the majority of computation off-chain. ‘Validators’ bundle transactions together, before they are submitted to the Ethereum mainnet. This submission to the mainnet contains enough information to validate whether a given transaction is included in the bundle, which is better known as a state transition zero-knowledge proof (SNARK).

SNARKs can be computationally expensive, so moving the calculations off-chain helps to speed things up and lower costs. Validators receive a share of the transaction fees in exchange for generating the SNARKs, with a second group known as ‘Guardians’ monitoring the Validators. More on these two groups in a moment.

Latency Issues

ZK Sync is built on the Optimistic Rollup flavour of Plasma. We would go as far as to suggest it is just another Plasma; it is still not commercially viable. The Plasma ecosystem has become increasingly fractured over time, spawning over a dozen variants which claim to solve different problems. This scatter gun approach has often created new issues, leading to further fragmentation of the Plasma scene. A summary of this confusing ecosystem is included below:

Alongside a number of other important issues, Plasma has a major problem with latency, which we have been highlighting since early 2018. As a side-chain which relies on periodic commitments to the main-chain, the latency of Plasma’s side-chains will always be worse than their underlying base-layer. We therefore do not think that any form of Plasma or side-chain will ever achieve commercial success. For ZK Sync, the announcement stated:

‘We expect current developments in ZK prover technology to reach proving times that will enable ZK Rollup blocks to be produced in under a minute.’

One new Ethereum block is added approximately every fifteen seconds. If we assume a best-case scenario, where the ZK Rollup block is produced in less than one minute and it is mined in the next possible Ethereum block, then transaction latency will still be problematically high.

Currently, ZK Rollup blocks are produced in approximately 20 minutes which is obviously not remotely commercially-viable.

High latency is a problem for any application requiring multiple transactions in a short amount of time, such as trading. Even simple use cases, like purchasing goods in a shop, become problematic when latency is high.

Validator Bonds

ZK Sync also claims to offer immediate transaction finality, backed by Validator security bonds, as an attempt to solve the latency issue highlighted earlier. There are three steps to the process: First, Validators reach consensus about which transactions will be included in the next Rollup block. Second, this information is communicated publicly. Third, the Rollup block is committed to the Ethereum main-chain. Transaction finality is achieved at the second step, provided that the block is actually committed as promised in step three.

To ensure that step three always follows step two, Validators must post a large security bond which is at risk of being slashed if the promised transactions are not included in the committed Rollup block:

‘However, if it doesn’t contain the promised transaction, the security bond of the intersection of the signers of the original receipt and the signers of the new blocks will be slashed. This intersection is guaranteed to have more than ⅓ of the stake. This guarantees that at least ⅓ of the security bond is slashable, and that only malicious users will be punished.’

This is a novel approach to layer-2 scaling which attempts to circumvent the high latency inherent in side-chains by enforcing an economic finality. Accordingly, ZK Sync claims to move both computation and confirmation off-chain.

There are four potential issues with this system. First, as acknowledged by ZK Sync, transaction finality is actually only reached when the Rollup commitment has been safely recorded on the Ethereum main-chain. Anything before this has a lower level of guarantee. Second, the security bond system can introduce significant costs in terms of the funds locked up by validators and the associated capital inefficiency. This may limit the maximum transaction size, which is a third issue. Fourth, depending on the method used, there are significant latency issues relating to reaching consensus between the 30–100 Validators (this may explain why ZK Sync has chosen to restrict the Validator pool size in this way).

Furthermore, the wider commitment-based architecture inherits the tremendous cost that all side-chain variants exhibit to post those commitments on-chain. Any side-chain construction which relies on periodic commitments to a main-chain is also necessarily limited by the performance of the main-chain. The ZK Sync announcement admits that transactions are:

‘2. Potentially reversible, but only within a few minutes’

Bearing in mind that ZK Prover technology has not yet advanced to the point where SNARKs can be produced in under one minute (although we do not doubt that this is possible), the ZK Sync approach is — at best — a cost-inefficient, high-latency and delayed finality solution.

Enter nahmii

ZK Sync’s reliance on a side-chain construction is a clear problem, which introduces a range of performance and finality issues. Thankfully, there is a better approach. Our scaling and interoperability protocol for Ethereum, nahmii, addresses all of the key requirements for a commercial-grade solution: throughput, latency, finality and cost. Like ZK Sync, we handle transaction processing away from the slower Ethereum mainnet. Unlike ZK Sync, we do not require regular commitments to the main-chain to achieve true finality.

Like ZK Sync, nahmii deposits are held on-chain in a smart contract. Our protocol is fully non-custodial and it uses the Ethereum blockchain for security oversight, with users able to challenge any fraudulent attempted withdrawals from the system. Importantly, nahmii provides immediate finality and web-scale latency for transactions. When a payment is made using nahmii, the transaction is signed by both parties and the Operator of the system. Once the Operator publishes the transaction receipt, it is considered final. This is a substantial improvement over ZK Sync’s eventual (theoretical) processing time of one minute.

The nahmii protocol also offers fixed, low transaction fees without the need for consensus-generating ‘Validators’ posting punitive security bonds. Similarly, nahmii’s developer tools (SDK, CLI) do not require developers to learn yet another programming language — unlike ZK Sync’s ‘Zinc’ framework.

It remains to be seen if generalised computation can be achieved effectively within any side-chain or Plasma architecture, including ZK Sync. This ability was a key consideration during nahmii’s design and essentially exists today, albeit in our development environment where we have been testing these features for over 12 months already. Not only does this capability exist, it would be trivial for developers to implement different forms of transactions.

Deployment Challenges

Most importantly, nahmii is live and ready to build on today. The first nahmii contracts were deployed to mainnet over 11 months ago, with deposits, payments and withdrawals live since April 2019.

Having gone through the process of building and deploying nahmii, we can attest to the difficulty of creating a layer-2 protocol from scratch. In addition to the concerns set out here regarding ZK Sync, we would expect their system to encounter a range of challenging problems as it matures. We have already identified a number of major security and economic vulnerabilities with their architecture, not all of which have been set out here. It remains to be seen whether these will be discovered before funds are needlessly lost.

As highlighted in this article, no side-chain construction can beat nahmii on performance, latency or finality. To date, the hubii team have been content with building the best scaling solution on the market; however, it is clear that the blockchain industry has been slow to acknowledge this. Today’s article marks the start of a more aggressive approach to our competitors.

We have built the only commercially-viable blockchain scaling solution and it’s time for the industry to start paying our technology the attention it deserves. All other solutions theorised, in testing or in production so far should be considered naive at best; successful products cannot be implemented upon them. At best, it is possible that the architects of these systems just have insufficient experience in building products. At worst, the wider blockchain community is being knowingly misled by experts who are promising great things which they know can never be delivered and will never be utilised in the way that they suggest.

The only exceptions we have observed are some Lightning-type constructions, which can have specialised, but limited, use cases.

You can find out more about nahmii at our website, alternatively we invite you follow our Twitter account and join our active Telegram community. Developers can view our public GitHub repos here, including the SDK and CLI on npm.

Special thanks to our COO, Mark Briscombe, who contributed to this article.