# Quantum-Proofing Ethereum: Using ERC-4337 Account Abstraction with a Wallet with a Quantum Resistant ZK STARK Signing Mechanism

## **💸 Hard Problem Statement**

Quantum computers will break Ethereum and Bitcoins signing scheme by allowing anyone to reverse engineer a secret key from a public key. Luckily, addresses are safe; if we make public keys "quantum-secret" and don't reveal them either, then there is a path for plausible quantum resistance without many changes to the system.

### Links to understand:
**Nontechnical intro:** https://hackernoon.com/quantum-contingencies-in-cryptography-a-short-primer-fd143xrp
**Technical breakdown without solution:** https://www.ledger.com/blog/should-crypto-fear-quantum-computing (ignore their "IS THERE A CURE" section -- they didn't consider this solution)
**Technical breakdown with solution:** https://blog.aayushg.com/posts/quantumcrypto
**In-Depth Technical Solution + Discussion:** https://ethresear.ch/t/quantum-proof-keypairs-with-ecdsa-zk/14901
**ECDSA Signature Details** (and more efficient version that may or may not be quantum proof), by Dan and Vivek: https://personaelabs.org/posts/efficient-ecdsa-1/
**Account Abstraction**: https://ethereum.org/en/roadmap/account-abstraction/
Bonus: **Pretty Quantum Math Animations for RSA by Veritasium:w** https://www.youtube.com/watch?v=-UrdExQW0cs
Bonus: **Aayush's Video Intro for this Project**: https://youtu.be/_-6Ye8cVJFA

Implement a system that allows a user a fully quantum-secure way to interact with Ethereum moving forwards.

## **🧙 Detailed Requirements**

Required components include:
- A **wallet interface** that signs with a ZK-STARK of an ECDSA signature, revealing only the address and keeping the public key secret. You can fork an open source wallet like Tally Ho if you wish, or use a simple burner wallet with local Javascript, make your own from scratch.
- An **account abstraction smart contract** that verifies that signature, and allows you to execute any other solidity function on chain. You can fork the [infinitism template](https://github.com/eth-infinitism/trampoline), that will probably be easiest.
- Ideas to **monkeypatch ecrecover** and other on-chain utilities that let smart contracts to ingest public keys. These will have to be replaced to allow smart contracts which used such commands in the past to continue as usual.

Note that for now, the address that sends the transaction on-chain will not be quantum secure (this will change when Ethereum officially forks and adopts STARKs for signatures by default).

## **🎯 Expected Deliverables**

Deliver a full end to end system with a test. I should be able to interact with most smart contracts on Ethereum end-to-end without ever revealing my wallet public key.

## **💯 Evaluation Criteria**

**1. Functionality**

- You should implement all 3 components such that I can interact with a pre-existing on-chain contract with minimal changes to Ethereum.

**2. Security**
- The system needs to generate STARK proofs client-side, and verify the proofs on-chain efficiently enough to be practical on an L2. Note that verification will be too expensive on an L1.

**3. Speed**
- It should be fast to generate this post-quantum ZK STARK client-side. Most frameworks do this by default so I expect this to be easy.

## **🥷 How to submit your entry**

Link us to a git repo/organization and live demo deployed to a public website or browser extension that we can use to instantly test the functionality.

Fill in this form: https://ni31qtivlel.typeform.com/to/D92QYgYR -- mark Push Protocol for sponsoring the project.