Creating an API Key
Preparing and submitting a campaign
Creating an API Key
Auto generating a fuzzing configuration file
## How does fuzzing compare to formal verification? Formal verification techniques are great! They allow you to prove that your smart contracts are mathematically correct. However, to get these guarantees, youâll first need to invest a significant amount of time in manually providing the mathematical building blocks required to prove the contract. If youâve got months to spend and donât plan on making changes to your codebase, then formal verification is the tool for you! Fuzzing, on the other hand, takes a much more practical approach as it requires just a single annotation to be useful! While it canât categorically prove the absence of bugs like formal verifiers, it gets close to it by cleverly executing millions of test cases. Keep in mind that both formal verification and fuzzing suffer from the problem that a tool's results are only as good as the properties you write. Writing properties is often a difficult and time consuming task, and you can easily miss a critical specification, thereby allowing a bug to go unnoticed. > "formally verified" does not mean secure. With [Scribble](https://docs.scribble.codes) we've made the property writing process as simple and foolproof as possible. It's accessible to developers and requires much less maintenance. Furthermore, you can use fuzzing to check your properties out-of-the-box, without the need for complex mathematical proofs. # Campaign Reports Everything you need to know about campaign reports Campaign reports show you the results for both ongoing and finished fuzzing campaigns. ## Statistics The statistics view shows you some basic information and telemetry to see how the fuzzer is doing: * Fuzzing Speed * Coverage * Duration * Residual Risk Learn more about the statistics on this dedicated page: {% content-ref url="/pages/-MY5MX2vdBIOyxxwh6nm" %} [Statistics](/general/reports/coverage) {% endcontent-ref %} # Statistics On the coverage metrics reported by Diligence Fuzzing ## Modes When looking at a campaign report, you'll prominently find the most important statistics: 1. Total instruction coverage 2. Analysis duration 3. Residual risk 4. Testcases per second You'll probably be good with just those metrics, but if you want more insight into what the fuzzer is doing, then you should check out "đ Pro Mode" which adds a ton of metrics to your report! 1. Branch Coverage 2. Path Coverage 3. Number of issues found 4. Transaction Depth 5. Transaction Status The rest of this page will describe the different types of coverage, what they mean, and how you can use them to optimize your fuzzing campaigns.  ## Instruction Coverage Instruction coverage tells you the percentage of instructions in the target contracts that have been covered. {% hint style="info" %} Instruction coverage doesn't translate directly to line coverage, as not every line is equally represented in the bytecode instructions. {% endhint %} Instruction coverage gives you a good overview of the amount of features/functions that have been covered by fuzzing. A low coverage usually means that large parts of the code are not explored by the fuzzer. ## Line Coverage We display line coverage as green markers in the file-view window. While fuzzing we mark a line as covered (green) whenever we execute an instruction that maps to code on that line. You might notice that line coverage doesn't highlight every line in a function, even though it seems like it should have covered 100% of it. This usually happens when there are empty lines, code comments, structure definitions, etc. We don't count these lines as executable, so we keep them unmarked. The picture below shows how fuzzing covered the transfer function completely  {% hint style="info" %} Line coverage is super helpful to investigate why a fuzzer is getting stuck (if it's getting stuck). One example that we frequently encounter is forgetting to mint tokens for a fuzzing account in the seed state. In such a scenario, all transfers from the fuzzing account will result in a revert, blocking the fuzzer from further exploring the function that tries to perform the transfer. {% endhint %} ## Branch Coverage Branch coverage tells you the absolute amount of branches that were covered during the fuzzing campaign.  You can find a branch at any point in your code where execution can "jump" to one or more places; for instance, in the conditional below: ``` uint i = 0; if (a) { i = 1; } return i; ``` This piece of code has three branches: 1\. Line 2 -> Line 3 (a == False)\ 2\. Line 4 -> Line 5 (a == False)\ 3\. Line 2 -> Line 5 (a == True) {% hint style="info" %} We measure branch coverage at the EVM level! The number of branches in the EVM bytecode doesn't necessarily match the number of branches in your Solidity code. {% endhint %} A growing number of covered branchs tells us that the fuzzer is covering more and more edge-cases in the code. ## Path Coverage A growing number of paths tells us that the fuzzer is finding more and more test-cases that each let the code follow a new unique path. Even after instruction coverage and branch coverage converge, you'll often see this metric still growing. You can feel a little bit more safe with each additional path covered!  # Incremental Fuzzing Reusing fuzzing corpuses Instead of starting your fuzzing campaigns from scratch you can reuse existing fuzzing corpuses to hit the ground running. ### Corpus One way to think about a fuzzer is an automatic test-case generator. In fact, this is why many fuzzing and symbolic-execution approaches are referred to as "automatic test-case generation techniques". While the fuzzer is running, it will find an increasing number of test-cases that increase instruction-, branch- and path coverage. Over time, it will accumulate these tests, and incremental fuzzing allows you to use them for subsequent campaigns. You provide an existing corpus to the fuzzer in addition to the seed state. The fuzzer will then first run through all of the provided test-cases and add them to the new corpus if they are still useful (for instance, by increasing coverage). Then fuzzing continues as it normally would. Except that it will get a huge head start! It'll be as if you've already been fuzzing for hours! ### Incremental fuzzing The accumulated corpus is instrumental in the fuzzing process itself, but also for continuous/incremental fuzzing campaigns. The main reason for this is that typically code doesn't change much between fuzzing campaigns. Bug fixes leave most of the code unchanged, and refactorings are usually confined to a small region of the codebase. Depending on the situation, more than 90% of the code might not change at all. When that's the case, it doesn't make sense to start fuzzing from scratch; does it? {% hint style="info" %} How much you gain with incremental fuzzing depends on the size of the previous corpus and the amount of changes since that time. {% endhint %} ### Setting it up Setting up incremental fuzzing is a breeze! {% tabs %} {% tab title="CLI" %} You can reuse the corpus from previous campaigns by passing in their ID: ``` fuzz -c .fuzz.yml run --corpus cmp_
Coverage without recorded lesson
Coverage with recorded lesson