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

core/validatorapi: add SubmitBeaconBlock to validatorapi #409

Merged
merged 4 commits into from
Apr 11, 2022

Conversation

dB2510
Copy link
Contributor

@dB2510 dB2510 commented Apr 9, 2022

Adds support for submit Partially signed beacon block to validatorapi.

category: feature
ticket: #225

@codecov
Copy link

codecov bot commented Apr 9, 2022

Codecov Report

❗ No coverage uploaded for pull request base (main@2c477b3). Click here to learn what that means.
The diff coverage is 65.51%.

@@           Coverage Diff           @@
##             main     #409   +/-   ##
=======================================
  Coverage        ?   56.98%           
=======================================
  Files           ?       63           
  Lines           ?     5605           
  Branches        ?        0           
=======================================
  Hits            ?     3194           
  Misses          ?     1992           
  Partials        ?      419           
Impacted Files Coverage Δ
core/types.go 41.66% <0.00%> (ø)
testutil/beaconmock/beaconmock.go 66.66% <0.00%> (ø)
core/encode.go 58.08% <41.66%> (ø)
core/validatorapi/validatorapi.go 51.43% <65.57%> (ø)
core/validatorapi/router.go 64.70% <97.56%> (ø)

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 2c477b3...4a97cc2. Read the comment docs.

if err != nil {
return errors.Wrap(err, "getting slots per epoch")
}
epoch := eth2p0.Epoch(uint64(slot) / slotsPerEpoch)
Copy link
Contributor

Choose a reason for hiding this comment

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

@dB2510 we are doing this in several places, perhaps we should create an issue to generalise it

Copy link
Contributor

Choose a reason for hiding this comment

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

Yeah, a function in this package called epochFromSlot is probably not a bad idea. We could also do PR to add eth2client.EpochFromSlotProvider to upstream client repo.

// core.Duty{Slot: slot, Type: core.DutyProposer}
// vs
// core.NewProposerDuty(slot)
func NewProposerDuty(slot int64) Duty {
Copy link
Contributor

Choose a reason for hiding this comment

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

@dB2510 slot is an uint64 or eth2p0.Slot

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Added this to align with the other similar types: NewAttesterDuty and NewRandaoDuty in the same file.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Maybe we can address this later as part of this issue: #383

Copy link
Contributor

Choose a reason for hiding this comment

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

yeah, it can also be done as big refactor when we do that issue

@@ -184,3 +184,49 @@ func DecodeProposerUnsignedData(unsignedData UnsignedData) (*spec.VersionedBeaco

return proData, nil
}

// EncodeBlockParSignedData returns the partially signed block data as an encoded ParSignedData.
func EncodeBlockParSignedData(block *spec.VersionedSignedBeaconBlock, shareIdx int) (ParSignedData, error) {
Copy link
Contributor

Choose a reason for hiding this comment

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

@dB2510 wouldn't it make sense if EncodeBlockParSignedData would be an accesor of spec.VersionedSignedBeaconBlock and DecodeBlockParSignedData a constructor of ParSignedData ?

Copy link
Contributor

@corverroos corverroos Apr 11, 2022

Choose a reason for hiding this comment

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

We prefer to keep data and logic separate. Pure functions and pure data.

As per golang guidelines: Functions over methods.

Copy link
Contributor

Choose a reason for hiding this comment

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

Also, spec.VersionedSignedBeaconBlock isn't our type. So we cannot add methods to it.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

yeah right, spec.VersionedSignedBeaconBlock is go-eth2-client's type that we are using.

Copy link
Contributor

@leolara leolara left a comment

Choose a reason for hiding this comment

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

approved with comments

Copy link
Contributor

@corverroos corverroos left a comment

Choose a reason for hiding this comment

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

Looks good! Just need to figure out the block version thing

@@ -184,3 +184,49 @@ func DecodeProposerUnsignedData(unsignedData UnsignedData) (*spec.VersionedBeaco

return proData, nil
}

// EncodeBlockParSignedData returns the partially signed block data as an encoded ParSignedData.
func EncodeBlockParSignedData(block *spec.VersionedSignedBeaconBlock, shareIdx int) (ParSignedData, error) {
Copy link
Contributor

Choose a reason for hiding this comment

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

Also, spec.VersionedSignedBeaconBlock isn't our type. So we cannot add methods to it.

func submitBlock(p eth2client.BeaconBlockSubmitter) handlerFunc {
return func(ctx context.Context, params map[string]string, query url.Values, body []byte) (interface{}, error) {
var phase0Block *eth2p0.SignedBeaconBlock
err := phase0Block.UnmarshalJSON(body)
Copy link
Contributor

Choose a reason for hiding this comment

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

problem: decoding json isn't a good way to detect block type, since json is very flexible, especially if some fields overlap and the general structure is the same. This first phase0 check will probably succeed for all block types. Suggest adding a test for other block types.

We should probably look at what the differences are between the versions/types. I'm guessing fields were added mostly and the newer types are backwards compatible with older data. That means we should probably just use the latest version always.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I think using latest version will create problems for us testing with old testnets like prater/kiln, have to check what's block version there. Latest one would be bellatrix though (the name of merge hard fork)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Also to check what gnosis is having

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Note: prater has altair beacon block version.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

using latest version should work

if err != nil {
return errors.Wrap(err, "getting slots per epoch")
}
epoch := eth2p0.Epoch(uint64(slot) / slotsPerEpoch)
Copy link
Contributor

Choose a reason for hiding this comment

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

Yeah, a function in this package called epochFromSlot is probably not a bad idea. We could also do PR to add eth2client.EpochFromSlotProvider to upstream client repo.

}
epoch := eth2p0.Epoch(uint64(slot) / slotsPerEpoch)

var sig eth2p0.BLSSignature
Copy link
Contributor

Choose a reason for hiding this comment

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

structure: can probably extract this as function getBlockSignature

Copy link
Contributor

Choose a reason for hiding this comment

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

or rather extract the whole verifyBlockSignature as a function

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Sure!

if err != nil {
return err
}
pubkey, _, err := c.awaitBlockFunc(ctx, int64(slot))
Copy link
Contributor

Choose a reason for hiding this comment

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

Since there is a TODO to remove pubkey from awaitBlockFunc (see above), you should rather call awaitProposerFunc.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Got it!

@corverroos corverroos added the do not merge Indicate to bulldozer bot that this PR should not be merged label Apr 11, 2022
Copy link
Contributor

@corverroos corverroos left a comment

Choose a reason for hiding this comment

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

LGTM

@corverroos corverroos removed the do not merge Indicate to bulldozer bot that this PR should not be merged label Apr 11, 2022
@dB2510 dB2510 added the merge when ready Indicates bulldozer bot may merge when all checks pass label Apr 11, 2022
@obol-bulldozer obol-bulldozer bot merged commit 023f894 into main Apr 11, 2022
@obol-bulldozer obol-bulldozer bot deleted the dhruv/dutypro_vapis branch April 11, 2022 18:46
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
merge when ready Indicates bulldozer bot may merge when all checks pass
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants