Reactions: The Bitcoin Zero-Knowledge Arms Race Begins

Starkware plans to scale Bitcoin with zero-knowledge technology

Reactions: The Bitcoin Zero-Knowledge Arms Race Begins

In case you missed it, Starkware, a company historically active in the Ethereum ecosystem, announced yesterday plans to start committing significant resources towards new Bitcoin scaling opportunities that have emerged over the past months.

Pioneers of zero-knowledge systems, the group has revealed plans to leverage OP_CAT in order to bring their STARK technology to Bitcoin. The soft fork proposal could allow zero-knowledge proofs to be verified natively, opening up an entirely new design space for developers.

The announcement is looked at by many as a significant technical milestone for the Bitcoin protocol. Here are my unsolicited 2 cents on the matter.

A long time coming

As Starkware CEO Eli Ben-Sasson points out in his announcement post, the idea of using zero knowledge to improve Bitcoin is nothing new. Developers have been discussing applications of the technology for over a decade already. Ben-Sasson himself presented very early concepts of the idea at a Bitcoin conference in 2013 in San Jose. In 2017, Blockstream developers Gregory Maxwell, Pieter Wuille & Andrew Poelstra co-published a research paper on the use of Bulletproof, a zero-knowledge protocol to support confidential transactions on Bitcoin.

In more recent years, BitVM creator Robin Linus instigated work on ZeroSync, a compression technique used to create zero-knowledge proofs of Bitcoin’s blockchain. Once fully implemented, it would significantly reduce the resource requirements involved in running a Bitcoin node. In 2022, the Human Rights Foundation commissioned current Alpen Labs researcher John Light to produce a full report on the potential of validity rollups on Bitcoin, using zero-knowledge proofs.

Zero-knowledge proofs have a wide range of applications and we are not nearly at the end of hearing about them. Many expect the technology will define this next era of computation and I would be hard-pressed to bet against them. It’s almost guaranteed that higher-level Bitcoin applications will start leveraging them soon and we can only expect this trend to grow from here.

It's still early

Most technological gains around zero-knowledge cryptography have been made in the last ten years. The field is rapidly evolving as more cryptographers become interested in applications of the technology. Researchers have been in something of an arms race figuring out who could shave the most time and resources required to produce and verify those proofs. As of now, most of the proof systems remain computationally expensive. Different protocols make different tradeoffs, but improvements have been focused on verification so that the average user can quickly and efficiently verify proofs. While the pace of innovation has been relentless, generating those proofs at scale is likely to require specialized hardware and large operations.

Despite massive unlocks and significant achievements in the field, it’s worth noting that a decade is not exceptionally long in cryptographic circles. Many of the most recent proposals leverage techniques that are considered technically sound but not as battle-hardened and tested as Bitcoin’s. In 2018, a hidden inflation bug was discovered in the ZK-SNARK implementation of Zcash which could have allowed an attacker to counterfeit the currency. In fairness, the STARK construction proposed by Starkware is considered significantly more secure because of its more transparent nature.

It's hard to get excited about rollups

One of the motivations for this project is to enable zk-rollups on Bitcoin. For those not familiar, rollups are highly touted products that use off-chain sequencing to scale applications and throughput. Zk-rollups, or validity rollups, propose to create proofs of the system’s record of transactions which can then be independently verified by users, allowing off-chain systems that do not require additional trust assumptions.

Today, none of the major rollup implementations on Ethereum have fully implemented this system. Each one relies on a central operator responsible for both proving and ordering transactions. In the odd cases where proofs are actually generated, only permissionned actors can submit them to prevent fraud. Starkware’s Starknet currently offers no mechanism for users to force their transactions out of the system if the operator stops collaborating or their infrastructure goes down. Their application-specific rollup, Starkex, does currently offer the equivalent of unilateral exit. 

Pretty much every project has billions of dollars under deposit which are effectively secured by a set of multi-signature keys. The same group of people responsible for handling those keys can also upgrade the rollup contract and control the associated funds. As early as a couple of days ago, the sixth largest rollup on Ethereum, Linea, was unilaterally halted by the operator, and all user funds were frozen following a hack. 

There is an alternative, more optimistic case, here which I’m probably not well suited to write but a lot of work and resources are going into solving the issues outlined above. An important amount of research will be needed for the complete, trustless, vision to manifest.

It’s also possible rollups evolve, like Ethereum has, into curious beasts of complexity that only a handful of people can tame.

The BitVM sidequest

The introduction of BitVM by Robin Linus last year is what really kicked off the zero-knowledge race on Bitcoin into high gear. Starkware is making headlines because of its resume but multiple teams like Alpen Labs, Citrea and Bitlayer are actively researching how to optimize zero-knowledge proofs for their implementations.

It’s going to be interesting to see what choices they make going forward and whether or not they stick to their guns. A strong case can be made that OP_CAT introduces many efficiencies but it’s not yet clear exactly what the tradeoffs are. I expect many companies will continue exploring the BitVM path and simply emulate the zero-knowledge computation. It’s important to point out that in both cases, bridging funds from Bitcoin’s chain to any other system involves light client security which is liable to re-org attacks.

A lot of airtime has been given in the last month to liquidity issues around BitVM. If we consider the current user profile for those types of solutions, I find the idea that this is going to stop anyone from participating a little dubious. It might not be practical or sustainable but I’m honestly not sure whatever market exists for this cares much at all. Again, users are currently depositing billions of dollars into multi-sigs so anything else will seem almost trustless in comparison.

More developer funding

A million dollars allocated towards funding research is a net positive for the ecosystem. This is an encouraging development for the growing mindshare around OP_CAT. It’s unlikely that a bug bounty leads anywhere but I’m interested to see what comes out of more focused work on proof-of-concepts and applications. It’s easy to frown at the source of those funds but ultimately the result of those efforts will be judged on their technical merits. Bitcoin’s development process is not as easily influenced as some talking heads would have you believe.

It’s also important to remember that OP_CAT is only one piece of the script puzzle. Breakthroughs on specific use cases are exciting but they are rarely enough to justify losing sight of the big picture. None of this technology is mature enough to pay significant dividends in the short term. Precipitating an upgrade today when it would still take years to reliably implement these systems seems a bit rash. If people want centralized virtual machines there are plenty of sidechains to choose from.

We are breaking new ground every day at this point and it’s hard to even predict where we will be a month from now. I’m cautiously optimistic about the progress being made around Bitcoin script improvements but it feels unwarranted to commit to anything at this time. We’ll need to let the dust settle down for a little while.