feat: Add operator receiver functionality for base BGT rewards

[ZERGUCCI]

This PR introduces an validator operator receiver where bgt base fees are optionally minted to instead of directly to the operator address

Context:

Each validator has a pubkey. Each pubkey is tied to a separate operator address. That operator address is used to a) control validator configs, b) update the cutting board, c) receive base bgt fees, and d) receive reward vault token incentives.

Receiving nontransferrable bgt base fees into the operator address means the operator address will come to hold tokens with substantial value, and comingle the validator team's financial management with its core operations.

Allowing validators to optionally specify a different operatorReceiver address to receive its bgt base fees improves the security of the operator address and gives validator teams more flexibility in their access controls for validator config vs. financial management.

The change itself is non intrusive, meaning setting an operator receiver is optional and validator operators unaware of the change or unwanting can operate exactly as they did before the change and base bgt will still be minted to their operator. All other block reward and validator functionality is unaffected.

Submitted by:

The Honey Jar validator infrastructure & operations team

Edit: not calling beaconDepositContract.getOperator(pubkey) in the setter was intentional to avoid the security risk of unnecessary external calls, eliminate any possibility of someone setting a receiver for an operator they don't control, and to minimize gas usage.

[rolandpo]

lgtm

[ZERGUCCI]

Might update so it doesnt require changes to the beacon deposit contract as just was informed changes there will take longer.

[ZERGUCCI]

Re committed to revert any changes to BeaconDeposit.sol and move all functionality into BlockRewardController.sol in upgrade safe manner to allow a quicker possible merge without the need of a hard fork

[ertemann]

This would be a very benificial change imo for handling rewards both for our app BeeBribes and generally for validator ops.

The current custody/reward setup make soliciting stake very difficult, this would help!

[sj448]

i would suggest to take pubkey too as an input to get operator address from deposit contract and put an explicit check of msg.sender==operator to avoid spamming of this function.

[ZERGUCCI]

I intentionally set it up so that you can only set your own operator receiver (sets directly to msg.sender) without the need for making an external call to the distributor to increase security in the event the distributor contract somehow gets exploited and for general gas efficiency.

I understand your point of people being able to spam it though, what do you see as the motive of people doing that?

[ZERGUCCI]

The potential spammer in question would cause no harm as they are setting their own operator receiver and the gas cost is a natural deterrent to this behavior. I can add the check if you'd like though

[ZERGUCCI]

I've implemented the suggested changes as I believe you might be one of the Berachain developers, though I'm not entirely certain.

[sj448]

LGTM, but we’ll keep the PR open because this change will mainly go live with POL v2. Since we’re planning to use EIP‑2537 for v2, the current implementation of this feature might no longer be relevant at that point.

[ZERGUCCI]

Okay. How long do you think roughly until POL V2 goes live?

[sj448]

i dont have any estimate on this yet, we will update you once things are in motion

[ZERGUCCI]

Okay sounds good, I will familiarize myself with EIP-2537 in the meantime to better understand the change it will have in this context.

[sj448]

Hello gents, quick update on this. With BRIP-0004, which proposes enshrining the distributeFor function call into the execution layer and reducing the cutting board queue to real-time execution, we are introducing a feature to separate the reward/commission receiver address from the address used to queue new reward allocations.

With real-time reward allocation activation, we expect validators would ideally want a hot wallet to control this operation. So we’re introducing a new address, operatorRewardAllocator, to manage the cutting board changes, while keeping the operator address as the receiver of BGT and incentive shares. This operatorRewardAllocator will be controlled by the operator address and can be changed by it. To maintain backward compatibility, we’ll allow the operator address to queue a new cutting board if operatorRewardAllocator is not set (i.e., is the zero address).

@ZERGUCCI @ertemann @rolandpo would love to get your feedback on this.