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

E2E: fee-recipient evaluator #10528

Merged
merged 118 commits into from
Jun 30, 2022
Merged

E2E: fee-recipient evaluator #10528

merged 118 commits into from
Jun 30, 2022

Conversation

james-prysm
Copy link
Contributor

@james-prysm james-prysm commented Apr 14, 2022

What type of PR is this?

E2E

relates to #10292

What does this PR do? Why is it needed?
This PR is to provide E2E for the fee-recipient feature #10292 ( only works post merge/bellatrix release) It will check the presence of the fee recipient in the bellatrix block and see if the user receives transactions.

  • inject the fee recipient into the validator ( not available yet for the current release: breaking flag name change /web3signer testing:missing validator registration),
  • validate that a fee recipient exists in the block,
  • validate that the fee recipient is the corresponding set fee recipient for validator startup,
  • then check if the balance has changed on the execution client side

@james-prysm james-prysm added the E2E Tests End-To-End testing label Apr 14, 2022
@james-prysm james-prysm self-assigned this Apr 14, 2022
@james-prysm james-prysm added the Merge PRs related to the great milestone the merge label Apr 14, 2022
@james-prysm james-prysm marked this pull request as ready for review April 21, 2022 13:13
@james-prysm james-prysm requested a review from a team as a code owner April 21, 2022 13:13
@james-prysm james-prysm requested review from potuz, rkapka and nisdas April 21, 2022 13:13
publickey := validator.GetPublicKey()
// calculate deterministic fee recipient using first 20 bytes of public key
deterministicFeeRecipient := common.HexToAddress(hexutil.Encode(publickey[:fieldparams.FeeRecipientLength])).Hex()
if deterministicFeeRecipient != account.Hex() && components.DefaultFeeRecipientAddress != account.Hex() {
Copy link
Member

Choose a reason for hiding this comment

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

As a last point, is there anyway to differentiate which validator should be running with the default recipients and which validators should not be ? It is possible (ex:some validator bug) , where the validator does not apply the proposer config correctly and just uses the default fee recipient. With this check we wouldn't have anyway to differentiate. If this isn't possible to figure out currently it is fine we can ignore it for now.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

That's a good point was also thinking about it. I'll see if I can think of something for this. There definitely are validators that use the default , will spend more time figuring out why.

@prylabs-bulldozer prylabs-bulldozer bot merged commit 96fecf8 into develop Jun 30, 2022
@delete-merged-branch delete-merged-branch bot deleted the fee-recipient-e2e branch June 30, 2022 00:24
@nisdas nisdas mentioned this pull request Jul 1, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
E2E Tests End-To-End testing Merge PRs related to the great milestone the merge
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants