ERC-7760: Minimal Upgradeable Proxies

Minimal upgradeable proxies with immutable arguments and support for onchain implementation queries


Metadata
Status: DraftStandards Track: ERCCreated: 2024-08-19
Authors
Atarpara (@Atarpara), JT Riley (@jtriley-eth), Thomas (@0xth0mas), xiaobaiskill (@xiaobaiskill), Vectorized (@Vectorized)
Requires

Abstract


This standard defines minimal ERC-1967 proxies for three patterns: (1) transparent, (2) UUPS, (3) beacon. The proxies support optional immutable arguments which are appended to the end of their runtime bytecode. Additional variants which support onchain implementation querying are provided.

Motivation


Having standardized minimal bytecode for upgradeable proxies enables the following:

  1. Automatic verification on block explorers.
  2. Ability for immutable arguments to be queried onchain, as these arguments are stored at the same bytecode offset,
  3. Ability for the implementation to be queried and verified onchain.

The minimal nature of the proxies enables cheaper deployment and runtime costs.

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.

General specifications

All of the following proxies MAY have optional data bytecode appended to the end of their runtime bytecode.

Emitting the ERC-1967 events during initialization is OPTIONAL. Indexers MUST NOT expect the initialization code to emit the ERC-1967 events.

Onchain querying of implementation for I-variants

The I-variants have logic that returns the implementation baked into their bytecode.

When called with any 1-byte calldata, these I-variants will return the address (left-zero-padded to 32 bytes) and will not forward the calldata to the target.

The bytecode of the proxies before any optional immutable arguments MUST be verified with the following steps:

  1. Fetch the bytecode before any immutable arguments with EXTCODECOPY.
  2. Zeroize any baked-in factory address in the fetched bytecode.
  3. Ensure that the hash of the final fetched bytecode matches the expected hash of the bytecode.

If the hash does not match, the implementation address returned MUST NOT be trusted.

Minimal ERC-1967 transparent upgradeable proxy

The transparent upgradeable proxy is RECOMMENDED to be deployed by a factory that doubles as the account that is authenticated to perform upgrades. An externally owned account may perform the deployment on behalf of the factory. For convention, we will refer to the factory as the immutable account authorized to invoke the upgrade logic on the proxy.

As the proxy's runtime bytecode contains logic to allow the factory to set any storage slot with any value, the initialization code MAY skip storing the implementation slot.

The upgrading logic does not emit the ERC-1967 event. Indexers MUST NOT expect the upgrading logic to emit the ERC-1967 events.

During upgrades, the factory MUST call the upgradeable proxy with following calldata:


Minimal ERC-1967 transparent upgradeable proxy for (basic variant)

Runtime bytecode (20-byte factory address subvariant):


where ________________________________________ is the 20-byte factory address.

Runtime bytecode (14-byte factory address subvariant):


where ____________________________ is the 14-byte factory address.

Minimal ERC-1967 transparent upgradeable proxy (I-variant)

Runtime bytecode (20-byte factory address subvariant):


where ________________________________________ is the 20-byte factory address.

Runtime bytecode (14-byte factory address subvariant):


where ____________________________ is the 14-byte factory address.

Minimal ERC-1967 UUPS proxy

As this proxy does not contain upgrading logic, the initialization code MUST store the implementation at the ERC-1967 implementation storage slot 0x360894a13ba1a3210667c828492db98dca3e2076cc3735a920a3ca505d382bbc.

Minimal ERC-1967 UUPS proxy (basic variant)

Runtime bytecode:


Minimal ERC-1967 UUPS proxy (I-variant)

Runtime bytecode:


Minimal ERC-1967 beacon proxy

As this proxy does not contain upgrading logic, the initialization code MUST store the implementation at the ERC-1967 implementation storage slot 0x360894a13ba1a3210667c828492db98dca3e2076cc3735a920a3ca505d382bbc.

Minimal ERC-1967 beacon proxy (basic variant)

Runtime bytecode:


Minimal ERC-1967 beacon proxy (I-variant)

Runtime bytecode:


Rationale


No usage of PUSH0 opcode

