EIP-8164: Native Key Delegation

1

Add a new transaction type that allows EIP-7702-style delegation of accounts to non-ECDSA keys. Specify ed25519 as the first non-ecdsa key type. Discuss extension to post-quantum key schemes, pending selection of a suitable scheme

EIP source

5 Likes
2

Good read.

The “either or” interaction with 7702 delegations is a bit offputting as it feels like a regression. I understand that it simplifies the scope.. do you see the future combined designator EIP as necessary / inevitable, or is that just one potential approach?

I think it’s worth acknowledging that this will become a new best practice for sweeping compromised accounts and we can expect a spike in delegations similar to 7702 (additionally there isn’t the opportunity to recover any assets which weren’t swept, given the irreversibility of this type of delegation)

3

I’d advise against hard coding signature algorithms, particularly ed25519 as you will run into the same problem as EIP-7980 (ACDE do not want to add another non PQ safe algorithm).

You should also probably modularise your spec, I.e. support signing for any algorithm. You may wish to checkout EIP-7932, it could be useful.

1 Like
4

I think the followup work is

  • native key tx type that supports 4844
  • native key tx type that supports 7702
  • combined key + contract delegation

7702 that does a combined delegation, as well as of 4844 txn.

2 Likes
5

The purpose of the EIP is to address that ACDE concern. It is impossible to have a secure migration path to a PQ scheme without first having a secure migration path to some scheme. It’s explicitly not modular to keep it as simple as possible. What we want is a single-signature migration path for existing accounts that allows batching. We added a specific scheme (ed25519) so that the path can be used in prod and have tooling built around it well before it’s needed

1 Like
6

If you had to pick a scheme use P256. It was the initial design of EIP-7932 and EIP-7980 to use ed25519, and it got almost instantly dropped because of ed25519.

7

I have no attachement to any signature scheme. Just to establishing a migration pattern early

3 Likes
8

Is this a contingency plan in case EIP-8141 is not approved, since we will specify the signature and validate during execution using code?

9

I think this is a much simpler alternative to one of the things that EIP-8141 does.

2 Likes
10

i think 8141 is trying to solve too many problems at once, and has too much complexity to be effectively reviewed. 4 new opcodes, which may operate in 15 different modes is not a reasonable approach to any problem, and will not result in normalizing user migration in a reasonable amount of time. 8141 is likely to go the way of 7702, where hardware and other wallets explicitly disable it due to their inability to assess the safety of any individual transaction

2 Likes
11

now has ML-DSA instead of ed25519 :slight_smile:

12

I’ve been building more or less exactly the crafted-signature path this EIP describes, at the application layer on top of EIP-7702, so maybe some numbers from a working implementation are useful here.

The setup: instead of signing the 7702 authorization tuple, I craft it — r is a hash commitment to the account’s initial configuration, and the account is just whatever address ecrecover spits out. No key ever exists, and forging the same address with a real key would mean solving the discrete log, so you get the rootlessness property this EIP is after, today, without touching the protocol. Using chainId 0 in the tuple means the nonce only burns on the chain that applies it, so the same blob keeps working on any chain you haven’t touched yet, indefinitely.

I ran one blob unmodified against Sepolia and Base Sepolia: same account, same address, same factor configuration, gas identical to the unit on both (375,598).

A few things I hit that might be relevant to the crafted-signature section:

  • v turned out to be unnecessary as an input: recovering with v=27 worked every time the crafted r was a valid x-coordinate.
  • crafting is cheap, about 2 attempts on average to land a valid r, and you can always pick low-s.
  • one footgun: my address commits to the whole initial config, which includes a P-256 possession proof signed by the factor holder. Whether re-crafting from the same factors gives you the same address depends entirely on the signer’s nonce policy — RFC 6979 reproduces, random-nonce signers don’t. Took me a while to notice because my TypeScript and Python clients disagreed on it. If tooling around 8164 assumes recomputability, it should care about this.

Doing this app-side also makes it obvious why the protocol version matters: my delegation is irrevocable forever by construction (I accept and document that, but it’s a one-way door), and rootlessness doesn’t remove the secp256k1 authority — whoever breaks the curve can still compute the key nobody ever held, whatever factors are installed. Native migration like this EIP proposes is the actual fix for that.

Code is here if anyone wants to poke at it (MIT, and to be clear: not audited): GitHub - bernalli/glaux: Minimal, crypto-agile EIP-7702 smart account: one address on every EVM chain, 2-of-3 threshold on the operational path, P-256/secure-enclave signers, sign-once replay-many rotation. Unaudited reference implementation. · GitHub — the two-chain run with explorer links is in docs/deployments.md, trade-offs in docs/threat-model.md. Happy to be told where it breaks.