Indexing contract events

[kroggen]

When looking for a smart contract events using aergoscan (and also via GRPC) it is very slow to load events as the current method scan many blocks searching for events from the contract.

The events tab generally shows no event, even when we click on "load more" many times. This is because there are so many blocks and to get an event from just 3-7 days ago we would need to click that button many many times.

Proposal

The indexer could save the list of events for each contract on a database.

It would be good for 2 reasons:

• It would be faster to retrieve past events from contracts
• It can help make the indexing faster, by keeping these events on the first pass (parallel) and only when finished processing all the blocks (and having contract info) they can process the events

The storage could be in a SQLite database, named something like events.db, using the contract address as the name of the table (to minimize storage size) and other data in the table itself, like:

CREATE TABLE Am.... (
  block_number INTEGER,
  event_id INTEGER,
  event_name TEXT,
  arguments TEXT,
  PRIMARY KEY(block_number, event_id)
)

The block number cannot be the primary key because the contract can emit more than one event on the same block.

Querying this database would be so much faster than querying the blockchain, because the aergo blockchain did not include indexing of the events.

If it is too much data to be stored on the database, then we can store just the block_number:

CREATE TABLE Am.... (
  block_number INTEGER PRIMARY KEY
)

In this case the database would have, for each contract, a list of blockno that generated at least 1 event.

And then aergoscan can retrieve the blockno from the database and then retrieve the events from the blockchain using the block number (faster than scanning thousands of blocks)

API

The new API to retrieve the events from a contract could be different: instead of querying by block range, we could query by "the last N events", and then "the next N events" using an offset.

In this case it would be guaranteed that some events would be retrieved in a single query