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

Support multiple signers loaders #17

Open
ltitanb opened this issue Jul 16, 2024 · 3 comments · May be fixed by #206
Open

Support multiple signers loaders #17

ltitanb opened this issue Jul 16, 2024 · 3 comments · May be fixed by #206
Labels
core Core part of the repo (signer, modules interface)

Comments

@ltitanb
Copy link
Collaborator

ltitanb commented Jul 16, 2024

We currently support two loaders for the signer module:

pub enum SignerLoader {
/// Plain text, do not use in prod
File {
key_path: String,
},
ValidatorsDir {
keys_path: String,
secrets_path: String,
},
}

In particular the ValidatorsDir supports the ERC-2335 keystore format as used in Lighthouse.

We should:

  • add support for other keystores as used in other CL clients
  • add support for remote signers, such as web3signer and Dirk

We can open sub-issues for each one as needed

@DrewVanderWerff
Copy link
Contributor

Should this be closed?

@ManuelBilbao ManuelBilbao linked a pull request Jan 6, 2025 that will close this issue
@iurii-ssv
Copy link

iurii-ssv commented Feb 5, 2025

hey @ltitanb @DrewVanderWerff I'm browsing through commit-boost docs (and relevant code) and I'm struggling a bit to see how commit-boost is meant to work with web3-signer

it seems the idea is for SignerClient to be used directly with web3-signer API just by providing a URL where web3-signer is run at - but when I look into (https://github.com/Consensys/web3signer?tab=readme-ov-file#api) it seems like they describe completely different endpoints in there (from the ones SignerClient is working with)

could you help me understand this better ? Is commit-boost using some unofficial web3-signer API (or why their docs describe API differently) ?

We are looking to integrate commit-boost with our DVT solution (SSV network) and it looks like the most straightforward way to interface our distributed-validator-signing-service/procedure with commit-boost (so it can request such signatures) would be to "pretend" as if our distributed-validator-signing-service is a web3-signer service by implementing the exact web3-signer API, but the open question is - like I mentioned above, which API is the correct one to implement ? Or maybe you would recommend a different approach entirely ?

I guess #195 was looking for similar clarifications.

@DrewVanderWerff
Copy link
Contributor

Hey we are working on better docs on our side + web3. But it's supported officially since their last release: https://github.com/Consensys/web3signer/releases/tag/24.12.0 . If there is still some ambiguity around how it will work, while we work on docs just have the team ping us and we can try and help!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
core Core part of the repo (signer, modules interface)
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants