Multicall & Upgrade tests for accounts

[ermvrs]

We designed Rosetta accounts to act differently on specific function selectors. Currently, there are only two special selectors, but we may add more in further depending on the need.

pub const MULTICALL_SELECTOR: felt252 = 0xFFFFFFFF;
pub const UPGRADE_SELECTOR: felt252 = 0x74d0bb9d; // function upgradeRosettanetAccount(uint256)

Multicall Selector : This transaction is defined as a multicall transaction. As you know, native multicall is not supported in Ethereum. So, we designed different ways to achieve using this functionality in Starknet. While sending a transaction, this transaction has to be encoded & signed, like calling a function with this selector and an array of the following type as a parameter

pub struct RosettanetMulticall {
    to: EthAddress,
    value: u256,
    calldata: Span<felt252>,
    directives: Span<u8>
}

So, the account will execute these calls in the same order. We don't need to verify the target function on these calls, but maybe we can add a new property called entry point and remove directives, so multicall will be executed in an ordinary way in starknet. Since 1:1 EVM implementations can't use this functionality without changing their interaction part.

Upgrade Selector : Once this selector is sent, the account contract will read the latest class hash from the Rosettanet registry. It upgrades itself if there is a different class hash in the registry.

The upgrade part has already been implemented, but we need to develop tests for it. Develop a mock account contract and try to upgrade. I don't have security concern about this part. But we really need to implement nonce check feature before going live.

[ermvrs]

After we decide multicall object, we have to redefine multicall selector

[ermvrs]

Rosettanet calls are expensive at the moment. I believe we have to implement multicall is like ordinary starknet multicall struct so we don't need to verify target functions on each call. So the user has to sign a transaction from Ethereum such as if they are calling their own account contract with multicall selectors and an array of the following struct

• Target contract: This can be the contract address or the ethereum address. If Contractaddress it will be uint256 otherwise eth address. Contract address will be cheaper but inconsistent
• Entrypoint: it is felt252 but in solidity it will be uint256
• calldata: array of felt252
• directives: array of uint8

The user will sign this transaction with their web3 wallet. We can trust these inputs, and we don't need to use the keccak syscall three times for each call.

Maybe we don't even need directives.