New ERC：Key based tokens

ERCs
1

[ERC] Add ERC: Key Hash Based Tokens by dugubuyan · Pull Request #1061 · ethereum/ERCs · GitHub
The proposal, ERC-KeyHashToken: Key Hash-Based Token Standard (EIP-TBD), introduces two token standards: ERC-KeyHash721 for non-fungible tokens (NFTs) and ERC-KeyHash20 for fungible tokens (akin to ERC-20). Unlike traditional standards, it employs a keyHash (computed as keccak256(hashKey)) to represent ownership instead of Ethereum addresses, with operations (e.g., transfer, destroy) verified via ECDSA signatures. The core innovations include enhanced privacy, separation of ownership and transaction initiation, and robust security through EIP-712 signatures and nonce mechanisms.

  • Need for Privacy Protection
  • Current State: In ERC-20 and ERC-721, ownership is tied to Ethereum addresses, which are publicly visible on the blockchain. Through on-chain analysis, these addresses can be linked to real-world identities, particularly in high-value transactions or NFT markets, compromising user privacy.
  • Proposal Advantage:
    • Replaces addresses with keyHash, allowing users to prove ownership without revealing their actual addresses. The hashKey (kept confidential) is only provided during signature operations, with only the keyHash recorded on-chain, reducing identity linkage risks.
    • Users can generate unique hashKeys for each token or balance, further minimizing linkability between on-chain activities, aligning with privacy trends like EIP-5564 (Stealth Addresses).
  • Necessity: As regulatory scrutiny increases (e.g., GDPR) and user demand for privacy grows (e.g., decentralized identity needs), privacy protection is a critical requirement for blockchain applications. ERC-KeyHashToken provides a standardized solution for privacy-sensitive scenarios.
  • Demand for Transaction Flexibility and User Experience Optimization
  • Current State: Traditional token standards require owners to pay gas fees and initiate transactions from their addresses, increasing costs and complexity in high-gas or batch transaction scenarios.
  • Proposal Advantage:
    • Separates ownership from transaction initiation, allowing anyone with a valid signature to initiate transactions and pay gas fees. This enables third parties (e.g., service providers, enterprises) to cover gas costs, similar to EIP-2612’s permit mechanism.
    • Supports batch transactions, such as transferring multiple NFTs in one transaction, optimizing gas usage.
  • Necessity: With fluctuating Ethereum gas fees, reducing transaction costs is vital. The proposal’s support for gas sponsorship and batch processing is particularly valuable for large-scale applications, enhancing user experience.
  • Detailed Application Scenarios
  1. Anonymous Collectibles (NFT Use Case)
  • Scenario Description: In digital art or collectibles markets, NFT owners want to hide their identities to avoid on-chain tracking. For example, a high-net-worth individual purchasing an art NFT wishes to remain anonymous.
  • Application:
    • With ERC-KeyHash721, NFT ownership is tied to a keyHash rather than a public address. Owners transfer NFTs via signatures without exposing their addresses.
    • Users can generate unique hashKeys for each NFT, reducing activity correlation.
  • Advantages: Enhances user privacy, attracting privacy-conscious collectors and boosting market competitiveness.
  • Real-World Example: NFT projects like Azuki or CryptoPunks could adopt this standard to offer greater privacy, appealing to high-end users.
  1. Private Financial Transactions
  • Scenario Description: In DeFi or institutional finance, users want to transfer tokens without exposing addresses, such as high-net-worth individuals moving large ERC-20 token amounts.
  • Application:
    • With ERC-KeyHash20, token balances are tied to keyHash, and users execute transfers via signatures.
    • Third parties can cover gas fees, simplifying operations.
  • Advantages: Protects transaction privacy, reduces on-chain tracking risks, and supports flexible gas payment, ideal for enterprise applications.
  • Real-World Example: Stablecoins like MakerDAO’s DAI could adopt this standard for privacy-preserving private transactions.
  1. Batch Transactions and Gas Sponsorship
  • Scenario Description: NFT marketplaces or gaming platforms need to transfer tokens in bulk for users who prefer not to pay high gas fees. For example, Axie Infinity wants to distribute reward tokens to new players.
  • Application:
    • Using ERC-KeyHash721 or ERC-20, platforms collect user signatures, initiate batch transactions, and cover gas fees.
    • Mimics Bitcoin’s UTXO model for optimized balance transfers (e.g., leftKeyHash).
  • Advantages: Reduces user costs, simplifies operations, and suits large-scale distribution scenarios.
  • Real-World Example: Platforms like OpenSea or Axie Infinity could use gas sponsorship to improve user retention.

Comparison with Existing Standards

Feature ERC-20/ERC-721 ERC-KeyHashToken
Ownership Identifier Ethereum Address keyHash (keccak256(hashKey))
Privacy Protection Public, No Privacy Anonymous, Signature-Based
Gas Payment Owner Pays Third-Party Can Pay
Security Basic Signatures EIP-712, Nonce, Deadline
Use Cases General Tokens Privacy, Batch Transactions, DID

Potential Challenges and Solutions

  • Privacy Limitation: hashKey must be transmitted during transfers, risking exposure.
    • Solution: Recommend hardware wallets for hashKey storage and encrypted channels for transmission.
  • Gas Costs: Signature verification and EIP-712 hashing increase gas consumption.
    • Solution: Use gas sponsorship and optimize implementations (e.g., batch operations) to offset costs.
  • User Education: Managing hashKey adds complexity.
    • Solution: Develop user-friendly wallet tools to simplify signature and key management.
1 Like