Handling Ethereum calls

[raulk]

This are just some initial thoughts to kickstart a discussion.

Context

EVM smart contracts can call other code by performing CALL, CALLCODE, DELEGATECALL, STATICCALL opcodes. Let's specify the differences by working out through the following example.

Address A (externally owned account) calls address B (smart contract), and B performs a __________ to address C (smart contract), where _________ is...

Opcode	Description	msg.sender	storage affected	side effects
CALL	Message-call into an account	B	C	allowed
CALLCODE	Message-call into this account with alternative account’s code	B (*)	B	allowed
DELEGATECALL	Message-call into this account with an alternative account’s code, but persisting the current values for sender and value	A	B	allowed
STATICCALL	Static message-call into an account	B	B	disallowed (**)

(Descriptions from https://www.evm.codes/)

(*) This was deemed a bug and CALLCODE was eventually replaced with DELEGATECALL in EIP-7. .callcode() was removed from Solidity in 2018, and it is only accessible via EVM assembly.

(**) Side effects are listed in EIP-214. Performing side effects returns an exception (i.e. success output parameter is 0).

Discussion

Resolving addresses

All these operations can be called on two kinds of addresses:

• Ethereum addresses (usually derived from cryptographic material, e.g. ecrecover)
• f2 addresses (expected to be user input)

The Ethereum registry serves two purposes:

• Holds mappings between Ethereum and Filecoin f2 addresses -- both of which are backed by the same secp256k1 key
• Serves as a holding pen for funds sent counterfactually, concretely on sends to unmapped Ethereum addresses (both accounts and contract addresses). These funds can be claimed later by associating an f2 address.

❓ Question: how do the call handlers interact with the registry?

CALLCODE

Should we drop support for CALLCODE? Solidity no longer supports it and it's highly unlikely that we'll encounter this scenario. We could make usages of CALLCODE abort.

CALL

This is just a normal send.

DELEGATECALL

The FVM will need to cooperate here. We will need a mechanism to call other code within our own context / Kernel.

STATICCALL

Call the target actor with a special kernel that prohibits side effects?

[anorth]

Can I clarify that this is mostly about calling other EVM contracts? We're not talking about DELEGATECALL to a native actor or anything like that.

[Stebalien]

Yes. But, specifically:

We will need a mechanism to call other code within our own context / Kernel.

We can implement this as either a native DELEGATECALL syscall, or as some form of dynamic library feature.

[maciejwitowski]

Closing this one after splitting into:
#870
#871
#872