Skip to content
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

Change BLS Public Key Length Check in Beacon RPC Server #1571

Merged
merged 11 commits into from
Feb 13, 2019

Conversation

rauljordan
Copy link
Contributor

@rauljordan rauljordan commented Feb 12, 2019

Part of #1565


Description

Write why you are making the changes in this pull request

Currently, our beacon RPC server checks if the public key in the assignments request is of length 48, however, our BLS library created by Herumi has pubkeys of length 96. Until we find a better BLS library or roll out our own, we will be stuck with a crashing runtime due to this strict check.

Write a summary of the changes you are making

This changes the length to global config param which can be checked against instead of a magic number.

@rauljordan rauljordan self-assigned this Feb 12, 2019
@rauljordan rauljordan added the Ready For Review A pull request ready for code review label Feb 12, 2019
@rauljordan rauljordan added this to the Sapphire milestone Feb 12, 2019
@codecov
Copy link

codecov bot commented Feb 12, 2019

Codecov Report

❗ No coverage uploaded for pull request base (master@c4ad6f2). Click here to learn what that means.
The diff coverage is n/a.

@@            Coverage Diff            @@
##             master    #1571   +/-   ##
=========================================
  Coverage          ?   71.84%           
=========================================
  Files             ?       99           
  Lines             ?     6674           
  Branches          ?        0           
=========================================
  Hits              ?     4795           
  Misses            ?     1470           
  Partials          ?      409

@@ -43,8 +43,8 @@ func (vs *ValidatorServer) ValidatorEpochAssignments(
ctx context.Context,
req *pb.ValidatorEpochAssignmentsRequest,
) (*pb.ValidatorEpochAssignmentsResponse, error) {
if len(req.PublicKey) != 48 {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why change this? Didn't we have panics where invalid public keys were sent?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

IMO, this needs to be fixed to the expectation size. If it's 96 now then it should be 96.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

pub key size should really become its own variable if it's referenced in multiple places

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes, it can be a params constant

@@ -171,7 +188,7 @@ func TestValidatorCommitteeAtSlot_CrosslinkCommitteesFailure(t *testing.T) {
}
}

func TestValidatorCommitteeAtSlot_Ok(t *testing.T) {
func TestValidatorEpochAssignments_CorrectAssign(t *testing.T) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

CorrectAssign? Can you make this human readable?

@nisdas
Copy link
Member

nisdas commented Feb 13, 2019

@rauljordan This would clash with the spec though, a lot of the data structures take the public keys as 48 bytes, cant we just lop off half the bits to create a public key with 48 bytes as a temporary solution ?

@terencechain
Copy link
Member

From eth2.0 spec's point of view, it doesn't care for the size of the pub key, it's all abstracted out. As long this doesn't break bls_verify (which I don't think it should) then we are good

@nisdas
Copy link
Member

nisdas commented Feb 13, 2019

@terenc3t data structures like this https://github.com/ethereum/eth2.0-specs/blob/master/specs/core/0_beacon-chain.md#depositinput , and also https://github.com/ethereum/eth2.0-specs/blob/master/specs/bls_signature.md#bls_verify in the bls spec assume 48 bytes. Also the deposit_data argument for the deposit function in the deposit contract is hardcoded to expect a pubkey of 48 bytes not 96 bytes. Its not really abstracted away; we could change all this to 96 bytes, but why not just cut off the last 48 bytes of the pub key ? That way we are still in sync with the spec

@terencechain
Copy link
Member

I see. That makes sense for the time being but we won't be compatible with rest of the clients :P

@rauljordan
Copy link
Contributor Author

In my opinion, once we implement our own BLS we'll have 48byte pubkeys, so this won't be an issue. The cutoff thing sounds a bit weird to do, so I'd rather just stick to this for now until we have our BLS that is in line with the spec.

@rauljordan rauljordan merged commit f707f14 into master Feb 13, 2019
@rauljordan rauljordan deleted the less-strict-length branch February 13, 2019 18:08
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Ready For Review A pull request ready for code review
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants