Add new DomainType for application usage with "internal" namespace
#2884
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
34 tasks
|
I like this approach more than #2882. |
djrtwo
reviewed
May 4, 2022
ralexstokes
force-pushed
the
add-application-domain-type-by-bit
branch
from
f0628e2 to
8384fd8
Compare
This was referenced May 12, 2022
djrtwo
reviewed
May 13, 2022
|
yeah makes sense, I'll update |
ralexstokes
force-pushed
the
add-application-domain-type-by-bit
branch
2 times, most recently
from
5ba1812 to
71835c6
Compare
ralexstokes
force-pushed
the
add-application-domain-type-by-bit
branch
from
71835c6 to
2a6d2e1
Compare
djrtwo
approved these changes
May 16, 2022
9 tasks
18 tasks
bors bot
pushed a commit
to sigp/lighthouse
that referenced
this pull request
Jun 30, 2022
## Issue Addressed Lays the groundwork for builder API changes by implementing the beacon-API's new `register_validator` endpoint ## Proposed Changes - Add a routine in the VC that runs on startup (re-try until success), once per epoch or whenever `suggested_fee_recipient` is updated, signing `ValidatorRegistrationData` and sending it to the BN. - TODO: `gas_limit` config options ethereum/builder-specs#17 - BN only sends VC registration data to builders on demand, but VC registration data *does update* the BN's prepare proposer cache and send an updated fcU to a local EE. This is necessary for fee recipient consistency between the blinded and full block flow in the event of fallback. Having the BN only send registration data to builders on demand gives feedback directly to the VC about relay status. Also, since the BN has no ability to sign these messages anyways (so couldn't refresh them if it wanted), and validator registration is independent of the BN head, I think this approach makes sense. - Adds upcoming consensus spec changes for this PR ethereum/consensus-specs#2884 - I initially applied the bit mask based on a configured application domain.. but I ended up just hard coding it here instead because that's how it's spec'd in the builder repo. - Should application mask appear in the api? Co-authored-by: realbigsean <sean@sigmaprime.io>
29 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Opening in lieu of #2882.
Context
This PR adds a new DomainType for use by applications adjacent to the core protocol so they can leverage the signing machinery developed here when working with consensus types.
An example use case is the work-in-progress Builder API where a validator may want to outsource block construction to a network of builders external to their local execution client. See ethereum/execution-apis#209 for details.
Rationale
This PR creates a "reserved" signing namespace for applications by setting the top bit in the
DomainType. Applications are still expected to set other bits in the remainder of theDomainTypedata to get domain separation from other applications using this scheme.This responsibility is on the applications to self-organize who uses which concrete
DomainTypes.Examples:
This approach is chosen over the approach in #2882 as there is less machinery to get right for users of the consensus spec.