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] - Set graffiti per validator #2044

Closed
wants to merge 27 commits into from

Conversation

pawanjay176
Copy link
Member

Issue Addressed

Resolves #1944

Proposed Changes

Adds a "graffiti" key to the validator_definitions.yml. Setting the key will override anything passed through the validator --graffiti flag.
Returns an error if the value for the graffiti key is > 32 bytes instead of silently truncating.

@pawanjay176 pawanjay176 marked this pull request as ready for review December 4, 2020 16:25
@pawanjay176 pawanjay176 added the ready-for-review The code is ready for review label Dec 4, 2020
Copy link
Member

@realbigsean realbigsean left a comment

Choose a reason for hiding this comment

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

Just a few feature suggestions, looks good to me otherwise

@@ -278,7 +278,8 @@ Typical Responses | 200
{
"enable": true,
"description": "validator_one",
"deposit_gwei": "32000000000"
"deposit_gwei": "32000000000",
"graffiti": "Mr F was here"
Copy link
Member

Choose a reason for hiding this comment

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

😂

Copy link
Member

@AgeManning AgeManning 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 good to me. It should be backwards compatible, have you tested this?

Also, I guess there's no real way for the user to set this other than manually editing the file? I guess in the VC API we can make it more user friendly.

This is failing an old test that should be fixed in latest code.

@AgeManning AgeManning 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 Dec 16, 2020
@pawanjay176
Copy link
Member Author

I have tested this but I think the requirements of #2074 supersedes this PR now.

@pawanjay176 pawanjay176 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 Dec 23, 2020
@gak gak mentioned this pull request Jan 5, 2021
Copy link
Member

@realbigsean realbigsean left a comment

Choose a reason for hiding this comment

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

tiny requests and I'm a little unsure about whether we should load graffiti from file in the block service. I think I would lean towards it's ok because of the defaulting logic but wondering what @paulhauner thinks

@@ -226,14 +238,22 @@ impl<T: SlotClock + 'static, E: EthSpec> BlockService<T, E> {
.ok_or("Unable to produce randao reveal")?
.into();

let graffiti = self
Copy link
Member

Choose a reason for hiding this comment

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

wondering if we should load graffiti here or as a separate service

@pawanjay176
Copy link
Member Author

pawanjay176 commented Jan 22, 2021

I think I would lean towards it's ok because of the defaulting logic

Yeah the defaulting logic should work well enough. One potential issue is where the graffiti file itself is malicious. Since we try reading from the graffiti file before every proposal, if an attacker manages to change the file in some malicious way(e.g. file causes oom or takes too long to read leading to delayed proposal), they could crash the vc or delay the proposal enough for the block to get orphaned.

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.

Cool man! I'm sure people will enjoy drawing body parts pictures on the graffiti walls with this!

I just had a few comments, nothing major :)

@paulhauner paulhauner removed the ready-for-review The code is ready for review label Feb 11, 2021
@pawanjay176 pawanjay176 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 15, 2021
@fireduck64
Copy link

For whatever it is worth, I just tried this from the PR branch and couldn't get it to work.

The graffiti file had just this single line:
default: graffitiwall:720:641:#ffff00

Command line option to vc was:
--graffiti-file /vol/data/graffiti.txt

Feb 15 20:06:32.119 INFO Lighthouse started                      version: Lighthouse/v1.1.0-c7cc99e+
Feb 15 20:06:32.119 INFO Configured for network                  name: mainnet
Unable to initialize validator config: Error reading graffiti file: InvalidLine

I later removed the file just to make sure it was getting the right file path and got:

Feb 15 20:07:22.989 INFO Lighthouse started                      version: Lighthouse/v1.1.0-c7cc99e+
Feb 15 20:07:22.989 INFO Configured for network                  name: mainnet
Unable to initialize validator config: Error reading graffiti file: InvalidFile(Os { code: 2, kind: NotFound, message: "No such file or directory" })

Full command was:
docker run -d --restart no --name lighthouse-vc --network host
--mount 'type=volume,src=lighthouse_vc_vol,dst=/root/.lighthouse'
-v ~/data:/vol/data
$DOCKER_LIGHTHOUSE lighthouse vc --network mainnet --http --graffiti-file /vol/data/graffiti.txt --metrics

@fireduck64
Copy link

After commit 529725f my graffiti file seems to be accepted.

I am excited about this feature.

@pawanjay176
Copy link
Member Author

@fireduck64 Thank you so much. There was a bug in the file reading logic. Should be fixed now.

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 working nicely for me!

I just had a couple of minor suggestions for docs, detail in errors and a nit about some parsing. We're almost there!

@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 Mar 1, 2021
@pawanjay176 pawanjay176 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 Mar 1, 2021
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.

Looks good! I'll merge this tomorrow once we've solved a new cargo audit issue that showed up :)

@paulhauner paulhauner added ready-for-merge This PR is ready to merge. and removed ready-for-review The code is ready for review labels Mar 2, 2021
@michaelsproul
Copy link
Member

bors r+

bors bot pushed a commit that referenced this pull request Mar 2, 2021
## Issue Addressed

Resolves #1944 

## Proposed Changes

Adds a "graffiti" key to the `validator_definitions.yml`. Setting the key will override anything passed through the validator `--graffiti` flag. 
Returns an error if the value for the graffiti key is > 32 bytes instead of silently truncating.
@bors bors bot changed the title Set graffiti per validator [Merged by Bors] - Set graffiti per validator Mar 2, 2021
@bors bors bot closed this Mar 2, 2021
michaelsproul pushed a commit that referenced this pull request Mar 10, 2021
## Issue Addressed

Resolves #1944 

## Proposed Changes

Adds a "graffiti" key to the `validator_definitions.yml`. Setting the key will override anything passed through the validator `--graffiti` flag. 
Returns an error if the value for the graffiti key is > 32 bytes instead of silently truncating.
michaelsproul added a commit that referenced this pull request Mar 10, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
ready-for-merge This PR is ready to merge.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants