A year ago, on May 30th, 2023, we released zkSecurity to the world with a tweet and a blog post.
Our theory at the time was that ZK circuits were hard to write correctly, and that with the boom of ZK platforms and frameworks and languages, developers were going to write bugs. What we didn’t know is how many bugs…
A year later, our team is quite different! Brandon ended up stepping down to an advisor role due to becoming the CEO of O(1) Labs. Our loss, but good for O(1) Labs :) Gregor left O(1) Labs to join us full time, and Mathias ended up joining the founding team (so that we’re back to three cofounders!). It’s been an exciting year of growth, and we’re thrilled to now have a team of around 10 dedicated engineers!
Our theory when we started zkSecurity was that ZK platforms would launch, and we would have plenty of ZK circuits to audit. But instead, ZK platforms took their time, and we ended up going through the entire stack in the meantime. Auditing proof systems, compilers, libraries, user applications, and integrations in real-world systems. Let’s say that we learned more about the whole stack in a year than in years as developers.
We also underestimated how easy it was to mess up ZK code, finding numerous soundness issues, proof forgeries, and even double spending bugs in client’s code. (I highly recommend checking our blog where we post our public reports.) This led us to write tools like Circomscribe, explore how we could find bugs using taint analysis, and publish a taxonomy of ZK bugs.
We knew from the start that the ZK boom was handing out a new programmable abstraction to developers, a programmable abstraction that was both complicated and confusing. The ZK codebases we looked at have (on average) been large and complex; the two main ingredients for bugs (and cool applications). Moreover, useful ZK applications most often means that they implement cryptographic algorithms in their circuits, add to that that they tend to target financial systems, and the impact of a bug is magnified significantly. And of course, if you have a privacy-enhanced application, then exploits can go undetected. This might seem scary, but for us it means job security.
At the same time zkVMs came into the mix. Bringing much more familiar abstractions to developers, and shifting the bugs to the compiler and proof system layers. While the cost of that nice abstraction layer has kept decreasing in the last years, some experts seem to argue that they’re not going to completely replace circuits yet. At the very least, they’ll still be circuits to audit, as optimization seekers are not going anywhere. But it’s not too far-fetched to see a future where zkSecurity might be much more focused on auditing the inner guts of a zkVM rather than a user application implemented as a circuit. Although, progress in proof systems hasn’t seemed to slow down either in the last year, so we’re not worried just yet.
This year was also the year we helped people win $500,000 of prize by hosting one of the ZPrize category. The year our post on the Nova attack blew up, and the year we launched a number of projects: wasmati, zkBitcoin, and zkNews (which we will talk about in a later post).
Where will we be in a year? It’s hard to say. While we started as an auditing firm, half of our time is now being spent doing dev work. With some work funded by grants through the Ethereum Foundation and the PSE team (which we’ll talk in a later blogpost), and some work funded by Starkware (which we’ll have more to say about in the near future).
If you’re interested in joining the adventure, and you’re into zero-knowledge proofs and security, you can apply by taking our zkBank challenge here!