Cracking the Code of DeFi Vulnerabilities: Alp Bassa’s Deep Dive into Smart Contract Security
In Brief
Alp Bassa, a Research Scientist at Veridise, discusses innovative tools, zero-knowledge proof audits, and blockchain security’s future.
In this exclusive interview, taken during the Hack Seasons Conference, Alp Bassa, a Research Scientist at Veridise, shares insights into Veridise’s innovative tools, the intricacies of zero-knowledge proof audits, and the future of blockchain security. During the discussion, we will explore the intersection of mathematics, cryptography, and blockchain technology through the eyes of one of the industry’s leading experts.
Many entrepreneurs are drawn to their field by a specific moment or event. What was your journey to Web3?
I come from an academic background. I’m a mathematician who was doing research in number theory, focusing on curves over finite fields, elliptic curves, and their applications in coding theory and cryptography. These tools are heavily used, especially now with zero-knowledge cryptography having a bigger influence in the Web3 space.
I saw that there were lots of interesting things happening there. Then I started working at Veridise, where they do security audits and specialize particularly in the ZK domain, which is where my expertise fits in very nicely.
Why do we even need security audits? Can developers operate without them, or are they mandatory?
The security of the systems requires a different mindset that you have to take already at the development stage. Not all developers can focus on all aspects of the development process simultaneously – ensuring the right specifications, behavior, efficiency, integration into a larger setup, and security. Most of the time, security is an aspect that is not covered well throughout the development process.
It has become almost impossible for a developer to be confident enough with various complex tools to guarantee they are used correctly and that there are no vulnerabilities. It’s just a different mindset that needs to be applied. That’s why audits are useful.
Can you elaborate on the in-house tools Veridise has developed and how they enhance audit quality?
There’s a wide spectrum of tools that can be used. Some are more primitive but don’t require too much background and are easily accessible, like fuzzers. Some are in the middle, like static analysis tools. They’re quite fast but not too exact – they can give some false positives.
Then there are tools that are heavily backed by mathematics, based on SMT solvers and other mathematical background. These are very precise but computationally heavy. We use a combination of all these tools, each with their pros and cons, to catch bugs and vulnerabilities.
What are some of the unique security considerations that Veridise addresses for DeFi protocols?
For DeFi protocols, we have a static analysis tool where you tell the system beforehand what kind of vulnerabilities to look for or what structures to aim for. There are many of them. For instance, reentrancy attacks were responsible for the DAO hack of 2016. Flash loan attacks were exploited in the attack on Cream Finance, which caused about $130 million to be stolen.
Through our experience over the years of auditing, we have a good overview of what the vulnerabilities are, and our tools are made to check for all of these. During our audits, we look at them one by one in detail to see if such risks appear.
Please elaborate more on how you use ZK technology and why ZK audits are your main priority?
ZK is particularly interesting from a formal verification perspective because it translates very well into the use of tools. We have tools that are particularly aimed at checking ZK applications. Because it’s so suitable for our methods, that’s the area we’ve focused on a lot.
We’ve identified critical vulnerabilities in core circuit libraries. Our team is very strong in that field, so we decided to be very present and at the frontier of ZK auditing. Most of our research is also motivated by needs and requirements from an auditor’s perspective on the ZK domain.
How does your expertise in ZK circuits differentiate from other companies?
I would say our tools are what differentiate us a lot because we come from a formal verification background. We have very strong tools, and by now, the extent of the projects has become so large that human endeavor alone is not really sufficient for having good coverage of the codebase. It’s necessary, but by itself, it’s not enough.
How does Veridise balance manual code review with automated tool analysis in its auditing process?
There is a need for both of them. We notice it also in the audits. Most of the time, when we do very rigorous human auditing and then run the tools afterward on the codebase, we find some vulnerabilities that have escaped our attention. Sometimes, we run the tools first, but the tools can only detect certain kinds of structures.
Since there are so many layers of complication and abstraction in these systems, just relying on the tools is also not enough. I feel like you can’t do without either one of them, and I don’t think that will change in the future.
What are the key features of Veridise’s Vanguard tool, and how does it improve smart contract security?
Vanguard is one of our main tools. It’s used for static analysis. In static analysis, you provide a certain specification of the intended behavior and then check whether that is satisfied – whether certain properties hold without running the code. It’s not dynamic; you don’t execute the code, but you statically try to assess if certain patterns are there that could cause vulnerabilities.
Vanguard comes in many flavors. We have parts of it that are quite good for improved smart contract security, and parts focusing on zk applications.
Can you elaborate more about vulnerabilities you’ve encountered in smart contracts and ZK circuits?
In ZK circuits, which I work more on, one of the most commonly encountered vulnerabilities would be under-constrained circuits. In a ZK application, your codebase consists of two parts: the program itself (the normal execution) and the constraints. You require that the constraints reflect the behavior of the program execution in a one-to-one way.
According to a recent paper, about 95% of all vulnerabilities in ZK circuits are caused by under-constrained circuits. We have tools, such as PICUS, which is particularly aimed at detecting those under-constrained circuits.
How does Veridise approach the disclosure process for vulnerabilities discovered during audits?
Of course, we don’t make vulnerabilities public at any point because someone else might exploit the bug before it’s fixed, especially if the codebase is already in use. At the end of the auditing process, we deliver an audit report where we give the customer a list of all bugs and vulnerabilities we’ve discovered.
We give the customer some time to fix those, and then they send us their fixes, which we review to check if they really address all the issues we raised. We put it all together in a final report. The report is the property of the customer. We don’t make it public unless the customer agrees.
If you go to the Veridise webpage, you can see a list of all the audit reports that customers agreed to make public. In most cases, they’re okay with us making it public. In fact, they want it as a certificate that the code was audited and is as free of bugs as it can be after an audit.
How does Veridise adapt its auditing processes for different blockchain platforms and languages?
As you know, the field is very vibrant, and every day there are new chains, new languages, and new ways of expressing ZK circuits. We see that also with the incoming projects and requests for audits that are based on different environments or languages. We go with the flow, see where the requests come from, and have a feeling of which direction the field will evolve in the near future.
We try to adapt our tools to address the needs from the community. This will continue in the future, where we will change things dynamically according to how the field evolves.
Can you elaborate more about the tools you’re planning to implement in the future?
One direction in which the tools will change in the near future is that we will offer security as a service. It’s called our SaaS platform, where we will make the tools available for people to use during the development process.
Rather than first finishing the entire project and then doing an audit, we will make our tools useful in a setup where developers can use them while developing to ensure that the code they’re developing is secure and doesn’t contain any vulnerabilities. The SaaS should be available in the near future.
Disclaimer
In line with the Trust Project guidelines, please note that the information provided on this page is not intended to be and should not be interpreted as legal, tax, investment, financial, or any other form of advice. It is important to only invest what you can afford to lose and to seek independent financial advice if you have any doubts. For further information, we suggest referring to the terms and conditions as well as the help and support pages provided by the issuer or advertiser. MetaversePost is committed to accurate, unbiased reporting, but market conditions are subject to change without notice.
About The Author
Victoria is a writer on a variety of technology topics including Web3.0, AI and cryptocurrencies. Her extensive experience allows her to write insightful articles for the wider audience.
More articles
Victoria is a writer on a variety of technology topics including Web3.0, AI and cryptocurrencies. Her extensive experience allows her to write insightful articles for the wider audience.
