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: add system config consensus to deprecate clique #1102

Draft
wants to merge 8 commits into
base: develop
Choose a base branch
from

Conversation

yiweichi
Copy link
Member

1. Purpose or design rationale of this PR

Add a new consensus to deprecate clique
Project doc
...

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

Copy link

coderabbitai bot commented Dec 15, 2024

Important

Review skipped

Draft detected.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.


Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media?

❤️ Share
🪧 Tips

Chat

There are 3 ways to chat with CodeRabbit:

  • Review comments: Directly reply to a review comment made by CodeRabbit. Example:
    • I pushed a fix in commit <commit_id>, please review it.
    • Generate unit testing code for this file.
    • Open a follow-up GitHub issue for this discussion.
  • Files and specific lines of code (under the "Files changed" tab): Tag @coderabbitai in a new review comment at the desired location with your query. Examples:
    • @coderabbitai generate unit testing code for this file.
    • @coderabbitai modularize this function.
  • PR comments: Tag @coderabbitai in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
    • @coderabbitai gather interesting stats about this repository and render them as a table. Additionally, render a pie chart showing the language distribution in the codebase.
    • @coderabbitai read src/utils.ts and generate unit testing code.
    • @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.
    • @coderabbitai help me debug CodeRabbit configuration file.

Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments.

CodeRabbit Commands (Invoked using PR comments)

  • @coderabbitai pause to pause the reviews on a PR.
  • @coderabbitai resume to resume the paused reviews.
  • @coderabbitai review to trigger an incremental review. This is useful when automatic reviews are disabled for the repository.
  • @coderabbitai full review to do a full review from scratch and review all the files again.
  • @coderabbitai summary to regenerate the summary of the PR.
  • @coderabbitai generate docstrings to generate docstrings for this PR. (Beta)
  • @coderabbitai resolve resolve all the CodeRabbit review comments.
  • @coderabbitai configuration to show the current CodeRabbit configuration for the repository.
  • @coderabbitai help to get help.

Other keywords and placeholders

  • Add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.
  • Add @coderabbitai summary to generate the high-level summary at a specific location in the PR description.
  • Add @coderabbitai anywhere in the PR title to generate the title automatically.

CodeRabbit Configuration File (.coderabbit.yaml)

  • You can programmatically configure CodeRabbit by adding a .coderabbit.yaml file to the root of your repository.
  • Please see the configuration documentation for more information.
  • If your editor has YAML language server enabled, you can add the path at the top of this file to enable auto-completion and validation: # yaml-language-server: $schema=https://coderabbit.ai/integrations/schema.v2.json

Documentation and Community

  • Visit our Documentation for detailed information on how to use CodeRabbit.
  • Join our Discord Community to get help, request features, and share feedback.
  • Follow us on X/Twitter for updates and announcements.

Copy link

@jonastheis jonastheis left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  • this seems nicely testable in unit tests by mocking the EthClient and returning the values you expect for signing and verifying so you should be able to cover most of the code.
  • what about the block hash? don't we need to exclude the ExtraData from the block hash calculation so that we can create the same hashes when reconstructing blocks from L1?
  • how does an upgrade work with the new consensus mechanism? this is a mandatory upgrade, so node operators need to upgrade before a hard fork. but how exactly do we support and switch the consensus mechanism from clique to system contract based on a fork given in the config?

consensus/system_contract/consensus.go Outdated Show resolved Hide resolved
consensus/system_contract/consensus.go Outdated Show resolved Hide resolved
consensus/system_contract/system_contract.go Outdated Show resolved Hide resolved
consensus/system_contract/system_contract.go Outdated Show resolved Hide resolved
consensus/system_contract/system_contract.go Outdated Show resolved Hide resolved
@ranchalp
Copy link

Thanks for the comments @jonastheis , addressed them except for the one on failing the node on Start (commented there in the convo)

@ranchalp ranchalp force-pushed the feat-system-config-consensus branch from 7774ca6 to a77524f Compare January 16, 2025 13:20
@ranchalp
Copy link

Bringing back the implementation with only one signer, see discussion here.

@Thegaram Thegaram mentioned this pull request Jan 17, 2025
13 tasks
@ranchalp ranchalp force-pushed the feat-system-config-consensus branch from cc0c2d9 to 4047f24 Compare January 20, 2025 09:38
Copy link

@jonastheis jonastheis left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to me. These 2 questions remain though:

  1. what about the block hash? don't we need to exclude the ExtraData from the block hash calculation so that we can create the same hashes when reconstructing blocks from L1?
  2. how does an upgrade work with the new consensus mechanism? this is a mandatory upgrade, so node operators need to upgrade before a hard fork. but how exactly do we support and switch the consensus mechanism from clique to system contract based on a fork given in the config?

