WIP T 16269 broken erc721 balances tables

[soispoke]

Brief comments on the purpose of your changes:
This PR aims to improve/fix erc721 balances on ethereum.
Changes have been added (mainly fix the sign for amounts, and the send/receive fields + some improved incremental filters), but there are still issues with duplicate owners that need to be addressed, see https://dune.com/queries/1246260

The test was also changed (and is currently failing), so that wallet address is not part of it (therefore, it is now actually testing for unique owners)

@hildobby @0xRobin @aalan3

For Dune Engine V2
I've checked that:
General checks:

• I tested the query on dune.com after compiling the model with dbt compile (compiled queries are written to the target directory)
• I used "refs" to reference other models in this repo and "sources" to reference raw or decoded tables
• if adding a new model, I added a test
• the filename is unique and ends with .sql
• each sql file is a select statement and has only one view, table or function defined
• column names are lowercase_snake_cased
• if adding a new model, I edited the dbt project YAML file with new directory path for both models and seeds (if applicable)
• if adding a new model, I edited the alter table macro to display new database object (table or view) in UI explorer
• if adding a new materialized table, I edited the optimize table macro

Join logic:

• if joining to base table (i.e. ethereum transactions or traces), I looked to make it an inner join if possible

Incremental logic:

• I used is_incremental & not is_incremental jinja block filters on both base tables and decoded tables
  • where block_time >= date_trunc("day", now() - interval '1 week')
• if joining to base table (i.e. ethereum transactions or traces), I applied join condition where block_time >= date_trunc("day", now() - interval '1 week')
• if joining to prices view, I applied join condition where minute >= date_trunc("day", now() - interval '1 week')

[height]

This pull request has been linked to 1 task:

• T-16269 Broken erc721 balances tables (unlink task)

💡Tip: Add "Close T-16269" to the pull request title or description, to a commit message, or in a comment to mark this task as "Done" when the pull request is merged.

[0xRobin]

@soispoke, I fixed some grouping and partitioning issues I found. (see PR mentioned above)
I believe query should now return correct results but I was not able to fully test it.

[0xBoxer]

Seems good to me, this should make sure that every NFT (combination of address and id) only exists once in the balances table for any given day or hour.

[soispoke]

thanks @0xBoxer

[0xBoxer]

@soispoke @0xRobin

I found a edge case where the script goes wrong:

https://dune.com/queries/1079379

https://etherscan.io/token/0xc7457f480416e145093edb355f626faa0fc7f90e?a=2116

This is a weird contract that minted a token_id twice.
The currently running script assumes that the first owner is the correct one and actually changes the balance of the first owner on a transfer 20 days later, despite that owner not even having an outgoing transfer for this token.

The second minter is the correct one and sells his NFT a few minutes after minting, this tx is completely missing from our results. Therefore, in the period between 01/05 to 20/05 this token has wrong owner data.

This finding makes me question what usually happens in the script if a token gets traded multiple times within a day, because that seems to be what's going wrong here.

[0xRobin]

@0xBoxer Good catch!
This is actually expected behaviour from the current query.
When 2 addresses have positive delta for that day (meaning more incoming then outgoing transfers for that ID) the query itself produces 2 records.
The deduplication happens later on the table merge cause those entries will have identical unique keys. So I guess it's currently quite random which owner will be chosen as we don't have strong ordering guarantees within the source table partitions.

We could update the query to include the deduplication and favour the entry which had the last incoming transfer. Another option might be to provide ordered output if that guarantees us the deduplication by the merge will choose the correct owner. (Will need to look into spark/databricks docs to confirm)