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

feat: pipelined state processor for follower nodes #894

Open
wants to merge 5 commits into
base: develop
Choose a base branch
from

Conversation

omerfirmak
Copy link

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:

  • build: Changes that affect the build system or external dependencies (example scopes: yarn, eslint, typescript)
  • ci: Changes to our CI configuration files and scripts (example scopes: vercel, github, cypress)
  • docs: Documentation-only changes
  • feat: A new feature
  • fix: A bug fix
  • perf: A code change that improves performance
  • refactor: A code change that doesn't fix a bug, or add a feature, or improves performance
  • style: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc)
  • test: Adding missing tests or correcting existing tests

3. Deployment tag versioning

Has the version in params/version.go been updated?

  • This PR doesn't involve a new deployment, git tag, docker image tag, and it doesn't affect traces
  • Yes

4. Breaking change label

Does this PR have the breaking-change label?

  • This PR is not a breaking change
  • Yes

@omerfirmak omerfirmak marked this pull request as ready for review July 10, 2024 09:53
@omerfirmak omerfirmak force-pushed the omerfirmak/pipelined-processor branch from 5af7ab1 to e0b317b Compare July 10, 2024 10:04
defer pl.Release()

for _, tx := range block.Transactions() {
res, err := pl.TryPushTxn(tx)

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) {

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:

  1. CCC on follower nodes does not need to block block processing, it can happen completely async.
  2. 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.)

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

Successfully merging this pull request may close these issues.

3 participants