mirror of
https://github.com/sigp/lighthouse.git
synced 2026-04-17 04:48:21 +00:00
Implement feerecipient API for keymanager (#3213)
## Issue Addressed * #3173 ## Proposed Changes Moved all `fee_recipient_file` related logic inside the `ValidatorStore` as it makes more sense to have this all together there. I tested this with the validators I have on `mainnet-shadow-fork-5` and everything appeared to work well. Only technicality is that I can't get the method to return `401` when the authorization header is not specified (it returns `400` instead). Fixing this is probably quite difficult given that none of `warp`'s rejections have code `401`.. I don't really think this matters too much though as long as it fails.
This commit is contained in:
ethDreamer
@@ -26,14 +26,9 @@ Lighthouse BN also provides a method for defining this value, should the VC not
|
||||
Assuming trustworthy nodes, the priority for the four methods is:
|
||||
|
||||
1. `validator_definitions.yml`
|
||||
1. `--suggested-fee-recipient-file`
|
||||
1. `--suggested-fee-recipient` provided to the VC.
|
||||
1. `--suggested-fee-recipient` provided to the BN.
|
||||
|
||||
Users may configure the fee recipient via `validator_definitions.yml` or via the
|
||||
`--suggested-fee-recipient-file` flag. The value in `validator_definitions.yml` will always take
|
||||
precedence.
|
||||
|
||||
### 1. Setting the fee recipient in the `validator_definitions.yml`
|
||||
|
||||
Users can set the fee recipient in `validator_definitions.yml` with the `suggested_fee_recipient`
|
||||
@@ -56,36 +51,111 @@ Below is an example of the validator_definitions.yml with `suggested_fee_recipie
|
||||
suggested_fee_recipient: "0xa2e334e71511686bcfe38bb3ee1ad8f6babcc03d"
|
||||
```
|
||||
|
||||
### 2. Using the "--suggested-fee-recipient-file" flag on the validator client
|
||||
|
||||
Users can specify a file with the `--suggested-fee-recipient-file` flag. This option is useful for dynamically
|
||||
changing fee recipients. This file is reloaded each time a validator is chosen to propose a block.
|
||||
|
||||
Usage:
|
||||
`lighthouse vc --suggested-fee-recipient-file fee_recipient.txt`
|
||||
|
||||
The file should contain key value pairs corresponding to validator public keys and their associated
|
||||
fee recipient. The file can optionally contain a `default` key for the default case.
|
||||
|
||||
The following example sets the default and the values for the validators with pubkeys `0x87a5` and
|
||||
`0xa556`:
|
||||
|
||||
```
|
||||
default: 0x6cc8dcbca744a6e4ffedb98e1d0df903b10abd21
|
||||
0x87a580d31d7bc69069b55f5a01995a610dd391a26dc9e36e81057a17211983a79266800ab8531f21f1083d7d84085007: 0x6cc8dcbca744a6e4ffedb98e1d0df903b10abd21
|
||||
0xa5566f9ec3c6e1fdf362634ebec9ef7aceb0e460e5079714808388e5d48f4ae1e12897fed1bea951c17fa389d511e477: 0xa2e334e71511686bcfe38bb3ee1ad8f6babcc03d
|
||||
```
|
||||
|
||||
Lighthouse will first search for the fee recipient corresponding to the public key of the proposing
|
||||
validator, if there are no matches for the public key, then it uses the address corresponding to the
|
||||
default key (if present).
|
||||
|
||||
### 3. Using the "--suggested-fee-recipient" flag on the validator client
|
||||
### 2. Using the "--suggested-fee-recipient" flag on the validator client
|
||||
|
||||
The `--suggested-fee-recipient` can be provided to the VC to act as a default value for all
|
||||
validators where a `suggested_fee_recipient` is not loaded from another method.
|
||||
|
||||
### 4. Using the "--suggested-fee-recipient" flag on the beacon node
|
||||
### 3. Using the "--suggested-fee-recipient" flag on the beacon node
|
||||
|
||||
The `--suggested-fee-recipient` can be provided to the BN to act as a default value when the
|
||||
validator client does not transmit a `suggested_fee_recipient` to the BN.
|
||||
|
||||
## Setting the fee recipient dynamically using the keymanager API
|
||||
|
||||
When the [validator client API](api-vc.md) is enabled, the
|
||||
[standard keymanager API](https://ethereum.github.io/keymanager-APIs/) includes an endpoint
|
||||
for setting the fee recipient dynamically for a given public key. When used, the fee recipient
|
||||
will be saved in `validator_definitions.yml` so that it persists across restarts of the validator
|
||||
client.
|
||||
|
||||
| Property | Specification |
|
||||
| --- | --- |
|
||||
Path | `/eth/v1/validator/{pubkey}/feerecipient`
|
||||
Method | POST
|
||||
Required Headers | [`Authorization`](./api-vc-auth-header.md)
|
||||
Typical Responses | 202, 404
|
||||
|
||||
#### Example Request Body
|
||||
```json
|
||||
{
|
||||
"ethaddress": "0x1D4E51167DBDC4789a014357f4029ff76381b16c"
|
||||
}
|
||||
```
|
||||
|
||||
```bash
|
||||
DATADIR=$HOME/.lighthouse/mainnet
|
||||
PUBKEY=0xa9735061c84fc0003657e5bd38160762b7ef2d67d280e00347b1781570088c32c06f15418c144949f5d736b1d3a6c591
|
||||
FEE_RECIPIENT=0x1D4E51167DBDC4789a014357f4029ff76381b16c
|
||||
|
||||
curl -X POST \
|
||||
-H "Authorization: Bearer $(cat ${DATADIR}/validators/api-token.txt)" \
|
||||
-H "Content-Type: application/json" \
|
||||
-d "{ \"ethaddress\": \"${FEE_RECIPIENT}\" }" \
|
||||
http://localhost:5062/eth/v1/validator/${PUBKEY}/feerecipient | jq
|
||||
```
|
||||
|
||||
#### Successful Response (202)
|
||||
```json
|
||||
null
|
||||
```
|
||||
|
||||
### Querying the fee recipient
|
||||
|
||||
The same path with a `GET` request can be used to query the fee recipient for a given public key at any time.
|
||||
|
||||
| Property | Specification |
|
||||
| --- | --- |
|
||||
Path | `/eth/v1/validator/{pubkey}/feerecipient`
|
||||
Method | GET
|
||||
Required Headers | [`Authorization`](./api-vc-auth-header.md)
|
||||
Typical Responses | 200, 404
|
||||
|
||||
```bash
|
||||
DATADIR=$HOME/.lighthouse/mainnet
|
||||
PUBKEY=0xa9735061c84fc0003657e5bd38160762b7ef2d67d280e00347b1781570088c32c06f15418c144949f5d736b1d3a6c591
|
||||
|
||||
curl -X GET \
|
||||
-H "Authorization: Bearer $(cat ${DATADIR}/validators/api-token.txt)" \
|
||||
-H "Content-Type: application/json" \
|
||||
http://localhost:5062/eth/v1/validator/${PUBKEY}/feerecipient | jq
|
||||
```
|
||||
|
||||
#### Successful Response (200)
|
||||
```json
|
||||
{
|
||||
"data": {
|
||||
"pubkey": "0xa9735061c84fc0003657e5bd38160762b7ef2d67d280e00347b1781570088c32c06f15418c144949f5d736b1d3a6c591",
|
||||
"ethaddress": "0x1d4e51167dbdc4789a014357f4029ff76381b16c"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### Removing the fee recipient
|
||||
|
||||
The same path with a `DELETE` request can be used to remove the fee recipient for a given public key at any time.
|
||||
This is useful if you want the fee recipient to fall back to the validator client (or beacon node) default.
|
||||
|
||||
| Property | Specification |
|
||||
| --- | --- |
|
||||
Path | `/eth/v1/validator/{pubkey}/feerecipient`
|
||||
Method | DELETE
|
||||
Required Headers | [`Authorization`](./api-vc-auth-header.md)
|
||||
Typical Responses | 204, 404
|
||||
|
||||
```bash
|
||||
DATADIR=$HOME/.lighthouse/mainnet
|
||||
PUBKEY=0xa9735061c84fc0003657e5bd38160762b7ef2d67d280e00347b1781570088c32c06f15418c144949f5d736b1d3a6c591
|
||||
|
||||
curl -X DELETE \
|
||||
-H "Authorization: Bearer $(cat ${DATADIR}/validators/api-token.txt)" \
|
||||
-H "Content-Type: application/json" \
|
||||
http://localhost:5062/eth/v1/validator/${PUBKEY}/feerecipient | jq
|
||||
```
|
||||
|
||||
#### Successful Response (204)
|
||||
```json
|
||||
null
|
||||
```
|
||||
|
||||
|
||||
|
||||
Reference in New Issue
Block a user