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

mark v1 block publishing deprecated #8520

Open
rolfyone opened this issue Aug 21, 2024 · 4 comments
Open

mark v1 block publishing deprecated #8520

rolfyone opened this issue Aug 21, 2024 · 4 comments
Assignees
Labels
good first issue 🙋 This is a good first issue for a new contributor to work on

Comments

@rolfyone
Copy link
Contributor

ethereum/beacon-APIs#467

In line with the beacon-apis PR, we should go ahead and mark our v1 block endpoints as deprecated.

This basically involves

  • adding a deprecated attribute to the PostBlindedBlock offering /eth/v1/beacon/blinded_blocks
  • and PostBlock offering /eth/v1/beacon/blocks

Maybe a text search just to make sure we're not using the POST anywhere else but its unlikely. This is a pretty good first issue, it should show up in our integration tests as deprecated when they run and also need that change made (updating reference files appropriately)

@rolfyone rolfyone added the good first issue 🙋 This is a good first issue for a new contributor to work on label Aug 21, 2024
@hudlerrr
Copy link

Hi @rolfyone could I get this issue assigned :)

@aslikaya
Copy link
Contributor

aslikaya commented Sep 7, 2024

Maybe a text search just to make sure we're not using the POST anywhere else but its unlikely.

@rolfyone Do you mean PostBlindedBlock and PostBlock? They are not used somewhere other than tests and JsonTypeDefinitionBeaconRestApi

by the way we worked with @hudlerrr together on this

@rolfyone
Copy link
Contributor Author

rolfyone commented Sep 8, 2024

Hey - That's correct, the two classes are PostBlindedBlock and PostBlock classes offer those 2 classes.

If we search for the endpoint (eg. v1/beacon/blocks) it'll come up in the validator api constants, and we're just confirming that nothing uses those constants... so above maps to SEND_SIGNED_BLOCK and nothing references that constant now so that'll basically mean that we're not calling the V1 endpoint on the validator side.

Often they don't have a / at the start of /eth so its worth just searching for from the version tag.... I'll let you check the blinded one in a similar way, just making sure the blinded_blocks URL isn't referenced (it'll be in the validator constants though in `ValidatorApiMethod') and the method reference isn't used... If you get stuck here I can always double check...

@aslikaya
Copy link
Contributor

aslikaya commented Sep 9, 2024

Thanks for your help @rolfyone We just searched for instances of those classes previously. I just did the text search for those endpoints. They don't seem to be used anywhere else other than ValidatorApiMethod and their respective classes (PostBlindedBlock, PostBlock). There are other endpoints sharing the same initial path with those, we don't do anything with them, right?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
good first issue 🙋 This is a good first issue for a new contributor to work on
Projects
None yet
Development

No branches or pull requests

3 participants