Ream EL integration - #196
Conversation
Add project proposal cc @Sahilgill24
taxmeifyoucan
left a comment
taxmeifyoucan
left a comment
There was a problem hiding this comment.
Thank you for the proposal! It looks really good, already seen the presentation so I can tell it's very feasible and well researched. Only had minor comments on the doc
| ``` | ||
|
|
||
| ### Public reactions | ||
|
|
There was a problem hiding this comment.
The motivation is pretty long and could be summarized in one paragraph instead of bunch of sections. You don't need to share individual tweets in each paragraph, maybe just link them in the paragraph on relevant words. Also it's a bit biased - the cl/el split enables client diversity. Embedding Reth into Ream produces a single language stack. And there are existing single binary solutions like Erigon with Caplin. Also for regular users tools like nicenode, stereum, dappnode etc.
|
|
||
| ### Strong success | ||
|
|
||
| - Interop with other lean clients supporting EL e.g. EthLambda to run long running devnets. |
There was a problem hiding this comment.
I think there should be some goal, at least an estimate, in overall performance gain, identifying how much it lifts the communication bottleneck
| - Pass the reth handle to the lean chain service. | ||
| - Integrate into methods like `handle_produce_block` and `on_block` to call the reth engine API. | ||
|
|
||
| ### Week 5: Proposal and Scope |
There was a problem hiding this comment.
I think you can skip this
There was a problem hiding this comment.
Do you please help me with I can change here? Is this what you mean - Remove last two points in the Week 0-4 and combine it into Week 0-5
There was a problem hiding this comment.
The proposal should focus on upcoming work, the prior research is encapsulated in the proposal itself and references below. I think you can skip this week 5 section (finalizing proposal doesnt have to be a roadmap item) and maybe just list finished points from previous weeks
|
|
||
| - Interop with other lean clients supporting EL e.g. EthLambda to run long running devnets. | ||
| - Benchmark report quantifying latency and delays in validator duties under defined load. | ||
| - Ream devnet supporting type-3 transactions. |
There was a problem hiding this comment.
You mention before type 3 tx are not supported by lean as of yet so it doesn't really depend on the project
There was a problem hiding this comment.
Another EPF project on Ream is working on PeerDAS node. And this project's benchmarks might be underwhelming without blobs (I expect 1x to 2x kind of improvement).
That's why if at the end we can leverage the work done by another EPF project i.e the PeerDAS node, then I think it can be less complicated to support this and then we can see benchmarks with mainnet like blocks (and the improvement can look over 100x but the right metric to look at should be the milliseconds saved which can help in the narrow slot time budget in lean chain).
There was a problem hiding this comment.
Makes sense, thanks! Maybe just elaborate on that in the proposal to make it more clear
Updated the roadmap and motivation sections, clarified the handling of Type-3 transactions, and integrated community feedback on the complexity of running Ethereum nodes post-Merge.
Added details about negligible delay for CL EL communication and interop with lean clients.
|
Thanks for the review!
Pls let us know if any more changes required |
Updated benchmarking and interop sections with revised delay metrics.
2 participants
Add project proposal
cc @Sahilgill24