EOA Contract Differentiation

[andrew-fleming]

Preface

Signature validation is handled at the contract level on StarkNet; thus, users utilize account contract abstractions to handle tx authentication. Read more on this concept in the Account documentation and in Perama's blogpost.

Because Solidity handles accounts by deriving them from a private key, the assembly function extcodesize() proves useful in differentiating between an EOA and an actual contract. EOAs return 0 as code size, contracts do not.

Problem

Because EOAs are contracts, it seems like we'll need a new way to differentiate EOA contracts and regular contracts. While implementing ERC721, this is discovered to be a problem, but I'm sure this will show up elsewhere in the future. A feature request for StarkWare seems warranted here.

Thoughts, ideas, and/or opinions regarding this differentiation issue? Any potential solutions overlooked?

[martriay]

I think we could explore a solution similar to EIP-1271 and have an is_account function (or similar) that returns 1 (true) or a magic value.

Note that the role of the magic value makes more sense in Ethereum where you need to identify you're calling the right function since function selectors are only the first 4 bytes of a hash (32bits), making collisions much more likely than in StarkNet where function selectors are 250bits.

[andrew-fleming]

@juniset I think that's a good approach. I added is_account to #133 wherein EOAs return 1 and contracts that accept safe NFT transfers return 0 (which triggers the interface check). Having the method return a magic value might be the better implementation.

[martriay]

I see no downsides with the magic value, let's go that way.

[juniset]

Sounds good! For consistency I think we should also make the is_valid_signature method return a magic value.

[georgercarder]

If the goal is to have a secure way of distinguishing if a call is from a contract or "EOA"s (an Account style contract), simply exposing an is_account function is not a secure solution.
Malicious developers who wish to convince contracts that need to make this distinction can simply deploy their convincing contract with such an is_account function. Both non-"EOA" and "EOA" contracts can have such a is_account function. This is very different than in the EVM where a pattern to ensure that the msg.sender == tx.origin is by running ecrecover on a message signed by the msg.sender's private key which is only possible with a true EOA.

I'll review the workings of the current Account contract and spec and see if there is anything from the set public key and transaction signature that could be coupled and checked by the contract that could enforce this distinction.

[atimark]

{
"status":"1",
"message":"OK",
"result":[
{
"account":"0x88197EaCf7545B2686715FbBE3DBb0ec725A8514",
"balance":"1230512732137993"
},
{
"account":"0x262a6f88604aa10b30565b02731441ab55d9e9a3",
"balance":"45510297013773890"
},
{
"account":"0x27a0a9bf2916685ac00c2abc735eb9048a1c3ba4",
"balance":"15634979003136277"
}
]
}

[martriay]

This week @spalladino suggested to replace is_account with ERC165, which makes a lot of sense to me:

• just like 165, is_account is an introspection mechanism
• if we go with is_account, we'll find awkward scenarios such as ERC721Receiver having to implement a falsy is_account function to play nicely with ERC721 -- while ERC721Receiver already implements 165, so it'd suffice with asking if it supports the account interface
• using 165, we're both simplifying the account interface and hardening the standard at the same time (by requiring contracts to comply with the full interface not just is_account)
• it returns a magic value by default, leveling up the security

Therefore I (stealing Palla's thunder) suggest we remove is_account and add 165 as part of the account standard.

[martriay]

I'm so sorry https://github.com/OpenZeppelin/cairo-contracts/blob/main/contracts/ERC165.cairo#L12

[andrew-fleming]

Yes! This definitely solves the awkward is_account instances while also hardening the 165 standard.

Regarding the account interface, I believe it will look something like what I coded below.

pragma solidity ^0.8.9;

interface IAccount {
    function getNonce() external;
    function supportsInterface(bytes4) external;
    // hash, r, s
    function isValidSignature(bytes32, bytes32, bytes32) external;
    // to, selector, calldata, nonce
    function execute(address, bytes4, bytes calldata, uint256) external;
}

This calculates to the magic value 0xabffa2f1.

contract Selector {
    // returns 0xabffa2f1
    function calculateSelector() public pure returns (bytes4) {
        IAccount i;
        return i.getNonce.selector ^ 
        i.supportsInterface.selector ^
        i.isValidSignature.selector ^
        i.execute.selector;
    }
}

What do you guys think?

[martriay]

I don't think we should include supportsInterface, since it's part of the account standard but not its interface. Also, note that is_valid_signature takes a hash and an array of hashes, so (bytes32, bytes[]) would be a better approximation.

Finally, I'm not sure how to deal with the camel/snake case thing here (I'm starting to hate it). I guess it makes sense to write the account interface verbatim, this means not changing the casing.

[andrew-fleming]

Excellent, sounds good. And good call on the array of hashes—I'm used to seeing r and s as separate bytes32 params. Here's the updated interface and calculated selector:

pragma solidity ^0.8.9;

interface IAccount {
    function get_nonce() external;
    // hash, sig[]
    function is_valid_signature(bytes32, bytes[] calldata) external;
    // to, selector, calldata, nonce
    function execute(address, bytes4, bytes calldata, uint256) external;
}

contract Selector {
    // returns 0x50b70dcb
    function calculateSelector() public pure returns (bytes4) {
        IAccount i;
        return i.get_nonce.selector ^ 
        i.is_valid_signature.selector ^
        i.execute.selector;
    }
}

[martriay]

Well Cairo selectors are always a felt so I guess we should go with bytes32 instead of bytes4. Mhh although following that reasoning, everything could be bytes32. This is an awful approximation.

I wonder what @juniset thinks of this.