Remote/web3signer key registration via keymanager API survives restart

[yorickdowne]

🚀 Feature Request

Description

I am using the keymanager API to register remote keys kept in web3signer, as per https://ethereum.github.io/keymanager-APIs/?urls.primaryName=v1.0.0#/Remote%20Key%20Manager/importRemoteKeys

They do not persist across a restart.

Describe the solution you'd like

It'd be immensely helpful if these keys were persisted across restart. One way to do so might be to allow creation of a permanent wallet of kind "web3signer". Currently this is rejected with a note that permanent wallets are not required for web3signer keys.

Describe alternatives you've considered

I'd need to have a helper container running that, on start, queries web3signer keymanager API until it is up, gets the list of pubkeys, waits for Prysm keymanager API to be up, then registers validators. This is brittle, and feels a bit hacky. I'd prefer to register the keys once via keymanager API, when the user imports them to web3signer via its keymanager API, and then have that persist on restart.

[james-prysm]

related to #9994
perhaps in the future we can do this and track it will need to think carefully on the ux.
in the mean time you will need to track it yourself and update the flag associated... you can also write it to a file ( think i have it implemented) to read from...

[yorickdowne]

Fair enough. This behavior of not keeping an imported remote key across restarts is unique to Prysm.

[james-prysm]

got it thanks for the FYI

[yorickdowne]

Thinking about ux, a relatively simple answer is for wallet create to accept kind web3signer, and to change the help text to show web3signer, not remote, as remote isn’t recognized as a kind.

And the keymanager api works as expected.

Where this falls short is the use case where a user might have both imported and web3signer keys. But that also fails now: If a wallet of kind imported exists, the remote api fails, with an error message about the wallet needing to be of kind web3signer.

[james-prysm]

There's also interactions with validators-external-signer-public-keys flag to consider here where the values are passed in. this takes both a string list as well as a URL, some groups are using the URL based endpoint and keeping track of which keys are added and removed themselves to provide on restart. would need some kind of flag path figured out.

[yorickdowne]

Yep, using the public-keys flag with the web3signer API URL works. Closing.

[james-prysm]

will look at this again soon

[jakubbujny]

I think it should work similar to other validator clients like Teku or Lighthouse so public keys added via key manager are saved on disk so that configuration can survive the restart and be read during the startup to quickly start signing again