Investigate EOA control delegation

[j1010001]

Capturing problem statement + ideas: https://www.notion.so/flowfoundation/Investiagion-EOA-control-delegation-2001aee1232480d5aad3fcb94ac7820a

[joshuahannan]

Had an initial call with the team to lay out the problem and discuss some considerations for the solution. Dete's writeup in the notion doc summarizes the problem and potential solutions, but here are some additional notes from the call:

We need to be able to do both of these:

• Create a brand new COA that controls a brand new EOA
• Create a brand new COA that controls an existing EOA by configuring it with some mechanism from the EVM side. That is either a signed message, or something with EIP 7701

Since these new Cadence controlled EOAs will have 90% of the same functionality as existing COAs, it would be really nice to be able to use the same type for both. That would allow it to continue to work with existing code that interacts with COAs. There may be an issue with managing both types of accounts with the same object that may prevent this, like how to tell them apart.

Need to figure out the order of operations for creating a Cadence controlled EOA. Does EVM indicate first that it can be controlled by cadence or does Cadence generate the address first and get the validation from EVM later? Leaning towards EVM first to avoid having unusable COAs, but this might require a way for an EVM address to indicate that it only wants to be able to be controlled by a specific account in Cadence. I'll do some more research on the right path for this.

My current priorities:

1. Familiarize myself with the EVM smart contract. As part of this, I am updating comments and rearranging code to make it more clear and help myself learn.
2. Familiarize myself with the FVM codebase and how COAs work in FVM. I'll be talking to Gregor, Janez, and maybe Ramtin about this soon.
3. Learn about EIP 7701 and how that might be able to be used to delegate control of an account.

[m-Peter]

While working on the Pectra upgrade for Flow EVM, I came across this and opened an issue to track it: #7169 .
Mainly to investigate if there's a workaround to make COAs comply with the EIP-7702.
Given that COAs don't really have any keys, like EOAs do, it's quite hard to sign authorizations.
The specification for EIP-7702 can be found here: https://eip7702.io/#specification, and some functional examples of how to utilize it with 3rd party clients, such as Viem, can be found here: https://viem.sh/docs/eip7702/sending-transactions .
The EVM GW has some integration tests for this as well: https://github.com/onflow/flow-evm-gateway/blob/main/tests/web3js/eth_eip_7702_sending_transactions_test.js .
I will loop in @bluesign as well, given that we had some discussion about the shortcomings of COAs and possible solutions for this.

[bluesign]

More I learn about the evm, I am more convinced that COA was a design flaw tbh. ( or hype directed development )

Any chance you can share with me to notion doc?

In the meantime, after experimenting with evm a bit, I believe users should not own a COA at all. ( only developers should use it )

[bluesign]

I have few questions that I am not sure about the answers.

Considering I have a key pair ( EVM EOA ):

1. is it safe to delegate it and take it back ? ( we can think it as giving the pubkey temporarily, where it is not stored etc )

I am a bit on "no" side here, but my EVM experience is limited.

So giving access to COA and revoking later for me is a no go a bit.

2. can one EOA have multiple COA bindings?

this is also a bit tricky I guess, I feel like it adds value, and as it cannot be revoked ( from point 1 ) I think it makes sense.

[devbugging]

Looking at this I don't think EIP 7702 can be used to achieve delegation of EOA to COA permanently since the contract code is only active during transaction. This means if COA would want to make an action on behalf of EOA, the EOA would have to prepare and sign the transaction first, which makes the whole idea of COA controlling EOA not work. It could be only used for initial delegation of access, but there's also other ways to do that, but I don't see how it could be used after that.

The EIP-3074 would make it possible to permanently delegate EOA control to COA (until revoke), but it was withdrawn due to EIP 7702.

[joshuahannan]

Thanks for looking into that @devbugging! So you're pretty confident that using 7702 is not worth exploring more? We'll need to do something that gets more into the internals of the EVM?

[bluesign]

Looking at this I don't think EIP 7702 can be used to achieve delegation of EOA to COA permanently since the contract code is only active during transaction

7702 should set code persistently until it is revoked iirc, but I may be wrong

[jribbink]

Yeah, these account abstraction EIPs had a lot of thrashing leading up to Pectra before ending up on 7702, specifically around persistence, hence some of the ambiguity here - but https://eips.ethereum.org/EIPS/eip-7702 should be the current reference.

[devbugging]

oh my bad, I mixed 3074 with 7702 I guess (yesterday wasn't my day).

The 7702 as proposed to permanently set the code on EOA would work. What this means is we can have two approaches:

• converting an EOA into smart contract account that is same as now COA is, and then change the logic of EVM implementation
• using EOA with delegated access so we can use an existing COA to access the EOA until revoked, this should work more natively and I don't think require much changes in EVM implementation on Flow. Will focus on this approach and what it would take.

[devbugging]

@jribbink yeah that's probably what got me confused yesterday. But yeah official reference is clear.

[bluesign]

just need to add a forwarder function to COA smart contract code [https://github.com/onflow/flow-go/blob/master/fvm/evm/handler/coa/coa.sol]; something like: forwardCall( target, data, gas )

then inside forwardCall need to pre check if it is called by COA; like: `EXTCODECOPY(address(this)) == 0xef0100 || msg.sender '

this should be a working implementation without anything else, but there are a lot of nice to haves, which leads to more questions, should COA know about this delegation when it happened?, multiple delegations etc.