blocks|key|5715793|text|type|unstyled|depth|inlineStyleRanges|entityRanges|data|entityMap^0^^$0|@$1|2|3|-4|4|5|6|B|7|@]|8|@]|9|$]]]|A|$]]

<h1>Summary</h1>
Fuzzing &amp; Symbolic execution accomplish similar goals of finding cases where code breaks, but have tradeoffs in speed vs. precision, and take very different approaches.
Fuzzing: Much faster to do, but less precise.
Symbolic Execution: Much slower to do, but more precise.
<h1>Full Explainer</h1>
Let's look at a practical example to understand the difference between these two.
We will state with an example where fuzz testing can shine.
<h2>Where fuzzing excels - Fuzz Run</h2>
<pre class="lang-js prettyprint-override"><code>pragma solidity ^0.8.16;
 
contract VulnerableContractOne {
 
 function func_one(int128 x) public {
 if (x == -20) {
 revert(); // BUG
 }
 }
}
</code></pre>
(Yes,<code>func_one</code> could be restricted to <code>pure</code>, but the current foundry tester was having a hard time reading the function from the ABI as a pure function)
In our contract above, we can clearly see that entering <code>-20</code> as an input parameter to <code>func_one</code> will result in a <code>revert</code>, which we will say is where our bug is.
Approaching this from a <a href="https://book.getfoundry.sh/forge/fuzz-testing" rel="nofollow noreferrer">foundry fuzz/invariant test</a> we can write a fuzz or invariant test that will throw pseudo-random values at this function until it finds an area that will break it.
<pre class="lang-js prettyprint-override"><code>// SPDX-License-Identifier: UNLICENSED
pragma solidity ^0.8.16;

import &quot;forge-std/Test.sol&quot;;
import &quot;forge-std/StdInvariant.sol&quot;;
import &quot;../contracts/VulnerableOne.sol&quot;;

contract VulnerableOneTest is StdInvariant, Test {
 VulnerableOne public vulnerableOne;

 function setUp() public {
 vulnerableOne = new VulnerableOne();
 targetContract(address(vulnerableOne));
 }
 
 // Our Fuzz Test (stateless fuzz test)
 function testShouldNeverRevert(int128 x) public {
 vulnerableOne.funcOne(x);
 }
 
 // Our Invariant Test (stateful fuzz test)
 function invariant_shouldNeverRevert() public {
 assert(true);
 }
}
</code></pre>
And in our <code>foundry.toml</code> we can set the config:
<pre><code>[fuzz]
runs = 1000
seed = '0x3e8'
include_storage = true
include_push_bytes = true

