-
Notifications
You must be signed in to change notification settings - Fork 473
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
Implement beacon chain push withdrawals (EIP-4895) #4731
Conversation
src/Nethermind/Nethermind.Merge.Plugin/Data/V1/ExecutionPayloadV1.cs
Outdated
Show resolved
Hide resolved
src/Nethermind/Nethermind.Consensus/Processing/BlockProcessor.cs
Outdated
Show resolved
Hide resolved
|
||
foreach (var withdrawal in block.Withdrawals) | ||
{ | ||
if (_logger.IsTrace) _logger.Trace($" {(BigInteger)withdrawal.Amount / (BigInteger)Unit.Ether:N3}{Unit.EthSymbol} to account {withdrawal.Recipient}"); |
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.
what about traces around withdrawals?
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.
Could you reach out Mikhail Kalinin and Alex Stokes about withdrawalRoot validation?
It should be added to BlockValidator for sure (even now), but the question is how we should validate them when we're receiving newPayload from CL client.
8d3db64
to
6d83a24
Compare
2539d2f
to
9e6ee93
Compare
src/Nethermind/Nethermind.Merge.Plugin/Data/ExecutionPayload.cs
Outdated
Show resolved
Hide resolved
…stamp_activation_fix
…e_valid_responses
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.
LGTM
d506374
to
7e804d8
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.
Main issues:
Incomplete validation ofindex
andamount
could lead to consensus issue on our side- I don't like how engine versioning is being handled. IMO we should model it as it is in the spec with either composition or inheritance + generics for messages. This would help us have better separation between protocol versions similar to what we have for eth protocol in networking. Would make code changes tracked easier. Would make code more resemble the spec. We could potentially use similar strategy on tests. More details with example in NewPayloadHandler.cs comment.
src/Nethermind/Nethermind.Consensus/Withdrawals/ValidationWithdrawalProcessor.cs
Outdated
Show resolved
Hide resolved
src/Nethermind/Nethermind.Consensus/Processing/BlockProcessor.cs
Outdated
Show resolved
Hide resolved
src/Nethermind/Nethermind.Consensus/Withdrawals/ValidationWithdrawalProcessor.cs
Outdated
Show resolved
Hide resolved
src/Nethermind/Nethermind.Blockchain.Test/GenesisLoaderTests.cs
Outdated
Show resolved
Hide resolved
src/Nethermind/Nethermind.Merge.Plugin/Handlers/ForkchoiceUpdatedHandler.cs
Show resolved
Hide resolved
b4bcf93
to
8e7be8d
Compare
dcb5a6a
to
a25e999
Compare
…b.com/nethermindeth/nethermind into feature/shanghai-eip-4895-withdrawals # Conflicts: # src/Nethermind/Nethermind.Consensus/Validators/BlockValidator.cs
…into feature/shanghai-eip-4895-withdrawals
Closes #4580
Changes:
These changes are preliminary for prototyping purposes and are subject to change.
Withdrawal
class has been added to theBlock
BlockProcessor
has been modified to process withdrawals if anyTypes of changes
What types of changes does your code introduce?
Testing
Requires testing
In case you checked yes, did you write tests??
Further comments