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

Block rewards API endpoint #12020

Merged
merged 56 commits into from
Mar 28, 2023
Merged

Block rewards API endpoint #12020

merged 56 commits into from
Mar 28, 2023

Conversation

rkapka
Copy link
Contributor

@rkapka rkapka commented Feb 20, 2023

What type of PR is this?

Feature

What does this PR do? Why is it needed?

Implements https://ethereum.github.io/beacon-APIs/?urls.primaryName=dev#/Beacon/getBlockRewards

Notes:

  • Because it's not possible to calculate attestation rewards in Phase 0 before the end of the next epoch, we would need extra logic for this. Therefore Phase 0 is not supported in the API.
  • I created a blockfetcher equivalent of statefercher for code reuse.
  • I moved the creation of mux router from api/gateway/gateway.go to beacon-chain/server/main.go, so that the same router can be used for pure http endpoints and gprc-gateway endpoints .

Which issues(s) does this PR fix?

Part of #11952

# Conflicts:
#	beacon-chain/rpc/eth/beacon/blocks.go
#	testing/spectest/shared/altair/operations/sync_committee.go
#	testing/spectest/shared/bellatrix/operations/sync_committee.go
#	testing/spectest/shared/capella/operations/sync_committee.go
@rkapka rkapka marked this pull request as ready for review February 21, 2023 14:38
@rkapka rkapka requested a review from a team as a code owner February 21, 2023 14:38
@rkapka rkapka added Ready For Review A pull request ready for code review API Api related tasks labels Feb 21, 2023
@rkapka rkapka removed the Ready For Review A pull request ready for code review label Feb 24, 2023
rkapka added 4 commits March 1, 2023 14:14
# Conflicts:
#	beacon-chain/core/altair/block.go
#	beacon-chain/core/altair/block_test.go
#	beacon-chain/rpc/eth/beacon/blocks_test.go
g := &Gateway{
ctx: ctx,
cfg: &config{
router: mux.NewRouter(),
router: router,
Copy link
Contributor

Choose a reason for hiding this comment

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

Could we make this an Option? Then after all for loop that applies the Options runs, we can check if the router field is nil, and if so give it a default value of mux.NewRouter. That way tests don't need to specify it when they don't want to customize the router.

There could be Options that want to rely on the router, which would make ordering tricky, but it's probably best for Options to not reach down into other fields anyway, since that creates fragile ordering assumptions. So Options like that would have to make sure to specify a router and do any route registration or other changes to the router before passing it as an Option to New.

if err != nil {
log.Fatal(err)
}

r := mux.NewRouter()
r.HandleFunc("/swagger/", gateway.SwaggerServer())
r.HandleFunc("/healthz", healthzServer(gw))
gw.SetRouter(r)
Copy link
Contributor

Choose a reason for hiding this comment

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

You are already setting the router to this value in gateway.New so I assume you do not need to use SetRouter here.

return
}
attsReward := newBalance - oldBalance
oldBalance = newBalance
Copy link
Contributor

@kasey kasey Mar 22, 2023

Choose a reason for hiding this comment

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

This old/new balance variable juggling is a little tricky, I wonder if it could be easier to read if you used a separate variable for the balance at each step, then at the end you could have:
Attestations: attBalance - initBalance, and so on
wdyt?

Finalized bool `json:"finalized"`
}

type BlockRewards struct {
Copy link
Contributor

Choose a reason for hiding this comment

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

Why do we need this type - do we never need to read unmarshal a value into BlockRewards? Could this be a bit simpler if the handler used BlockRewardsJson and explicitly converted values to strings, so the value can just be passed to standard json.Marshal?

"github.com/prysmaticlabs/prysm/v4/testing/require"
)

func TestMarshalBlockRewards(t *testing.T) {
Copy link
Contributor

@kasey kasey Mar 22, 2023

Choose a reason for hiding this comment

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

You could basically delete this entire file of tests if the handler can directly use BlockRewardsJson.

}

// BeaconDbBlocker is an implementation of Blocker. It retrieves blocks from the beacon chain database.
type BeaconDbBlocker struct {
Copy link
Contributor

Choose a reason for hiding this comment

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

Nice job on this refactor, looks great!

State(ctx context.Context, stateId []byte) (state.BeaconState, error)
StateRoot(ctx context.Context, stateId []byte) ([]byte, error)
// Stater is responsible for retrieving states.
type Stater interface {
Copy link
Contributor

Choose a reason for hiding this comment

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

nice!

blks := make([]interfaces.ReadOnlySignedBeaconBlock, count)
blkContainers := make([]*ethpbalpha.BeaconBlockContainer, count)
for i := primitives.Slot(0); i < count; i++ {
b := util.NewBeaconBlock()
Copy link
Contributor

Choose a reason for hiding this comment

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

Noticing that this makes phase0 blocks but your rewards code wants > phase0.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

this has nothing to do with rewards, it's used only in TestGetBlock

kasey
kasey previously approved these changes Mar 24, 2023
@rkapka rkapka dismissed stale reviews from ghost and kasey via 874fb41 March 28, 2023 15:39
Copy link
Contributor

@james-prysm james-prysm left a comment

Choose a reason for hiding this comment

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

ok with the recent changes, with the caveat that router options such as cors will be taken care of in a later PR and that kasey oked the core logic of the API.

@rkapka rkapka merged commit 98949d8 into develop Mar 28, 2023
@rkapka rkapka deleted the block-rewards branch March 28, 2023 16:44
rkapka added a commit that referenced this pull request Mar 30, 2023
Co-authored-by: terencechain <terence@prysmaticlabs.com>
Co-authored-by: prylabs-bulldozer[bot] <58059840+prylabs-bulldozer[bot]@users.noreply.github.com>
james-prysm pushed a commit that referenced this pull request Apr 3, 2023
Co-authored-by: terencechain <terence@prysmaticlabs.com>
Co-authored-by: prylabs-bulldozer[bot] <58059840+prylabs-bulldozer[bot]@users.noreply.github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
API Api related tasks 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