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

[Merged by Bors] - Allow per validator fee recipient via flag or file in validator client (similar to graffiti / graffiti-file) #2924

Closed
wants to merge 42 commits into from

Conversation

pk910
Copy link
Contributor

@pk910 pk910 commented Jan 17, 2022

Issue Addressed

#2883

Proposed Changes

  • Added suggested-fee-recipient & suggested-fee-recipient-file flags to validator client (similar to graffiti / graffiti-file implementation).
  • Added proposer preparation service to VC, which sends the fee-recipient of all known validators to the BN via /eth/v1/validator/prepare_beacon_proposer api once per slot
  • Added /eth/v1/validator/prepare_beacon_proposer api endpoint and preparation data caching
  • Added cleanup routine to remove cached proposer preparations when not updated for 2 epochs

Additional Info

Changed the Implementation following the discussion in #2883.

@pk910
Copy link
Contributor Author

pk910 commented Jan 17, 2022

Hmm, it was a nice try, but doesn't work at the moment...

lighthouse[69268]: Jan 17 09:34:48.001 CRIT Error whilst producing block message: All endpoints failed http://localhost:5052/ => RequestFailed("Error from beacon node when producing block: ServerMessage(ErrorMessage { code: 400, message: "BAD_REQUEST: invalid query: Invalid query string", stacktraces: [] })"), service: block

Seems I missed something - Looking into it..

@pk910 pk910 marked this pull request as draft January 17, 2022 12:21
@pawanjay176
Copy link
Member

pawanjay176 commented Jan 17, 2022

@pk910 This is looking good :) Your issue looks like incorrect parsing of the address. You can try printing out the fee_recipient right before it is passed to the api in block_service.rs and see if it's what you are expecting.

Is it allowed to add an optional parameter to the bn api just like that or is the api specification managed somewhere else and needs a change request there?

You would need to request for change in the api specification as having a different behaviour would break lighthouse vc compatibility with other client beacon nodes. The api specification is maintained here https://github.com/ethereum/beacon-apis/issues

@pk910 pk910 force-pushed the fee-recipient-per-validator branch from 0b4ad35 to 9384165 Compare January 18, 2022 23:29
@pk910 pk910 force-pushed the fee-recipient-per-validator branch from 9384165 to 4330306 Compare January 19, 2022 13:11
@pk910
Copy link
Contributor Author

pk910 commented Jan 19, 2022

I've reimplemented the way how the fee-recipient is transmitted to the BN. There is now a new "proposal preparation" service in VC that sends the fee-recipients of all known validators to the BN at the beginning of each epoch using the new /eth/v1/validator/prepare_beacon_proposer api.

This is a working prototype that has successfully proposed blocks with individual fee-recipients for me in the kintsugi net.

A few things that should be looked into:

  • VC publishes the proposer preparations at the beginning of each epoch. I'm not sure if that interferes other much more important api calls at the beginning of an epoch or could overload the BN with a big number of VCs?
  • The proposer preparation is currently stored forever in a simple HashMap.. I'm pretty sure there is a much more elegant solution for that and I have a feeling that this cache should not live in the execution layer code (actually I didn't get it running in the BeaconChain struct, which looks like a better place for such a cache)
  • Proposer preparations are currently stored in memory forever. There should be something that removes them again when not updated for 2 epochs. As I think the cache implementation needs rework anyway I have not invested work in that yet.
  • There is no limitation of how many proposer preparations are stored in memory.. As the index is a u64 there can probably be enough entries to fill up BN memory completely - that looks like a possible dos attack surface to me

It can probably be implemented in a much cleaner way, so I'm totally fine if you decide to throw it away and redo yourself ;)
Can also try to rework some parts myself if you give me some advice how to continue :)

@paulhauner paulhauner self-requested a review January 20, 2022 08:03
@paulhauner paulhauner self-assigned this Jan 20, 2022
@paulhauner
Copy link
Member

I haven't done a review, but thanks for your contribution @pk910!

Earlier today I created #2936. It seems this PR is along similar lines 🎉

I'll find some time this week or early next to review this 🙏

@paulhauner paulhauner added the bellatrix Required to support the Bellatrix Upgrade label Feb 1, 2022
Copy link
Member

@paulhauner paulhauner left a comment

Choose a reason for hiding this comment

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

This is looking really good, we're so close. I've left some minor requests here, I'm keen to merge after they're addressed.

Thanks again for this high-value contribution 🙏

beacon_node/beacon_chain/src/execution_payload.rs Outdated Show resolved Hide resolved
.epoch()
.map_err(warp_utils::reject::beacon_chain_error)?;

