HomeEIPs
EIPsEIP-6189
EIP-6189

Alias Contracts

Allows the creation of contracts that forward calls to other contracts
ReviewStandards Track: Core
Created: 2022-12-20
Requires: EIP-2929, EIP-6188
Gavin John (@Pandapip1)
DiscussionsOriginal linkEdit
1 min read

The EIP-6189 proposal suggests the implementation of Alias Contracts in Ethereum. Alias Contracts would allow for the creation of a contract that acts as a proxy for another contract, allowing for easier upgrades and maintenance of the original contract without disrupting its functionality. The proposal outlines the technical specifications for Alias Contracts, including the ability to delegate calls to the original contract, the ability to upgrade the original contract while maintaining its address, and the ability to transfer ownership of the Alias Contract. Overall, the proposal aims to improve the flexibility and maintainability of smart contracts on the Ethereum network.

Video
Anyone may contribute to propose contents.
Go propose
Original

Abstract

This EIP allows contracts to be turned into "alias contracts" using a magic nonce. Alias contracts automatically forward calls to other contracts.

Motivation

This EIP is not terribly useful on its own, as it adds additional computation and gas costs without any useful side effects. However, in conjunction with EIP-6190, it can be used to make SELFDESTRUCT compatible with Verkle trees.

Specification

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

Definitions

A contract is an alias contract if its nonce is 2^64-1, and its contract code is equal to 0x1.

Prerequisites

EIP-6188 MUST be used to protect the magic nonce value of 2^64-1.

Opcode Changes

CALL, CALLCODE, DELEGATECALL, STATICCALL, PAY, and EOA Transactions

The "callee" refers to the account that is being called or being paid.

If the nonce of the callee is 2^64-1, the call MUST be forwarded to the address stored in the 0th storage slot of the callee (as if the callee was the address stored in the 0th storage slot of the callee). This MUST repeat until a non-alias contract is reached. The CALLER MUST remain unchanged.

If there is more than one alias contract in the chain, the original callee and all subsequent callees (except the last one) MUST have their 0th storage slot set to the address of the final non-alias contract. Then, the call MUST be forwarded as usual. This MUST occur, even in a read-only context like STATICCALL.

For example, if A is an alias contract that forwards calls to B, which is an alias contract that forwards calls to C, then A's 0th storage slot is set to C's address. Then, the call is forwarded to C.

Finally, the opcode MUST proceed as usual, using the final non-alias contract.

The CALL, CALLCODE, DELEGATECALL, and STATICCALL opcodes and EOA Transactions MUST cost an 25 gas per account accessed in this manner (including the final one, and including if no aliased accounts were used), in addition to all the regular costs incurred by accessing accounts (see EIP-2929). For every account whose 0th storage slot is updated, those opcodes MUST also cost an additional 5000 gas.

If an infinite loop occurs, the transaction MUST run out of gas and revert.

EXTCODEHASH, EXTCODECOPY, EXTCODESIZE, and BALANCE

The "accessed account" refers to the account that is being accessed (i.e. the account whose code is being accessed, or the account whose balance is being accessed).

Similar to the CALL family of opcodes, if the nonce of the accessed account is 2^64-1, the accessed account's address MUST be replaced with the address stored in the 0th storage slot of the accessed account. This MUST repeat until a non-alias contract is reached.

If there is more than one alias contract in the chain, the original accessed account and all subsequent accessed accounts (except the last one) MUST have their 0th storage slot set to the address of the final non-alias contract. Then, the accessed account MUST be replaced as usual. This MUST occur, even in a read-only context like STATICCALL.

Finally, the opcode MUST proceed as usual, using the final non-alias contract.

The EXTCODEHASH, EXTCODECOPY, EXTCODESIZE, and BALANCE opcodes MUST cost an 25 gas per account accessed in this manner (including the final one, and including if no aliased accounts were used), in addition to all the regular costs incurred by accessing accounts (see EIP-2929). For every account whose 0th storage slot is updated, those opcodes MUST also cost an additional 5000 gas.

If an infinite loop occurs, the transaction MUST run out of gas and revert.

CREATE and CREATE2

If CREATE or CREATE2 would create (or fail to create, depending on which EIPs are used) an account at an address, and that account's code is 0x1, and its nonce is 2^64-1, then instead of reverting, an attempt MUST be made to create a contract at the address stored in the 0th storage slot of the existing account. This MUST repeat until a non-alias contract is reached.

If there is more than one alias contract in the chain, the original accessed account and all subsequent accessed accounts (except the last one) MUST have their 0th storage slot set to the address of the final non-alias contract.

Finally, the opcode MUST proceed as usual, returning the address of the newly-created contract.

The CREATE and CREATE2 opcodes MUST cost an 25 gas per account accessed in this manner (including the final one, and including if no aliased accounts were used), in addition to all the regular costs incurred by accessing accounts (see EIP-2929). For every account whose 0th storage slot is updated, those opcodes must also cost an additional 5000 gas.

If an infinite loop occurs, the transaction runs out of gas and reverts.

ADDRESS

This opcode remains unchanged; ADDRESS points to the address that doesn't have a nonce of 2^64-1.33

Transfers to the zero address

Transfers to the zero address continue to have the same effect as the CREATE opcode, and will cost extra gas as discussed in the CREATE and CREATE2 section.

Transaction Validity

The "origin" refers to the account that sent the transaction to be validated.

If the nonce of the origin is 2^64-1, the origin MUST be updated to the address stored in the 0th storage slot of the current origin (as if the origin was the address stored in the 0th storage slot of the current origin). This MUST repeat until a non-alias contract is reached.

If there is more than one alias contract in the chain, the original origin and all subsequent origins (except the last one) MUST have their 0th storage slot set to the address of the final non-alias contract. Then, the call MUST be forwarded as usual.

An additional 25 gas per account accessed in this manner (including the final one, and including if no aliased accounts were used), in addition to all the regular costs incurred by accessing accounts (see EIP-2929) is added to the validation costs. For every account whose 0th storage slot is updated, it also costs an additional 5000 gas.

Finally, validation proceeds as normal.

RPC Endpoint Changes

eth_getStorageAt

The eth_getStorageAt RPC endpoint must error if the target contract has a contract code of 0x1 and a nonce of 2^64-1.

Rationale

The additional gas cost of 25 represents the cost of fetching the nonce and comparing it to the given value.

eth_getStorageAt was modified to throw an error because of alias contracts' special behavior.

The nonce of 2^64-1 was chosen since it is the nonce protected by EIP-6188.

The contract code of 0x1 was chosen arbitrarily. A nonzero code was chosen just in case a non-alias contract with nonce 2^64-1 somehow had its code set to 0x0, or an EOA had its nonce set to 2^64-1.

Backwards Compatibility

This EIP requires a protocol upgrade, since it modifies consensus rules. No existing contracts should be affected, as they will not have a nonce of 2^64-1, nor will they have the contract code 0x1.

Security Considerations

The additional gas costs may cause potential DoS attacks if they access an arbitrary contract's data or make frequent contract deactivations. Contract authors must be aware and design contracts accordingly. There may be an effect on existing deployed code performing autonomous destruction and revival.

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 EIP builders, scale Ethereum.
Resources
GitHub
Supported by