Change the API of `execute_message`

[MathieuDutSik]

Motivation

The function execute_message takes a single argument. However, two additional arguments are implicit and can be accessed by the runtime:

• is_bouncing
• message_origin_chain_id.

Their return types Option<bool> and Option<ChainId> reflect this. The solution is to have a single function execute_message that takes 3 arguments.

Fixes #4271

Proposal

The solution was relatively straightforward to implement and yields a net simplification.

For the source of the message, several names are possible:

• source_chain_id.
• message_origin_chain_id.
• chain_id.
• origin. I chose origin since it is the terminology used in MessageContext and is the shortest one.

The code of the smart contracts was not corrected. Ignored argument is_bouncing are quite apparent. This should be corrected so that the smart contract handles the bouncing case correctly. But this is for further work.

Test Plan

The CI.

Release Plan

• Nothing to do / These changes follow the usual release cycle.

Links

None.

[deuszx]

I'm not convinced this is a necessary change. Just like origin/sender etc are accessed via runtime similarly the origin chain id (and is_bouncing) can be there. In the API we have what's necessary and nothing more. Not every contract will use these new arguments and so they will have to ignore it.

[ma2bd]

I like the argument is_bouncing because it is likely going to be used immediately and people should know about bouncing messages. For the other one, we need to look at the resulting changes in examples.

[MathieuDutSik]

I like the argument is_bouncing because it is likely going to be used immediately and people should know about bouncing messages. For the other one, we need to look at the resulting changes in examples.

Yes, for is_bouncing that seems clear.

Now, regarding the source_chain_id:

• There are 6 contracts that do not use it and 4 that use it. Therefore, I think there are valid cases where it matters and valid cases where it does not matter.
• The source_chain_id can be put in the message itself. It is also possible to put other information: original block timestamp, height, etc.

Therefore, my proposal is:

• Add the ChainId in the message of the smart contract that uses it.
• Remove the origin: ChainId from the execute_message prototype.
• Keep the is_bouncing in the prototype.

[ma2bd]

Add the ChainId in the message of the smart contract that uses it.

Definitely not. This is a waste of storage and network (because the information is already present)