Do we have to refactor CALLDATALOAD, CALLDATASIZE, and CALLDATACOPY?

[PaulRBerg]

This is a question for you @IaroslavMazur.

We are working on implementing the CALL2 opcodes while maintaining the standard EVM opcodes CALL for increased backward compatibility.

Don't we also have to refactor CALLDATALOAD, CALLDATASIZE, and CALLDATACOPY? These opcodes read from calldata, which in the case of SabVM, they might contain trailing token IDs and values.

My hunch is that yes, we do need to refactor them. But the good news is that they need not contain custom stack inputs, so we don't need companion opcodes (that is, we don't need CALLDATALOAD2, etc.).

[IaroslavMazur]

What exactly do you mean by "refactoring", in the context of the aforementioned opcodes?

All of them work with the information about/from the calldata of the current execution context, and the only potential problem I've thought about in this regard is if a smart contract deployed to SabVM would try to work with the calldata directly - but instead of accounting for MNTs, it'd expect to find just the standard value there (e.g. when CALLDATALOAD is being called during the execution of the old-school CALL opcode).

While this will mean less backwards-compatibility for SabVM, I don't know what we could to to address this. It's not like we could have 2 different behaviors for these 3 opcodes, depending on the "perspective" of the caller contract upon the calldata - there's no way we could check programmatically how the contract will interpret the calldata after these opcodes are executed.

[IaroslavMazur]

Right now, the nr_of_transferred_tokens and the (token_id, value) pairs are at the same level as the standard value, as they have replaced it.

The backwards compatibility is assured by us supporting the standard opcodes (that redirect the action to our custom opcodes, where relevant), and not by structuring our own opcodes in a certain way (can't backwards-support what's not even backwards-recognizable 🙂)

[PaulRBerg]

I stand corrected. Thank you for explaining.

[IaroslavMazur]

I stand corrected. Thank you for explaining.

🫡

[PaulRBerg]

In practice what will happen is this:

• We will implement a precompile (in Rust) that facilitates MNT transfers with (token_id, value) pair sitting at the same level as data
• In Solidity, we will offer a library that we will enshrine in our documentation (i.e. all users will need to use that)
• The enshrined library will be syntactic sugar to interact with the precompiles, encoding the Solidity parameters according to the API of the precompile

[PaulRBerg]

Related discussion about the enshrined library: #86