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
Fix remote signing #4502
Fix remote signing #4502
Conversation
Performance Report✔️ no performance regression detected Full benchmark results
|
}; | ||
} | ||
|
||
async signAttestationSelectionProof(pubkey: BLSPubkeyMaybeHex, slot: Slot): Promise<BLSSignature> { | ||
const domain = this.config.getDomain(slot, DOMAIN_SELECTION_PROOF); | ||
const signingRoot = computeSigningRoot(ssz.Slot, slot, domain); | ||
|
||
return await this.getSignature(pubkey, signingRoot); | ||
const signableMessage: SignableMessage = { |
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.
If the web3signer is not enabled, all this objects are being created for nothing right?
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.
Updated to only create the Singable messages when web3signer 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.
@dapplion Your recent changes now makes it such that the objects are being created even when web3signer is not enabled. Is that intentional/okay now?
Please add an e2e test that run the web3signer docker container and request signatures for all available objects. I would really need to have programmatic certainty that this works before merging. |
block: ssz.altair.BeaconBlock.toJson(data.block as altair.BeaconBlock), | ||
}; | ||
} else { | ||
throw new Error(`version ${data.version} not supported by remote signer`); |
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.
What about the bellatrix fork? Using this pattern doesn't scale and will be painful to mantain
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.
I basically followed the pattern used in lighthouse here. Had an older version so bellatrix was not included. Added it now. As regards observation about maintenance. I'll revisit this after setting up all the tests
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.
Yet to do the final sanity check but it occurred to me, that maybe the maintenance won't be too hard. Because:
- Having another fork is a coordinated effort that will be planned out and include coordinated code changes
- Even if lodestar can handle new forks without code changes, it should not, because it also depends on making sure that the Web3Signer has been updated to also handle the new fork. If not, lodestar will pass the call to web3signer but it will fail.
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.
Right I wasnt aware of how weird the web3signer request types are 😅 made such that any fork after bellatrix with use the bellatrix path
return getRemoteSigners(args); | ||
} else { | ||
return indexes.map((index) => ({type: SignerType.Local, secretKey: interopSecretKey(index)})); | ||
} |
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.
What's the purpose of this? I don't follow
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.
To consume the interop indexes from the web3signer you should load the interop keystores in the web3signer and then use .fetch
Motivation
Using remote signer currently does not work. This is because the web3signer URL is different from what lodestar expects.
PS: currently draft PR as the branch still need to be tested on goerli test net.
Description
Update implementation to use correct web3signer endpoints.
Closes #4424
Steps to test or reproduce