[Merged by Bors] - Standard beacon api updates #1831
Conversation
…ties once per epoch
…dard-beacon-api-updates � Conflicts: � beacon_node/http_api/src/lib.rs � common/eth2/src/lib.rs
…dard-beacon-api-updates � Conflicts: � beacon_node/http_api/tests/tests.rs
…dard-beacon-api-updates � Conflicts: � beacon_node/http_api/src/lib.rs
…lighthouse into standard-beacon-api-updates
| pubkey: PublicKey, | ||
| ) -> Result<ValidatorDuty, String> { | ||
| let pubkey_bytes = PublicKeyBytes::from(&pubkey); | ||
| mut known_pubkeys: Vec<(PublicKey, u64)>, |
There was a problem hiding this comment.
I have an alternate pattern, feel free to ignore if you like.
Instead of known_pubkeys and unknown_pubkeys, just have a pubkeys: &[(PublicKey, Option<u64>)]. Then, before the for loop on L64, define an indices = Vec::with_capacity(pubkeys.len()) and push into it whenever you discover a validator index.
This removes known_pubkeys from this function and the caller, replacing it with indicies which is in this function only. It also removes an iteration on L85.
There was a problem hiding this comment.
Ok, I added this in, but needed an additional way to track the pubkeys of the validator indices we query for. They become necessary when creating empty duties for validators we query for but get no results for. Let me know what you think.
| vec![] | ||
| }; | ||
| .into_iter() | ||
| .map(|data| (data.validator_index, data)) |
There was a problem hiding this comment.
I get the feeling that if we mapped into a ValidatorDuty here, instead of on L114, we could avoid the proposal_slots_by_index map.
It's really not a big deal at all, I just thought I'd mention it.
There was a problem hiding this comment.
I was able to get rid of the attester_duties_by_slot map, but now need to use the pubkey returned by the query for the duty as opposed to the pubkey we have locally. Not that they should be different, but there's an extra deserialization.
I also mapped the result of this query to validator indices to compare with indices we queried for so we can create any remaining empty duties. Let me know if this is along the lines you were thinking.. the codes still a bit ugly, but I'm not really sure how to clean it up further
## Issue Addressed Resolves #1809 Resolves #1824 Resolves #1818 Resolves #1828 (hopefully) ## Proposed Changes - add `validator_index` to the proposer duties endpoint - add the ability to query for historical proposer duties - `StateId` deserialization now fails with a 400 warp rejection - add the `validator_balances` endpoint - update the `aggregate_and_proofs` endpoint to accept an array - updates the attester duties endpoint from a `GET` to a `POST` - reduces the number of times we query for proposer duties from once per slot per validator to only once per slot Co-authored-by: realbigsean <seananderson33@gmail.com> Co-authored-by: Paul Hauner <paul@paulhauner.com>
|
Pull request successfully merged into master. Build succeeded: |
Issue Addressed
Resolves #1809
Resolves #1824
Resolves #1818
Resolves #1828 (hopefully)
Proposed Changes
validator_indexto the proposer duties endpointStateIddeserialization now fails with a 400 warp rejectionvalidator_balancesendpointaggregate_and_proofsendpoint to accept an arrayGETto aPOST