State network fuzzing tutorial #255
Conversation
| Compound comp = Compound(0x4Ddc2D193948926D02f9B1fE9e1daa0718270ED5); | ||
| constructor() { | ||
| hevm.roll(16771449); // sets the correct block number |
There was a problem hiding this comment.
Does this mean that by writing hevm.roll(16771449);, you will fork the blockchain state from block 16771449? This behavior would then be different to the way foundry works. There an initial block number parameter is passed in and if you skip to a new block, it's all just simulated locally, but your state is still loaded from the initially set block height.
This difference is not necessarily bad, but it could break some tests that rely on relative time/block jumps, i.e. the contract requires 10 blocks to have passed and you write hevm.roll(block.number + 10), but now the actual state has changed and your assumptions on the current state might be different.
There was a problem hiding this comment.
Echidna only sets a particular state as the initial one, but after that, everything else can be changed. I will clarify this in the article.
There was a problem hiding this comment.
I added a note about this.
|
|
||
| ## Example | ||
|
|
||
| One of the most anticipated features of Echidna 2.1.0 is the state network forking. This means that Echidna can run starting with an existing blockchain state provided by an external RPC service (Infura, Alchemy, local node, etc). |
There was a problem hiding this comment.
I think we should reword this, and remove the "most anticipated features" part
There was a problem hiding this comment.
We should also have the introduction in an introduction section, and not in the example
There was a problem hiding this comment.
I reworked this as introduction and example, please take a look
| ``` | ||
|
|
||
| While the source code for the [cETH contract is available](https://etherscan.io/address/0x4ddc2d193948926d02f9b1fe9e1daa0718270ed5#code), their source maps are NOT. | ||
| In order to generate the coverage report for a fetched contract, **both** source code and source mapping should be available. In that case, there will be a new directory inside the corpus directory to show coverage for each contract that was fetched. In any case, the coverage report will be always available for the user-provided contracts, such as this one: |
There was a problem hiding this comment.
mhh, not related to this article, but why not relying on crytic-compile for this?
There was a problem hiding this comment.
AFAIK, crytic-compile cannot produce the same bytecode as the one deployed, so it is unclear if that will be useful, but @arcz has the detail.
|
This PR is ready for another round of review or to merge it. As usual, the failed test are unrelated link. @montyly |
No description provided.