search

ethereum / keymanager-APIs

Collection of RESTful APIs provided by Ethereum consensus keymanagers
https://ethereum.github.io/keymanager-APIs/
Creative Commons Zero v1.0 Universal
38 stars 19 forks source link

Fee Recipient Post Merge (WIP) #23

Closed james-prysm closed 2 years ago

james-prysm commented 2 years ago

Post Merge, consensus clients will need to set an Eth 1 account when running a validator/beacon Chain in order to receive the fees on processing transactions while proposing a block. Currently, PoS validators only receive funds from the protocol and do not receive fees on the transactions themselves. Users would like a way to tell the Validator Client/ Beacon Node to change the fee recipients dynamically while the system is running.

Each validator index ( not public key according to this api https://github.com/ethereum/beacon-APIs/pull/178) can have a fee recipient.

james-prysm commented 2 years ago

How do we protect this endpoint 🤔 ? is it merged into the existing endpoints or separate?

dapplion commented 2 years ago

To clarify this would be added to a validator_client oapi file not the keymanager right? Drawing similarities, the keymanager API does not handle graffiti.

g11tech commented 2 years ago

To clarify this would be added to a validator_client oapi file not the keymanager right? Drawing similarities, the keymanager API does not handle graffiti.

I think thats the proposal: to have a patch request to update fee-recipient (and may be graffiti too). Then the validator will update the beacon using beacon proposer api call. Right @james-prysm ?

But wouldn't this also necessitate a mappings DB validator side, as far as you know, your current implementation has this mapping updated in db beacon side.

james-prysm commented 2 years ago

I think thats the proposal: to have a patch request to update fee-recipient (and may be graffiti too). Then the validator will update the beacon using beacon proposer api call. Right @james-prysm ?

right for dynamic updating otherwise it'll use the burn address if you don't use any of the validator flags

But wouldn't this also necessitate a mappings DB validator side, as far as you know, your current implementation has this mapping updated in db beacon side.

i have it stored in memory right now but if the validator restarts it should probably use the updated file? we have it persisting on the beacon node side.

james-prysm commented 2 years ago

first spec used for fee recipient api merged in, closing issue.