Update EIP-8141: Spec cleanup and clarifications

[morph-dev]

Clean up of the EIP-8141 spec. Some highlighter changes:

• sig.signer can be empty and defaults to tx.sender
• raw sig.signature bytes are elided for all sig_hash
  • since all signatures need to be valid for tx to be valid -> committing to sig.msg indirectly commits to sig.signatures as well
  • if they are not elided, they can't be used for signature aggregation in the future
• Mempool: Expiry Verifier Frame can only be the first frame in the frame list
• Moved some content from one section to another where I though it would be more appropriate

Note

I left several TODO in the code where I think we might want to change / clarify something. These should be resolved before merging.

[eth-bot]

File EIPS/eip-8141.md

Requires 1 more review from Authors: @derekchiang, @drortirosh, @fjl, @forshtat, @lightclient, @nerolation, @shahafn, @vbuterin, @yoavw

[derekchiang]

I think the signature index thing is mostly an optimization for quantum (since the outer signatures can be aggregated and then removed from the txns), which is not really useful here since the signature is ECDSA.

Re why no P256 support -- supporting P256 in the default code means that we'd have to support P256-EOAs, where the EOA address is derived from P256 pub key. My initial version of default code actually did support that, but after some discussions with @lightclient we decided to remove it since introducing a new class of passkey-derived EOAs may open a can of worms that is hard to put back.

[derekchiang]

By the way, another TODO for the default code is that we need to define a gas schedule for it. Since the default code is implemented not in the EVM but rather in client code, it's not clear how much gas it costs, unless we define it.

Or, we could define the default code in terms of EVM bytecode.

[morph-dev]

I think signature index makes design cleaner. Why would code iterate over all signatures and try to check which one of them matches the requirements (scheme, msg, target), when we can just pass the index and it only checks one. Also, having index would make it easier to design gas schedule (if we want it to be executed as client code rather than EVM bytecode).

Regarding P256 support, I can see that as a good enough reason. It's something we can easily add in the future.