EIPs

TL;DR

This EIP significantly reduces the gas costs for the alt_bn128 curve operations (ECADD, ECMUL, and pairing checks) to reflect performance improvements in Ethereum clients like Geth and Parity.

Gas Cost Reduction

The gas costs for precompiles introduced in EIP-196 and EIP-197 were updated as follows:

Rationale

The cost reduction makes privacy and scaling solutions (like AZTEC, Matter Labs, and Zether) that rely on these elliptic curve operations much more practical and affordable on the Ethereum mainnet.

TL;DR

This EIP defines a standard way for smart contracts to verify signatures, enabling them to act like externally owned accounts (EOAs) for authentication. Contracts can implement an isValidSignature function, allowing other contracts to check if a signature is valid on their behalf. This is crucial for applications like decentralized exchanges with off-chain order books where smart contract wallets need to sign orders.

Specification

A contract that wishes to be able to sign messages must implement the ERC1271 interface, which contains a single function:

function isValidSignature(
  bytes32 _hash,
  bytes memory _signature
) public view returns (bytes4 magicValue);

• Functionality: When called, this function should return a magic value (0x1626ba7e) if the signature is valid for the given hash. Otherwise, it should return a different value.
• State: The function must not modify state (it is a view function).
• Flexibility: The implementation can use any logic to validate the signature, such as checking against a list of authorized signers, using multi-sig logic, or supporting different signature schemes.

TL;DR

This ERC proposes a compact 64-byte signature representation for secp256k1 signatures, down from the standard 65 bytes. It achieves this by storing the yParity bit (recovery ID) in the most significant bit of the s value, which is otherwise unused in canonical signatures. This saves space and gas, especially in contexts like meta-transactions.

Specification

A standard signature consists of r, s, and yParity. Since the top bit of s is always zero for canonical signatures (per EIP-2), this ERC "hijacks" that unused bit to store the yParity. The resulting 64-byte signature is a concatenation of two 32-byte values:

• r: The first 32 bytes, representing the x-coordinate of the signature point.
• yParityAndS: The second 32 bytes, which combines the yParity and s.

Visually, the structure is:

[256-bit r value][1-bit yParity value][255-bit s value]

TL;DR

This EIP reprices the ModExp (modular exponentiation) precompile to more accurately reflect its true computational cost. This makes various cryptographic functions that depend on it (like VDFs, SNARKs, and accumulators) cheaper and more practical to use on Ethereum.

New Gas Cost Formula

A new algorithm was introduced to calculate the gas cost, replacing the one from EIP-198. The formula is designed to better approximate the complexity of the underlying "bigint" library operations.

max(200, floor(multiplication_complexity * iteration_count / 3))

• Multiplication Complexity: Approximates the cost of a multiplication, calculated as (ceil(max(base_length, modulus_length) / 8))^2.
• Iteration Count: Approximates the number of multiplications needed, based on the bit length of the exponent.

Rationale

The previous formula from EIP-198 was found to be an inaccurate approximation. The new formula better models the performance of modern exponentiation algorithms, and the gas cost is calibrated against other precompiles like ECRecover to ensure network security and prevent DoS vectors.

TL;DR

This ERC defines a standard interface for commit-reveal schemes. It provides a generic commit function that can be added to any contract, allowing users to commit to an action without revealing it immediately. This helps prevent front-running attacks and adds a layer of privacy to applications like voting systems. The reveal mechanism is intentionally left open for developers to implement as needed.

Specification

The standard defines two interfaces for implementing commit-reveal schemes. The core interface is minimal for backward compatibility, while the general interface provides more features.

interface IERC_COMMIT_CORE {
    function commit(bytes32 _commitment) payable external;
}

interface IERC_COMMIT_GENERAL {
    event Commit(
        uint256 indexed _timePoint,
        address indexed _from,
        bytes32 indexed _commitment,
        bytes _extraData);

    function commitFrom(
        address _from,
        bytes32 _commitment,
        bytes calldata _extraData)
    payable external returns(uint256 timePoint);
}

TL;DR

This ERC extends EIP-1271 to allow signature verification for smart contracts that have not been deployed yet (counterfactual accounts). It introduces a wrapper format for signatures that includes the necessary data to deploy the contract, enabling dApps to verify signatures from users who haven't made their first on-chain transaction.

Specification

When a contract is not yet deployed, it wraps its standard EIP-1271 signature with deployment data. The wrapper format is detected by a specific magicBytes suffix.

• Wrapper Format: concat(abi.encode((create2Factory, factoryCalldata, originalSignature)), magicBytes)
• Magic Suffix: The signature ends with 0x64926492...6492.
• Verification Process: A verifier checks for the magic suffix. If present, it uses the provided create2Factory and factoryCalldata to deploy the contract. After deployment, it calls the standard isValidSignature function on the now-deployed contract with the original, unwrapped signature.

TL;DR

This ERC extends ERC-721 to create verifiable AI-Generated Content (AIGC) NFTs. It provides a standard way to prove that a piece of digital content was generated by a specific AI model with a specific prompt, using techniques like Zero-Knowledge Machine Learning (zkML) or Optimistic Machine Learning (opML). This enables on-chain provenance for AI art and new monetization models for model creators.

Specification

The standard introduces a core interface, IERC7007, which must be implemented alongside ERC-721. It includes:

• addAigcData(...): A function to associate AI-generated data (the content) and a proof with a token.
• verify(...): A view function that checks if the AI-generated data is valid for a given prompt and proof. This is where the zkML or opML verification logic resides.
• Optional Extensions: Includes Enumerable for discovering prompts/tokens and Updatable to handle data changes, which is particularly useful in optimistic systems.

A key design choice is that the tokenId is derived from the hash of the prompt, ensuring that each unique prompt corresponds to a single, unique NFT.

TL;DR

This ERC introduces a minimalistic standard for decentralized identity (DID) verification. It allows users to create, verify, and revoke their identity through a smart contract, using cryptographic hashes to keep sensitive data off-chain. The goal is to provide a simple, private, and user-controlled identity layer for dApps without the complexity of other DID solutions.

Specification

The standard defines an IDecentralizedIdentity interface with the following key components:

• Identity Struct: Stores the user's address, an identity hash, verification hashes, and a boolean isVerified status.
• Core Functions:
  • createIdentity(bytes32 identityHash): Creates a new identity for the caller.
  • verifyIdentity(bytes32[2] calldata verificationHashes): Verifies the identity by submitting hashes derived from off-chain proofs.
  • revokeIdentity(): Revokes the verification status of an identity.
• Events: Emits IdentityCreated, IdentityVerified, and IdentityRevoked events for transparency and traceability.