forked from paradigmxyz/reth
-
Notifications
You must be signed in to change notification settings - Fork 5
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
Create MPT scroll-reth #85
Labels
enhancement
New feature or request
Comments
Outstanding work: We need to make the CLI reth/crates/scroll/cli/src/lib.rs Lines 103 to 154 in fdf74bb
|
closed by #107 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Describe the feature
We currently have a single node implementation for scroll that uses the BMPT state commitment. As we undergo our transition to using the native Ethereum MPT it would be of value to provide an MPT implementation so that we can leverage it for both comparison with l2geth (MPT) and for witness generation in for the stateless block verifier.
Implementation
Rename
ScrollNode
asScrollNodeBMPT
. Introduce a new nodeScrollNodeMPT
with the same configuration. On this node when implementingNodeTypes
we should specify theMerklePatriciaTrie
for the state commitment. Introduce an additional scroll binary for theMPT
node. Ensure that this node can not be compiled with thescroll
feature flag.References below:
reth/crates/scroll/node/src/lib.rs
Lines 38 to 79 in 133d9c0
reth/crates/scroll/node/src/types.rs
Lines 8 to 18 in 133d9c0
reth/crates/scroll/bin/src/main.rs
Lines 1 to 46 in 133d9c0
Distribution
We have two possibilities for the distribution of scroll reth.
Node client binary + state dump / import
We can distribute the node client and also provide a state dump. A user can then spin up the node and import the state dump using the
init-state
command. This should provide them with a node with a database that allows them to invoke desired RPC commands on it. Alternatively, the user can use theimport
command which allows them to import a set of rlp encoded blocks from a file. This should be confirmed and tested that this pattern works. This is a more technical option but allows consumers of reth to become more familiar with its operation and is more flexible as different users can import different blocks/states as they require.Hosted Node Client
We can deploy servers (EC2 instances or kube pods) to host the reth clients and expose the RPC for consumers. This is a simple approach for consumers and the clients are "managed" however the consumers will have less flexibility about what blocks are included in the chain.
Conclusion
It may be best to provide both solutions. We host nodes for both the mpt and bmpt implementations of reth synced to mainnet and we also distribute the node client and allow consumers to import state / create chains that satisfy their use case. We should discuss with SRE how we want to deploy these nodes, as dedicated EC2 instances or as containers on kubernetes.
Additional context
No response
The text was updated successfully, but these errors were encountered: