EIP-3030: BLS Remote Signer HTTP API Standard #3030

ghost · 2020-10-08T08:46:35Z

Summary

This EIP defines a HTTP API standard for a BLS remote signer, consumed by validator clients to sign block proposals and attestations in the context of Ethereum 2.0 (eth2).

Discussion Thread

https://ethereum-magicians.org/t/eip-3030-bls-remote-signer-http-api-standard/4810

ghost · 2020-10-08T08:51:41Z

Adding to the discussion:

Hello! Please, do feel free to include more people in this conversation 🙂

DISCUSSION THREAD HERE

MicahZoltu

The frontmatter stuff must be changed, the rest is general feedback left here since there is no discussion link yet.

EIPS/eip-xxxx.md

Co-authored-by: Micah Zoltu <micah@zoltu.net>

holiman · 2020-10-08T12:07:36Z

EIPS/eip-3030.md

+#### Pre-image validation
+
+A key feature for a remote signer, pre-image validation, implies that not only the `signingRoot`, but all the required elements needed to perform complete validation of the message, are sent through the wire to obtain a signature.


I'd argue that pre-image validation is such a core feature that the post-image shouldn't even be sent to the signer. The signer should always be forced to calculate the hash-to-sign locally, given the input + info about signing request (maybe using mimetypes to signal what type of signing is requested)

With this spec, as is, you cement the behaviour of a standard-compliant signer to sign blind checks. Which seems like a very bad idea, IMO

We can do the following then:

Add as required fields domain, the type of message to be produced (randao, block, or attestation), and the specific data per type of message.

It is responsibility of the Remote Signer Client to perform the adequate checks on the received payload in order to admit it and process the signature.

You can also remove the signingRoot parameter. Btw, can you point me towards info about what the signingRoot consists of? Is it the ssz-hash of a full block? or a header? How large is the preimage?

The signingRoot is the string representation of a SHA256 Hash. The result of the Ethereum 2.0 function compute_signing_root.

I see. So, in practice, what's the size of the ssz_object ? Why not send it in it's entirety?
And depending on the size of that -- if it's extremely large, perhaps only portions + proofs/hashes for missing parts?

Fyi this is Prysm's definition. We have a field for the beacon object for additional verifications such as slashing prevention.

https://github.com/prysmaticlabs/prysm/blob/master/proto/validator/accounts/v2/keymanager.proto#L53

It's not a mandatory field, the remote can ignore it

there s one scenario in my head where having the signingRoot together with all the needed fields to recompute it might come in handy, tamper detection. if the sent root and the calculated root mismatch then you have a big problem

In that case, someone is tampering with the traffic. So if they can modify one (e.g. the signingRoot, to sign something else), why wouldn't they tamper with both?
On the one hand, there's a vague argument "it might be handy". So the arguments for including it are:

It may be handy, against a sloppy attack where the attacker modifies one but not both fields

The arguments against including it are:

If it's included, a lazy implementation or insecurely configured signer can choose to blindly sign anything.

If we do not include it, we force to sealer to at least verify that it's a block being sealed, and not something else.

If we do not include it, since the selaer needs to parse the ssz-object, it becomes a very small step to also do at least some basic anti-slashing validations, such as "do not seal same height twice".

well, you are right of course :D thanks ,
pushing for everything to get signeres to not sign anything blindly should be the the goal

holiman · 2020-10-08T12:20:32Z

EIPS/eip-3030.md

+
+#### Authentication
+
+Can be accomplished through the use of an HTTP Request Header. There are several ways to negotiate and issue a valid token to authenticate the communication between the validator client and the remote signer, each of them with potential drawbacks (e.g replay attacks, challenges in distributing the token to the validator client, etc.). In general, any method of authentication must be combined with transport encryption to be effective.


There is no need for authentication if the requestor is not privileged. And it wouldn't be privileged if you removed the need for the signer to trust the signingRoot.
So in essence, you now force the validator to store some sealer-credential, instead of a sealing-key -- just swapping one set of secrets for another.

I agree. This rationale should be more emphatic on the point about swapping of secrets, since it beats the purpose of this API. Please notice that the following paragraph advises the reader to explore the use of network Access Control Lists (ACLs).

terencechain · 2020-10-09T20:18:13Z

EIPS/eip-3030.md

+#### Pre-image validation
+
+A key feature for a remote signer, pre-image validation, implies that not only the `signingRoot`, but all the required elements needed to perform complete validation of the message, are sent through the wire to obtain a signature.


Fyi this is Prysm's definition. We have a field for the beacon object for additional verifications such as slashing prevention.

https://github.com/prysmaticlabs/prysm/blob/master/proto/validator/accounts/v2/keymanager.proto#L53

It's not a mandatory field, the remote can ignore it

terencechain · 2020-10-09T20:20:59Z

EIPS/eip-3030.md

