OPINION: Devs don’t know enough about zero knowledge security — and it’s a ticking time bomb

Brian Pak is CEO & co-founder of ChainLight, a blockchain security firm that specialises in smart contract audits and on-chain monitoring.

The words zero knowledge, once relegated to academic papers and cryptography forums, have roared into the mainstream.

ZK technology lets a party, such as a blockchain protocol, prove to another party that something is true, like a person’s age, while keeping that information completely confidential.

ZK cryptography is finding success in scaling top smart contract network Ethereum. More than a dozen ZK-based networks, commonly called ZK rollups, run on top of Ethereum, with a combined $4 billion worth of deposits.

But despite the hype, there’s a big problem. The lack of knowledge about ZK is a ticking time bomb.

Most crypto developers still know very little about this complex topic.

And as more developers start to experiment with ZK technology, it’s creating major security risks, and even preventing the technology from meeting its true potential.

At the same time, ZK technology promises to revolutionise the crypto industry, so getting developers and the broader community of users up to speed is imperative.

ZK devs are ‘out of their depth’

In 2022, Ethereum co-founder Vitalik Buterin pointed out security risks of ZK rollups, such as bugs in the circuit constraint code.

These codes are critical in ZK rollups as they define and enforce rules for the cryptographic proofs ensuring transaction validity.

Bugs in these codes can lead to severe security vulnerabilities, such as incorrect proofs or unauthorised fund access.

Since Buterin’s warning, developers have identified several more vulnerabilities in projects using ZK technology.

In November, ChainLight discovered a bug within ZK Sync Era’s ZK-circuits which could have allowed a hacker to steal $1.9 billion.

Also in 2018, a Zcash cryptographer discovered a vulnerability in the zero-knowledge proofs underlying the protocol. If left unpatched, the bug could have allowed an attacker to create fake Zcash tokens without being detected.

Vulnerabilities like this are a sad indictment on a new form of technology that is clearly not understood by enough people.

Many developers writing the code and security professionals who have to sign off on the security of it are simply out of their depth.

And it’s not surprising — anyone will tell you that a PhD level of understanding in mathematics is required to grok the security aspects of ZK technology.

This means the number of people qualified to audit ZK code is limited, as are the resources necessary to train them.

And a lack of experts to properly audit ZK code is not the only issue.

ZK rollups, such as zkSync Era and StarkNet, are developed in-house and, as a result, peer review processes are not nearly as thorough as the standards seen in academia.

I’ll be staying sceptical of ZK technology security until the peer review process is more standardised.

ZK isn’t achieving its potential

The lack of understanding of ZK technology is also hindering it from meeting its full potential.

This is due to a lack of confidence in the technology leading builders to choose more familiar frameworks.

For example, one of the major benefits touted of ZK rollups is instant finality.

This means that as soon as the proof of a block is verified on the Ethereum mainnet, the results are final. This notably allows instant asset withdrawals and also improves security.

Optimistic rollups, the main rival to ZK rollups, require a seven-day waiting period to withdraw assets.

There’s a growing consensus that ZK rollups are the superior solution to scale Ethereum over and above Optimistic rollups.

Some go as far as describing them as the “holy grail” of scaling solutions.

Immutable X’s co-founder Robbie Ferguson described ZK rollups as “by far the easiest way to scale high-throughput transactions.”

But, in reality, most developers are still not using the technology for its true potential because they’re simply not comfortable with using some of its unique features due to the complexity.

For example, none of the existing ZK rollups actually have the advertised instant finality.

The coding is so technical that developers might be scared of making a mistake, leading them to instead choose not to implement instant finality.

Instead, protocols have a so-called execution delay, where there is a roughly one-day window to detect an exploit and revert the changes before they are finalised.

With this, the security of ZK rollups comes with a major compromise, and forgoes one of its most significant benefits.

Only improving the understanding of ZK technology will allow builders to maximise its potential without compromising on security.

Security by design

Across the whole of web3 — not just in the ZK sphere — projects don’t take audits seriously enough.

Many projects view audits merely as stamps of approval to make themselves look reputable, rather than the rigorous exercises in security they should be.

There are several cases where known bugs have crept into new DeFi protocols, costing investors millions.

For example, several protocols that forked lending protocol Compound v2′s code, such as Hundred Finance and Onyx Protocol, did so blindly, and failed to account for known attack vectors in the code.

Instead, developers should strive to build protocols that are secure by design, meaning that they’re built in a way that first and foremost protects against attacks.

Building by design starts with staying up to date with threats in the ecosystem.

If a project lacks the resources for thorough auditing, it still needs to keep up with the hacks that happen to other projects so that they don’t fall victim themselves.

While failing to build protocols that are secure by design would be a problem for any project, it is particularly detrimental in the case of ZK technology.

For example, let’s take a look at existing ZKEVMs — ZK rollups that perfectly replicate Ethereum’s operating system.

Many ZKEVMs rely on manually defined circuits, which require human involvement and use young, untested libraries.

The likelihood that developers will make errors in this environment is high, leaving ZK rollups more vulnerable to the risk of attacks.

With investors piling into ZK rollups, incentivised by potential token airdrops, they become lucrative targets for the next major crypto heist.

Solutions

Implementing security at the very beginning of the development cycle and on an ongoing basis — such as through bug bounties — can help fix this.

There is no question that ZK technology is a game changer for Ethereum, and constant development is fundamental to scaling the blockchain.

However, the solutions offered by ZK rollups are matched by their potential to cause problems with security.

Startups must first be honest about whether they are using ZK technology because it is necessary or because they are jumping on the bandwagon.

If they’re certain that they are the former, then they must be aware of the risks and building with security by design is absolutely fundamental.