[invariant]
runs = 2000
depth = 15
fail_on_revert = true
</code></pre>
To run one of the two tests alone, we can do one of the following to run that single respective test:
<pre class="lang-bash prettyprint-override"><code>forge test -m testShouldNeverRevert
forge test -m invariant_shouldNeverRevert
</code></pre>
<h3>Quick Primer on Foundry Fuzz (&amp; Invariant) Testing</h3>
You can learn more about the difference between <a href="https://ethereum.stackexchange.com/questions/144691/whats-the-difference-between-invariant-and-fuzz-testing">fuzz tests and invariant tests here</a>, but the synopsis is that fuzz tests are the process of providing random data as inputs during testing to break something.
Foundry fuzz tests are known as stateless fuzzing. Where each &quot;run&quot; of a fuzz test (like our <code>testShouldNeverRevert</code>) is independent.
Foundry invariant tests are known as stateful fuzzing. Where each &quot;run&quot; of an invariant test consists of many function calls where the state of the system is contained. Ie, if storage is changed, then storage persists between function calls until a run has completed. You can increase the number of function calls by adjusting the <code>depth</code> in <code>foundry.toml</code>. The larger the <code>depth</code> the more function calls the test will make.
For the rest of this post, I will refer to foundry's fuzz tests as &quot;stateless fuzzing test&quot; and invariant tests as &quot;stateful fuzzing test&quot;
<h3>Fuzzing catches our bugs</h3>
If we run either one of our tests, we will see that we are able to find the bug of supplying <code>-20</code> as an input parameter. Foundry can be a little intelligent with the random values it supplies to try, it'll look at storage of the contract and other values to try to find a bug.
Output of <code>forge test -m testShouldNeverRevert</code>:
<pre><code>Running 1 test for test/VulnerableOne.t.sol:VulnerableOneTest
[FAIL. Reason: EvmError: Revert Counterexample: calldata=0x5cee85beffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffec, args=[-20]] testShouldNeverRevert(int128) (runs: 899, μ: 5561, ~: 5561)
Test result: FAILED. 0 passed; 1 failed; finished in 46.05ms
</code></pre>
With <code>seed = '0x3e8'</code> in our <code>foundry.toml</code> we will always get this output.
However, our <code>forge test -m invariant_shouldNeverRevert</code> can give different outputs.
Either:
<pre><code>Running 1 test for test/VulnerableOne.t.sol:VulnerableOneTest
[PASS] invariant_shouldNeverRevert() (runs: 1000, calls: 15000, reverts: 0)
Test result: ok. 1 passed; 0 failed; finished in 1.01s
</code></pre>
Or something like:
<pre><code>[FAIL. Reason: EvmError: Revert]
 [Sequence]
 sender=0x000000000000000000000000000000003e5e3c23 addr=[contracts/VulnerableOne.sol:VulnerableOne]0x5615deb798bb3e4dfa0139dfa1b3d433cc23b72f calldata=funcOne(int128), args=[-170141183460469231731687303715884104505]
 sender=0xe5b327aeb092428856e2b70d9a0a0bfa7ca794fb addr=[contracts/VulnerableOne.sol:VulnerableOne]0x5615deb798bb3e4dfa0139dfa1b3d433cc23b72f calldata=funcOne(int128), args=[-170141183460469231731687303715884104438]
 sender=0x000000000000000000000000000000000000007f addr=[contracts/VulnerableOne.sol:VulnerableOne]0x5615deb798bb3e4dfa0139dfa1b3d433cc23b72f calldata=funcOne(int128), args=[170141183460469231731687303715884105726]
 sender=0x00000000000000000000000000000000000000ce addr=[contracts/VulnerableOne.sol:VulnerableOne]0x5615deb798bb3e4dfa0139dfa1b3d433cc23b72f calldata=funcOne(int128), args=[-170141183460469231731687303715884105504]
 sender=0x00000000000000000000000000000000000000ce addr=[contracts/VulnerableOne.sol:VulnerableOne]0x5615deb798bb3e4dfa0139dfa1b3d433cc23b72f calldata=funcOne(int128), args=[-170141183460469231731687303715884103908]
 sender=0x00000000000000000000000000000000000000af addr=[contracts/VulnerableOne.sol:VulnerableOne]0x5615deb798bb3e4dfa0139dfa1b3d433cc23b72f calldata=funcOne(int128), args=[-20]
</code></pre>
With our stateful fuzz test, we can see it took a few calls in a single run to find <code>-20</code>.
In any case, we were able to very quickly find the edge case of the bug in this. However, we got a little lucky. Fuzzing tries random values, and if you change the number of runs to something much less like 10, it's highly likely foundry wouldn't have found our edge case.
<h3>Where fuzzing excels - Symbolic Execution</h3>
Now, let's try to approach finding this bug using symbolic execution. Symbolic execution is the process of exploring the state paths of a program given different inputs to arrive at a mathematical expression that describes the system.
Let's look at that another way.
To do symbolic execution, we'd want to take our function and replicate it as a mathematical expression.
Something like the following (not actual code)
<pre><code>x &gt; -2**128 &amp;&amp; x &lt; 2**128 // type constraints on x
if(x == 231) break // conditional
assert(x) // check for not reverting
</code></pre>
You could then take your model and place it into an SMT Solver like <a href="https://microsoft.github.io/z3guide/" rel="nofollow noreferrer">z3</a>.
Once you have a model, the math to prove the assumptions becomes much easier, since math is either correct or not.
The solidity compiler comes pre-built with an <a href="https://docs.soliditylang.org/en/v0.8.17/smtchecker.html" rel="nofollow noreferrer">SMTChecker</a> which under the hood does this process.
The SMTChecker looks for <code>assert</code> commands to break, so in a test we could update our file:
<pre class="lang-js prettyprint-override"><code>pragma solidity ^0.8.16;

contract VulnerableContractOne {
 function func_one(int128 x) public {
 if (x == -20) {
 assert(false);
 revert(); // BUG
 }
 assert(true);
 }
}
</code></pre>
And solidity will attempt to convert this solidity code into a mathematical expression and look for the path to break the asserts.
We can run the SMT Checker on this solidity code like so:
<pre><code>solc VulnerableOne.sol --model-checker-targets all --model-checker-engine all
</code></pre>
And you'll get an output like:
<pre><code>Warning: CHC: Assertion violation happens here.
Counterexample:

