To accurately evaluate contract usage, we want to look in to all function calls that happen within a transaction. This is the "traces" dataset. Function calls (traces) gives us insight in to the building block contracts (i.e. DEX that calls a token and an oracle) and underlying contracts called by custom contracts (i.e. trading bots). If we only looked at "transaction" level data, we would only be able to see the first contract called, which would cause us to lose this granularity and make incorrect judgements of onchain activity.
It's not controversial to look at traces; however, it introduces infra problems and other nuance:
Traces data tables are much larger than transaction data tables (~20-100x larger); so queries often run long or take up a ton of memory. We need to build a better/smaller data model to support these queries.
There are many possible ways you could attribute usage to each internal contract (i.e. do you split gas, do you count 1 transaction for each contract)
Gas: You could: 1. Attrbute all of a transactions' gas to a contract, 2. Get the gas used by each function call, by subtracting sub-traces, 3. equally amortize all gas used across each contract or function call - There are likely cases where each makes sense, so we could store each metric in a model
App-level attribution requires uniqueness - There could be multiple contracts from the same app called in a single transaction; so we need to be careful to not over-count
TODO: What we need to build
Ideas:
Enriched transaction table?
Hourly/Daily aggregate by contract?
Related Items
Migrate High-Frequency Bot Logic (TODO: Make Issue)
Migrate Likely Duplicate Address Logic (Sybil Input) (TODO: Make Issue)
Any other address segmentation/classification concepts
Prior Work - We'd want to be able to trivially recreate all of these with proper data models
Problem
To accurately evaluate contract usage, we want to look in to all function calls that happen within a transaction. This is the "traces" dataset. Function calls (traces) gives us insight in to the building block contracts (i.e. DEX that calls a token and an oracle) and underlying contracts called by custom contracts (i.e. trading bots). If we only looked at "transaction" level data, we would only be able to see the first contract called, which would cause us to lose this granularity and make incorrect judgements of onchain activity.
It's not controversial to look at traces; however, it introduces infra problems and other nuance:
TODO: What we need to build
Ideas:
Related Items
Prior Work - We'd want to be able to trivially recreate all of these with proper data models
Future Work Ideas/Concepts