FailSafe: Advanced Security for Digital Assets
  • Introduction to FailSafe
  • Whitepaper
    • Introduction
      • Defense-in-Depth
      • Forward Security
    • Web3 Threats to Your Crypto
      • The Human Factor: Design with Operator Error in Mind
    • Defense-in-Depth & the Lifecycle of a Transaction
      • Defense 1: de-risk Web3 Asset Positions
      • Defense 2: FailSafe Blockchain Reconnaissance
      • Defense 3: FailSafe Interceptor Service
      • Discussion
    • FailSafe Architecture
      • Forward Security in FailSafe
        • Quantum Threats to EVM-based Blockchains
          • On ECDSA Key Re-use
          • On New Quantum-resilient Alternatives
          • Account Abstraction as a Path to Sunseting ECDSA on Ethereum?
        • Introducing the Quantum Migration Tool (qMig)
          • Assumptions and Goals
          • How Does qMig work?
          • Discussion
          • FailSafe+qMig
    • Conclusion
    • Further Reading
  • How FailSafe helps your Organisation
    • Reduce Attack Surface Area
    • Radar for Security Risks
    • React to Malicious Threats
    • Forward Security against Looming Quantum Computing Threats
  • FailSafe as a tool for Enterprise Risk Management
Powered by GitBook
On this page
  1. Whitepaper
  2. FailSafe Architecture
  3. Forward Security in FailSafe
  4. Quantum Threats to EVM-based Blockchains

Account Abstraction as a Path to Sunseting ECDSA on Ethereum?

Last updated 2 years ago

A future version of Ethereum is expected to support an account abstraction, a unified representation of an account (rather than the two types that exist today; a smart contract account, and an externally owned account (EOA) with a corresponding ECDSA private key). The most recent account abstraction proposal under consideration is . Among its features is a representation of an account as a smart contract wallet with for submitting requests (referred to as UserOperations) to the wallet. UserOperations can be signed using a quantum safe signature scheme. Under this proposal, after a network upgrade, the current user base with quantum vulnerable EOAs “”, as noted by Vitalik.

In the event of a quantum attack breakthrough, the user dependent upgrade strategy might mean a large number of unconverted accounts. Addresses with prior transaction history would be at highest risk. A recent examining addresses holding ether found that 65% of these addresses have a prior transaction history, where the ECDSA public key can be readily retrieved (this is excluding ERC20s tokens and other forms of assets). If the quantum attack breakthrough occurs while any significant portion of EOAs haven’t been upgraded yet, any subsequent transactions signed with ECDSA (including upgrade to quantum resilient wallet) would be suspect: is it the attacker or the key rightful owner performing the operation? By comparison, this dilemma is more severe than the after the 2016 DAO exploit (which resulted in a hard fork, and two chains going forward, Ethereum and Ethereum classic). To address this problem, a path rooted in cryptographic based trust is needed even when the algorithm authorising the majority of today's transactions is compromised (i.e., in a scenario where users need to migrate their Web3 assets to a forked version of the chain, where UserOperations only use quantum resilient algorithms).

EIP-4337
cryptographic agility
can individually upgrade their wallets to quantum-safe ones
Deloitte study
Ethereum rollback debate