Dora, the TipsetExplorer

Indexing blockchain events is crucial for dApps as it enables quick and efficient access to relevant data stored on the blockchain, which is required for providing a seamless user experience. Without indexing, searching and retrieving data from the blockchain would negatively impact the functionality and usability of dApps. This way, there are services like The Graph - https://thegraph.com/en/), that make it easy for developers to start indexing these Events, on-demand.

This project, "Dora, The TipsetExplorer" is a The Graph-like event indexer, for the FEVM, where you specify Handlers (files written/generated in Elixir that instructs Dora on how to deal with events) by Smart Contract or default Handlers for a specific Event.

At the moment there is nothing similar to this Project working on FEVM (Hyperspace, at least), so we decided to build our own. For now, it relies on the Filfox API - https://hyperspace.filfox.info/api/v1/docs/static/index.html to obtain transactions and events information.

This Indexer has some interesting built-in features that are very helpful for maintaining these types of services.

• Index Smart Contracts on demand;
• Each Smart Contract has its separate Process running to handle Indexing.
• Fault tolerance at the Process/in-memory level. If a process responsible for Indexing a specific smart contract, crashes, there is a Supervisor Process that will try to re-spawn it and continue where it left off.
• Fault tolerance in case of a full crash of Dora. It takes advantage of a {key, value} store in a local file. If the whole app crashes, when restarting the server, previously running processes for each Smart Contract, will be started and resume at the same Event they were before. This ensures that no Events are lost during the downtime. If this file also fails us, Dora, will look for this information in its local Database. This way, it has 3 different mechanisms for recovery.
• Easily Pause and Stop indexing a Smart Contract.
• Plug and Play Event Handlers by Smart Contract address or Default Handlers for an Event type.
• Automatic code generation for new Handlers.
• Abstracted Event Data/Arguments decoding. Delt by each Explorer process.
• Abstracted Database tables under Events and Projections, that enable you to store full Maps and query by their values.
• Simple to use API, with just two main endpoints (api/events/:type and api/projections/:type).

For more technical and detailed information, check the project's README on the Github repo.

This project is built on top of Elixir and PostgresQL. The main magic for indexing and handling new Events happen with the help of Elixir. It's a Functional programming language that compiles to Erlang and runs on the BEAM virtual machine. It's highly oriented to distributed and concurrent processing, taking advantage of the Actor Model. This way, we can have dedicated processes to manage the health of other individual processes that are responsible for the indexing of Smart Contracts. Each Smart Contract being indexed has its own dedicated process, ensuring that a lagging process or an unhealthy one, won't affect the others. As stated in the long description, this system can also recover from different severity crashes and resume where it left off. It first tries to look for the previous state in a {key, value} store, and if this file hasn't any information because it got corrupted or lost, it will look for information in the DB.

A cool thing about this project is the Handler Generator. By just running "mix dora.gen.handler ContractName contract:0x1234 abi:path/abi.json", the project will parse the given ABI and automatically generate a handler for all Events detected, including how to fetch each argument by the respective name. The base logic of Dora, also takes care of decoding Events topics and data, this way we can deal with different types of arguments, indexed or not! If you just want to keep track of events, running the generator is simply enough.

For more complex actions, it's possible to create projections. The idea with projections, is that they work as an Aggregate for specific Events. With this, we can build a fully complete "Backend".

Both the API and Database tables were abstracted in a way that the User doesn't need to worry much about them, but the final goal for this project is to have a full app generator, like a "create react app", and as a Developer, you just need to write new Handlers, and not even knowing about the underlying code and logic!

For extra technical and detailed information, check the project's README on the Github repo.

Sponsor Technology: Relying on the Hyperspace Network itself to deploy a couple of smart contracts in order to test emitting new Events, and reading them with the Filfox API.

Anything Hacky: Using the Filfox API. For a real project outside the hackathon, this should rely on an RPC node.

How did I impress myself: Building the code generator for Event Handlers, given an ABI. It was the first time I did something like that, and it turned out amazing, and fits like a glove the final goal of this project, and how similar services in other chains work!