Does it make sense to specifically identify these, or does the logic belong at the application layer (i.e. we detect the proxy backend status using bigquery-public-data.crypto_ethereum.traces and update a etherface-downstream table in BQ with this enrichment?
They're the most common type of contract by bytecode:
And they're also amongst the most commonly called:
Does it make sense to specifically identify these, or does the logic belong at the application layer (i.e. we detect the proxy backend status using
bigquery-public-data.crypto_ethereum.tracesand update aetherface-downstream table in BQ with this enrichment?They're the most common type of contract by bytecode:
And they're also amongst the most commonly called:
Here's one of the more prolific examples: https://etherscan.io/address/0xfbddadd80fe7bda00b901fbaf73803f2238ae655
And here's how etherscan uses it: https://docs.etherscan.io/api-endpoints/contracts#verify-proxy-contract
Verified proxy contracts will display the "Read/Write as Proxy" of the implementation contract under the contract address's contract tab