cerc-io/lighthouse
16
0
Fork 0
Code Issues 1 Pull Requests Packages Projects Releases Wiki Activity

remove strict fee recipient docs (#3551)

Browse Source 
## Issue Addressed

Related: #3550

Remove references to the `--strict-fee-recipient` flag in docs. The flag will cause missed proposals prior to the merge transition.



Co-authored-by: realbigsean <sean@sigmaprime.io>
This commit is contained in:
realbigsean 2022-09-08 00:06:25 +00:00
parent 419c53bf24
commit 81d078bfc7
2 changed files with 3 additions and 15 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
book/src/builders.md
View File

@ -55,9 +55,7 @@ Both the gas limit and fee recipient will be passed along as suggestions to conn
in either, it will *not* keep you from proposing a block with the builder. This is because the bounds on gas limit are calculated based
on prior execution blocks, so it should be managed by an execution engine, even if it is external. Depending on the
connected relay, payment to the proposer might be in the form of a transaction within the block to the fee recipient,
so a discrepancy in fee recipient might not indicate that there is something afoot. If you know the relay you are connected to *should*
only create blocks with a `fee_recipient` field matching the one suggested, you can use
the [strict fee recipient](suggested-fee-recipient.md#strict-fee-recipient) flag.
so a discrepancy in fee recipient might not indicate that there is something afoot.
### Set Gas Limit via HTTP

14
book/src/suggested-fee-recipient.md
View File

@ -12,8 +12,7 @@ coinbase and the recipient of other fees or rewards.
There is no guarantee that an execution node will use the `suggested_fee_recipient` to collect fees,
it may use any address it chooses. It is assumed that an honest execution node *will* use the
`suggested_fee_recipient`, but users should note this trust assumption. Check out the
[strict fee recipient](#strict-fee-recipient) section for how to mitigate this assumption.
`suggested_fee_recipient`, but users should note this trust assumption.
The `suggested_fee_recipient` can be provided to the VC, which will transmit it to the BN. The BN also
has a choice regarding the fee recipient it passes to the execution node, creating another
@ -181,15 +180,6 @@ curl -X DELETE \
null
```
## Strict Fee Recipient
If the flag `--strict-fee-recipient` is set in the validator client, Lighthouse will refuse to sign any block whose
`fee_recipient` does not match the `suggested_fee_recipient` sent by this validator. This applies to both the normal
block proposal flow and block proposals through the builder API. Proposals through the builder API are more likely
to have a discrepancy in `fee_recipient` so you should be aware of how your connected relay sends proposer payments before
using this flag. If this flag is used, a fee recipient mismatch in the builder API flow will result in a fallback to the
local execution engine for payload construction, where a strict fee recipient check will still be applied.
## FAQ
### Why do I have to nominate an Ethereum address as the fee recipient?
@ -198,5 +188,5 @@ You might wonder why the validator can't just accumulate transactions fees in th
accumulates other staking rewards. The reason for this is that transaction fees are computed and
validated by the execution node, and therefore need to be paid to an address that exists on the
execution chain. Validators use BLS keys which do not correspond to Ethereum addresses, so they
have no "presence" on the execution chain. Therefore it's necessary for each validator to nominate
have no "presence" on the execution chain. Therefore, it's necessary for each validator to nominate
a separate fee recipient address.