Auditing Like A Pro With Nikesh Nazareth

Nikesh Nazareth is a Blockchain Security Researcher at OpenZeppelin. As a part of the leading crypto security company, Nikesh spends time both completing security audits with many of the leading projects in the space, as well as pursuing research in between reviewing smart contract and protocol-level code. Nikesh explores journey to becoming a physicist turned smart contract auditor, his auditing-stack, and tips for new auditors. 

Educational background:

I completed a Physics and Computer science double degree. I wanted to be a physicist before I realised that loving physics and being a physicist are two very different things. So I leaned into the Computer Science side, which seemed more directly impactful.

How did you get started in blockchain auditing? How does your background help you in your audits?

I got started in the industry for somewhat political reasons. I would like to see more individual liberty in general and I consider decentralized technology to be a promising mechanism to advance that goal. In particular, being able to make believable commitments with people you don't know or trust opens up a whole new range of possible social coordination mechanisms. In my mind, making it safer for regular users is an intermediate goal towards encouraging more widespread adoption so that we can experiment with and transition to those mechanisms. It's also a nice way to apply my security skills to support the movement.

In terms of how my background helps audits, I have worked in security for several years, which has been useful to train the right mindset. I also had a focus on cryptography, which helped understanding the industry as a whole and many techniques used in it. Although these days the relevant cryptography is much more advanced than my background, so there's always something new to learn.

What was the most thrilling moment in your blockchain security career?

Finding interesting and impactful bugs is always thrilling! However, this might sound surprising, but the one that comes to mind was actually a pretty unremarkable low-severity bug that I found in the OpenZeppelin contracts library before I joined the company. I had decided to work in the industry, but I wasn't sure how much my existing skills would translate. Being able to make a real contribution to an important project was pretty exciting. It also lead to my current role, so that was a big win.

What do you think separates a good auditor from an elite one?

I think a good auditor is someone who can match known attacks to code patterns to find which ones apply. And the more attacks you've seen in different contexts, the better you'll be at identifying vulnerabilities. But I think the best auditors (and security professionals generally) also think about attack surfaces and systemic fragilities.

There's an insight I like to share with new hires in OpenZeppelin: we're not trying to be smart, we're trying to be safe. We want systems to be as simple and locally predictable as possible. All assumptions should be explicitly enforced in the code, wherever possible. If you're reviewing (or writing) code and you find yourself needing to track several moving parts simultaneously, there's very likely to be an edge case where the system can get into an inconsistent state. And that's usually where you can find novel attacks.

What project(s) are you currently auditing?

I'm not sure if we should be stating this publicly. What's the goal of this question? Maybe we can reframe it

What’s the most critical bug you’ve ever found during an audit?

I'm not quite sure how to rank the criticals because we're reviewing code before it's deployed. If you're looking at a situation where you can take user funds, determining exactly how bad it would be depends on the details of the counterfactual world where we didn't prevent it, like how big the protocol would have become before the issue was discovered and exploited. I think by that standard, the bugs that could have prevented Optimism fraud proofs (under their old architecture) were probably the most severe, with lots of caveats around all the other security measures failing.

But I also don't think that's particularly insightful. In my experience, once you've identified a mismatch between the code and its purpose, whether or not it is critical is almost entirely random and depends on a lot of contingent facts about the rest of the system.

The bugs I like to remember are ones that reflect the system design. For instance, in the original Compound audit we found that under some circumstances, the liquidation mechanism was actually counterproductive - it was incentivizing users to push the protocol into insolvency. Or there are cases where protocols have encrypted and/or commit-reveal voting schemes, not realizing that confidentiality doesn't imply authentication: you can still duplicate votes that you can't read. This matters whenever you're trying to vote with the majority (rather than, just express your own preference). I like these because you can't really identify them with better tooling or tests - you have to really think about how the system works and what it's trying to achieve.

Which codebase has been the most interesting to audit, and why?

The Augur project comes to mind. I think prediction markets are very interesting and largely underrated. I also like that they were committed to ensuring a robust design without taking centralization shortcuts. As an auditor, that meant we had to think about some unusual edge cases, like what happens to the ecosystem when a market forks.

How do you set up for an audit? What tools or environment do you use?

My setup is pretty simple. I use VSCode to interact with the code and Obsidian to take notes. I have a few simple scripts to speed up repetitive tasks but most of my audit time is just reviewing and thinking about the code.

Describe your auditing process. Do you follow a specific methodology?

It depends on the system and if I've seen the basic pattern before. Typically, I'll start by reviewing documentation and asking the client questions until I'm sure I understand how it's supposed to work. Then I'll do a superficial review of the code to get a sense about how it all fits together. 

But most of my audit time is in manual review, where I'll take detailed notes on everything the code is doing. The actual review process is pretty repetitive, just looking for common context-sensitive patterns. For instance, when reviewing the constructor I'll think about uninitialized variables. When reviewing a function, I'll think about access control, input validations and any state transitions. If there are tokens involved, I'll think about approvals, transfers and flash loans. If there are proxies, I'll think about the upgrade logic and whether the implementation is locked down. Whenever I notice code smells, or I have questions to resolve, I use Obsidian to quickly tag the idea so I can go back to the review without getting distracted. Once I've seen and understood the whole system, I'm in a better position to resolve all the questions that I tagged.

Finally, when I have the system clear in my mind, I'll think about the system boundaries, any unwarranted assumptions or fragilities and investigate potential vulnerabilities. I might modify the test suite or write proof-of-concept attacks. The basic idea is to keep exploring until I'm confident that I've chased down all open questions.

What tips do you have for new auditors?

I think getting familiar with all the basic patterns and vulnerabilities is a good first step. There are plenty of resources and capture-the-flag examples to get up to speed. If you're part of a team, I'd recommend trying to explain the system to each other at the conceptual level, the way you might explain it to somebody who doesn't read code. If you can't explain it at the conceptual level, and can't predict how a user action would flow through the system, you don't understand it well enough. Other than that, I don't think there is any substitute for experience - just try to be systematic and keep reviewing code until you're comfortable.

Is there a specific area of blockchain or smart contract technology you are particularly passionate about? If yes, why?

Like many people in the industry, I'm interested in Elinor Ostrom's work on how various communities have solved public goods problems. It really highlighted to me that ownership doesn't necessarily imply exclusive control in perpetuity, and at least some market failures are downstream of this confusion. I think blockchains give us an opportunity to be much more precise about particular property rights, how they interact with the open market, and how they can be assigned and revoked. I like the fact that our industry has a few different groups experimenting in this direction.

I also broadly like living in a country with a good social safety net, but I have reservations about its implementation. I have some partial intuitions about how to transition to a voluntarily funded scheme that doesn't respect country boundaries, and what the incentive structures might look like.

But in both cases, I don't think the technology is ready yet. It's more of an intuition than an actual plan, and we have to start with local low-stakes experiments. I hope as the privacy and scaling technologies improve we'll have a lot more innovation in this area.

OpenZeppelin Security Audits

OpenZeppelin, a leader in blockchain security, sets the standard when it comes to open-source libraries, technology, expertise, and security audits. If you’d like to work with OpenZeppelin on a state-of-the-art security audit, then get in touch.