Support proxy contracts / ability to execute view functions on verified contracts

[mds1]

I was trying to view the source of a contract, but his contract uses the EIP-1967 proxy pattern, so I couldn't view the underlying logic.

There are two potential features I can think of to enable viewing of the underlying logic (which is why this issue covers two feature requests):

1. Natively support proxy contracts, with a separate option on hover to view the source underlying implementation. Not sure how big the scope is here since there's at least EIP-1967 and EIP-1167, and possibly others
2. Allow view functions to be called and if the result is an address, allow it to be actionable

[tintinweb]

Hey @mds1, thanks for the feature requests.

I am not sure if this is going to pollute the hover box too much. While I understand that for proxied contracts it might be nice to retrieve the underlying logic contract detecting this is passively (from the address without issuing a request) is not trivial. I'd like to avoid that the extension "phones out" to learn more about a contract if it is not absolutely necessary (there's kind of a privacy angle to this and I generally don't like extensions that do things without the user knowing)

I feel like you have a specific idea about an extension that would be helpful to you. Could you elaborate a bit more? (e.g. on the view feature and how this is intended to be used). The reason why I am asking is that it sounds like this could be its own extension - if it's worth the effort.

[mds1]

I feel like you have a specific idea about an extension that would be helpful to you. Could you elaborate a bit more? (e.g. on the view feature and how this is intended to be used). The reason why I am asking is that it sounds like this could be its own extension - if it's worth the effort.

I can see something like this being useful during both contract and frontend development/testing. Here's the use case where I'd see myself using this:

1. I often develop/test contracts against a forked mainnet due to their dependencies on existing contracts, so assertions are often based on mainnet values, e.g. expect(tokenBalance.mul(exchangeRate)).to.equal(someValue). When debugging to see what went wrong (e.g. am I not parsing their decimals properly, or am I reading the wrong value, or is the bug in my contract, etc.), I often head to Etherscan to read various values from various contracts. I'll copy/paste them somewhere to save them off temporarily to avoid heading back to Etherscan to pull them again later

2. Pretty much the same use case for frontend development, but instead of testing contract functionality this is usually for displaying information to users

[wizzard0]

phones out

I guess one can specify their own node address to connect to and avoid data leaks this way?