Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Enhancing Scroll: Path-Based State Schema Support for Optimized Performance #1100

Open
CRossel87a opened this issue Dec 13, 2024 · 0 comments

Comments

@CRossel87a
Copy link

Rationale
The new path-based schema introduced in Geth v1.13.0 represents a major evolution in Ethereum's state storage, offering significant advantages such as faster performance, effective pruning, and reduced disk usage. These enhancements align closely with Scroll's goals of scalability and efficiency. By integrating support for the path-based schema in Scroll's Geth fork, the platform could offer the following benefits:

Use-Cases:

Improved State Management: Enable efficient pruning to eliminate junk accumulation, making node operation more sustainable over time without requiring offline pruning or database resyncing.
Enhanced Synchronization: Utilize the new state storage model for faster and more reliable synchronization, particularly in full sync or catchup scenarios.

Future-Proofing: Align Scroll's Geth fork with upcoming standards, especially as Geth is expected to make the path-based schema the default in future versions (v1.14.x).

Implementation
To support the path-based schema in Scroll, the following steps could be considered:

Database Compatibility: Introduce a --state.scheme flag, allowing operators to choose between hash (current scheme) and path (new scheme). This ensures backward compatibility while enabling the use of the new schema.

Sync Mode Adjustments: Adapt Scroll's synchronization logic to handle the single-state trie constraint of the path-based model. Incorporate mechanisms such as dirty caching and reverse diffs to optimize block processing and reorgs.

Integrating this feature would demonstrate Scroll's commitment to leveraging cutting-edge developments in Ethereum infrastructure, ensuring that the platform remains competitive and developer-friendly. A pruned Scroll node currently requires 1.4TB of disk space, and a full archive node has passed 3 TB. Based on what I've seen this path based schema can do, I would not be surprised if Scroll chain-data dips below 300 GB.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant