ethereum / builder-specs

Specification for the external block builders.
https://ethereum.github.io/builder-specs/
Creative Commons Zero v1.0 Universal
179 stars 61 forks source link

clarify builder signing domain #39

Closed tersec closed 2 years ago

tersec commented 2 years ago

This spec is not, however, written in Python pseudocode. Even after reading that's the intent, it's not something that I'd read into the actual prose.

Nothing about

Signing

All signature operations should follow the [standard BLS operations][bls] interface defined in consensus-specs.

To assist in signing, we use a function from the [consensus specs][consensus-specs]: [compute_domain][compute-domain]

There are two types of data to sign over in the Builder API:

  • In-protocol messages, e.g. BlindedBeaconBlock, which should compute the signing root using [compute_signing_root][compute-root] and use the domain specified for beacon block proposals.
  • Builder API messages, e.g. validator registration, which should compute the signing root using [compute_signing_root][compute-root] with domain given by compute_domain(DOMAIN_APPLICATION_BUILDER). As compute_signing_root takes SSZObject as input, client software should convert in-protocol messages to their SSZ representation to compute the signing root and Builder API messages to the SSZ representations defined above.

suggests Python semantics on the level of default arguments are more than accidental.

ralexstokes commented 2 years ago

To assist in signing, we use a function from the [consensus specs][consensus-specs]: [compute_domain][compute-domain]

I think this makes it clear, but like I said I'm open to clarifying further.

Do you like the way I wrote it above or would you rather spell out the data like you did here?

tersec commented 2 years ago

Do you like the way I wrote it above or would you rather spell out the data like you did here?

I do like your suggested approach: https://github.com/ethereum/builder-specs/pull/39/commits/8f68a98d61fc1200d7ed93d4a9d58c7886e54054