Prysm: Allow for more powerful graffiti inputs

Created on 23 Apr 2020  路  9Comments  路  Source: prysmaticlabs/prysm

馃殌 Feature Request

Description

Suggested by @protolambda, we should allow for more interactivity in the block graffiti input, possibly adding script support or more responsive inputs rather than something hard coded.

Not a priority, but making an issue to make sure its not forgotten.

Enhancement Help Wanted Needs Design

Most helpful comment

I think having prysm calling scripts or executing HTTP requests can be a security risk and in the end more maintenance. Perhaps pointing to a file something like --graffiti-file=dynamic_graffiti.txt would be just good enough. This way anyone could write a script outside of the prysm scope to update the file contents.

All 9 comments

Yes, basically instead of --graffiti we could have a --graffiti-script tag, that calls the specified script. E.g. `--graffiti-script="echo -n protolambda". And maybe provide it data through stdin. E.g. current slot, validator pubkey of proposer, encoded block body, or things like that.
Others can then also hook it up with their more advanced graffiti tooling, e.g. call a remote webserver for a new graffiti tag to use.

Also, it may be good to call this in advance of proposing the block, to not delay it too much. (A simple subprocess echo call is fine, a webserver request not so much)

What about --graffiti-endpoint=0.0.0.0:7878 which will listen on 0.0.0.0:7878 for HTTP-POST requests to update the graffiti.

Another idea would be to add a grpc-method to the beacon-node which will update the graffiti of all connected validators.

I think having prysm calling scripts or executing HTTP requests can be a security risk and in the end more maintenance. Perhaps pointing to a file something like --graffiti-file=dynamic_graffiti.txt would be just good enough. This way anyone could write a script outside of the prysm scope to update the file contents.

If a file, being able to specify a list of inputs would be even better. So you can just write your next 100 graffiti in advance, and prysm uses one by one. And maybe specify which validator you'd want to use which graffiti, with wildcards if it doesn't matter.

<val index>-<slot>-<format>: <content>

E.g.

Have unique messages for each of your validators:
1234-*-txt: Validator 1234 greets you

Tag your name on any proposal:
*-*-txt: @protolambda was here

For prepared automation of special arbitrary graffiti at e.g. slot 1204-1206:
*-1204-hex: 000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f
*-1205-hex: 202122232425262728292a2b2c2d2e2f303132333435363738393a3b3c3d3e3f
*-1206-hex: 404142434445464748494a4b4c4d4e4f505152535455565758595a5b5c5d5e5f

And then anyone able to write a text file can have their custom graffiti. And scripting is easier, as you just replace the file every so often based on your needs.

Would also be nice to create an input to remove a line or bump a sequential integer pointer. Therefore one could in theory prepare a drawing for https://beaconcha.in/graffitiwall?

With https://github.com/prysmaticlabs/prysm/pull/8041 landing, all that's required for programmatic access (via file-updating) is to not cache the config file.
https://github.com/prysmaticlabs/prysm/blob/b4437e6cecd78257d2699f42073a90a940baf716/validator/node/node.go#L379

Done with #8041

@rauljordan did you see my comment? (https://github.com/prysmaticlabs/prysm/issues/5597#issuecomment-740474680)
I can create a new issue if preferred.

Edit: #8126

@rauljordan did you see my comment? (#5597 (comment))
I can create a new issue if preferred.

Yes. Please create a separate issue for this

Was this page helpful?
0 / 5 - 0 ratings