Standardization of cross-contract calls

[xgreenx]

The main goal of this topic - to define, describe and standardize cross-contract execution based on ink to avoid unexpected behavior.

The second goal - to be an instruction(or base point for documentation) on how to do cross-contract execution to avoid issues like #634 and etc.

Like a Solidity, the ink will be used often for tokens and DeFi. So definition and execution of ERC20 analogs must be clearly documented. Like it have been done for ERC20(and other standards).

First, we need to define how better to call the method of another contract if you have only the address of this contract(and maybe trait/interface). At the moment it is not described in the documentation, but can be found via code.

To execute the method of some contract you need to know the selector of this method. You can set the selector manually, but it also can be generated automatically according to these rules.

The rules to create the selector of the method are not the same as in Solidity. ink takes the first 4 bytes of the hash of functions name(including namespace/trait/path) when Solidity takes the first 4 bytes of the hash of functions signature. It is an important difference that can cause many unexpected behaviors. So ERC20.transfer method will have a different selector than Erc20.transfer. While in the case of Solidity naming of interface/contract doesn't impact the hash and it is two same methods if they have the same arguments and return values.

The first question: Is it the final architecture decision about selector evaluation?
The second: We need to define a naming convention for traits(interfaces) which better to use during contract creation and implementation. For example, we can define that name of each trait must be in the CamelCase, the naming of the method in under_score. We will create repositories with trait definitions(ink::trait_definition) of default ERC*. In this case, if someone is waiting for the address of the ERC20 token, he expects that contract implements the ERC20 trait from this repository. But at the moment it is not possible(take trait definition from the crate) due to issue: #683

At the moment, we do not have a beautiful and simple way to get the selector of some method if we have the trait. We need to calculate it manually. For that, you need to use the name of the function and blake2b-256 hasher and take the first 4 bytes.

Will be cool to have the ability to get a selector of some method based on the trait. Or create a struct around the address, call_builder and trait_definition to simplify contract execution. But it can be part of this issue: #665

TODO: Add more information/updates during this issue

[Norfolks]

Since that we could have tokens both working with EVM, and ink!.
We need to have contracts working fine with both type of ERC20 contracts(written in solidity and ink!).
To provide so, we can use #[ink(selector = "..")] for methods notation, and explicitly set them equals to EVM hash type.
Because selectors created too different, it looks like the only way.

So erc20::transfer_from hashed with blake2b could never be the same as for transferFrom(address,address,uint256) hashed with keccack256.

[xgreenx]

Since that we could have tokens both working with EVM, and ink!.
We need to have contracts working fine with both type of ERC20 contracts(written in solidity and ink!).
To provide so, we can use #[ink(selector = "..")] for methods notation, and explicitly set them equals to EVM hash type.
Because selectors created too different, it looks like the only way.

So erc20::transfer_from hashed with blake2b could never be the same as for transferFrom(address,address,uint256) hashed with keccack256.

It can be a cool feature to have the same identifiers as in EVM to have cross-pallet calls, but I think it is something another and not part of this issue and maybe the current scope of ink!=)

[xgreenx]

We created a repository with defined traits and base implementation of tokens. It is not production-ready because there exist issues that must be resolved first. But we will resolve them and update the code according to resolved issues.