For more widespread EVM compatibility, the proxies deliberately do not use the PUSH0 opcode proposed in EIP-3855.

Converting the proxies to PUSH0 variants may be done in a separate future ERC.

Optimization priorities

The proxies are first optimized for minimal runtime gas before minimal bytecode size.

Minimal nature

These proxies made from handcrafted EVM bytecode. While utmost efforts have been made to ensure that they are as minimal as possible at the time of development, it is possible that they can be further optimized. If a variant has already been used in the wild, it is preferable to keep their existing layout in this standard, as the benefits of automatic block explorer verification will outweigh the few gas saved during runtime or deployment.

For historical reference, the ERC-1167 minimal proxy was not the theoretical minimal at the time of writing. The 0age minimal proxy has lower runtime gas costs and smaller bytecode size.

Transparent upgradeable proxy

The factory address in the transparent upgradeable proxy is baked into the immutable bytecode of the minimal transparent upgradeable proxy.

This is to save a SLOAD for every proxy call.

As the factory can contain custom authorization logic that allows for admin rotation, we do not lose any flexibility.

The upgrade logic takes in any 32 byte value and 32 byte storage slot. This is for flexibility and bytecode conciseness.

We do not lose any security as the implementation can still modify any storage slot.

14-byte factory address subvariants

It is beneficial to install the transparent upgradeable proxy factory at a vanity address with leading zero bytes so that the proxy's bytecode can be optimized to be shorter.

A 14-byte factory address (i.e. 6 leading zero bytes) is chosen because it strikes a balance between mining costs and bytecode size.

I-variants

The so-called "I-variants" contain logic that returns the implementation address baked into the proxy bytecode.

This allows contracts to retrieve the implementation of the proxy onchain in a verifiable way.

As long as the proxy's runtime bytecode starts with the bytecode in this standard, we can be sure that the implementation address is not spoofed.

The choice of reserving 1-byte calldata to denote an implementation query request is for efficiency and to prevent calldata collision. Regular ETH transfers use 0-byte calldata, and regular Solidity function calls use calldata that is 4 bytes or longer.

Omission of events in bytecode

This is for minimal bytecode size and deployment costs.

Most block explorers and indexers are able to deduce the latest implementation without the use of events simply by reading the slots.

Immutable arguments are not appended to forwarded calldata

This is to avoid compatibility and safety issues with other ERC standards that append extra data to the calldata.

The EXTCODECOPY opcode can be used to retrieve the immutable arguments.

No fixed initialization code

As long as the initialization code is able to initialize the relevant ERC-1967 implementation slot where needed (i.e. for the UUPS proxy and Beacon proxy), there is no need for additional requirements on the initialization code.

Out of scope topics

The following topics are intentionally out of scope of this standard, as they can contain custom logic:

  • Factories for proxy deployment.
  • Logic for reading and verifying the implementation from the I-variants onchain.
  • Beacon for the beacon proxies.

Nevertheless, they require careful implementation to ensure security and correctness.

Backwards Compatibility


No backward compatibility issues found.

Reference Implementation


Minimal ERC-1967 transparent upgradeable proxy implementation

Minimal ERC-1967 transparent upgradeable proxy implementation (basic variant)


Minimal ERC-1967 transparent upgradeable proxy implementation (I-variant)


Minimal ERC-1967 UUPS proxy implementation

Minimal ERC-1967 UUPS proxy implementation (basic variant)


Minimal ERC-1967 UUPS proxy implementation (I-variant)


Minimal ERC-1967 beacon proxy implementation

Minimal ERC-1967 beacon proxy implementation (basic variant)


Minimal ERC-1967 beacon proxy implementation (I-variant)


Security Considerations


Transparent upgradeable proxy factory security considerations

To ensure security, the transparent upgradeable proxy factory must implement proper access control to allow proxies to be upgraded by only authorized accounts.

Calldata length collision for I-variants

The I-variants reserve all calldata of length 1 to denote a request to return the implementation. This may pose compatibility issues if the underlying implementation actually uses 1-byte calldata for special purposes.

Copyright


Copyright and related rights waived via CC0.