Adds initial versions of our account abstraction contracts

[smartcontracts]

Description

Helloooo, as always. This PR adds various contracts that enable basic account abstraction for EOAs. Here's the overview for the newly added contracts:

ECDSAContractAccount

ECDSAContractAccount is a super simple contract that verifies transaction signatures and runs ovmCALL or ovmCREATE. It has a single entrypoint:

    function execute(
        bytes memory _transaction,
        bool _isEthSignedMessage,
        uint8 _v,
        bytes32 _r,
        bytes32 _s
    )
        public
        returns (
            bytes memory _ret
        )

SequencerMessageDecompressor

SequencerMessageDecompressor is middleware that allows the sequencer to run custom decompression steps to reduce calldata size. Currently, it also allows the sequencer to generate ECDSAContractAccount contracts on behalf of a user via the new ovmCREATEEOA opcode without requiring the user to sign two different transactions.

ExecutionManager (changes)

ExecutionManager now has three new functions, ovmCREATEEOA, ovmSETNONCE, and ovmGETNONCE, which make it possible to dynamically generate ECDSAContractAccount contracts on behalf of users.

Metadata

Fixes

• Fixes YAS-607, YAS-608, YAS-609

Contributing Agreement

-[x] I have read and understood the Optimism Contributing Guide and Code of Conduct and am following those guidelines in this pull request.

[karlfloersch]

Nice! This LGTM! The thing that really needs to be changed / updated / tested more about this is the actual transaction encoding & decoding that will be used by the sequencer.

For instance, we really need to add tests which generate the calldata in exactly the way that the sequencer will generate calldata (using the same function even), and then make sure that the signatures are recovered correctly. That's currently missing but definitely is something we need to add.

Instead of adding it to this PR; however, I am down to create a new ticket for finalizing the sequencer tx data format and knock out that ticket during the contracts refactor. That said, open to suggestions if we want to knock that out now.

Ah and another ticket we need to add (or implement in this PR) is making the sequencer decompressor & EOA contracts upgradable. This is going to be required for upgrading the fee mechanism post launch

cc @kfichter @ben-chain

Either way, I'm approving and we can chat about the best way to proceed wrt making tickets for or implementing:

1. calldata decoding/encoding (finalizing the format that the sequencer will use)
2. Adding fee collection to the (ECDSA) EOA Contract
3. Making the EOA Contracts upgradable.

[karlfloersch]

Right now this EOA contract is not upgradable but it definitely should be & also shouldn't be hard to make it. This contract won't have to change too much but we just need to make a more generalized: EOAContract which starts out with it's implementationAddress pointing at this contract, as well as a simple function

So it's important that we allow upgradability

should add a very simple function to this in order to enable upgradability --

    function upgrade(address newImplementationAddress) {
        ExecutionManger em = ExecutionManager(msg.sender);
        require(em.ovmCALLER() == em.ovmADDRESS());
        implementationAddress = newImplementationAddress;
    }

This can be the final form of the EOAContract

[karlfloersch]

So the parent / upgradable contract would look something like:

contract EOA {
    address implementationAddress;
    function() public {
        ExecutionManger em = ExecutionManager(msg.sender)
        address target;
        bytes memory returndata;
        if (implementationAddress == address(0)) {
            (target, returndata) = em.ovmCALL(ECDSAContractAccount_ADDRESS, calldata) // call the ECDSAContractAccount
        } else {
            (target, returndata) = em.ovmCALL(implementationAddress, calldata)  // call the alt implementation
        }
        em.ovmCALL(target, returndata)
    }
    function upgrade() {
        ExecutionManger em = ExecutionManager(msg.sender);
        require(em.ovmCALLER() == em.ovmADDRESS());
        implementationAddress = newImplementationAddress;
    }
}

[smartcontracts]

Good point! I'll add this.

[karlfloersch]

Ugh one horrible note is that if we transpile revert (which we have to) we will need to transpile this contract so that we don't actually REVERT when this require fails. 😭

I guess this is an argument for not adding upgradability until we have the final version of the contracts because we'll have to change a bunch of stuff when we rewrite these contracts anyway

[karlfloersch]

So this native "recover" logic should probably be replaced with -- https://github.com/ethereum-optimism/optimism-monorepo/pull/243/files#diff-4a7bd8c005926e358a62f04b6d552157L187 recoverEOAAddress(...) or equivalent. Unfortunately the actual signature recovery logic for normal Ethereum transactions is a bit complex (you have to RLP encode 2 zero values) and so we need to update this to work end-to-end.

I'm down to put off finalizing the tx decoding and the specific sequencer calldata format util later but if we do we should definitely create tickets for it.

[karlfloersch]

Oh, alternatively our SequencerMessageDecompressor actually constructs the exact RLP encoded calldata and then passes that directly into the ECDSAAccountContract.

No matter what, this decoding logic will definitely need to be updated.

[karlfloersch]

This confused me so much but then I remembered we don't ABI encode our parameters ughhhh

[smartcontracts]

Agh yeah. I'm gonna rename this to be more clear that it's a wrapper around the ExecutionManager.

[karlfloersch]

Ah I just realized that this does not include fee logic! We'll need to add an ERC20 contract precompile which is at a fixed address & which we use for collecting fees inside of the EOA account.

Again, either we add it here / include in this PR or we'll need to make another ticket for it

[tynes]

Instead of hardcoding 108, shouldn't this use something like:

uint256 id;
assembly {
    id := chainid()
}

raw[6] = RLPWriter.encodeUint(id);

[tynes]

I like the usage of defaultAbiCoder.encode more than my above implementation of serializeEthSignTransaction, we should create a function in ovm-utils

[tynes]

What do you think about calling this EIP155 instead of NATIVE_ETH_TRANSACTION? I think its more descriptive of its type

[K-Ho]

closed in favor of ethereum-optimism/contracts#33