-
Notifications
You must be signed in to change notification settings - Fork 240
add api key bls remote signer #1128
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
Conversation
if blsRemoteSignerEnabled && blsSignerAPIKey == "" { | ||
return nil, fmt.Errorf("BLS signer API key is required if BLS remote signer is enabled") | ||
} |
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.
Is this requirement predicated on a new version of Cerberus that also requires API key? I've got remote BLS running on my testnet now with Cerberus. When I upgrade my node, do I need to simultaneously upgrade Cerberus? If I upgrade Cerberus first, will my node fail to remote sign until upgraded with this change?
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.
yes basically you will have to clean import on the new version of cerberus - since it sets up a DB and then persists some metadata for the keys - if you are already running cerberus. You will have to upgrade both together
not ideal but given only few folks (2-3 folks outside us) are testing right now on testnet it's an okay process. wdyt?
Basically steps
- Upgrade Cerberus (with postgres)
- Reimport key which will give you API key
- Add that in
.env
on eigenda with latest eigenda release - restart eigenda
there could be missed batches in between which won't be able to sign due to this inconsistency
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.
Yea, as long as current testnet users are in the loop, seems ok.
If possible might make sense to disable remote singing on node as first step - reverting to local BLS, to allow for Cerberus upgrade validation outside production path. Or maybe recommend users spin up new Cerberus alongside old Cerberus on new port so that they can import and validate new Cerberus is ready before pulling the switch. Then update .env
and bump node release.
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.
that's a good point. I will write an upgrade guide in release notes with these options and share. good call on that.
Why are these changes needed?
Checks