Stateless mode (not yet working!!!) #1570
Closed
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.
Here's a branch containing the (unfinished!) code for stateless mode.
When I tried merging this in a week ago, it caused a performance regression (see #1558), so I reverted it. I'm pushing this branch so that someone else can (if you want to) pick up this code after I'm gone, but I'm not merging it into master (so I'm expecting the bits to rot if nobody does this soon).
(Note that the performance regression has nothing to do with running in stateless mode; this code causes a performance regression even when running normally.)
Regarding the cause of the performance regression, I'd suggest looking at memory.nim (where I had to switch to using a seq[Future[byte]] instead of a seq[byte]); there's probably some clever data structure you could use instead, but it'll need to involve Futures in some way in order to allow opcodes like MLOAD and MSTORE to play nicely with speculative execution. Note that I'm not saying that I know for sure that memory.nim is the cause of the problem, just that it's one place in the code where I did something obviously-hideously-inefficient, so that'd be a good first place to look.
The work on speculative execution isn't finished; see the comment on popInt in stack.nim, explaining how to finish propagating the async-stack-pop through the rest of the code base.
The work on stateless-execution in general isn't finished, but the idea is to pass in an Ethereum JSON-RPC URL for the stateless-data-source-url parameter on the command line. The intent is that this should make the Engine API (see handle_newPayload in engine_api.nim) run new blocks statelessly. But like I said, this work isn't finished; in the past (see #1311) I had blocks almost running correctly-but-very-slowly (it took five minutes to run a block, and often ran into that problem described in the comment at repeatedlyTryToPersist in process_transaction.nim, and I never quite got the peer pool correctly downloading those missing nodes), but this branch is an imperfect recreation of that past branch and I haven't managed to finish it before I leave.
I'm sorry for leaving the code in such a lousy state. Good luck!