-
Notifications
You must be signed in to change notification settings - Fork 811
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
Conversation
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.
Just a few feature suggestions, looks good to me otherwise
- We could add a graffiti field to this PATCH: https://github.com/sigp/lighthouse/blob/stable/validator_client/src/http_api/mod.rs#L417 Which would resolve Remote graffiti provider #2031
- could add a reference to this in: https://lighthouse-book.sigmaprime.io/validator-management.html
@@ -278,7 +278,8 @@ Typical Responses | 200 | |||
{ | |||
"enable": true, | |||
"description": "validator_one", | |||
"deposit_gwei": "32000000000" | |||
"deposit_gwei": "32000000000", | |||
"graffiti": "Mr F was here" |
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.
😂
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 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.
I have tested this but I think the requirements of #2074 supersedes this PR now. |
Signed-off-by: pawan <[email protected]>
Signed-off-by: pawan <[email protected]>
7bdec09
to
f9daecb
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.
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 |
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.
wondering if we should load graffiti here or as a separate service
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. |
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.
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 :)
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: Command line option to vc was:
I later removed the file just to make sure it was getting the right file path and got:
Full command was: |
After commit 529725f my graffiti file seems to be accepted. I am excited about this feature. |
@fireduck64 Thank you so much. There was a bug in the file reading logic. Should be fixed now. |
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 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!
Co-authored-by: Paul Hauner <[email protected]>
Co-authored-by: Paul Hauner <[email protected]>
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! I'll merge this tomorrow once we've solved a new cargo audit
issue that showed up :)
bors r+ |
## 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.
Pull request successfully merged into unstable. Build succeeded: |
## 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.
This reverts commit cc7a309.
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.