info!(
Copy link
Member

Choose a reason for hiding this comment

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

Suggested change
info!(
debug!(

This might get a little noisy when polling once per slot (per validator client).

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Agree 👍
Should we change the log entry on VC side to debug, too?

Copy link
Member

Choose a reason for hiding this comment

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

Oh yep, good idea!

validator_client/src/config.rs Outdated Show resolved Hide resolved
validator_client/src/cli.rs Outdated Show resolved Hide resolved
validator_client/src/cli.rs Outdated Show resolved Hide resolved
@paulhauner paulhauner added waiting-on-author The reviewer has suggested changes and awaits thier implementation. and removed ready-for-review The code is ready for review labels Feb 7, 2022
@pk910
Copy link
Contributor Author

pk910 commented Feb 7, 2022

@paulhauner
All suggestions applied 👍

@paulhauner paulhauner added ready-for-review The code is ready for review and removed waiting-on-author The reviewer has suggested changes and awaits thier implementation. labels Feb 7, 2022
Copy link
Member

@paulhauner paulhauner left a comment

Choose a reason for hiding this comment

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

This looks great, I just made suggestions for your comment in #2924 (comment).

After those a resolved, it's merge time 🎉

validator_client/src/preparation_service.rs Outdated Show resolved Hide resolved
validator_client/src/preparation_service.rs Outdated Show resolved Hide resolved
@paulhauner paulhauner added waiting-on-author The reviewer has suggested changes and awaits thier implementation. and removed ready-for-review The code is ready for review labels Feb 7, 2022
Co-authored-by: Paul Hauner <paul@paulhauner.com>
@pk910
Copy link
Contributor Author

pk910 commented Feb 8, 2022

@paulhauner
applied 👍
ready to merge? 🎉

@paulhauner
Copy link
Member

Let's goooo

bors r+

@paulhauner paulhauner added ready-for-merge This PR is ready to merge. and removed waiting-on-author The reviewer has suggested changes and awaits thier implementation. labels Feb 8, 2022
bors bot pushed a commit that referenced this pull request Feb 8, 2022
…t (similar to graffiti / graffiti-file) (#2924)

## Issue Addressed

#2883 

## Proposed Changes

* Added `suggested-fee-recipient` & `suggested-fee-recipient-file` flags to validator client (similar to graffiti / graffiti-file implementation).
* Added proposer preparation service to VC, which sends the fee-recipient of all known validators to the BN via [/eth/v1/validator/prepare_beacon_proposer](ethereum/beacon-APIs#178) api once per slot
* Added [/eth/v1/validator/prepare_beacon_proposer](ethereum/beacon-APIs#178) api endpoint and preparation data caching
* Added cleanup routine to remove cached proposer preparations when not updated for 2 epochs

## Additional Info

Changed the Implementation following the discussion in #2883.



Co-authored-by: pk910 <philipp@pk910.de>
Co-authored-by: Paul Hauner <paul@paulhauner.com>
Co-authored-by: Philipp K <philipp@pk910.de>
@bors
Copy link

bors bot commented Feb 8, 2022

Timed out.

@paulhauner
Copy link
Member

bors retry

bors bot pushed a commit that referenced this pull request Feb 8, 2022
…t (similar to graffiti / graffiti-file) (#2924)

## Issue Addressed

#2883 

## Proposed Changes

* Added `suggested-fee-recipient` & `suggested-fee-recipient-file` flags to validator client (similar to graffiti / graffiti-file implementation).
* Added proposer preparation service to VC, which sends the fee-recipient of all known validators to the BN via [/eth/v1/validator/prepare_beacon_proposer](ethereum/beacon-APIs#178) api once per slot
* Added [/eth/v1/validator/prepare_beacon_proposer](ethereum/beacon-APIs#178) api endpoint and preparation data caching
* Added cleanup routine to remove cached proposer preparations when not updated for 2 epochs

## Additional Info

Changed the Implementation following the discussion in #2883.



Co-authored-by: pk910 <philipp@pk910.de>
Co-authored-by: Paul Hauner <paul@paulhauner.com>
Co-authored-by: Philipp K <philipp@pk910.de>
@bors bors bot changed the title Allow per validator fee recipient via flag or file in validator client (similar to graffiti / graffiti-file) [Merged by Bors] - Allow per validator fee recipient via flag or file in validator client (similar to graffiti / graffiti-file) Feb 8, 2022
@bors bors bot closed this Feb 8, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bellatrix Required to support the Bellatrix Upgrade ready-for-merge This PR is ready to merge.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants