-
Notifications
You must be signed in to change notification settings - Fork 279
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
base: develop
Are you sure you want to change the base?
Conversation
Important Review skippedDraft detected. Please check the settings in the CodeRabbit UI or the You can disable this status message by setting the 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? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
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)
Other keywords and placeholders
CodeRabbit Configuration File (
|
d87b55d
to
f438d7b
Compare
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.
- 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?
Thanks for the comments @jonastheis , addressed them except for the one on failing the node on Start (commented there in the convo) |
7774ca6
to
a77524f
Compare
Bringing back the implementation with only one signer, see discussion here. |
cc0c2d9
to
4047f24
Compare
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.
Looks good to me. These 2 questions remain though:
- 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?
4e0c302
to
7cbad55
Compare
7cbad55
to
b68d2d6
Compare
In order to only verify the current signature if the block was not requested, I modify the Then the Thoughts? @jonastheis @Thegaram |
21c43e3
to
0e1fb13
Compare
0e1fb13
to
ec2e3d0
Compare
core/types/block.go
Outdated
@@ -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:"-"` |
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.
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:"-"` |
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.
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?
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.
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) |
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.
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
eth/ethconfig/config.go
Outdated
sysEngine := system_contract.New(context.Background(), chainConfig.SystemContract, l1Client) | ||
|
||
// Determine the fork block at which the switch occurs. | ||
var forkBlock *big.Int |
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.
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
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.
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 { |
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.
use the isEuclid
method instead
8f785f6
to
20185f2
Compare
Thanks @jonastheis. Addressed the comments. |
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:
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?