fix(unmerged): contract caller as a chain extension origin

[chungquantin]

In the extension code, we have set the contract itself as the default origin for all calls. However, when it comes to methods like approve and transfer_from, there's a potential problem. Typically, the approve function allows a user (like ALICE) to approve another entity (like a contract) to spend their funds. But since we've set the contract as the origin for all calls, transfer_from would only be callable by the contract itself.

// Contract is the origin by default.
let origin = RawOrigin::Signed(env.ext().address().clone());
log::debug!(target: Logger::LOG_TARGET, "contract origin: origin={origin:?}");
let mut origin: Config::RuntimeOrigin = origin.into();

Shouldn't it be self.ext().caller() instead so the caller of the extrinsic is the caller of the contract, not the contract by itself. Would love to have some view on this!

Proposed changes

Payload sent to extension must have an extra flag to distinguish between which method should be called with contract as origin or caller as origin. Maybe the last byte of the encoding scheme?

Guideline for the reviewers

• See transfer_from_works() in pop-api/examples/fungibles how ALICE can be the dispatch origin for transfer_from instead of a hard-coded contract address. We did not cover this in the contract integration test because it we use the dispatch functions from pallet-assets directly to handle these logics. But as a smart contract developer, everything must be possibly handled on the contract side.

[Daanvdplas]

I think this is definitely something that we need to consider. Both serve a different use case. When we use the contract address to make the calls, the contract serves somewhat as a different entity (e.g. a DAO). When we use the caller's address, the contract serves somewhat as a wrapper (e.g. a wrapper to make something standard compliant). Not sure how we can provide this different use case for each api. Creating a different function id sounds a bit like an overkill to differ between calling with the contract's address or the caller to the contract.

Providing the account which to call the pallet from was another idea but then we would have to filter out these bytes before decoding into the dispatch call or runtime read so that is not ideal either.

[Daanvdplas]

Why are we changing this?

[Daanvdplas]

Again, why are we changing this?

[chungquantin]

This was changed just to test if it works (will be reverted later when we decide the next step with the extension origin). Reason why I don't add the method caller() because it will bring back stuffs that @evilrobot-01 removed before #265 that removed the Config associated type. The caller() method returns OriginFor<Config> so if we want that method, we need to revert the changed Frank made.

[Daanvdplas]

Can we not add a function caller instead? This function is to get the address and should not be changed tmo

[chungquantin]

Explained here: #301 (comment)