feat(eth2api): add submit_proposal_preparations client method#549
feat(eth2api): add submit_proposal_preparations client method#549emlautarom1-agent[bot] wants to merge 1 commit into
submit_proposal_preparations client method#549Conversation
Add a `submit_proposal_preparations` extension method on
`EthBeaconNodeApiClient` (POST /eth/v1/validator/prepare_beacon_proposer)
so a Pluto node can send fee-recipient proposal preparations to its own
beacon node. Mirrors go-eth2-client's `SubmitProposalPreparations`
(Charon app/app.go setFeeRecipient).
- New `ProposalPreparation { validator_index, fee_recipient }` type.
- Method serializes to `[{validator_index, fee_recipient}]` per the
beacon API spec and maps a non-200 response to an error.
- beaconmock now records submitted preparations at a recording route
(higher priority than the default swallow handler) and exposes them
via `MockState::proposal_preparations` for the follow-up fee-recipient
subscriber tests.
- Unit tests cover body serialization, the success path, the error
path, accumulation across submissions, and invalid-body rejection.
Part of #402. Closes #527.
![emlautarom1-agent[bot]](https://avatars.githubusercontent.com/u/31224949?s=60&v=4){kind=small}
| /// Priority for the recording route; lower value (higher priority) than the | ||
| /// default 200 handler in `defaults.rs`, so submissions are captured instead of | ||
| /// silently swallowed. | ||
| const PROPOSAL_PREPARATION_PRIORITY: u8 = 100; |
There was a problem hiding this comment.
Differs from Charon. Charon's beaconmock no-ops this endpoint (testutil/beaconmock/server.go); here it records instead. defaults.rs already mounts a 200-swallow route at the default priority 255, so this recording route must sit at a higher priority (lower number) to win — hence 100, matching the attestation store's override pattern. Without it, submissions would hit the swallow route and never be recorded.
| .iter() | ||
| .map(|preparation| PrepareBeaconProposerRequestBodyItem { | ||
| validator_index: preparation.validator_index.to_string(), | ||
| fee_recipient: format!("0x{}", hex::encode(preparation.fee_recipient)), |
There was a problem hiding this comment.
Parity quirk. fee_recipient is intentionally lowercase 0x-hex, not EIP-55 checksummed. This matches go-eth2-client's ExecutionAddress.String() (%#x) that the beacon node receives — deliberately not the checksumming bellatrix::execution_address_serde used elsewhere in this crate, which is for a different (response) code path. The spec pattern ^0x[a-fA-F0-9]{40}$ accepts either case.
| .await? | ||
| { | ||
| PrepareBeaconProposerResponse::Ok => Ok(()), | ||
| _ => Err(EthBeaconNodeApiClientError::UnexpectedResponse), |
There was a problem hiding this comment.
Consistency. Non-2xx collapses to UnexpectedResponse, dropping the node's code/message. Chosen to match the existing wrappers in this file (get_spec/get_genesis/get_fork_schedule) rather than introduce a new error-detail shape here.
emlautarom1
changed the title
submit_proposal_preparations client method
emlautarom1
left a comment
emlautarom1
left a comment
There was a problem hiding this comment.
Manually checked, LGTM. Adds a single extension method over the eth2api and some test code.
1 participant
Closes #527.
Summary
Adds the client half of proposal preparations:
EthBeaconNodeApiClient::submit_proposal_preparations, which forwards fee-recipient preparations to a node's own beacon node (POST /eth/v1/validator/prepare_beacon_proposer). Until now only the VC-facing router handler existed, so a Pluto node could accept preparations from its validator client but had no way to relay them upstream. This is the prerequisite for thesetFeeRecipientslot subscriber, which republishes preparations at the start of each epoch.The method mirrors go-eth2-client's
SubmitProposalPreparations— the call Charon'ssetFeeRecipientmakes inapp/app.go. It takes a list ofProposalPreparation { validator_index, fee_recipient }and serializes each to{ validator_index: <decimal string>, fee_recipient: <0x address> }, matching the beacon API spec and go-eth2-client's JSON encoding.Differences from Charon
testutil/beaconmock/server.go). Pluto captures each submission and exposes it throughMockState::proposal_preparations, so the follow-up subscriber can be exercised end-to-end against the mock — which is the reason the mock side is built here at all.submit_proposal_preparationsbuilds on the code-generatedprepare_beacon_proposerclient and puts an ergonomic, strongly-typedProposalPreparationin front of the stringly-typed generated request body.UnexpectedResponserather than surfacing the beacon node'scode/message, consistent with the other wrappers in this crate.Out of scope
The
setFeeRecipientslot subscriber that drives this method once per epoch is a separate follow-up ticket; this PR lands only the client method and the mock support it depends on.