EIP-7932: Secondary Signature Algorithms
Introduces a precompile and registry for handling alternative signature algorithms
Abstract
This EIP:
- Creates a unified registry & standardized interface for introducing additional signature algorithms for the use of deriving account addresses.
- Introduces a precompile at address
SIGRECOVER_PRECOMPILE_ADDRESSfor decoding these newly introduced algorithms.
Motivation
As quantum computers become more advanced, several new post-quantum (PQ) algorithms have been designed. These algorithms all have certain issues, 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 provides a solution to the large volume of algorithms by introducing a registry of algorithms that can be used via a single interface.
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.
Unless explicitly noted, integer encoding MUST be in big-endian format.
Parameters
| Constant | Value |
|---|---|
GAS_PER_ADDITIONAL_VERIFICATION_BYTE | 16 |
SIGRECOVER_PRECOMPILE_ADDRESS | Bytes20(0x12) |
SIGRECOVER_PRECOMPILE_BASE_GAS | 3000 |
SECP256K1_SIGNATURE_SIZE | 65 |
Algorithm specification
This EIP only provides the secp256k1 algorithm. Further algorithms MUST be specified via a distinct EIP.
Each type of algorithm MUST specify the following fields:
| Field Name | Description |
|---|---|
ALG_TYPE | The uint8 that would be present at signature_info[0] |
GAS_PENALTY | The additional gas penalty from verification of the signature |
The GAS_PENALTY field MUST be assumed to be the worst-case scenario and MUST only account for verification costs, not storage nor signing.
A verification function must be present per algorithm. The verification function MUST have the following signature:
def verify(signature_info: Bytes, payload_hash: Hash32) -> Bytes
The verify function MUST either return an error or return the full public key of the sender.
Specifications MUST include some form of security analysis on the provided algorithm and basic benchmarks justifying gas costs. Additionally, algorithms MUST ensure that variations of signatures cannot be made without the private key.
An example of this specification can be found here.
Deriving address from public keys
The function below MUST be used when deriving an address from a public key:
Algorithm Registry
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.
Gas calculation
All signatures that use more resources than the secp256k1 curve suffer an additional penalty which MUST be calculated
as specified in the calculate_penalty function.
secp256k1 algorithm
| Field | Value |
|---|---|
ALG_TYPE | 0xFF |
GAS_PENALTY | 0 |
This algorithm MUST ONLY be used if the transaction's signature is secp256k1 but the additional_signatures field contains one or more entries. It MUST NOT be present if the transaction does not contain additional signatures. secp256k1 MUST NOT be present in any additional_signatures entry.
sigrecover precompile
This EIP also introduces a new precompile located at SIGRECOVER_PRECOMPILE_ADDRESS.
This precompile MUST cost SIGRECOVER_PRECOMPILE_BASE_GAS when called regardless of validity. This cost MUST be aggregated with calculate_penalty(signature_info) and charged before the sigrecover precompile executes.
The precompile MUST output the 20-byte address of the signer provided. Callers MUST assume all zero bytes as a failure. On failure, the precompile MUST return 20 0x0 bytes.
The precompile logic contains the following logic:
Rationale
ERC-4337 interoperability
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.
Precompile over native EVM code
Having a precompile allows non-EVM processes, i.e. transaction level signature verification, to access the registry without having to call into the EVM.
Opaque signature_info type
As each algorithm has unique properties, e.g. signature recovery and key sizes, the object needs to hold every permutation of every possible signature and potentially additional recovery information. A bytearray of a dynamic size would be able to achieve this goal. However, this leads to a DoS vector which the Gas penalties section solves.
Gas penalties
Having multiple different algorithms results in multiple different signature sizes and verification costs. Hence, every signature algorithm that is more expensive than the default ECDSA secp256k1 curve incurs an additional gas penalty. This is to discourage the use of overly expensive algorithms for no specific reason.
The GAS_PER_ADDITIONAL_VERIFICATION_BYTE value being 16 was taken from the calldata cost of a transaction, as it is a similar data type and must persist indefinitely to ensure later verification.
Backwards Compatibility
EIP-7932 does not modify any existing logic and does not pose any backwards compatibility issues.
Test Cases
Test cases for the sigrecover precompile may be found in the precompile_test_cases.py file.
Security Considerations
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
Copyright and related rights waived via CC0.