Draft: Devnet support #171
Conversation
| let prune_until = self | ||
| .safe_epoch | ||
| .number | ||
| .saturating_sub(self.config.chain.seq_window_size); |
src/driver/mod.rs
Outdated
| fn get_l1_start_block(epoch_number: u64, channel_timeout: u64) -> u64 { | ||
| epoch_number | ||
| .checked_sub(channel_timeout) | ||
| .unwrap_or(epoch_number) |
There was a problem hiding this comment.
Is this the correct logic? Shouldn't we return an epoch value of 0 if it underflows? Similar to how you changed the prune function.
| @@ -43,7 +43,7 @@ pub struct ChainWatcher { | |||
| /// The L2 starting block | |||
| l2_start_block: u64, | |||
| /// Channel for receiving block updates for each new block | |||
| pub block_update_receiver: mpsc::Receiver<BlockUpdate>, | |||
| block_update_receiver: Option<mpsc::Receiver<BlockUpdate>>, | |||
There was a problem hiding this comment.
Nice change. This is a lot clearer than what we were doing before with leaving a useless channel there on initialization.
docs/devnet.md
Outdated
| @@ -0,0 +1,135 @@ | |||
| # Devnet Environment | |||
|
|
|||
| The devnet environment is constructed atop the OP stack devnet, also known as "bedrock". Essentially, this environment runs `op-geth` and `geth` node in development mode, excluding the PoS client, and without finality. This is why the `--devnet` flag is necessary. This flag allows for the acceptance of any block as finalized. Otherwise, the Magi would operate exclusively with finalized blocks. | |||
There was a problem hiding this comment.
This kind of implies that the devnet is called bedrock, rather than the op stack. Can we make this clearer?
There was a problem hiding this comment.
You are right, my eyes glazed over 👍 Fix 9f420c9
docs/devnet.md
Outdated
|
|
||
| For troubleshooting, please refer to the official [documentation](https://community.optimism.io/docs/developers/build/dev-node/#). | ||
|
|
||
| ### Configure OP-Geth for Magic |
docker/start-op-geth.sh
Outdated
| then | ||
| if [ $NETWORK = "devnet" ] | ||
| then | ||
| rm -rf $DATADIR |
There was a problem hiding this comment.
Why are we deleting the datadir if it is a devnet? Wouldn't this cause us to resync from genesis on every restart?
There was a problem hiding this comment.
The idea is that when you're working on the devnet and making changes to the code of the node, you'd likely prefer to start syncing from a clean environment. But i agree it might not always be necessary.
UPD: e671918
The function returns genesis zero block #0 of the L1 in case of overflow.
|
This is looking good. Is there anything else you wanted to add before moving it from draft? |
No, i think it's good. Moved to PR. |
Hey,
I've created a draft pull request because I'm not certain all changes from the PR will be accepted. We implemented support for the OP devnet while familiarizing ourselves with Magi. This PR contains fixes for several issues as well as the logic for the devnet.
The first part focuses on fixes that can be particularly useful, as they address potential math overflows concerning
state.purgeand the calculation of the l1 start block during the initiation of the node and during reorgs. There are also updates to the Docker setup to support custom genesis and rollup JSON configurations. I believe these overflows should be addressed; for instance, if someone were to launch their own local instance of optimism using dev PoS L1, this could be problematic.The second part pertains to the support of the OP devnet itself. We introduced a devnet parameter for the config because the default devnet employs PoW mining and doesn't finalize blocks. As such, the L1 watcher would interpret the latest block as finalized. This might be a relevant feature for Magi, and the PR includes updates to documentation and Docker concerning the devnet flag. I'd love to get your feedback on this.
Quick summary of PR:
state.purgeand corrected the calculation of l1 start blocks passed toChainWatcherduring initiation and reorgs.block_update_receiverlogic inChainWatcher. Previously, there was a default channel creation with a receiver which wasn't used at all and was subsequently replaced after startup.devnetflag, primarily utilized to determine the L1 finalized block. Ifdevnetmode is enabled, it will default to the latest block. This is a contentious point, and I'm eager to hear your thoughts. It also involves changes in Docker, documentation, entrypoints, and more.Let me know what you think. If necessary, I can create another pull request with only the selected changes/fixes.