Add /roadmap/dencun/ page
#12413
Merged
Add /roadmap/dencun/ page
#12413
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
github-actions
bot
added
content 🖋️
✅ Deploy Preview for ethereumorg ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
nhsz
reviewed
Mar 11, 2024
WalkthroughThe recent update introduces the Cancun-Deneb (Dencun) FAQ to the Ethereum network documentation, focusing on the Proto-Danksharding upgrade (EIP-4844) for enhancing scalability and decentralization while reducing costs and limiting chain growth. Changes
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 Configration File (
|
konopkja
reviewed
Mar 12, 2024
konopkja
reviewed
Mar 12, 2024
konopkja
reviewed
Mar 12, 2024
konopkja
reviewed
Mar 12, 2024
konopkja
reviewed
Mar 12, 2024
timbeiko
reviewed
Mar 12, 2024
There was a problem hiding this comment.
Apologies for the delayed review! Aside from the minor comments, I think one thing that could be good (but more work...!) would be to look at the other EIPs in the fork and highlight their impact on developers. Most notably, we are deactivating SELFDESTRUCT! There are also a bunch of new opcodes (see EIPs 1153, 5656, etc.) going live, and so it may make sense to have a section dedicated to these features.
Should those new opcodes be added to the docs? https://ethereum.org/en/developers/docs/evm/opcodes/ |
minimalsm
reviewed
Mar 12, 2024
minimalsm
reviewed
Mar 12, 2024
minimalsm
reviewed
Mar 12, 2024
minimalsm
reviewed
Mar 12, 2024
Co-Authored-By: Tim Beiko <9390255+timbeiko@users.noreply.github.com> Co-Authored-By: Jakub <100724231+konopkja@users.noreply.github.com>
minimalsm
reviewed
Mar 12, 2024
minimalsm
reviewed
Mar 12, 2024
minimalsm
reviewed
Mar 12, 2024
minimalsm
reviewed
Mar 12, 2024
|
Thanks @timbeiko! Appreciate the review... updates have been applied. The economics section was explicitly asked from the community; given concerns have just removed that section. Can always iterate if needed. Marking ready for final review. |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Review Status
Actionable comments generated: 1
Configuration used: CodeRabbit UI
Files selected for processing (2)
- public/content/roadmap/dencun/index.md (1 hunks)
- src/lib/utils/md.ts (1 hunks)
Additional comments: 2
public/content/roadmap/dencun/index.md (1)
- 104-112: Given the feedback from the comments regarding the placement of video content, it might be beneficial to reconsider the positioning of the "More of a visual learner?" section. Although it follows an established pattern, moving the video content higher up on the page could enhance user engagement by providing immediate access to visual learning resources. This adjustment could cater to users who prefer video content without navigating through the entire page.
src/lib/utils/md.ts (1)
- 255-255: The addition of
"/roadmap/dencun"to thetemporalAllowedPagesarray in thegetPostSlugsfunction correctly integrates the new Dencun FAQ page into the website's content structure. This change follows the established pattern for adding new content pages and ensures that the new page is included in the list of compiled content pages. The implementation appears to be correct and consistent with the existing codebase.
Comment on lines
7
to
122
| - **No Action Required for Your ETH**: Following the Ethereum Dencun upgrade, there is no need to convert or upgrade your ETH. Your account balances will remain the same, and the ETH you currently hold will remain accessible in its existing form after the hard fork. | ||
| - **Beware of Scams!** <Emoji text="⚠️" /> **anyone instructing you to "upgrade" your ETH is trying to scam you.** There is nothing you need to do in relation to this upgrade. Your assets will stay completely unaffected. Remember, staying informed is the best defense against scams. | ||
|
|
||
| [More on recognizing and avoiding scams](/security/) | ||
|
|
||
| ## What problem is the Dencun network upgrade solving? {#network-impact} | ||
|
|
||
| Dencun primarily addresses **scalability** (handling more users and more transactions) with **affordable fees**, while **maintaining decentralization** of the network. | ||
|
|
||
| The Ethereum community has been taking a "rollup-centric" approach to its growth, which places layer 2 rollups as the primary means to safely support more users. | ||
|
|
||
| Rollup networks handle the _processing_ (or "execution") of transactions separate from Mainnet and then publish a cryptographic proof and/or compressed transaction data of the results back to Mainnet for record keeping. Storing these proofs carries an expense (in the form of [gas](/glossary/#gas)), which, before Proto-Danksharding, had to be stored permanently by all network node operators, making it an expensive task. | ||
|
|
||
| The introduction of Proto-Danksharding in the Dencun upgrade adds cheaper data storage for these proofs by only requiring node operators to store this data for about 18 days, after which data can be safely removed to prevent expansion of hardware requirements. Because rollups typically have a withdrawal period of 7 days, their security model is unchanged as long as blobs are available on L1 for this duration. The 18-day pruning window provides a significant buffer for this period. | ||
|
|
||
| [More on scaling Ethereum](/roadmap/scaling/) | ||
|
|
||
| ## How is old blob data accessed? {#historical-access} | ||
|
|
||
| While regular Ethereum nodes will always hold the _current state_ of the network, historical blob data can be discarded approximately 18 days after its introduction. Before discarding this data, Ethereum ensures that it has been made available to all network participants, allowing time for: | ||
|
|
||
| - Interested parties to download and store the data. | ||
| - Completion of all rollup challenge periods. | ||
| - Finalization of the rollup transactions. | ||
|
|
||
| _Historical_ blob data may be desired for a variety of reasons and can be stored and accessed using several decentralized protocols: | ||
|
|
||
| - **Third-party indexing protocols**, such as The Graph, store this data through a decentralized network of node operators incentivized by crypto-economic mechanisms. | ||
| - **BitTorrent** is a decentralized protocol where volunteers can hold and distribute this data to others. | ||
| - **[Ethereum portal network](/developers/docs/networking-layer/portal-network/)** aims to provide access to all Ethereum data through a decentralized network of node operators by distributing data among participants akin to BitTorrent. | ||
| - **Individual users** are always free to store their own copies of any data they wish for historical reference. | ||
| - **Rollup providers** are incentivized to store this data to enhance the user experience of their rollup. | ||
| - **Block explorers** typically run archival nodes that index and store all this information for easy historical reference, accessible to users via a web interface. | ||
|
|
||
| It is important to note that recovering historical state operates on a **1-of-N trust model**. This means that you only need data from _a single trustworthy source_ to verify its correctness using the current state of the network. | ||
|
|
||
| ## How does this upgrade contribute to the broader Ethereum roadmap? {#roadmap-impact} | ||
|
|
||
| Proto-Danksharding sets the stage for the full implementation of [Danksharding](/roadmap/danksharding/). Danksharding is designed to distribute the storage of rollup data across node operators, so each operator only needs to handle a small part of the total data. This distribution will increase the number of data blobs per block, which is essential for scaling Ethereum to handle more users and transactions. | ||
|
|
||
| This scalability is crucial to [supporting billions of users on Ethereum](/roadmap/scaling/) with affordable fees and more advanced applications, while maintaining a decentralized network. Without these changes, the hardware demands for node operators would escalate, leading to the need for increasingly expensive equipment. This could price out smaller operators, resulting in a concentration of network control among a few large operators, which would go against the principle of decentralization. | ||
|
|
||
| ## Does this upgrade affect all Ethereum consensus and validator clients? {#client-impact} | ||
|
|
||
| Yes, Proto-Danksharding (EIP-4844) requires updates to both execution clients and consensus clients. All main Ethereum clients have released versions supporting the upgrade. To maintain synchronization with the Ethereum network post-upgrade, node operators must ensure they are running a supported client version. Note that the information about client releases is time-sensitive, and users should refer to the latest updates for the most current details. [See details on supported client releases](https://blog.ethereum.org/2024/02/27/dencun-mainnet-announcement#client-releases). | ||
|
|
||
| The consensus clients handle the _Validator_ software, which has all been updated to accommodate the upgrade. | ||
|
|
||
| ## How does Cancun-Deneb (Dencun) affect Goerli or other Ethereum testnets? {#testnet-impact} | ||
|
|
||
| - Devnets, Goerli, Sepolia and Holesky have all undergone the Dencun upgrade and have Proto-Danksharding fully functioning | ||
| - Rollup developers can use these networks for EIP-4844 testing | ||
| - Most users will be completely unaffected by this change to each testnet | ||
|
|
||
| ## Will all transactions on L2s now use temporary blob space, or will you be able to choose? {#calldata-vs-blobs} | ||
|
|
||
| ## Will all transactions on L2s now use temporary blob space, or will you be able to choose? {#calldata-vs-blobs} | ||
|
|
||
| Rollup transactions on Layer 2 (L2) of Ethereum have the option of using two types of data storage: temporary blob space or permanent smart contract calldata. Blob space is an economical choice, providing temporary storage at a lower cost. It guarantees data availability for all necessary challenge periods. On the other hand, smart contract calldata offers permanent storage but is more expensive. | ||
|
|
||
| The decision between using blob space or calldata is primarily made by rollup providers. They base this decision on the current demand for blob space. If blob space is in high demand, rollups may opt for calldata to ensure the data is posted in a timely manner. | ||
|
|
||
| While it's theoretically possible for users to choose their preferred storage type, rollup providers typically manage this choice. Offering this option to users would add complexity, particularly in cost-effective bundling transactions. For specific details on this choice, users should refer to the documentation provided by individual rollup providers. | ||
|
|
||
| ## Will 4844 reduce L1 gas? {#l1-fee-impact} | ||
|
|
||
| Not significantly. A new gas market is introduced exclusively for blob space, for use by rollup providers. _Although fees on L1 may be reduced by off-loading rollup data to blobs, this upgrade primarily focuses on the reduction of L2 fees. Reduction of fees on L1 (Mainnet) may occur as a second-order effect to a lesser extent._ | ||
|
|
||
| - L1 gas reduction will be proportional to adoption/usage of blob data by rollup providers | ||
| - L1 gas is likely to remain competitive from non-rollup related activity | ||
| - Rollups that adopt the use of blob space will demand less L1 gas, helping push L1 gas fees downward in the near-term | ||
| - Blob space is still limited, so if blobs within a block are saturated/full, then rollups may be required to post their data as permanent data in the meantime, which would drive L1 and L2 gas prices up | ||
|
|
||
| ## Will this reduce fees on other EVM layer 1 blockchains? {#alt-l1-fee-impact} | ||
|
|
||
| No. The benefits of Proto-Danksharding are specific to Ethereum layer 2 rollups that store their proofs on layer 1 (Mainnet). | ||
|
|
||
| Simply being compatible with the Ethereum Virtual Machine (EVM) does not mean that a network will see any benefit from this upgrade. Networks that operate independently of Ethereum (whether EVM compatible or not) do not store their data on Ethereum and will not see any benefit from this upgrade. | ||
|
|
||
| [More about layer 2 rollups](/layer-2/) | ||
|
|
||
| ## More of a visual learner? {#visual-learner} | ||
|
|
||
| <YouTube id="HT9PHWloIiU" /> | ||
|
|
||
| _Unlocking Ethereum's Scaling, EIP-4844 — Finematics _ | ||
|
|
||
| <YouTube id="dFjyUY3e53Q" /> | ||
|
|
||
| _Blobspace 101 with Domothy — Bankless_ | ||
|
|
||
| ## Further reading {#further-reading} | ||
|
|
||
| - [EIP4844.com](https://www.eip4844.com/) | ||
| - [EIP-4844: Shard blob transactions (Proto-Danksharding)](https://eips.ethereum.org/EIPS/eip-4844) | ||
| - [Dencun Mainnet Announcement](https://blog.ethereum.org/2024/02/27/dencun-mainnet-announcement) - _Ethereum Foundation blog_ | ||
| - [The Hitchhiker's Guide to Ethereum: Proto-Danksharding](https://members.delphidigital.io/reports/the-hitchhikers-guide-to-ethereum/#proto-danksharding-eip-4844) - _Jon Charbonneau_ | ||
| - [Proto-Danksharding FAQ](https://notes.ethereum.org/@vbuterin/proto_danksharding_faq) - _Vitalik Buterin_ | ||
| - [An In-depth Explanation of EIP-4844: The Core of the Cancun Upgrade](https://medium.com/@ebunker.io/an-in-depth-explanation-of-eip-4844-the-core-of-the-cancun-upgrade-de7b13761d2c) - _Ebunker_ | ||
| - [AllCoreDevs Update 016](https://tim.mirror.xyz/HzH5MpK1dnw7qhBSmzCfdCIxpwpD6DpwlfxtaAwEFro) - _Tim Beiko_ |
There was a problem hiding this comment.
The content provides a comprehensive overview of the Cancun-Deneb (Dencun) network upgrade, covering key aspects such as Proto-Danksharding, the impact on rollups, and the broader Ethereum roadmap. However, based on the PR objectives and comments, it seems there might be additional Ethereum Improvement Proposals (EIPs) related to the Dencun fork that could significantly impact developers, such as the deactivation of the SELFDESTRUCT feature and the introduction of new opcodes. Consider expanding the content to include information about these EIPs to ensure developers are well-informed about all aspects of the Dencun upgrade.
There was a problem hiding this comment.
Review Status
Actionable comments generated: 1
Configuration used: CodeRabbit UI
Files selected for processing (1)
- public/content/roadmap/dencun/index.md (1 hunks)
Additional comments: 1
public/content/roadmap/dencun/index.md (1)
- 1-5: The metadata section at the beginning of the file correctly specifies the title, description, and language. However, ensure that the
langfield's value is appropriate and consistent with the rest of the site's content structure.
Comment on lines
7
to
120
| ## How can ETH be converted after the hard fork? {#scam-alert} | ||
|
|
||
| - **No Action Required for Your ETH**: Following the Ethereum Dencun upgrade, there is no need to convert or upgrade your ETH. Your account balances will remain the same, and the ETH you currently hold will remain accessible in its existing form after the hard fork. | ||
| - **Beware of Scams!** <Emoji text="⚠️" /> **anyone instructing you to "upgrade" your ETH is trying to scam you.** There is nothing you need to do in relation to this upgrade. Your assets will stay completely unaffected. Remember, staying informed is the best defense against scams. | ||
|
|
||
| [More on recognizing and avoiding scams](/security/) | ||
|
|
||
| ## What problem is the Dencun network upgrade solving? {#network-impact} | ||
|
|
||
| Dencun primarily addresses **scalability** (handling more users and more transactions) with **affordable fees**, while **maintaining decentralization** of the network. | ||
|
|
||
| The Ethereum community has been taking a "rollup-centric" approach to its growth, which places layer 2 rollups as the primary means to safely support more users. | ||
|
|
||
| Rollup networks handle the _processing_ (or "execution") of transactions separate from Mainnet and then publish a cryptographic proof and/or compressed transaction data of the results back to Mainnet for record keeping. Storing these proofs carries an expense (in the form of [gas](/glossary/#gas)), which, before Proto-Danksharding, had to be stored permanently by all network node operators, making it an expensive task. | ||
|
|
||
| The introduction of Proto-Danksharding in the Dencun upgrade adds cheaper data storage for these proofs by only requiring node operators to store this data for about 18 days, after which data can be safely removed to prevent expansion of hardware requirements. Because rollups typically have a withdrawal period of 7 days, their security model is unchanged as long as blobs are available on L1 for this duration. The 18-day pruning window provides a significant buffer for this period. | ||
|
|
||
| [More on scaling Ethereum](/roadmap/scaling/) | ||
|
|
||
| ## How is old blob data accessed? {#historical-access} | ||
|
|
||
| While regular Ethereum nodes will always hold the _current state_ of the network, historical blob data can be discarded approximately 18 days after its introduction. Before discarding this data, Ethereum ensures that it has been made available to all network participants, allowing time for: | ||
|
|
||
| - Interested parties to download and store the data. | ||
| - Completion of all rollup challenge periods. | ||
| - Finalization of the rollup transactions. | ||
|
|
||
| _Historical_ blob data may be desired for a variety of reasons and can be stored and accessed using several decentralized protocols: | ||
|
|
||
| - **Third-party indexing protocols**, such as The Graph, store this data through a decentralized network of node operators incentivized by crypto-economic mechanisms. | ||
| - **BitTorrent** is a decentralized protocol where volunteers can hold and distribute this data to others. | ||
| - **[Ethereum portal network](/developers/docs/networking-layer/portal-network/)** aims to provide access to all Ethereum data through a decentralized network of node operators by distributing data among participants akin to BitTorrent. | ||
| - **Individual users** are always free to store their own copies of any data they wish for historical reference. | ||
| - **Rollup providers** are incentivized to store this data to enhance the user experience of their rollup. | ||
| - **Block explorers** typically run archival nodes that index and store all this information for easy historical reference, accessible to users via a web interface. | ||
|
|
||
| It is important to note that recovering historical state operates on a **1-of-N trust model**. This means that you only need data from _a single trustworthy source_ to verify its correctness using the current state of the network. | ||
|
|
||
| ## How does this upgrade contribute to the broader Ethereum roadmap? {#roadmap-impact} | ||
|
|
||
| Proto-Danksharding sets the stage for the full implementation of [Danksharding](/roadmap/danksharding/). Danksharding is designed to distribute the storage of rollup data across node operators, so each operator only needs to handle a small part of the total data. This distribution will increase the number of data blobs per block, which is essential for scaling Ethereum to handle more users and transactions. | ||
|
|
||
| This scalability is crucial to [supporting billions of users on Ethereum](/roadmap/scaling/) with affordable fees and more advanced applications, while maintaining a decentralized network. Without these changes, the hardware demands for node operators would escalate, leading to the need for increasingly expensive equipment. This could price out smaller operators, resulting in a concentration of network control among a few large operators, which would go against the principle of decentralization. | ||
|
|
||
| ## Does this upgrade affect all Ethereum consensus and validator clients? {#client-impact} | ||
|
|
||
| Yes, Proto-Danksharding (EIP-4844) requires updates to both execution clients and consensus clients. All main Ethereum clients have released versions supporting the upgrade. To maintain synchronization with the Ethereum network post-upgrade, node operators must ensure they are running a supported client version. Note that the information about client releases is time-sensitive, and users should refer to the latest updates for the most current details. [See details on supported client releases](https://blog.ethereum.org/2024/02/27/dencun-mainnet-announcement#client-releases). | ||
|
|
||
| The consensus clients handle the _Validator_ software, which has all been updated to accommodate the upgrade. | ||
|
|
||
| ## How does Cancun-Deneb (Dencun) affect Goerli or other Ethereum testnets? {#testnet-impact} | ||
|
|
||
| - Devnets, Goerli, Sepolia and Holesky have all undergone the Dencun upgrade and have Proto-Danksharding fully functioning | ||
| - Rollup developers can use these networks for EIP-4844 testing | ||
| - Most users will be completely unaffected by this change to each testnet | ||
|
|
||
| ## Will all transactions on L2s now use temporary blob space, or will you be able to choose? {#calldata-vs-blobs} | ||
|
|
||
| Rollup transactions on Layer 2 (L2) of Ethereum have the option of using two types of data storage: temporary blob space or permanent smart contract calldata. Blob space is an economical choice, providing temporary storage at a lower cost. It guarantees data availability for all necessary challenge periods. On the other hand, smart contract calldata offers permanent storage but is more expensive. | ||
|
|
||
| The decision between using blob space or calldata is primarily made by rollup providers. They base this decision on the current demand for blob space. If blob space is in high demand, rollups may opt for calldata to ensure the data is posted in a timely manner. | ||
|
|
||
| While it's theoretically possible for users to choose their preferred storage type, rollup providers typically manage this choice. Offering this option to users would add complexity, particularly in cost-effective bundling transactions. For specific details on this choice, users should refer to the documentation provided by individual rollup providers. | ||
|
|
||
| ## Will 4844 reduce L1 gas? {#l1-fee-impact} | ||
|
|
||
| Not significantly. A new gas market is introduced exclusively for blob space, for use by rollup providers. _Although fees on L1 may be reduced by off-loading rollup data to blobs, this upgrade primarily focuses on the reduction of L2 fees. Reduction of fees on L1 (Mainnet) may occur as a second-order effect to a lesser extent._ | ||
|
|
||
| - L1 gas reduction will be proportional to adoption/usage of blob data by rollup providers | ||
| - L1 gas is likely to remain competitive from non-rollup related activity | ||
| - Rollups that adopt the use of blob space will demand less L1 gas, helping push L1 gas fees downward in the near-term | ||
| - Blob space is still limited, so if blobs within a block are saturated/full, then rollups may be required to post their data as permanent data in the meantime, which would drive L1 and L2 gas prices up | ||
|
|
||
| ## Will this reduce fees on other EVM layer 1 blockchains? {#alt-l1-fee-impact} | ||
|
|
||
| No. The benefits of Proto-Danksharding are specific to Ethereum layer 2 rollups that store their proofs on layer 1 (Mainnet). | ||
|
|
||
| Simply being compatible with the Ethereum Virtual Machine (EVM) does not mean that a network will see any benefit from this upgrade. Networks that operate independently of Ethereum (whether EVM compatible or not) do not store their data on Ethereum and will not see any benefit from this upgrade. | ||
|
|
||
| [More about layer 2 rollups](/layer-2/) | ||
|
|
||
| ## More of a visual learner? {#visual-learner} | ||
|
|
||
| <YouTube id="HT9PHWloIiU" /> | ||
|
|
||
| _Unlocking Ethereum's Scaling, EIP-4844 — Finematics _ | ||
|
|
||
| <YouTube id="dFjyUY3e53Q" /> | ||
|
|
||
| _Blobspace 101 with Domothy — Bankless_ | ||
|
|
||
| ## Further reading {#further-reading} | ||
|
|
||
| - [EIP4844.com](https://www.eip4844.com/) | ||
| - [EIP-4844: Shard blob transactions (Proto-Danksharding)](https://eips.ethereum.org/EIPS/eip-4844) | ||
| - [Dencun Mainnet Announcement](https://blog.ethereum.org/2024/02/27/dencun-mainnet-announcement) - _Ethereum Foundation blog_ | ||
| - [The Hitchhiker's Guide to Ethereum: Proto-Danksharding](https://members.delphidigital.io/reports/the-hitchhikers-guide-to-ethereum/#proto-danksharding-eip-4844) - _Jon Charbonneau_ | ||
| - [Proto-Danksharding FAQ](https://notes.ethereum.org/@vbuterin/proto_danksharding_faq) - _Vitalik Buterin_ | ||
| - [An In-depth Explanation of EIP-4844: The Core of the Cancun Upgrade](https://medium.com/@ebunker.io/an-in-depth-explanation-of-eip-4844-the-core-of-the-cancun-upgrade-de7b13761d2c) - _Ebunker_ | ||
| - [AllCoreDevs Update 016](https://tim.mirror.xyz/HzH5MpK1dnw7qhBSmzCfdCIxpwpD6DpwlfxtaAwEFro) - _Tim Beiko_ |
There was a problem hiding this comment.
Overall, the content is well-structured, providing a comprehensive overview of the Dencun upgrade, its implications, and related concepts. However, consider the following suggestions to enhance clarity, accuracy, and user engagement:
-
Spelling and Grammar: Ensure all technical terms and names are spelled correctly throughout the document. This includes terms like "Proto-Danksharding," "Dencun," and "Ethereum." While the static analysis hints at possible spelling mistakes, these are likely false positives due to the technical nature of the content. However, it's crucial to maintain consistency in the spelling of these terms.
-
Video Placement and Headline (Lines 102-111): Based on the feedback from the PR comments, consider moving the video content closer to the top of the page. This adjustment could cater to visual learners early on and potentially increase engagement with the content. While the current pattern follows existing practices, evolving the content layout based on user feedback and behavior is beneficial.
-
Further Reading Section (Lines 112-120): The further reading section is well-curated, providing readers with additional resources for a deeper understanding of the Dencun upgrade and related topics. Ensure all external links are up-to-date and accessible to maintain the section's value.
-
Content Accuracy and Completeness: Given the feedback suggesting the inclusion of details about other EIPs involved in the Dencun fork, verify that the document comprehensively covers all significant aspects of the upgrade. If necessary, add information about the deactivation of SELFDESTRUCT and new opcodes introduced by EIPs 1153 and 5656, ensuring the content remains informative and up-to-date.
-
Avoiding Redundancy: In some sections, phrases like "a variety of reasons" (Line 48) and "specific details" (Line 83) could be simplified to make the content more concise. Consider revising these to enhance readability without losing meaning.
-
Economic Section Removal: Confirm that the removal of the economics section, as mentioned in the PR comments, aligns with the community's feedback and the document's objectives. Ensure the remaining content adequately addresses users' informational needs without the economics perspective.
Consider incorporating these suggestions to improve the document's clarity, engagement, and comprehensiveness.
Merged
There was a problem hiding this comment.
Review Status
Actionable comments generated: 0
Configuration used: CodeRabbit UI
Files selected for processing (1)
- public/content/roadmap/dencun/index.md (1 hunks)
Additional comments: 4
public/content/roadmap/dencun/index.md (4)
- 1-5: The metadata section at the top of the file is correctly formatted for a markdown document. However, the static analysis hint regarding the use of "en" seems to be a false positive, as "en" here correctly specifies the language of the document and is not a typo or grammatical error.
- 7-120: Throughout the document, there are several instances where the static analysis tool flagged potential spelling mistakes, particularly with terms specific to the Ethereum ecosystem, such as "Dencun," "Proto-Danksharding," "rollups," and names of testnets like "Goerli" and "Sepolia." These are not spelling errors but rather technical terms and names relevant to the content. Therefore, these flags can be safely ignored as false positives.
- 102-104: Regarding the placement of video content, there's a discussion in the comments about moving the video higher up on the page. While the current placement follows an established pattern, it's worth considering user feedback for future improvements. However, for consistency with the rest of the site, the current placement is acceptable. It might be beneficial to revisit this pattern in a broader context rather than making an isolated change here.
Consider evaluating the pattern of video placement across the site based on user feedback to enhance content accessibility and engagement.
- 119-119: The inclusion of external resources and further reading is a good practice, providing readers with additional information and perspectives. However, it's important to periodically review these links to ensure they remain relevant and accessible, as external content can change over time.
Verification successful
The executed script successfully verified that all the links in the further reading section are accessible, with no broken links found. However, it's still recommended to manually review the content for relevance and quality periodically, as the script does not assess these aspects.
Scripts Executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Check for broken links in the further reading section for url in https://www.eip4844.com/ https://eips.ethereum.org/EIPS/eip-4844 https://blog.ethereum.org/2024/02/27/dencun-mainnet-announcement https://members.delphidigital.io/reports/the-hitchhikers-guide-to-ethereum/#proto-danksharding-eip-4844 https://notes.ethereum.org/@vbuterin/proto_danksharding_faq https://medium.com/@ebunker.io/an-in-depth-explanation-of-eip-4844-the-core-of-the-cancun-upgrade-de7b13761d2c https://tim.mirror.xyz/HzH5MpK1dnw7qhBSmzCfdCIxpwpD6DpwlfxtaAwEFro; do if ! curl --output /dev/null --silent --head --fail "$url"; then echo "Broken link: $url" fi doneLength of output: 4209
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
Related Issue
Dencun updates
Preview link
Summary by CodeRabbit