Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Native key delegation framework for multi-scheme EOA authentication

Aperta
  • Qualcosa non va?
#18 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
25/100
Tipo di issue
Funzionalità
Chiarezza
Da chiarire
Stato di attività
Ferma
Stack tecnologico
rust
Ambito
authentication, backend, cryptography

Direzione di ricerca

Inizia leggendo TxEnvelope::decode_from(), TypedTransaction::sender(), il registro di SignatureVerifier, eoa_registry.rs, SenderBootstrap, resolve_sender_account() e gli entry point di account authenticate() esistenti. Il lavoro è completo solo dopo che envelope, identità del tipo di chiave, comportamento della migrazione, bootstrap del sender, verifica e trattamento delle commissioni sono stati specificati e implementati con test; le decisioni di progettazione ancora aperte devono essere risolte prima.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

enhancement

Summary

Add a framework for EOAs to authenticate with non-ECDSA signature schemes (Ed25519, P-256, post-quantum), including the ability to migrate an existing ECDSA EOA to an alternative key type. Inspired by EIP-8164 (Native Key Delegation for EOAs) but adapted to ev-rs's account-driven architecture.

Motivation

  • Post-quantum readiness: secp256k1 ECDSA is vulnerable to quantum attacks. A key migration path is needed before it becomes urgent.
  • Passkey/WebAuthn support: Issue #14 adds P-256 as a one-off. A framework avoids repeating that work for every new scheme.
  • ZK-friendly signatures: Ed25519 and Schnorr are cheaper to verify in zkVM guests than ECDSA (relevant to #4).
  • Key rotation: Users should be able to migrate to a new key without changing their account identity.

Why ev-rs is well-positioned

Unlike Ethereum (where EOAs are permanently bound to secp256k1), ev-rs already separates the relevant concerns:

Concern Current state What it enables
SignatureVerifierRegistry Pluggable per tx type byte Register new verifiers without touching existing code
Domain-tagged identity keccak256(domain_tag || payload) New key types get new domains, coexist cleanly
authenticate() on accounts Account code defines auth logic Key type/migration logic lives in the account, not the protocol
Registry-based identity resolution Address → AccountId via storage Same AccountId can be reachable from multiple address derivations

EIP-8164 needs a new tx type and special bytecode prefix to work around Ethereum's constraints. ev-rs can do this at the account code level with a new tx envelope variant and verifier registration.

Scope

1. Signature scheme trait and registry extensions
  • Define KeyType enum: Secp256k1, Ed25519, Secp256r1 (P-256), extensible
  • Add ed25519-dalek crate dependency for Ed25519 verification
  • Implement SignatureVerifier<TxEnvelope> for Ed25519
  • Evaluate whether new schemes get new tx type bytes (e.g. 0x04) or a single "multi-sig-type" envelope that carries key type + signature
2. Transaction envelope extension
  • Add new TxEnvelope variant (or generic typed envelope) that carries: key type identifier, public key, signature, and standard tx fields
  • Extend TxEnvelope::decode_from() to handle the new type byte
  • For Ed25519: public key is explicit in tx (no recovery like ECDSA), so TypedTransaction::sender() derives address from the embedded pubkey
3. Identity derivation for new key types
  • Add domain tags: DOMAIN_EOA_ED25519_V1 = b"eoa:ed25519:v1", DOMAIN_EOA_P256_V1 = b"eoa:p256:v1"
  • Add derive_ed25519_eoa_account_id(pubkey) and equivalent for P-256
  • Extend EOA registry (eoa_registry.rs) to handle new key type registrations
  • Ensure same AccountId is NOT derivable from different key types (domain separation guarantees this)
4. Account-level key delegation (migration)

This is the EIP-8164 equivalent: an existing ECDSA EOA permanently delegates to a new key.

  • EOA account code stores active key type + public key in account storage
  • authenticate() verifies against the stored active key, not hardcoded ECDSA
  • Migration transaction: signed by current key, sets new key type + pubkey
  • Once migrated, old ECDSA key can no longer authenticate (permanent delegation)
  • Consider: revocation/recovery mechanism? Multi-key threshold?
5. Bootstrap and sender resolution
  • SenderBootstrap in stf_traits needs to handle non-ECDSA account init
  • resolve_sender_account() must work for new key type address derivations
  • First tx from a new Ed25519 key should auto-create the EOA account (same as current ECDSA bootstrap flow)
6. Gas/fee considerations
  • Ed25519 verification is ~2x faster than secp256k1 in software — could price lower
  • P-256 is ~20-40% slower than secp256k1 (see #14) — price higher
  • verify_signatures_parallel() already handles heterogeneous verifiers via the registry

Design decisions to make

  1. Single envelope vs per-scheme envelopes: One new tx type 0x04 with a key-type discriminator, or separate type bytes per scheme? Single envelope is more extensible; separate types allow tighter RLP schemas.

  2. Account identity on migration: When an ECDSA EOA migrates to Ed25519, does the AccountId change? It shouldn't — the account ID should be stable. The new key's address becomes an alias in the registry pointing to the same AccountId.

  3. Interaction with EIP-7702 delegation: EIP-7702 lets EOAs delegate to contract code. Key delegation is orthogonal (changes how you sign, not what your account does). But if ev-rs supports both, need to define ordering: key delegation first, then code delegation? Or combined?

  4. ZK proving cost: Ed25519 verification in a zkVM is significantly cheaper than ECDSA. If #4 (ZK proving) is a priority, this influences which schemes to prioritize.

Non-goals

  • Custom/arbitrary signature schemes at the protocol level (accounts can implement anything in authenticate() already)
  • Changing the Ethereum-compatible RPC surface — JSON-RPC still accepts ECDSA-signed txs as before
  • Multi-sig or threshold schemes at the protocol level (this is account code territory)

Relationship to other issues

  • #14 (WebAuthn/P-256): P-256 becomes one key type in this framework rather than a standalone addition. #14's scope (WebAuthn payload parsing, gas pricing) feeds into Section 1 here.
  • #4 (ZK Proving): Ed25519/Schnorr are cheaper in zkVM circuits. This framework enables switching to ZK-friendly signatures.

References

  • EIP-8164: Native Key Delegation for EOAs
  • EIP-7702: Set EOA Account Code
  • EIP-665: Ed25519 Precompile
  • ed25519-dalek crate for Rust Ed25519 implementation
Lingua principale
Rust
Stelle
4
Fork
0
Nessuna PR unita negli ultimi 30g

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di evstack/ev-rs

Tutte le issue di evstack/ev-rs

Issue simili

Altre issue su Rust

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.