+[BLS Remote Signer](https://github.com/sigp/rust-bls-remote-signer) | Rust | Sigma Prime | Supports proposed specification.
+[Web3signer](https://github.com/PegaSysEng/web3signer) | Java | PegaSys | Supports proposed specification, although with [slightly different methods](https://pegasyseng.github.io/web3signer/web3signer-eth2.html):<br>{`/sign` => `/api/v1/eth2/sign`, `/publicKeys` => `/api/v1/eth2/publicKeys`}.
+
+The Prysm client supports a [Remote Signing Wallet](https://docs.prylabs.network/docs/wallet/remote/), however its API requires using gRPC as transport.


Prysm supports both gRPC and JSON over HTTP. There's a grpc<->json/http proxy. We will update our documentations

EIPS/eip-3030.md

Co-authored-by: Micah Zoltu <micah@zoltu.net>

MicahZoltu

This looks good to merge as a draft. @hermanjunge I encourage you to heed the advice given by Martin and continue to iterate on this in its draft form before submitting a move to Review.

This EIP defines a HTTP API standard for a BLS remote signer, consumed by validator clients to sign block proposals and attestations in the context of Ethereum 2.0 (eth2).

Add draft of the EIP

08093ed

MicahZoltu suggested changes Oct 8, 2020

View reviewed changes

Herman Junge and others added 5 commits October 8, 2020 12:01

Update EIPS/eip-xxxx.md

1b6590d

Co-authored-by: Micah Zoltu <micah@zoltu.net>

Update EIPS/eip-xxxx.md

2102d09

Co-authored-by: Micah Zoltu <micah@zoltu.net>

Update EIPS/eip-xxxx.md

0a39bab

Co-authored-by: Micah Zoltu <micah@zoltu.net>

Rename file

c5df99f

Remove 404 on spec /publicKeys

6c30758

holiman reviewed Oct 8, 2020

View reviewed changes

Adjust definitions

5b9ed19

holiman reviewed Oct 8, 2020

View reviewed changes

Further adjustments

fbf2b9c

ghost changed the title ~~[DRAFT] - BLS Remote Signer HTTP API Standard~~ EIP-3030: BLS Remote Signer HTTP API Standard Oct 8, 2020

Herman Junge added 5 commits October 8, 2020 23:11

Improve tests

4e8f773

Fix parameter definition

61195ad

Edit test result depiction

eadb63c

Edit author

28cc951

Add discussion thread link

cb13fd1

ghost mentioned this pull request Oct 9, 2020

Remote Signer (Tracking Issue) sigp/lighthouse#1637

Closed

terencechain reviewed Oct 9, 2020

View reviewed changes

MicahZoltu reviewed Oct 10, 2020

View reviewed changes

EIPS/eip-3030.md Outdated Show resolved Hide resolved

MicahZoltu reviewed Oct 10, 2020

View reviewed changes

EIPS/eip-3030.md Outdated Show resolved Hide resolved

Herman Junge and others added 2 commits October 11, 2020 19:16

Update EIPS/eip-3030.md

c145013

Co-authored-by: Micah Zoltu <micah@zoltu.net>

Update EIPS/eip-3030.md

c625262

Co-authored-by: Micah Zoltu <micah@zoltu.net>

MicahZoltu approved these changes Oct 13, 2020

View reviewed changes

MicahZoltu merged commit 17eb6ae into ethereum:master Oct 13, 2020

ghost mentioned this pull request Oct 24, 2020

EIP-3030: Update API definition #3069

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

EIP-3030: BLS Remote Signer HTTP API Standard #3030

EIP-3030: BLS Remote Signer HTTP API Standard #3030

ghost commented Oct 8, 2020 •

edited by ghost

Loading

ghost commented Oct 8, 2020 •

edited by ghost

Loading

MicahZoltu left a comment

holiman Oct 8, 2020

holiman Oct 8, 2020

ghost Oct 8, 2020

holiman Oct 9, 2020

ghost Oct 9, 2020

holiman Oct 9, 2020

terencechain Oct 9, 2020

tzapu Oct 12, 2020

holiman Oct 12, 2020

tzapu Oct 12, 2020 •

edited

Loading

holiman Oct 8, 2020

ghost Oct 8, 2020

terencechain Oct 9, 2020

terencechain Oct 9, 2020

MicahZoltu left a comment

		#### Pre-image validation

		A key feature for a remote signer, pre-image validation, implies that not only the `signingRoot`, but all the required elements needed to perform complete validation of the message, are sent through the wire to obtain a signature.


		#### Authentication

		Can be accomplished through the use of an HTTP Request Header. There are several ways to negotiate and issue a valid token to authenticate the communication between the validator client and the remote signer, each of them with potential drawbacks (e.g replay attacks, challenges in distributing the token to the validator client, etc.). In general, any method of authentication must be combined with transport encryption to be effective.

EIP-3030: BLS Remote Signer HTTP API Standard #3030

EIP-3030: BLS Remote Signer HTTP API Standard #3030

Conversation

ghost commented Oct 8, 2020 • edited by ghost Loading

Summary

Discussion Thread

ghost commented Oct 8, 2020 • edited by ghost Loading

MicahZoltu left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

tzapu Oct 12, 2020 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

MicahZoltu left a comment

Choose a reason for hiding this comment

ghost commented Oct 8, 2020 •

edited by ghost

Loading

ghost commented Oct 8, 2020 •

edited by ghost

Loading

tzapu Oct 12, 2020 •

edited

Loading