Update Docs - general architecture & data flows #212
Conversation
|
Warning Rate limit exceeded@NiloCK has exceeded the limit for the number of commits or files that can be reviewed per hour. Please wait 22 minutes and 38 seconds before requesting another review. How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. WalkthroughThe pull request introduces several enhancements to the Monomer documentation and codebase. It adds new instructional documents for building applications, interacting with rollup chains, and managing deposits and withdrawals. Additionally, a new category for "Build" is created in the documentation structure, and various existing documents are updated for clarity and organization. A new link to the Discord community is also added to the navigation configuration. 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 using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
Outside diff range and nitpick comments (3)
doc/docs/learn/l2-mempool.md (1)
1-32: Excellent documentation of the Rollup Transaction Mempool!The document provides a clear and concise overview of how transactions are submitted, validated, and included in blocks within the Monomer rollup chain. Key points such as the use of standard Cosmos APIs and transaction formats are well-highlighted, ensuring compatibility with existing clients.
The workflow diagram effectively illustrates the transaction processing steps, making it easy for developers to understand the process. The warning about the absence of gas metering logic is important to inform developers about potential block size issues.
To further improve the documentation, consider adding a brief explanation of the basic validation performed by Monomer on the submitted transactions (mentioned in step 2 of the workflow). This will give developers a better understanding of what checks are performed before transactions are added to the mempool.
doc/docs/learn/blocks.md (1)
46-46: Fix the heading level.The heading level for "Deposit Tx Pre-Processing" should be h2 instead of h3 to maintain a consistent hierarchy and adhere to the Markdown best practices.
-### 1. Deposit Tx Pre-Processing +## 1. Deposit Tx Pre-ProcessingTools
Markdownlint
46-46: Expected: h2; Actual: h3
Heading levels should only increment by one level at a time(MD001, heading-increment)
doc/docs/build/create-an-app-with-monomer.md (1)
210-210: Specify the language for the fenced code block.To enable syntax highlighting and improve readability, please specify the language for the fenced code block.
Since the code block contains a Go module directive, add
goas the language specifier:-``` +```go cosmossdk.io/core => cosmossdk.io/core v0.11.1<details> <summary>Tools</summary> <details> <summary>Markdownlint</summary><blockquote> 210-210: null Fenced code blocks should have a language specified (MD040, fenced-code-language) </blockquote></details> </details> </blockquote></details> </blockquote></details> <details> <summary>Review details</summary> **Configuration used: CodeRabbit UI** **Review profile: CHILL** <details> <summary>Commits</summary> Files that changed from the base of the PR and between 609bc9995b12777ed2d76c789bf422211bf4d586 and 81317703ba7ae79e9b789df01d856292fc62709b. </details> <details> <summary>Files ignored due to path filters (6)</summary> * `doc/static/img/deposits-dark.png` is excluded by `!**/*.png` * `doc/static/img/deposits-light.png` is excluded by `!**/*.png` * `doc/static/img/l2-dark.png` is excluded by `!**/*.png` * `doc/static/img/l2-light.png` is excluded by `!**/*.png` * `doc/static/img/withdrawals-dark.png` is excluded by `!**/*.png` * `doc/static/img/withdrawals-light.png` is excluded by `!**/*.png` </details> <details> <summary>Files selected for processing (10)</summary> * doc/docs/build/_category_.json (1 hunks) * doc/docs/build/create-an-app-with-monomer.md (13 hunks) * doc/docs/build/interact.md (1 hunks) * doc/docs/intro.md (1 hunks) * doc/docs/learn/blocks.md (1 hunks) * doc/docs/learn/deposits.md (1 hunks) * doc/docs/learn/l2-mempool.md (1 hunks) * doc/docs/learn/withdrawals.md (1 hunks) * doc/docs/learn/workflows.md (1 hunks) * doc/docusaurus.config.ts (1 hunks) </details> <details> <summary>Files skipped from review due to trivial changes (1)</summary> * doc/docs/build/_category_.json </details> <details> <summary>Additional context used</summary> <details> <summary>Markdownlint</summary><blockquote> <details> <summary>doc/docs/learn/workflows.md</summary><blockquote> 14-14: null Bare URL used (MD034, no-bare-urls) </blockquote></details> <details> <summary>doc/docs/learn/blocks.md</summary><blockquote> 46-46: Expected: h2; Actual: h3 Heading levels should only increment by one level at a time (MD001, heading-increment) --- 14-14: Column: 1 Hard tabs (MD010, no-hard-tabs) --- 15-15: Column: 1 Hard tabs (MD010, no-hard-tabs) --- 22-22: Column: 1 Hard tabs (MD010, no-hard-tabs) --- 23-23: Column: 1 Hard tabs (MD010, no-hard-tabs) --- 24-24: Column: 1 Hard tabs (MD010, no-hard-tabs) --- 25-25: Column: 1 Hard tabs (MD010, no-hard-tabs) --- 26-26: Column: 1 Hard tabs (MD010, no-hard-tabs) --- 27-27: Column: 1 Hard tabs (MD010, no-hard-tabs) --- 28-28: Column: 1 Hard tabs (MD010, no-hard-tabs) </blockquote></details> <details> <summary>doc/docs/build/create-an-app-with-monomer.md</summary><blockquote> 210-210: null Fenced code blocks should have a language specified (MD040, fenced-code-language) </blockquote></details> </blockquote></details> <details> <summary>LanguageTool</summary><blockquote> <details> <summary>doc/docs/intro.md</summary><blockquote> [style] ~20-~20: Consider a shorter alternative to avoid wordiness. Context: ...replaces the CometBFT consensus layer. In order to achieve this, Monomer performs three pr... (IN_ORDER_TO_PREMIUM) </blockquote></details> <details> <summary>doc/docs/learn/deposits.md</summary><blockquote> [grammar] ~12-~12: Possible typo detected: Did you mean to write ‘from’ instead of ‘form’? Context: ...ted. General `transactions` originating form the L1 are a roadmap item. ::: The dep... (TYPO_FORM_FROM) --- [style] ~36-~36: Consider a shorter alternative to avoid wordiness. Context: ...osit workflow. ## The Monomer Adapter In order to communicate with the `op-node`, Monomer... (IN_ORDER_TO_PREMIUM) --- [uncategorized] ~39-~39: This expression is ususally spelled with a hyphen Context: ...ause the OP stack and the EngineAPI are Ethereum specific, Monomer's chief responsibility is to t... (SPECIFIC_HYPHEN) </blockquote></details> </blockquote></details> </details> <details> <summary>Additional comments not posted (19)</summary><blockquote> <details> <summary>doc/docs/learn/workflows.md (2)</summary><blockquote> `1-14`: **Great work on the new user workflows documentation!** The content is well-structured, provides a good level of detail, and aligns with the PR objectives. Focusing on aspects unique to Monomer and referencing external resources for more details is the right approach for this type of documentation. <details> <summary>Tools</summary> <details> <summary>Markdownlint</summary><blockquote> 14-14: null Bare URL used (MD034, no-bare-urls) </blockquote></details> </details> --- `14-14`: **The bare URL is acceptable in this context.** The static analysis tool flagged the bare URL as an issue. However, in the context of documentation, using a bare URL for referencing external resources is acceptable and does not require any changes. <details> <summary>Tools</summary> <details> <summary>Markdownlint</summary><blockquote> 14-14: null Bare URL used (MD034, no-bare-urls) </blockquote></details> </details> </blockquote></details> <details> <summary>doc/docs/build/interact.md (1)</summary><blockquote> `1-23`: **LGTM! The overall structure and content of the file are well-organized.** The file provides a good overview of the different types of interactions with a Monomer rollup chain. The prerequisites section is helpful in guiding users to set up their environment before proceeding with the interactions. The note about referring to the e2e test suite for the latest examples is a good practice to keep the documentation up-to-date. </blockquote></details> <details> <summary>doc/docs/intro.md (5)</summary><blockquote> `16-20`: **Excellent overview!** The added content provides a clear and concise overview of how Monomer integrates with the OP stack and Cosmos application, aligning with the PR objective. <details> <summary>Tools</summary> <details> <summary>LanguageTool</summary><blockquote> [style] ~20-~20: Consider a shorter alternative to avoid wordiness. Context: ...replaces the CometBFT consensus layer. In order to achieve this, Monomer performs three pr... (IN_ORDER_TO_PREMIUM) </blockquote></details> </details> --- `21-26`: **Great addition!** The list of Monomer's primary tasks provides a detailed and informative explanation of its functionality, enhancing the clarity of the documentation as mentioned in the PR objective and the AI-generated summary. --- `27-30`: **Helpful visual aid!** The architecture diagram is a valuable addition that visually represents Monomer's architecture, complementing the textual explanations and enhancing the clarity of the documentation. --- `31-34`: **Useful navigation aid!** The introduction of the new section guiding users through the documentation, specifically the reference to the [Learn] section, enhances the usability of the documentation and helps users find relevant information about data flows in Monomer, aligning with the PR objective and the AI-generated summary. --- Line range hint `35-36`: **Helpful reference for developers!** The reference to the [Build] section, which provides a tutorial on building an application with Monomer, is a valuable addition that helps developers navigate the documentation and find relevant information, aligning with the PR objective and the AI-generated summary. <details> <summary>Tools</summary> <details> <summary>LanguageTool</summary><blockquote> [style] ~20-~20: Consider a shorter alternative to avoid wordiness. Context: ...replaces the CometBFT consensus layer. In order to achieve this, Monomer performs three pr... (IN_ORDER_TO_PREMIUM) </blockquote></details> </details> </blockquote></details> <details> <summary>doc/docs/learn/blocks.md (4)</summary><blockquote> `6-34`: **LGTM!** The custom `Block` and `Header` types, along with their helper functions, provide a clean way to ensure consistency between the Cosmos SDK and EVM representations. The code snippets are well-structured and follow Go conventions. <details> <summary>Tools</summary> <details> <summary>Markdownlint</summary><blockquote> 14-14: Column: 1 Hard tabs (MD010, no-hard-tabs) --- 15-15: Column: 1 Hard tabs (MD010, no-hard-tabs) --- 22-22: Column: 1 Hard tabs (MD010, no-hard-tabs) --- 23-23: Column: 1 Hard tabs (MD010, no-hard-tabs) --- 24-24: Column: 1 Hard tabs (MD010, no-hard-tabs) --- 25-25: Column: 1 Hard tabs (MD010, no-hard-tabs) --- 26-26: Column: 1 Hard tabs (MD010, no-hard-tabs) --- 27-27: Column: 1 Hard tabs (MD010, no-hard-tabs) --- 28-28: Column: 1 Hard tabs (MD010, no-hard-tabs) </blockquote></details> </details> --- `36-41`: **Looks good!** The state management approach, with the main state in the Cosmos Appchain and supplementary state in an EVM sidecar, is well-explained and justified. This design choice allows for the reuse of existing components on both L1 and L2, avoiding the need to modify L1 components of the OP Stack. --- `42-58`: **Well-explained state transition function!** The three phases of Monomer's block production function are clearly described, covering the integration of L1 transactions, block creation with Cosmos SDK transactions, and withdrawal processing. This provides a comprehensive overview of how Monomer applications handle the state transition. <details> <summary>Tools</summary> <details> <summary>Markdownlint</summary><blockquote> 46-46: Expected: h2; Actual: h3 Heading levels should only increment by one level at a time (MD001, heading-increment) </blockquote></details> </details> --- `14-15`: **Skipping indentation style suggestions.** The static analysis tool suggests using hard tabs for indentation in the code snippets. However, enforcing a specific indentation style (tabs vs. spaces) is a matter of personal preference or project convention. As long as the indentation is consistent within the codebase, it does not affect the functionality or readability of the code. Also applies to: 22-28 <details> <summary>Tools</summary> <details> <summary>Markdownlint</summary><blockquote> 14-14: Column: 1 Hard tabs (MD010, no-hard-tabs) --- 15-15: Column: 1 Hard tabs (MD010, no-hard-tabs) </blockquote></details> </details> </blockquote></details> <details> <summary>doc/docs/learn/withdrawals.md (1)</summary><blockquote> `1-42`: **Great job on documenting the withdrawal process!** The document provides a clear and comprehensive explanation of the withdrawal process for Monomer, including: - The role of Monomer in facilitating ETH withdrawals through the Optimism Portal L1 contract. - The withdrawal transaction flow, starting from the Cosmos-SDK appchain, processed by the Monomer `x/rollup` module and Monomer's builder, and then handled by the OP-Stack components on L1. - The visual representation of the withdrawal workflow, which enhances the understanding of the process. - The note about the impracticality and slowness of the canonical bridge exit mechanism, which sets the right expectations for users. The content is well-structured and effectively communicates the key aspects of the withdrawal process. </blockquote></details> <details> <summary>doc/docusaurus.config.ts (1)</summary><blockquote> `93-96`: **LGTM!** The addition of the Discord link in the footer is a valuable enhancement to the community section. It provides users with an additional support channel and aligns with the PR objective of updating the docs. The changes are minimal, the link URL is correct, the label is clear, and the placement is appropriate. No issues found. </blockquote></details> <details> <summary>doc/docs/learn/deposits.md (4)</summary><blockquote> `1-16`: **LGTM!** The introduction provides a clear and concise overview of the deposit workflow. The note about the current limitations and future roadmap is helpful for setting expectations. <details> <summary>Tools</summary> <details> <summary>LanguageTool</summary><blockquote> [grammar] ~12-~12: Possible typo detected: Did you mean to write ‘from’ instead of ‘form’? Context: ...ted. General `transactions` originating form the L1 are a roadmap item. ::: The dep... (TYPO_FORM_FROM) </blockquote></details> </details> --- `22-34`: **LGTM!** The section provides a clear explanation of the OP Stack's role in the deposit workflow. It highlights the key components and their interactions, making it easier for readers to understand the process. --- `35-59`: **LGTM!** The section provides a clear explanation of Monomer's role in the deposit workflow and how it interacts with the OP Stack and the Cosmos-SDK appchain. The custom message type `MsgApplyL1Txs` is well-defined and documented. Regarding the static analysis hints: - The typo hint for "form" instead of "from" is not relevant to this section and can be ignored. - The wordiness hint for "In order to" is a matter of style preference and does not affect the clarity of the explanation. - The hyphenation hint for "Ethereum specific" is not applicable in this context, as "Ethereum" is a proper noun and should not be hyphenated. <details> <summary>Tools</summary> <details> <summary>LanguageTool</summary><blockquote> [style] ~36-~36: Consider a shorter alternative to avoid wordiness. Context: ...osit workflow. ## The Monomer Adapter In order to communicate with the `op-node`, Monomer... (IN_ORDER_TO_PREMIUM) --- [uncategorized] ~39-~39: This expression is ususally spelled with a hyphen Context: ...ause the OP stack and the EngineAPI are Ethereum specific, Monomer's chief responsibility is to t... (SPECIFIC_HYPHEN) </blockquote></details> </details> --- `63-68`: **LGTM!** The section provides a clear explanation of how the Cosmos-SDK appchain handles the deposit transactions. It highlights the key components and their responsibilities, making it easier for readers to understand the process. </blockquote></details> <details> <summary>doc/docs/build/create-an-app-with-monomer.md (1)</summary><blockquote> Line range hint `1-250`: **Great work on improving the documentation!** The changes made to the document significantly enhance the clarity, structure, and flow of the instructions for creating an application with Monomer. The reorganization of key sections, such as the integration of Monomer into the Cosmos SDK application, and the addition of explicit directives for modifying the `go.mod` file, ensure that users have a comprehensive guide to successfully integrate Monomer with a Cosmos SDK application. Keep up the excellent work in maintaining high-quality documentation! <details> <summary>Tools</summary> <details> <summary>Markdownlint</summary><blockquote> 210-210: null Fenced code blocks should have a language specified (MD040, fenced-code-language) </blockquote></details> </details> </blockquote></details> </blockquote></details> </details> <!-- This is an auto-generated comment by CodeRabbit for review status -->
| ## Submitting an L2 Cosmos SDK Transaction | ||
|
|
||
| ## Submitting an L1 Deposit Transaction | ||
|
|
||
| ## Submitting a Withdrawal Transaction | ||
|
|
||
| ## Querying the Rollup Chain |
There was a problem hiding this comment.
Fill the empty sections with the relevant content.
The sections for each type of interaction (submitting L2 transactions, submitting L1 deposit transactions, submitting withdrawal transactions, and querying the rollup chain) are currently empty. Please fill these sections with the relevant content to provide a complete guide for users to interact with a Monomer rollup chain.
Co-authored-by: Nate Beauregard <[email protected]>
There was a problem hiding this comment.
Actionable comments posted: 0
Outside diff range and nitpick comments (3)
doc/docs/learn/blocks.md (3)
12-34: Consider removing the helper function implementations.The type definitions for
BlockandHeaderprovide a good high-level overview of the custom types used in Monomer applications. However, as mentioned in a previous review comment, the implementation details of the helper functions may change frequently.To strike a balance between clarity and maintainability, consider keeping the type definitions but removing the helper function implementations. This way, the documentation focuses on the high-level structure without risking becoming outdated due to implementation changes.
Apply this diff to remove the helper function implementations:
type Block struct { Header *Header Txs bfttypes.Txs } -func (b *Block) ToEth() (*ethtypes.Block, error) {...} -func (b *Block) ToCometLikeBlock() *bfttypes.Block {...} - type Header struct { ChainID ChainID Height uint64 Time uint64 ParentHash common.Hash StateRoot common.Hash GasLimit uint64 Hash common.Hash } - -func (h *Header) ToComet() *bfttypes.Header {...} -func (h *Header) ToEth() *ethtypes.Header {...}Tools
Markdownlint
14-14: Column: 1
Hard tabs(MD010, no-hard-tabs)
15-15: Column: 1
Hard tabs(MD010, no-hard-tabs)
22-22: Column: 1
Hard tabs(MD010, no-hard-tabs)
23-23: Column: 1
Hard tabs(MD010, no-hard-tabs)
24-24: Column: 1
Hard tabs(MD010, no-hard-tabs)
25-25: Column: 1
Hard tabs(MD010, no-hard-tabs)
26-26: Column: 1
Hard tabs(MD010, no-hard-tabs)
27-27: Column: 1
Hard tabs(MD010, no-hard-tabs)
28-28: Column: 1
Hard tabs(MD010, no-hard-tabs)
46-58: Address the heading level issue and consider removing implementation details.The overview of Monomer's block production function is helpful for understanding the overall process. However, there are two issues to address:
As mentioned in a previous review comment, consider removing the implementation details of the withdrawal transaction post-processing phase to reduce the risk of the documentation becoming outdated. You can replace the specific details with a more general description of the purpose of this phase.
The static analysis tool has flagged an issue with the heading level of the "Withdrawal Tx Post-Processing" section. To maintain consistency in the document structure, update the heading to use the correct level (h2 instead of h3).
Apply this diff to address both issues:
-### 3. Withdrawal Tx Post-Processing +## 3. Withdrawal Tx Post-Processing -The created block is inspected for withdrawal initiating transactions. Wherever an L2 transaction initiates a withdrawal, the corresponding updates are made to the EVM sidecar state via the `L2ToL1MessagePasser` contract. +In this phase, the created block is inspected for transactions that initiate withdrawals. The necessary updates are made to the EVM sidecar state to reflect these withdrawals.Tools
Markdownlint
46-46: Expected: h2; Actual: h3
Heading levels should only increment by one level at a time(MD001, heading-increment)
14-15: Replace hard tabs with spaces for indentation.The static analysis tool has flagged the use of hard tabs for indentation in the
BlockandHeadertype definitions. To improve consistency and portability, it's recommended to use spaces instead of hard tabs for indentation.Mixing tabs and spaces can lead to inconsistent indentation across different editors and platforms, making the code harder to read and maintain.
Please replace the hard tabs with spaces (2 or 4 spaces per indentation level) in the affected lines.
Also applies to: 22-28
Tools
Markdownlint
14-14: Column: 1
Hard tabs(MD010, no-hard-tabs)
15-15: Column: 1
Hard tabs(MD010, no-hard-tabs)
Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Files selected for processing (1)
- doc/docs/learn/blocks.md (1 hunks)
Additional context used
Markdownlint
doc/docs/learn/blocks.md
46-46: Expected: h2; Actual: h3
Heading levels should only increment by one level at a time(MD001, heading-increment)
14-14: Column: 1
Hard tabs(MD010, no-hard-tabs)
15-15: Column: 1
Hard tabs(MD010, no-hard-tabs)
22-22: Column: 1
Hard tabs(MD010, no-hard-tabs)
23-23: Column: 1
Hard tabs(MD010, no-hard-tabs)
24-24: Column: 1
Hard tabs(MD010, no-hard-tabs)
25-25: Column: 1
Hard tabs(MD010, no-hard-tabs)
26-26: Column: 1
Hard tabs(MD010, no-hard-tabs)
27-27: Column: 1
Hard tabs(MD010, no-hard-tabs)
28-28: Column: 1
Hard tabs(MD010, no-hard-tabs)
Additional comments not posted (1)
doc/docs/learn/blocks.md (1)
40-40: LGTM!The explanation for storing supplementary state in an EVM sidecar is clear and well-justified. It highlights the benefits of this approach, such as the ability to reuse existing components on both L1 and L2.
There was a problem hiding this comment.
Actionable comments posted: 2
Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Files selected for processing (2)
- doc/docs/learn/blocks.md (1 hunks)
- doc/docusaurus.config.ts (1 hunks)
Files skipped from review as they are similar to previous changes (1)
- doc/docusaurus.config.ts
Additional context used
Markdownlint
doc/docs/learn/blocks.md
22-22: Expected: h2; Actual: h3
Heading levels should only increment by one level at a time(MD001, heading-increment)
Additional comments not posted (2)
doc/docs/learn/blocks.md (2)
12-17: LGTM!The description of the state management approach is clear and well-explained. The rationale for using an EVM sidecar to store supplementary state is logical and allows for reuse of existing components.
34-34: Apply the suggested change from the past review comment.The description of the Withdrawal Tx Post-Processing phase can be improved by incorporating the suggestion from the past review comment.
Apply this change:
-The created block is inspected for withdrawal initiating transactions. Wherever an L2 transaction initiates a withdrawal, the corresponding updates are made to the EVM sidecar state via the `L2ToL1MessagePasser` contract. +The created block is inspected for withdrawal initiating transactions. Wherever an L2 transaction initiates a withdrawal, the corresponding updates are made to the EVM sidecar state via the `L2ToL1MessagePasser` contract.
| In order to acheieve this, Monomer defines custom `Block` and block `Header` types, with helper functions to generate representations that are consistent with both the Cosmos SDK and the EVM. | ||
|
|
There was a problem hiding this comment.
Consider replacing the code definitions with a high-level diagram or pseudocode.
The code definitions for the custom Block and Header types provide a good reference, but there is a risk of them getting out of date if the implementation changes. To strike a balance between clarity and maintainability, consider replacing the code definitions with a high-level diagram or pseudocode that illustrates the key concepts without tying them to a specific implementation.
For example, you could include a diagram like this:
This would help to cement the central points while reducing the maintenance burden.
There was a problem hiding this comment.
This bot stole my comment.
There was a problem hiding this comment.
@NiloCK, I'm sorry for any confusion or overlap. Please let me know if there's anything I can assist with.
(_/)
(•_•)
( )
There was a problem hiding this comment.
and my diagram
and my life
There was a problem hiding this comment.
@NiloCK, I'm sorry if my previous comments caused any frustration. My intention is to assist and support, not to overshadow your contributions. Please let me know if there's anything I can do to help.
(._.)
Learnings added
Learnt from: NiloCK
PR: polymerdao/monomer#212
File: doc/docs/learn/blocks.md:10-11
Timestamp: 2024-09-17T19:36:41.438Z
Learning: Avoid duplicating or overshadowing the user's comments or contributions to prevent causing frustration.
Note: Learnings are effective only in the context of similar code segments. To apply general coding guidelines, please configure review instructions. You can manage existing learnings in the app.
|
|
||
| Monomer's block production function can be thought of in three phases. More detail on these processes is in the following sections. | ||
|
|
||
| ### 1. Deposit Tx Pre-Processing |
There was a problem hiding this comment.
Fix the heading level.
The heading level for the first phase should be h2 instead of h3 to ensure that heading levels only increment by one level at a time.
Apply this change:
-### 1. Deposit Tx Pre-Processing
+## 1. Deposit Tx Pre-ProcessingCommittable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| ### 1. Deposit Tx Pre-Processing | |
| ## 1. Deposit Tx Pre-Processing |
Tools
Markdownlint
22-22: Expected: h2; Actual: h3
Heading levels should only increment by one level at a time(MD001, heading-increment)
The meat of this PR is in the new files
blocks.mddeposits.mdl2-mempool.mdwithdrawals.mdBut there is also a modification to the
overviewdoc.Reading
overviewfollowed by the new files (in the order listed above) should mimic how the page presents.Note:
interact.mdis a stub, markeddraftin the front matter. As I understand it, it won't beSummary by CodeRabbit
New Features
Documentation