Skip to content

chore: update notes to reflect prague default #1517

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Draft
wants to merge 1 commit into
base: master
Choose a base branch
from
Draft

chore: update notes to reflect prague default #1517

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
10 changes: 5 additions & 5 deletions src/forge/fork-testing.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -77,10 +77,8 @@ To understand what happens when a fork is selected, it is important to know how
Each fork is a standalone EVM, i.e. all forks use completely independent storage. The only exception is the state of the `msg.sender` and the test contract itself, which are persistent across fork swaps.
In other words all changes that are made while fork `A` is active (`selectFork(A)`) are only recorded in fork `A`'s storage and are not available if another fork is selected. However, changes recorded in the test contract itself (variables) are still available because the test contract is a _persistent_ account.


The `selectFork` cheatcode sets the _remote_ section with the fork's data source, however the _local_ memory remains persistent across fork swaps. This also means `selectFork` can be called at all times with any fork, to set the _remote_ data source. However, it is important to keep in mind the above rules for `read/write` access always apply, meaning _writes_ are persistent across fork swaps.


#### Examples

##### Create and Select Forks
Expand Down Expand Up @@ -223,18 +221,20 @@ contract SimpleStorageContract {
}
```


For more details and examples, see the [forking cheatcodes](../cheatcodes/forking.md) reference.

### EVM version

Proper configuration is needed to execute forked tests with chains using different EVM versions:

- if same EVM version applies for all forked chains used, then it can be globally configured in `foundry.toml` file

```toml
evm_version = "cancun"
evm_version = "prague"
```

- if different EVM versions are used, specific EVM test version can be set using inline configuration

```solidity
/// forge-config: default.evm_version = "shanghai"
```

10 changes: 6 additions & 4 deletions src/guides/deterministic-deployments-using-create2.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -22,16 +22,18 @@ For the best user experience it is recommended to avoid having different address

## Configuring your `foundry.toml`

In order to reliably deploy to deterministic addresses we will need to make sure our bytecode stays the same. To do so configure our `foundry.toml` as follows:
In order to reliably deploy to deterministic addresses we will need to make sure our bytecode stays the same. To do so configure our `foundry.toml` as follows :

```toml
[profile.default]
solc = "0.8.28"
evm_version = "cancun"
solc = "<SOLC_VERSION>"
evm_version = "<EVM_VERSION>"
bytecode_hash = "none"
cbor_metadata = false
```

Where `SOLC_VERSION` is a pinned version e.g. `0.8.28` and `EVM_VERSION` is a pinned EVM version e.g. `cancun`.

### Solc version

It is required to pin your `solc` (Solidity) version. It is generally recommended to use a recent version or, if preferred, the latest version.
Expand Down Expand Up @@ -111,7 +113,7 @@ The metadata file may look something like this:
"compilationTarget": {
"src/Counter.sol": "Counter"
},
"evmVersion": "cancun",
"evmVersion": "prague",
"libraries": {}
},
"sources": {
Expand Down
Loading