A single bug in a smart contract exposes an entire blockchain project to hacks that have historically resulted in a loss of millions of dollars. Right from The DAO hack in 2017 to the DForce hack & the Hegic contract bug in 2020 millions of dollars have been lost and there is a dire need for high-quality Smart Contract Audits. What is equally dire is the need for clarity of how audits are actually performed.
We covered a set of preliminary FAQs here some time back, however, we wanted to go deeper this time around. So, Ish & Nitika sat down for a discussion addressing some of the most frequently asked questions on smart contract auditing.
Watch the video here:
The written transcription of the video is below:
Ish Goel: Hey guys, my name is Ish Goel and in this video, we are going to talk about our smart contract audit service and answer some of the most frequently asked questions by a lot of people. I’ve got Nitika along with me, who’s been our go-to person for everything tech, and she’s the one who’s been developing a lot of smart contracts and also auditing them.
So today we’ve got her to answer some of those FAQs is for us. Hi Nitika, welcome to this first podcast episode of – All About Audits. Excellent. So, I think we will get started straightaway Nitika, so you know, some of the most commonly asked questions that we get for our smart contract auditing service where we, make sure that, you know, when people come to us, developers come to us for getting their contracts audited.
We try to make sure that they are bug-free. So, the first question which people ask and which developers keep posting to us is when do they think they are ready for an audit? So if somebody wants to know, when am I ready for an audit? What is your opinion in terms of when somebody’s ready?
Nitika Goel: So, from my experience, like I would broadly classify into two things. So one is an interim audit, and the second would be a full security audit. So if you are building an application, which is a complex one, and you have some complex components already coded, and you want an expert to look at them from a fresh pair of eyes, just to see that you know, you’re going in the right direction, the gas levels are optimized, that is the best strategy that you could have used. That’s when you go for an interim audit.
So for example, if you’re building a lending protocol, say something like a compound. So in this case, the main core logic would be how would I distribute the interest to all of my users who are depositing their funds?
So now what is the best strategy to do this if I cannot just distribute them in a single transaction that would meet the block gas limits, that’s not possible. So I will have to convert that to a way where the people come and they can claim their interests. So things like these you know, the approach that I’ve followed, is this the best one before it reaches a stage where I have written the entire code and it’s a point where I can’t go back now.
Ish Goel: So basically what you’re saying is that if somebody is building a DeFi protocol, so there are often components which are complex, so if its a lending protocol, there are some components, like a distribution of interest, which you mentioned, is that correct? Yep. So those are the ones which require a lot of due diligence. So when you’re building something big, you want to make sure that you are following the right path and I think you’re suggesting that, interim audits help in making sure that the path that you’re following for building this alternative financial product, which is eventually going to work on ethereum for that matter.
That particular component audited by people like us. And what are the other types of audits?
Nitika Goel: So then, we have the full security audits, where the application is complete, at least from the developer’s standpoint. So the features that were specked out, they’re all in place. You have done the functional testing by writing automated unit test cases generally.
It should be a 100% code and a branch line and branch coverage. So when you’re done with that stage and you want to go out to the community for others to try out their product, to put in some money, just play with the application. That’s the time when you come to us for a full security audit where we identify security vulnerabilities.
So our focus would be that this transaction should not have gone through or this should not have been misused and that’s in place.
Ish Goel: So it’s basically, you are saying that functional level testing is ideally done at the developer level, but then for these functionalities, which the developers have built our job, or for that matter, an auditor’s job is to find security vulnerabilities in that functionality.
So if you, if you were to summarize the answer to when am I ready for an audit? I think you’ve said that you are ready for an audit if you’ve built out a complex functionality of your project and you want to test its implementation with a bunch of experts or otherwise, if you are planning to launch the product to the main net or a bunch of people out there. That’s the time when you get a full security audit done. Is that fair? Is that a good summary? Summarize it. Perfect.
Cool. So the next question that we often get Nitika is, what is the duration of audits? One thing which we’ve seen, a lot of people come and say that we really want the audit very quickly.
They rush for it, which is not ideal because the auditors must get enough time to audit the contracts. So what is, what do you think is a typical audit duration? Or are there different types of contracts which require different audit times. But yeah, the question is how much does it take from a timing perspective?
Nitika Goel: So again, we can classify contracts. All contracts are not the same. So if I talk about a very standard ERC20 so it’s just a token that you’ve developed and there are a lot of open-source repositories like OpenZeppelin where you can get these already built for you. So such contracts, they do not take much of our time.
So, we can publish the report within 48 hours also. However, if you move to a little complicated contract, not that complicated, but yes, like a crowd sale where you have vesting schedules, where you have reward mechanisms, where you have referenced mechanisms. So these will take slightly longer. It could be a week, it could be two weeks. And then we have full-fledged dApps where, you know, they have a lot of like DeFi protocols,
Yes. So all of these would definitely require more time. So there are aggregators nowadays who are integrating with third-party protocols. So why do I build a Uniswap again? So if I just want to exchange tokens within my application, I’ll go and integrate with Uniswap. So, all of these kind of applications would definitely take a longer time.
Ish Goel: Because there are dependencies on different protocols. So the next question Nitika that I have for you is, are the reports private? Are the audit reports private? What do you have to say about that?
Nitika Goel: So this is a choice which the developers make. So, for interim audits, I’ve generally seen that these are the private ones because it’s still a work in progress. And, it’s just for consulting. It’s an expert’s eye that you want
Ish Goel: Sure and obviously. I mean, if something is not fully built, you don’t want to make your audit reports public, so, make sense.
Nitika Goel: But if we talk about full security audits, those are generally, the developers, they generally prefer open-source reports.
Ish Goel: Because that’s how you build trust,
Nitika Goel: And it’s more for the community. It’s for everybody to trust your application. So it’s naturally. You know, a way that you show confidence
Ish Goel: Sure, fantastic! Okay, so the next question that I have for you is, what will I find typically in an audit report? So when developers give us their code, what should they expect to get out of the audit reports?
Nitika Goel: That’s a very good question. So, If I explain a typical audit report from Somish what would that look like. So, we have a section where we mention the basics, like the commit number, what we’ve audited, the contracts that we’ve gone through, just to be very specific that these are the contracts that we’ve looked into. Then we have an understanding section where we try to explain what exactly do we think is the intended use of the product.
So this depends a lot on the documentation that has been provided to us. The clearer the documentation, the clearer the intended usage. And then we have issues which are categorized into three sections. So they are critical issues. They are major issues and minor issues.
Critical issues are revolved generally around issues like where the funds are locked, where there are chances that the users are going to lose their funds. It’s all something related to a loss of funds, basically. Or the owner has too much of rights where he can just play with the funds of somebody, of a user, and then we have major issues where the code is working correct, or maybe there’s a bug also, but the logic implemented has some vulnerabilities from a security point of view.
So these are generally in the major issues. So where maybe like parameters, I have not been sanitized well or stuff like that. And then we have minor issues where these are issues which have low chances of occurrence and low effect on the code as well. So these are the minor issues. And then we have a section for notes, where we have some gas optimizations, some solidity compiler checks or some basic things which are at the discretion of the developer, whether they want to resolve or not.
So from our side, the critical, the major and the minor issues are the ones which definitely need to be resolved before going out in the mainland.
Ish Goel: So, can you also talk about recommendations? Like people ask – do you identify bugs only or do you also provide recommendations on how to solve them?
Nitika Goel: So yeah, , the recommendation is like really clear. So this would have been the best approach. We do write mentioned that in the report. At times it is at the discretion of the developer. So for example, we might think that the owners should not have got this privilege, and that’s mentioned as an issue, but it might be at the discretion that the developer really wants that.
Ish Goel: So, its a governance, it’s also a business decision which they need to make
Nitika Goel: So, it depends. But for most of them, we do provide recommendations.
Ish Goel: So the next question that I have for you Nitika is, what all technologies do you audit, from a blockchain perspective, which type of smart contracts do we audit? If you could throw some light on that.
Nitika Goel: Yeah. So, we have worked personally on Ethereum, on Hyperledger fabric and EOS, IOST so basically it’s solidity, Golang, Node, C++. These are the languages where we’ve mostly done our audits on.
Ish Goel: Fantastic. Okay. So the next question that I want to ask you is, what are the type of tools that are used while doing an audit?
If you could throw some light on that.
Nitika Goel: So generally we use static analysis tools like Slither, security analysis tools, like Mythril. So these give us a long list of vulnerabilities that could be there. So, for example, re-entrancy attacks or shadowed variables or some compiler version incompatibility.
So all of these, they gave us a long list out of which the auditors then manually filter that which of these are actually true. If you are, the developer actually provides us with test cases. Then we run tools like solidity coverage to find out what’s the coverage of the unit test cases. It also gives us an idea of what kind of cases and scenarios have been covered and what has been left out. So how deep the testing has been done, how many branches and how many times that line has gone through our test. So all of these help us analyze the quality of the unit test cases that have been written. We use tools like solgraph, which give us a flow of the code. It gives us an overall picture.
So it plots a graph from that piece of code. It helps us analyze things like, is the function exposed to an external call, which should not have been maybe like it should have been an internal function, or if it’s like a complex logic, how exactly is the flow going? So it helps us focus on the areas which are more complex.
And of course that helps us in the manual review thing.
Ish Goel: Sounds good. Okay. And I have a couple of more questions. So one question is, how much is an automated audit which is also known as a formal verification these days. How is that different from a manual audit? Which, people do. So can you throw some light on that?
Nitika Goel: So, if I talk about formal verification, it’s basically a set of tools which are encoded in the language that the tool understand. So for example, if your contract says that the minimum staking period has to be 30 days, so you encode this rule into the tool and you pass the contract and the code should pass, if it’s like more than 30 days, it should fail, if it’s less than 30 days. So this. It’s slightly different from automated testing in a way that it also analyzes the vulnerabilities because it has more access. It accesses the coordinate different way. But yeah, so this is the basis of formal verification.
It’s very difficult to do formal verification of very complex projects because then the rules, defining those rules are quite…
Ish Goel: So, I think it’s formal verification for a simple ERC20 is very common.
Nitika Goel: So for ERC20 or maybe for like a crowd sales. Contracts, which have standardized over a period of time, that’s where it’s easier and where you have really like the custom contracts and you want to test out your game theory and everything, a manual review, I think it does a great job there.
Ish Goel: Fair enough. So, if you were to tell our audience in terms of, what should they go for, if they are building a DeFi protocol or for that matter, even if they’re building a less complex solution, I mean, from a security standpoint, audit standpoint, what do you feel is more relevant today? While we continue to research, but what do you feel is more relevant today.
Nitika Goel: So, as you rightly mentioned, it’s still in the research phases, or the formal verification and development of such tools is, it’s still in progress, and I’m sure it would have a lot of potential some years down the line. But if I talk about the technology as of now, I would definitely suggest a manual review by people who are experienced and who have knowledge in this domain. Yeah.
Ish Goel: Great. So the last question Nitika is, how much does it cost to do an audit? I think, yeah, we don’t really have a straightforward answer for this, but yeah, let you speak about it.
Nitika Goel: Yeah. This is quite subjective actually. So again, it depends on the contract and, on the complexity of the contract. It depends on whether you’ve written a unit test cases well, so that, that makes the job of the auditors quite simple.
Ish Goel: Also the number of lines I guess
Nitika Goel: Yeah, I think the complexity is what is important. And apart from that, the documentation. Because if you give us good documentation, if we understand, what the code is trying to do at least, it makes the job of the auditor simpler. And it also helps you. You know, find out the vulnerabilities, which are actually there or maybe the specifications which have not been coded at all.
I’ll give you this example. Like you have a requirement that the minimum stake period has to be, say 20 days. If it’s not coded, it slipped out of the mind of the developer. It would also slip out of his mind at the time of internal testing. Because it was not there in his mind.
Now, if this is written in the specification document, people like us can actually go and check whether this condition has actually been implemented. This is a very small example, but it helps a long way. There are times when certain things just miss out and it changes the entire game of the application. So it’s important. Yeah.
Ish Goel: Excellent. So the answer to the question is that give us your code, give us your documentation and we come back with a quotation in terms of the effort required to audit that piece of code. Fantastic. I think that’s it from the questions that I have for today. It’s been an excellent session.
Thank you for sharing your expertise with us Nitika, yeah, that’s all for today, but we are going to come back with more such sessions with Nitika. We planned to talk about the caveats of writing a smart contract and what all vulnerabilities are there. As we move along in this podcast series, we’ll cover some of the more important ones as we go forward and get to hear from Nitika in terms of what are those caveats and how do you solve for them.
Excellent. Guys, thank you so much for listening. And this is Ish Goel signing off along with Nitika. Thank you so much once again.
Nitika Goel: Thank you