Provide Documentation and a Precompile to Handle Fee Distributions

[patrick-ogrady]

We should either instruct people to deploy contracts to the blackhole address or should create a precompile that lets an admin dynamically adjust where fees go.

[aaronbuchwald]

The fees are added to the Coinbase address here: https://github.com/ava-labs/subnet-evm/blob/master/core/state_transition.go#L354.

Since they are added via AddBalance and not call, the smart contract is not given the chance to acknowledge the receipt of the funds. If we want to handle this, we can switch to using evm.Call here with a set amount of gas (assume that the contract deployed at the reward address is trusted by the system so that we can give it an arbitrary amount of gas to execute).

To implement this with the most flexibility, we can add a configurable precompile with the fields:

• initial reward address
• allow list of admins that can update the reward address

When the precompile configures itself, it can add the initial reward address to its own state and from then, the enabled addresses on the allow list will be configured to update the reward address.

In the state transition code, if the precompile is enabled, we will do evm.Call(rewardAddress...) instead of directly adding to the balance of the coinbase address. This way if a subnet wants to still use the coinbase address in any way, they can allow validators to set the coinbase address and then use that within the smart contract to determine how to distribute funds ie. the smart contract can use the COINBASE opcode to determine where to send those funds if they want to do something more complicated than sending all of the funds to the coinbase address.

[aaronbuchwald]

Problem

subnet-evm instances would like to exercise more granular control of how fees are handled on their subnets.

Ideally, we can provide them the capability to set the destination address for gas fees.

Proposed Solution

The proposed solution is to add a stateful precompile that will be checked when deciding what to do with fees. Specifically, the precompile will be invoked here: https://github.com/ava-labs/subnet-evm/blob/master/core/state_transition.go#L354 in order to decide where to send the fees.

Additionally, there are the following considerations for the desired behavior:

• Should the recipient address be invoked via evm.Call so that a smart contract can acknowledge the funds (this is a required functionality, Q is whether to make it configurable)
• How should evm.Call be invoked, how much gas should be allotted to the fee recipient contract
• How should users deploy a contract at the given address? Should this be set within the same precompile, within the same network upgrade but using a different precompile to deploy it at a specific address?

Here's a draft of a Solidity interface that could be made available:

//SPDX-License-Identifier: MIT
pragma solidity >=0.8.0;

// IRewards provides an interface for setting the configuration of how fees should be handled.
// The proposed design here is that the Rewards precompile will set in its own state the arguments
// included in the function.
// recipient: the address to deliver funds to
// performCall: whether to invoke the contract or just increment its balance. This parameter must be set
// to true if there is a contract that is deployed at the recipient address that must be invoked to distribute fees.
// gasLimit: the amount of gas to provide to the invoked smart contract if invoked (must be 0 if performCall is false).
interface IRewards is IAllowList {
    function setRewardHandlerAddress(address receipient, bool performCall, uint64 gasLimit) external;
}

The goal would be for this to be configurable via an allow list, which would allow admins to actively set and update the reward handler address or also to configure it from the activation of the precompile with no admins on the allow list, so that it will perform the same functionality trustlessly.