Skip to content
This repository has been archived by the owner on Mar 4, 2024. It is now read-only.

Optionally index CELO transactions #18

Open
silasbw opened this issue Aug 30, 2021 · 1 comment
Open

Optionally index CELO transactions #18

silasbw opened this issue Aug 30, 2021 · 1 comment

Comments

@silasbw
Copy link
Contributor

silasbw commented Aug 30, 2021

Start the indexer with an option to index CELO transactions.

For example, to execute a query like this:

select * from transfers where to = '0xSomeAddress' and currency = 'celo';
@gnardini
Copy link
Contributor

Some technical details/considerations:

Right now we're indexing events using getPastEvents on the contracts we want to index. This has a few limitations:

  • No way of knowing the gas fee that was paid for the transaction that emitted the event.
  • No way to index native CELO transfers.
  • No way to index arbitrary ERC20 contracts. We need to explicitly query for the events emitted by a contract, so we need a list of the contract addresses we want to index.

Good things about the current approach are:

  • Quite efficient. We can query by block ranges which makes indexing the whole thing very fast.
  • Adding a new contract doesn't require indexing the whole blockchain again, only the new events emitted by the contract.

One tool we'll need to use whatever direction we choose to follow is the function kit.web3.eth.getBlock(blockNumber, returnTransactionObjects) which returns information about a block. If the second argument is set to false it only returns a list of tx hashes for the block, otherwise it returns more information including gas paid for the tx and value transfered (native CELO transactions) but NO logs (events) at all.

We definitely need to call getBlock for each block, but we have two options:

  • Call it with returnTransactionObjects set to false and then make another query for each tx hash. This will allow us to index anything, including all the events we are currently indexing and any ERC20 token transfer that we aren't explicitly tracking. As long as it follows the ERC20 interface we'll be able to index it. It will require making a lot more requests to the node though and if we want to add new contracts it will require re-running everything unless we preemptively store the events for all contracts on the blockchain, which is a lot of extra information we probably won't use.

  • Call it with returnTransactionObjects set to true. In this case we'll need to do two things for each block:
    a. Check all the transactions with a non-zero value field and add them as CELO transfers. Make sure to check how this interacts with transfer events emitted by the CELO ERC20 contract to count each transaction exactly once.
    b. Store the gas fee paid info (gas, gasPrice, feeCurrency, gatewayFee -check what this gateway fee is exactly btw-) and tx hash into a new table so that we can join it with the transfers one or any other and we can know the gas fee paid.
    If we go this route we will still need to index all the events we want using the getPastEvents function like we're doing right now, the new stuff will only take care of CELO transactions and gas fees.

My feeling is that option 2 is simpler and more flexible so I suggest doing that.

Note that contrary to ERC20 tokens, none of this approaches would allow us to accurately calculate an address's balance since we are not counting paid gas fees as transfers (fees paid with cUSD/cEUR emit an event so we're indexing them). We could change this if it helped but I don't think that's a use case we envision for the indexer.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants