-
Notifications
You must be signed in to change notification settings - Fork 276
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
feat: pipelined state processor for follower nodes #894
base: develop
Are you sure you want to change the base?
Conversation
5af7ab1
to
e0b317b
Compare
defer pl.Release() | ||
|
||
for _, tx := range block.Transactions() { | ||
res, err := pl.TryPushTxn(tx) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Originally, we'd trace and ccc the whole block in one step (different ccc API).
By using a pipeline, we now process tx-by-tx in a pipelined manner. Are the CCC results the same? And do we gain a lot from this?
} | ||
} | ||
|
||
func (p *Processor) Process(block *types.Block, statedb *state.StateDB, cfg vm.Config) (types.Receipts, []*types.Log, uint64, error) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The original plan was to move CCC out of the block processing loop, so that it's not blocking it. By moving CCC from block_validator
to Process
here, it's still blocking block insertion, right? What do we gain here?
I feel like:
- CCC on follower nodes does not need to block block processing, it can happen completely async.
- We can run CCC for multiple blocks in parallel, we don't need to process blocks one-by-one. (But of course there might be memory concerns if we trace lots of blocks in parallel.)
1. Purpose or design rationale of this PR
brings ccc-enabled follower node performance in line with sequencer performance.
2. PR title
Your PR title must follow conventional commits (as we are doing squash merge for each PR), so it must start with one of the following types:
3. Deployment tag versioning
Has the version in
params/version.go
been updated?4. Breaking change label
Does this PR have the
breaking-change
label?