Rollup tutorial #657
Rollup tutorial #657
Conversation
✅ Deploy Preview for docs-optimism ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
WalkthroughThe modifications in the documentation primarily involve renaming sections to clarify access to Layer 1 and emphasize the creation of new addresses. There is a systematic effort to update terminology and structure to enhance clarity and user understanding in the context of setting up a Layer 2 rollup. Changes
Possibly related issues
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (invoked as PR comments)
Additionally, you can add CodeRabbit Configuration File (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
| You will need access to the Layer 1 execution and consensus layers. | ||
| </Callout> | ||
|
|
||
| ## Layer 1 |
There was a problem hiding this comment.
Consider expanding on the benefits and drawbacks of using source code over Docker
The section "Layer 1" mentions the choice of using source code over Docker but only briefly touches on the benefits. It could be enhanced by detailing why this approach might be preferable, including potential drawbacks for a more balanced view.
| @@ -242,16 +209,14 @@ | |||
|
|
|||
| {<h3>Fill out the environment variable file</h3>} | |||
|
|
|||
| Open up the environment variable file and fill out the following variables: | |||
| Open up the layer 1 environment variable file and fill out the following variables: | |||
There was a problem hiding this comment.
Review and possibly expand the description of L1_RPC_KIND
The table under "Fill Out Environment Variables" includes L1_RPC_KIND with various options like alchemy, quicknode, etc. It would be beneficial to provide a brief description or link to documentation about what these options mean and how they affect the connection to the L1 node.
| ## Deploy the L1 contracts | ||
| ### Configure your network | ||
|
|
||
| todo: figure out a good configuration process for this release |
There was a problem hiding this comment.
Address the placeholder text regarding network configuration
The section "Configure your network" contains a placeholder text "todo: figure out a good configuration process for this release". This should be completed or updated with actual content before the tutorial is finalized to avoid confusion.
|
|
||
|
|
||
|
|
||
| ### Generate the L2 config files |
There was a problem hiding this comment.
Complete the section on generating L2 config files
The "Generate the L2 config files" section is marked with a todo to rewrite it. This section is crucial for setting up the L2 configuration and should be detailed and clear to avoid setup errors.
| @@ -588,6 +627,8 @@ | |||
| It's important that you've already initialized the geth node at this point as per the previous section. Failure to do this will cause startup issues between `op-geth` and `op-node`. | |||
| </Callout> | |||
|
|
|||
There was a problem hiding this comment.
Clarify the configuration verification step for op-geth
The section starting op-geth includes a todo to verify configuration. It's important to ensure that all configurations are verified and correctly documented to prevent operational issues.
| @@ -633,6 +674,8 @@ | |||
| cd ~/optimism/op-node | |||
| ``` | |||
|
|
|||
There was a problem hiding this comment.
Ensure configuration verification for op-node
Similar to op-geth, the op-node section includes a todo for verifying configuration. Completing this verification is essential for ensuring the stability and correctness of the node operations.
| @@ -698,6 +742,8 @@ | |||
| cd ~/optimism/op-batcher | |||
| ``` | |||
|
|
|||
There was a problem hiding this comment.
Verify configuration for op-batcher
The section to start op-batcher also mentions a need to verify configuration. This step is critical to ensure that transactions are batched and published to L1 correctly.
| @@ -744,6 +790,8 @@ | |||
|
|
|||
| {<h3>Run op-proposer</h3>} | |||
|
|
|||
There was a problem hiding this comment.
Complete configuration verification for op-proposer
The op-proposer section has a todo for verifying configuration. Since this component is responsible for proposing new state roots, its correct configuration is vital for the integrity of the L2 rollup.
|
|
||
| ## Build the Source Code | ||
| <Callout> | ||
| You will need access to the Layer 1 execution and consensus layers. |
There was a problem hiding this comment.
the consensus layer requirement is for OP Node posting blobs?
There was a problem hiding this comment.
Yes, I'm pretty sure the l1.beacon endpoint is a hard requirement. Although this testnet rollup will be calldata. At the end, there should be call outs for how to enable op stack features: snap sync, span batches, and how to switch to using blobs.
|
More context on the latest best practices: ethereum-optimism/optimism#10678 |
|
This tutorial... i think we're in a better state with the monorepo tooling to take a much better approach here. |
#627