EIP-7775 - BURN opcode

Abstract

This proposal introduces a BURN opcode to the EVM. When called, the opcode is to burn native ether at the address of the current evm context.

Motivation

The motivation for this proposal is to provide a standardized and efficient way to burn native ether directly within the EVM. Historically, contracts such as the BeaconDepositContract have "burned" ether by making it irrecoverable from the given address. This approach can lead to confusion and potential misuse. By introducing a dedicated BURN opcode, we can ensure a clear and consistent method for burning native ether. This could become useful for Ethereum L2s when transferring ether back to the L1, as well as other EVM L1 chains that could leverage this for their cryptoeconomics.

Specification

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 and RFC 8174.

Behaviour

The BURN opcode (0xFC) is introduced with the following behavior:

1. Pops one 32-byte word from the top of the stack, treating these bytes as the uint256 amount of native ether to be burned.
2. Retrieves the current address from the EVM execution context.
3. Checks the balance of the current address.
4. If the amount to be burned is greater than the balance of the current address, the opcode MUST revert.
5. If the amount to be burned is 0, the execution MUST NOT revert.
6. Subtracts the amount from the current address's native ether balance.

When BURN is used in the context of a DELEGATECALL or CALLCODE, the contract whose balance is to be manipulated is the contract that issued the DELEGATECALL or CALLCODE instruction.

When BURN is used in the context of a STATICCALL the call MUST revert.

Gas Cost

The base gas cost for the BURN opcode is 100 gas. The dynamic gas cost is determined as follows:

1. If the value to be burned is 0, the dynamic gas cost is 0.
2. If the account doesn't exist, or the balance of the account is 0, the dynamic gas cost is 0.
3. Otherwise, the dynamic gas cost is 2800.

The total gas cost for the BURN opcode is the sum of the base gas cost and the dynamic gas cost.

Pseudocode

Example pseudocode for the BURN opcode:

def op_burn(pc, interpreter, scope):
    # Consume the base gas cost
    interpreter.consume_gas(100)

    # Pop the value to be burned from the stack
    value_to_burn = scope.stack.pop()

    # If the value to be burned is 0, do not revert
    if value_to_burn == 0:
        return None

    # Retrieve the current address from the EVM execution context
    current_address = scope.contract.address()

    # Check the balance of the current address
    balance = interpreter.evm.state_db.get_balance(current_address)

    # If the value to be burned is greater than the balance, revert
    if value_to_burn > balance:
        return "ErrInsufficientBalance"

    # If the account balance is 0, return.
    if balance == 0:
        return None

    # Subtract the value from the current address's balance
    interpreter.evm.state_db.sub_balance(current_address, value_to_burn)

    # The account is known to exist at this point, thus we consume "warm" gas.
    interpreter.consume_gas(2800)
    return None

Rationale

The introduction of the BURN opcode helps clean up a piece of weird semantics in the Ethereum. Historically, burning native ether involved sending them to an address from which they could not be recovered, such as the zero address or a contract with no withdrawal functionality. This method is not only inefficient but also confusing for indexers and other tools that track token movements. By providing a dedicated BURN opcode, we eliminate this ambiguity and ensure that the act of burning tokens is explicit and standardized.

Potential Pros:

• Provides a clear and standardized method for burning native ether within smart contracts.
• Allows for better accounting practices of native token within smart contracts.
• Reduces the possibility of a smart contract exploit caused by native token that was marked as "burned" being unintetionally recovered.

Potential Cons:

• Does not help remove unrecoverable ether sitting in existing contracts.
• New code in the clients
• New concept needed to be added to the yellow paper.

Backwards Compatibility

This EIP introduces a new opcode and thus must be activated via a scheduled hardfork.

Test Cases

Reference Implementation

Security Considerations

• Potentially opens up misuse when using DELEGATECALL.

Needs discussion.

Copyright

Copyright and related rights waived via CC0.