This EIP:
SIGRECOVER_PRECOMPILE_ADDRESS for decoding these newly introduced algorithms.As quantum computers become more advanced, several new post-quantum (PQ) algorithms have been designed. These algorithms all have certain drawbacks, such as large key sizes (>1KiB), large signature sizes, or long verification times. These issues make them more expensive to compute and store than the currently used secp256k1 curve.
This EIP allows the use of many algorithms by introducing an algorithm registry that can be used via a single interface.
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.
Unless explicitly noted, integer encoding MUST be in big-endian format.
| Constant | Value |
|---|---|
SIGRECOVER_PRECOMPILE_ADDRESS | Bytes20(0x12) |
SIGRECOVER_PRECOMPILE_BASE_GAS | 3000 |
New algorithms beyond the secp256k1 algorithm specified in this EIP MUST be specified via a distinct EIP.
Each type of algorithm MUST specify the following fields:
Specifications MUST include some form of security analysis on the provided algorithm and basic benchmarks justifying gas costs. Additionally, specifications MUST address malleability issues that may arise from specified algorithms.
An example of this specification can be found here.
The function below MUST be used when deriving an address from a public key:
This EIP uses the algorithm_registry object to signify algorithms that have been included within a hard fork.
A living EIP MAY be created on finalization of this EIP to track currently active algorithms across forks.
The algorithm type is reserved 0xFE as invalid / missing.
The following helper functions are defined for convenience:
secp256k1 algorithmsigrecover precompileThis EIP also introduces a new precompile located at SIGRECOVER_PRECOMPILE_ADDRESS.
This precompile MUST charge SIGRECOVER_PRECOMPILE_BASE_GAS static gas before executing.
The precompile MUST output the 20-byte address of the signer provided left padded to 32 bytes. Callers MUST assume all zero bytes as a failure. On failure, the precompile MUST return 32 0x00 bytes.
The precompile is defined as follows:
While initial drafts of this EIP were competing with ERC-4337, current versions of this EIP support it via the sigrecover precompile. This allows any ERC-4337 implementation to have the same signature verification logic and address derivation logic for any given private key. This also works agnostic of whatever algorithm derives the address.
Having a precompile allows non-EVM processes, i.e. transaction level signature verification, to access the registry without having to call into the EVM.
signature typeAs each algorithm has unique properties, e.g. supporting signature recovery and key sizes, the object needs to hold every permutation of every possible signature and potentially additional recovery information. A bytearray of an algorithm-defined size would be able to achieve this goal.
EIP-7932 does not modify any existing logic and does not pose any backwards compatibility issues.
Test cases for the sigrecover precompile may be found in the precompile_test_cases.py file.
Allowing more ways to derive addresses for a single account may decrease overall security for that specific account. However, this is partially mitigated by the increase in processing power required to trial all algorithms. Even still, adding additional algorithms may need further discussion to ensure that the security of the network would not be compromised.
Copyright and related rights waived via CC0.