HomeEIPs
EIPsEIP-5065
EIP-5065

Instruction for transferring ether

Instruction for just transferring ether without transferring the flow of execution
StagnantStandards Track: Core
Created: 2022-04-30
Requires: EIP-2929
Mudit Gupta (@maxsam4)
DiscussionsOriginal linkEdit
1 min read

EIP-5065, titled "Instruction for transferring ether," proposes a new instruction for transferring ether to a destination address without handing over the execution flow to it. This is motivated by the architectural principle that execution flow should never be handed over to an untrusted contract. Currently, Ethereum does not have an ideal way to transfer ether without transferring the execution flow. The only existing method involves creating a dummy contract, sending the precise amount of ether to it, and then calling SELFDESTRUCT from it. The proposed solution is to introduce a new instruction, AIRDROP, that transfers ether to the destination without making a call to it. The total gas cost would be the sum of a static cost, address access cost, and value to empty account cost. This instruction allows contracts to safely pass ether to an untrusted address without worrying about reentrancy or other malicious actions an untrusted contract can do. This EIP does not affect any old instructions and does not break any valid assumptions, hence it is backward compatible. The document also mentions that there are no known security risks associated with this proposal.

Video
Anyone may contribute to propose contents.
Go propose
Original

Abstract

Add a new instruction that transfers ether to a destination address without handing over the flow of execution to it. It should work similarly to how SELFDESTRUCT (0xFF) transfers ether to the destination without making a call to it.

Motivation

From an architectural point of view, execution flow should never be handed over to an untrusted contract. Ethereum currently does not have any ideal way to transfer ether without transferring the flow of execution. People have come up with reentrancy guards and similar solutions to prevent some types of attacks but it's not an ideal solution. The only way to transfer ether from smart contracts without triggering a call is to create a dummy contract, send the precise amount of ether to it and then call SELFDESTRUCT (0xFF) from it.

Specification

Introduce a new instruction, AIRDROP (0xFG) that transfers ether to the destination without making a call to it.

Stack input

address: the account to send ether to. value: value in wei to send to the account.

Gas

The total gas cost should be the sum of a static cost + address_access_cost + value_to_empty_account_cost.

  • Static cost: 6700
  • Dynamic cost:
    1. address_access_cost: If the target is not in accessed_addresses, charge COLD_ACCOUNT_ACCESS_COST gas, and add the address to accessed_addresses. Otherwise, charge WARM_STORAGE_READ_COST gas. Currently, COLD_ACCOUNT_ACCESS_COST is 2600 while WARM_STORAGE_READ_COST is 100.
    2. value_to_empty_account_cost: If value is not 0 and the address given points to an empty account, then value_to_empty_account_cost is the account creation gas cost which currently is 25000. An account is empty if its balance is 0, its nonce is 0 and it has no code.

Rationale

This behavior is already possible by deploying a new contract that does SELFDESTRUCT (0xFF) but it is prohibitively expensive. In most scenarios, the contract author only wants to transfer ether rather than transferring control of the execution. ERC20 can be used as a case study for this where most users transfer funds without a post-transfer hook.

This instruction allows contracts to safely pass ether to an untrusted address without worrying about reentrancy or other malicious things an untrusted contract can do on.

The static gas cost is derived by subtracting the gas stipend (2300) from the positive_value_cost of CALL (0xF1) opcode which is currently set to 9000.

Backwards Compatibility

No known issues as this is a new instruction that does not affect any old instructions and does not break any valid assumptions since it make not anything impossible possible.

Test Cases

TODO

Security Considerations

No known security risks.

Copyright and related rights waived via CC0.

Further reading
Anyone may contribute to propose contents.
Go propose
Adopted by projects
Anyone may contribute to propose contents.
Go propose

Not miss a beat of EIPs' update?

Subscribe EIPs Fun to receive the latest updates of EIPs Good for Buidlers to follow up.

View all
Serve Ethereum Builders, Scale the Community.
Resources
GitHub
Supported by