Add new DomainType for application usage with "internal" namespace#2884
Merged
djrtwo merged 1 commit intoethereum:devfrom May 16, 2022
Merged
Conversation
34 tasks
Contributor
|
I like this approach more than #2882. |
djrtwo
reviewed
May 4, 2022
Contributor
djrtwo
left a comment
There was a problem hiding this comment.
Looks good in general.
I might call it the DOMAIN_APPLICATION_MASK and say that DOMAIN_RANDOM_APPLICATION && DOMAIN_APPLICATION_MASK must be non-zero
f0628e2 to
8384fd8
Compare
This was referenced May 12, 2022
djrtwo
reviewed
May 13, 2022
Contributor
djrtwo
left a comment
There was a problem hiding this comment.
Ah, just realized this was added to Bellatrix. Do you think it makes more sense in Phase 0? As it applies to all phases in gneral?
Member
Author
|
yeah makes sense, I'll update |
5ba1812 to
71835c6
Compare
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 <[email protected]>
29 tasks
This file contains hidden or 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
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.