x = (- 20)

Transaction trace:
VulnerableContractOne.constructor()
VulnerableContractOne.func_one((- 20))
 --&gt; VulnerableOne.sol:7:13:
 |
7 | assert(false);
 | ^^^^^^^^^^^^^
</code></pre>
This tells us it found out that <code>-20</code> breaks the asserts. This is also an example of <a href="https://docs.soliditylang.org/en/v0.8.17/smtchecker.html" rel="nofollow noreferrer">formal verification</a> where we used math to prove or disprove a model works in an expected way. We've proven that the model can revert, when we expect the model to never revert.
<h3>Where fuzzing excels - summary</h3>
In our symbolic execution example we were able to find exactly the breaking path by converting our solidity to math, whereas in our fuzzing we just threw random values at it until we got the correct value.
Writing fuzz tests are much quicker and mentally easier than making sure our symbolic execution tests are correct, as there is a lot more to think about.
<h2>Where Symbolic Execution Excels - fuzzing</h2>
Now let's update the code to be a little tricker:
<pre class="lang-js prettyprint-override"><code>// SPDX-License-Identifier: MIT
pragma solidity ^0.8.16;

contract VulnerableContractOne {
 function func_one(int128 x) public {
 if (x / 4 == -2022) {
 assert(false);
 revert(); // BUG
 }
 assert(true);
 }
}
</code></pre>
If we run this in a foundry fuzz tester, it MAY find the right value, but more often than not the random attempts it makes won't find the value that sustains this.
<h2>Where Symbolic Execution Excels - Symbolic Execution</h2>
We can update our SMTChecker test:
<pre><code>pragma solidity ^0.8.16;

contract VulnerableContractOne {
 function func_one(int128 x) public {
 if (x / 4 == -2022) {
 assert(false);
 revert(); // BUG
 }
 assert(true);
 }
}
</code></pre>
Running our SMTChecker results in this:
<pre><code>Warning: CHC: Assertion violation happens here.
Counterexample:

x = (- 8088)

Transaction trace:
VulnerableContractOne.constructor()
VulnerableContractOne.func_one((- 8088))
 --&gt; VulnerableOne.sol:7:13:
 |
7 | assert(false);
 | ^^^^^^^^^^^^^
</code></pre>
And instantly gets the correct path for our issue.
This is because the SMTChecker models out the code, and then tries to break assumptions based on the path.
In this example, it was relatively trivial to get our symbolic tests up and going, but getting these correct for more complicated projects where more complicated invariants need to hold make writing these a much more time laborious process.
Some more clever tactics have sprung up such as <a href="https://blog.trailofbits.com/2022/12/08/hybrid-echidna-fuzzing-optik-maat/" rel="nofollow noreferrer">hybrid fuzzing</a> where fuzz attempts are fed into a symbolic execution framework that tries to model the system to get smarter with future inputs, as opposed to just continuing to do random attempts.

In web3, we have a number of fuzzing tools like <a href="https://book.getfoundry.sh/forge/fuzz-testing" rel="nofollow noreferrer">foundry's fuzz &amp; invariant tests</a> and Trail of Bits <a href="https://github.com/crytic/echidna" rel="nofollow noreferrer">Echidna</a>.
But what are the purposes of symbolic execution tools like <a href="https://github.com/trailofbits/manticore" rel="nofollow noreferrer">manticore</a> and <a href="https://maat.re/" rel="nofollow noreferrer">maat</a>?
Fuzz testing still seems to execute code, so I'm not sure I understand the categorical difference between fuzzing and symbolic execution.

Symbolic Execution vs Fuzz Testing - What's the difference?

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云AI代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

功能1上新10个字符

功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符。

功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符。

功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符

功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符

功能4上新

文章&问答评论现已支持表情

全新交互，全新视觉，新增快捷键、悬浮工具栏、高亮块等功能并同时优化现有功能，全面提升创作效率和体验

社区富文本编辑器全新改版！诚邀体验～ 

精选全网热门MCP server，让你的AI更好用 🚀

💥开发者 MCP广场重磅上线！

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

在web3中，我们有许多模糊工具，如铸造毛羽不变试验和Trail 捷达纳。但是，像蝎尾兽和玛特这样的符号执行工具的目的是什么？模糊测试似乎仍在执行代码，所以我不确定我是否理解模糊和符号执行之间的绝对区别。

问符号执行与Fuzz测试-有什么区别？
EN

回答 1

Ethereum用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问符号执行与Fuzz测试-有什么区别？EN