use-ink / ink

Polkadot's ink! to write smart contracts.

Home Page:https://use.ink

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Proxy contract does not set the caller correctly

goastler opened this issue · comments

Questions

  • Is this a bug concerning building of ink! smart contracts?
    • no
  • Is this a bug that appears when interacting with smart contracts via the Polkadot JS browser UI?
    • no

FAQ

  • Are you using the nightly Rust channel to compile your smart contract?
  • no
  • Are you using an up-to-date cargo-contract? Check via cargo contract --version.
    • yes
  • Are you using an up-to-date ink! version in your smart contract?
    • v4.1

Describe the bug
When forwarding a call from a proxy contract through to the destination contract, the caller is not set properly.

Expected behavior
The proxy contract sets the caller to the calling account rather than becoming the caller itself.

Screenshots

Additional context
The logic gets confusing, so I'll explain more here. We've got contract A and contract B. Contract B is a proxy contract pointing at contract A (followed the example here).

Alice calls function xyz() on contract B, the proxy contract. This call gets forwarded through to contract A as it should. However, function xyz() makes use of ink::env::caller() which resolves to the proxy contract (contract B)'s account id, not Alice's account id. It should be Alice's account id as Alice is the caller.

I imagine the caller is not being set when forwarding a call.

I've tested this on our proxy contract and the example proxy contract linked above, both have the same symptoms.

See a demo for working example using the ink-examples

Sorry for the late reply. Can you confirm the issue? If so, I will try to reproduce this week

any update on this @SkymanOne ?

This is an expected behaviour AFAIK, since the call is forwarded inside the proxy contract, and it the caller becomes the proxy. If you want to call to be transparent, you should consider using delegetor pattern. This way the callee operates on the caller's (i.e proxy) storage. and the caller should appear to be transparent as well.

Closing due to inactivity