Revision e9e27cce8a171ce033cd42abad598c27b07df555 authored by Valentin Chaboche on 13 September 2023, 10:43:35 UTC, committed by Marge Bot on 22 September 2023, 07:41:44 UTC
1 parent 262d346
YesEVM.md
# YesEVM
This document explains how you can run a proper manual upgrade/migration test starting from the **exact** state of the EVM rollup at the wanted level with the help of **Yes-node/wallet**.
## Preliminary steps
- Retrieve a full snapshot of the desired network and run a regular `octez-node` on it.
- Run a rollup node for the desired EVM rollup (with the correct preimages):
```
> octez-smart-rollup-node init operator config for <rollup-address> with operators <operator-alias> --data-dir ~/.evm-test/rollup-node
> octez-smart-rollup-node run observer for <rollup-address> with operators <operator-alias> --data-dir ~/.evm-test/rollup-node --rpc-port 8932
```
To ensure everything works properly, both the node and the rollup node will need to be on the same L1 level:
- Stop the node. Run it back with `[--connections 0]` to put it in a waiting mode. Get the L1 level with the `octez-client` and then stop the node. The rollup won't receive new blocks and wait at the same level, and can now be safely stopped.
- Create a snapshot of the node at the retrieved level.
> octez-node snapshot export --block <retrieved-level> --data-dir ~/evm-test/ghostnet-node
- Get a "snapshot" of the EVM rollup (basically all its data directory) and store it somewhere.
## Setup and use a yes-node/wallet
Fork the chain to make the tests in our deviated chain.
- Setup the yes-node/wallet on ghostnet:
```
# TODO: remove the following line. Should hopefully be merged to master soon, in the meantime:
> git checkout -B yes-evm
> git cherry-pick julien@yes-wallet-multi-network
> make
> ./scripts/patch-yes_node.sh
> cp octez-client octez-client-ok # octez-client compiled with the yes patches won't be able to actually inject transactions
> make octez-node octez-client
```
```
> octez-node config init --data-dir ~/.yes-node --synchronisation-threshold 0 --connections 0 --rpc-addr localhost:8732 --network <network>
```
```
> octez-node snapshot import <snapshot-file> --data-dir ~/.yes-node
```
```
Retrieve the list of bakers, here is an example for Ghostnet:
> curl https://api.ghostnet.tzkt.io/v1/delegates\?limit\=5000 | jq 'map(select ((.alias?) and .active) |{ "alias" : .alias, "address" : .address , "publicKey" : .publicKey})' > aliases.json
```
```
> dune exec devtools/yes_wallet/yes_wallet.exe -- create from context ~/.yes-node in ~/.yes-wallet --active-bakers-only --aliases aliases.json --network <network-name>
```
```
> octez-node run --data-dir ~/.yes-node
```
To push the chain forward:
```
> octez-client -d ~/.yes-wallet bake for --minimal-timestamp
```
Run a new EVM rollup node with the exported "snapshot" of the EVM rollup. Don't use the binary compiled with the __yes__ patches, as they will break the signature and the batcher of the rollup node won't be able to send operations.
Once this is done this network acts as a sandbox with the same values as the initial network you used. This means you can safely test whatever you want from your forked chain/EVM rollup (injecting transactions, applying upgrades to check they don't break the rollup, etc) while benefit from the tooling (indexers, wallets, etc).
![swh spinner](/static/img/swh-spinner.gif)
Computing file changes ...