Nonce does not increment with transactions

[Schereo]

One of the solution assertions is that the player has not done more than 1 transaction. Somehow the player's nonce is always 0 despite having executed some transactions. For example I've executed uniswapV1Exchange.tokenToEthSwapInput() in the test function test_puppet() but vm.getNonce(player) still results in 0.

[tinchoabbate]

Hi @Schereo, thanks for reporting! That's strange. I haven't run into this. Which forge version are you using?

[Schereo]

I'm using forge version 0.2.0

[tinchoabbate]

Ok, could you run forge --version and share the output here? Just to know which exact version within 0.2.0.
In my case, I've tested and solved Damn Vulnerable DeFi with the version specified in the .devcontainer/Dockerfile.

[Schereo]

This is the exact version I'm using: forge 0.2.0 (ea2eff9 2024-05-28T00:17:33.396420000Z)

[KarthikeyaGundumogula]

same with Truster also, the player address Nonce always returns zero, i console loged the msg.sender in the test_truster function its showing the default sender not the actual player.

[tinchoabbate]

Thanks for reporting! Can you share which forge version you're using by running forge --version?

[BBongRu]

The same here.

forge 0.2.0 (0116be1 2024-07-09T00:18:45.429480000Z)

I actually run the same exploit within the given DevContainer and got the same result as well unfortunately. The forge version inside the container is forge 0.2.0 (cafc260 2024-05-02T00:19:43.928046340Z)

I'm personally wondering why the transaction number assertion is required there.

[tinchoabbate]

Thanks for sharing. Strange that's also happening in the devcontainer - I've got solutions working nicely with the devcontainer. I thought the problem would only happen with newer versions of forge. I'll try to debug what's going on in the next days. If any of you happens to find the problem, feel free to report here as well!

why the transaction number assertion is required there

The idea is to limit the number of transactions the player can execute. Not only because that usually leads to more interesting solutions, but most importantly because in real life executing a rescue in a single transaction could be the only option.

[letonchanh]

The same problem happens in Shards. When the player deploys a smart contract, his nonce increases to 1, but he can also execute some transactions outside the smart contract without increasing the nonce.

[Jayanring]

Same issue with nonce, but prank only changes msg.sender inside contract call.

[EthanOK]

@tinchoabbate The same problem happens in NaiveReceiverChallenge. After passing the challenge, I output the log and the result of vm.getNonce(player) is zero. Is it a problem with my forge version?

> forge --version                                       
forge 0.2.0 (0116be1 2024-07-09T00:18:45.429480000Z)

[tinchoabbate]

Thanks all for reporting! Not sure what's going on. I tested it with the forge version specified in the devcontainer and worked. Not sure if this is a bug in newer versions of forge or sth I'm doing wrong to test for this condition. I'll have to debug deeper.
Will update you all here once I have a better idea of what's happening.

[tinchoabbate]

Hey everyone, there's already an issue opened in Foundry about this: foundry-rs/foundry#8811

[CanonicalJP]

The workaround proposed by Foundry is to use the --isolated option to make each tx be executed in a separate EVM context. It looks like that option was not working properly either, solved in foundry-rs/foundry#8878

On the other hand, I created #77 so that the option is included in the Usage section of the README

[CanonicalJP]

Now that I came back to Puppet after this, I'm just wondering if it can actually be resolved in a single transaction...