Add API-level proxy detection and implementation resolution #1711
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Closes #1655
This implements an API-level proxy detection as in #1655 by making use of the whatsabi library. A few explanations about this PR:
SourcifyChain
class for making it compatible to the whatsabi library as a provider, and for being able to resolve the implementation addresses ofDiamondProxy
contracts.proxyResolutionError
to the API response for the case that the proxy resolution fails. This could be due to an unresponsive RPC for example. In such a case, I still want to respond successfully to the user but let them know why the proxy fields are not there.FixedProxyResolver
was returned in a lot of cases where actually a library was called by aDELEGATECALL
. I decided to only support EIP1167 proxies for this resolver. Any otherFixedProxy
would be a non-standardised proxy (or even a library). So in case aFixedProxyResolver
is detected, we check explicitly for the opcodes standardised in EIP1167.0x0
. The latter was for example the case for a factory contract which deploys EIP1967 contracts. Therefore, I iterate over the returned resolvers and return the first implementation address which is not0x0
./check-all-by-addresses
endpoint and not thecheck-by-addresses
endpoint, because in the latter thechainIds
array does not contain objects.Remaining issue (non-blocking)
There is still a problem left from shazow/whatsabi#142:
A contract that embeds a proxy (as for example a factory contract) could falsely be detected as a proxy.
A first proposal to solve this is to not consider contracts with
CREATE
/CREATE2
opcodes as proxies. However, this will not catch all contracts that only embed proxy bytecodes, and also exclude factory contracts that could be at the same time a proxy.Edit: We decided that this problem is not a blocker for this PR. IMO, it is good to get this out and test it. The proxy data won't be persisted in our database with this change, so before we persist it we might be able to improve the proxy detection.