consensus/system_contract/system_contract.go Outdated Show resolved Hide resolved
consensus/system_contract/consensus.go Outdated Show resolved Hide resolved
@ranchalp ranchalp force-pushed the feat-system-config-consensus branch 3 times, most recently from 4e0c302 to 7cbad55 Compare January 21, 2025 12:40
@ranchalp ranchalp force-pushed the feat-system-config-consensus branch from 7cbad55 to b68d2d6 Compare January 21, 2025 12:43
@ranchalp
Copy link

In order to only verify the current signature if the block was not requested, I modify the queue used by the downloader so that it modifies a new requested rlp:"-" struct field of the header type (so that rlp does not use it for encoding). This field is set to true only if the blockheader is delivered by the queue in response to a request.

Then the consensus.go explicitly checks whether the requested is set to true to skip the signature verification.

Thoughts? @jonastheis @Thegaram

eth/downloader/resultstore.go Outdated Show resolved Hide resolved
les/downloader/downloader.go Outdated Show resolved Hide resolved
les/downloader/queue.go Show resolved Hide resolved
les/downloader/resultstore.go Show resolved Hide resolved
core/types/block.go Outdated Show resolved Hide resolved
eth/downloader/downloader.go Show resolved Hide resolved
@ranchalp ranchalp force-pushed the feat-system-config-consensus branch from 21c43e3 to 0e1fb13 Compare January 22, 2025 10:01
@ranchalp ranchalp force-pushed the feat-system-config-consensus branch from 0e1fb13 to ec2e3d0 Compare January 22, 2025 10:01
@@ -105,7 +105,7 @@ type Header struct {
//Hacky: used internally to mark the header as requested by the downloader at the deliver queue
// The tag "rlp:\"-\"" ensures it's excluded from the RLP encoding (and thus, from the hash computation).

Requested bool `json:"requested" rlp:"-"`
Requested bool `rlp:"-"`

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

similar to the RLP one, ignoring with json:"-". see documentation: https://pkg.go.dev/encoding/json#Marshal

@@ -79,7 +79,7 @@ type Header struct {
GasLimit uint64 `json:"gasLimit" gencodec:"required"`
GasUsed uint64 `json:"gasUsed" gencodec:"required"`
Time uint64 `json:"timestamp" gencodec:"required"`
Extra []byte `json:"extraData" gencodec:"required"`
Extra []byte `json:"extraData" gencodec:"required" rlp:"-"`

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm wondering if we ignore this with RLP encoding, do we still send this field when forwarding blocks in the network layer? How do we serialize and deserialize blocks there?

Copy link

@ranchalp ranchalp Jan 23, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fields with rlp:"-" are not used during serialization and deserialization, and are not send over the network layer.

params/config.go Outdated
@@ -633,6 +633,7 @@ type ChainConfig struct {
CurieBlock *big.Int `json:"curieBlock,omitempty"` // Curie switch block (nil = no fork, 0 = already on curie)
DarwinTime *uint64 `json:"darwinTime,omitempty"` // Darwin switch time (nil = no fork, 0 = already on darwin)
DarwinV2Time *uint64 `json:"darwinv2Time,omitempty"` // DarwinV2 switch time (nil = no fork, 0 = already on darwinv2)
EuclidBlock *big.Int `json:"euclidBlock,omitempty"` // Euclid switch block (nil = no fork, 0 = already on euclid)

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Euclid will be triggered not by block but by time. You can probably just copy this function and the definition of EuclidTime *uint64 from here: https://github.com/scroll-tech/go-ethereum/pull/1104/files#diff-10ff00a15ef58da7485fedeca3906c73cb236fde4b143a9d61601c63cbf1ffe8R899

sysEngine := system_contract.New(context.Background(), chainConfig.SystemContract, l1Client)

// Determine the fork block at which the switch occurs.
var forkBlock *big.Int

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

use the isEuclid function (pass into NewUpgradableEngine) to determine whether it is the Euclid fork. https://github.com/scroll-tech/go-ethereum/pull/1104/files#diff-10ff00a15ef58da7485fedeca3906c73cb236fde4b143a9d61601c63cbf1ffe8R899

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

consensus/consensus_wrapper is not really Go idiomatic naming. better use consensus/wrapper or consensus/upgradable or something. https://go.dev/doc/effective_go#package-names

}

// chooseEngine returns the appropriate consensus engine based on the header's number.
func (ue *UpgradableEngine) chooseEngine(header *types.Header) consensus.Engine {

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

use the isEuclid method instead

@ranchalp ranchalp force-pushed the feat-system-config-consensus branch from 8f785f6 to 20185f2 Compare January 23, 2025 09:25
@ranchalp
Copy link

Thanks @jonastheis. Addressed the comments.

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

Successfully merging this pull request may close these issues.

4 participants