ERC-7936: Versioned Proxy Contract Interface

Abstract

This EIP standardizes an interface for proxy contracts that allows callers to explicitly select which version of an implementation contract they want to interact with. Unlike traditional proxy patterns that only expose the latest implementation, this standard enables backward compatibility by maintaining access to previous implementations while supporting upgrades. The versioned proxy maintains a registry of implementation addresses mapped to version identifiers, allowing callers to specify their desired version at call time.

Motivation

Smart contract upgrades are essential for fixing bugs and adding features. Current proxy patterns typically force all callers to use the latest implementation, which can break existing integrations when interfaces change.

Furthermore, traditional proxy patterns expose all users to risk if an upgrade is malicious, as they have no choice but to use the latest implementation. This standard allows users to remain on verified versions they trust, mitigating the risk of a compromised admin key or governance process deploying harmful code.

This EIP addresses several key problems:

1. Breaking Changes: Interface changes in new implementations can break existing integrations.
2. Gradual Adoption: There is no standard way to allow gradual adoption of new contract versions.
3. Malicious Upgrades: Users today must trust proxy admins indefinitely, as they can't opt out of potentially harmful upgrades without ceasing use of the contract entirely.
4. Trust Assumptions: Contract users must maintain perpetual trust in governance or admin keys, with no ability to selectively trust specific, audited implementations.

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.

Interface

Behavior Requirements

1. The proxy contract MUST maintain a mapping of version identifiers to implementation addresses.
2. The proxy contract MUST maintain a default version that is used when no version is specified.
3. When executeAtVersion is called, the proxy MUST:
   • Verify the specified version exists
   • Forward the call to the corresponding implementation
   • Return any data returned by the implementation
4. The proxy contract MUST emit appropriate events when versions are registered, or when the default version changes.
5. The proxy contract SHOULD implement access control for administrative functions (registering versions, setting default).
6. The proxy contract MAY implement EIP-1967 storage slots for compatibility with existing tools.

Fallback Function

The proxy contract SHOULD implement a fallback function that forwards calls to the default implementation version when no version is specified. This maintains compatibility with traditional proxy patterns.

Rationale

Version Identifiers as bytes32

Version identifiers are specified as bytes32 rather than semantic versioning strings to:

1. Provide flexibility in versioning schemes
2. Reduce gas costs for storage and comparison
3. Allow for both string-based versions (converted to bytes32) and numeric versions
4. Allow for storing a Git commit identifier in SHA-1 or SHA-256

Explicit Version Selection

The standard requires callers to explicitly select a version through executeAtVersion rather than encoding version information in the call data to:

1. Maintain a clean separation between version selection and function calls
2. Avoid modifying existing function signatures
3. Make version selection explicit and auditable

Registry Pattern

The registry pattern was chosen over alternatives like:

1. Multiple Proxies: Having separate proxies for each version would increase deployment costs and complexity
2. Version in Storage: Storing a single "current version" would not allow different callers to use different versions simultaneously

Default Version

The default version mechanism allows the proxy to maintain compatibility with traditional proxy patterns and supports callers that don't need to specify a version.

Backwards Compatibility

This EIP is designed to enhance backward compatibility for smart contracts. It does not introduce any backward incompatibilities with existing Ethereum standards or implementations.

Existing contracts that interact with proxy contracts can continue to do so without modification, as the fallback function will route calls to the default implementation.

Security Considerations

This EIP is meant to significantly improve the security of the widely used proxy pattern.

Copyright

Copyright and related rights waived via CC0.