As the Ethereum ecosystem grows, so does the need for secure smart contracts. With billions of dollars locked in DeFi protocols and other decentralized applications, the stakes are high for developers to ensure that their code is free of vulnerabilities. Manual smart contract audits are the gold standard, but demand is high and good auditors are rare. The results are long waiting lists and prices that can quickly reach a six-digit range. An audit is usually performed when the project is mostly finished, and potential security debt has already piled up.
On top of that, the human eye is not perfect and might still miss critical bugs; you need more than audits short before launch to secure your locked funds appropriately. This is where security tools come into play.
Security best practices advocate using security analysis tools early in your development process. The "shift left" approach aims to test early on and avoid building up security debt systematically. Adding security layers can significantly reduce the risk of ending up on the Rekt leaderboard.
Many projects already have heightened security awareness, and some must-have tools are in the toolkits of devs, auditors, and bounty hunters like Mythril, Slither, VSCode w/ solidity visual developer, and Semgrep. Still, there is potential for new techniques and tools to make lives easier.
Fuzzing and the power of the monkey army
An increasingly popular approach is fuzzing, as it offers the power of the "monkey army" to throw thousands of randomized inputs against your code to provoke edge cases you would have never thought of testing; more formally: fuzzing is an automated bug detection technique that involves injecting millions of in-/valid, unexpected, or (semi) random data points to cause unexpected behavior.
The most basic approach is black box fuzzing, where inputs are created and mutated randomly. This is the proverbial monkey army, as we prejudicially think of it. But we all know our close relatives are more intelligent than that. If only we could teach them the difference between an uninteresting input and inputs that lead to more coverage of the codebase. Or could we teach them to memorize a corpus of interesting inputs and mutate the following based on that? What if we could even teach them to predict inputs that lead to another path covered? Wouldn't that make the fuzzer way more accurate and cover more of the code in less time?
Enter grey box fuzzing
With techniques like input prediction, coverage-guided fuzzing, transaction simulation, and more, the Consensys Diligence Team, especially Valentin Wüstholz, pushes the boundaries of grey box fuzzing to multiple times performance increases, making it one of the most promising approaches in the landscape. With Harvey, the fuzzing engine, the monkey army is suddenly exceptionally well-trained and seems more like a unique tactics squat than a bunch of brutes.
Property-based fuzzing is another approach that is becoming increasingly popular. This involves defining a set of properties a smart contract should uphold and use to generate test cases. Property-based fuzzing can uncover a broader range of vulnerabilities by focusing on the properties rather than specific inputs. To make property writing more accessible, the ConsenSys Diligence team created Scribble, a runtime verification tool and specification language to write properties in Solidity. With simple inline comments, Scribble automatically extends your codebase with assertions and checks that a fuzzer can use to find inconsistencies in your properties. In combination with grey box fuzzing, Scribble becomes a powerful tool that allows you to check for technical bugs and tap into business logic vulnerabilities. This is where many interesting hacks happen.
There are some very popular smart contract fuzzers in the market, like Trail of Bits' Echidna and Foundry's Forge fuzzer that utilize property-based fuzzing and do a great job in finding many bugs. However, not every fuzzer is created equal.
Diligence Fuzzing, powerful fuzzing now accessible for you
Harvey, combined with Scribble, brings you Diligence Fuzzing, the most powerful smart contract fuzzing service.
Since there were no standardized benchmarks for smart contract fuzzers in the market, we took a shot and built one. Introducing Daedaluzz, a benchmarking framework to compare as many fuzzers as possible despite their different approaches. Please read the full blog post for information on the test setting and system specs.
During a 4-hour fuzz run (aka fuzzing campaign), Harvey detected 28% more violations than Foundry's Forge fuzzer and 52% more than Trail of Bits Echidna. When compared to Foundry's fuzzer, it is remarkable that Harvey surpasses the number of found violations in only 15 minutes. This lets us believe that you will have plenty of fun with Harvey.
Get started in 3 steps
Improving your smart contract's security posture just takes three steps.
Step 1: Define Scribble specifications
Add the Scribble properties on how your smart contract should work. Scribble automatically creates assertions in your code which Harvey will use to check for inconsistencies. Harvey runs on your tests, too! You only need to deploy your system and write one or more Scribble properties. If you have Foundry tests, you can even skip the Scribble properties to get started.
Step 2: Submit your code
Submit your code to the Fuzzing platform to begin your first campaign. Harvey will analyze complex systems of multiple smart contracts to detect violations of your custom properties.
Step 3: Receive the results
Receive campaign results via the Fuzzing reporting dashboard and fix the violations in your code.
Don't take our word for it. Convince yourself.