Add changes for indexing events of Nabla smart contracts

[adelarja]

This ticket is related to this issue and pendulum-chain/tasks/issues/16.

We need to collect and transform some historic data emitted my the Nabla smart contracts. The aim of this PR is to add these changes to our indexers.

[adelarja]

Just some preliminary feedback, I know it's just a draft PR.

I suppose the contents of the abis/*.json and src/abi/*.ts files are the same but in the .ts files you make it easier to import the data? Before we merge we probably should remove the files that are not required by the indexer, and I assume the contents of the root abis folder is not really required (?)

@ebma Many thanks for the comment. I've deleted all the files in the abis folder. I was thinking that maybe we could leave the .json files in order to know which contract version we are using (having the abi and metadata as evidence), but it is not mandatory at all. As you said, it is only used for generating the ts files with the needed functions to handle the events.

Also, I see that right now in src/mappings/nabla.ts we define hard-coded addresses of all the contracts that we expect and want to watch over. Can we change the code so that the indexer picks up these events on all smart contracts? Because during the development we will probably have to deploy a lot of different instances of Routers, BackstopPools, SwapPools. And it does not make sense to use all of these instances at once, eventually once Nabla 'goes live' we'd of course only use one set of these contract instances. But I think choosing which set of instances should be done in the UI that interacts with the contracts. We should not make this assumption in the indexer and thus I'd hope we can provide events for any Nabla smart contract that is deployed. Without having to hard-code any address in the indexer. Do you think this is possible @adelarja?

I was able to handle this situation.

I've used some nested try catch statements to solve the issue in a more generic way. I'll push it today. This is basically what I did:

enum EventType {
    BackstopPoolEvent,
    RouterEvent,
    SwapPoolEvent
}

function getEventAndEventType(ctx: EventHandlerContext) {

    try {
        const event = bpool.decodeEvent(ctx.event.args.data);
        const eventType = EventType.BackstopPoolEvent;
        return {event, eventType}
    } catch {
        try {
            const event = spool.decodeEvent(ctx.event.args.data);
            const eventType = EventType.SwapPoolEvent;
            return {event, eventType};
        } catch {
            try {
                const event = rou.decodeEvent(ctx.event.args.data);
                const eventType = EventType.RouterEvent;
                return {event, eventType};
            } catch {
                const event = undefined;
                const eventType = undefined;
                return { event, eventType };
            }
        }
    }

Depending on the eventType we can use a particular function to create/modify/update the database.

@ebma There is one thing to note here: For some reason, the Token Contracts ( mUSD deployed to 6h6JMHYBV7P6uQekZXzHmmpzx7tzHutTyx448MnFogR6dNde, mEUR deployed to 6hJHAXrCYNFbuDzgwZb2S1UhamDBtR8Jw1cn9gKQ4QewvSh1 and mETH deployed to 6kwiNhGTHAfGb5x3gZBQxhiG2rf9F8W7Da3HhQRdBHQopSHv) are not generating errors when trying to decode them as BackstopPool events. That is reflected as false backstop pools being generated from our squid. I'll try to find a way to solve this. This is the main disadvantage of the generic implementation.

[adelarja]

@ebma I added a way to handle the events in a more generic way using the function named getEventAndEventType is used.

However, I left the old code related to the hard-coded smart contract addresses. In case we want to use it in the future, we could add all the backstop pools, swap pools and routers addresses into the foucoco or amplitude constants. I think it could be valuable fpr more efficient event management if needed.

I also left the old implementation commented for you to compare. as shown here.

[ebma]

Thanks for the update @adelarja. Did you manage to find a solution for the problem of ERC20 contract events being decoded to BackstopPool events? Or is that still a pending issue?

[adelarja]

Thanks for the update @adelarja. Did you manage to find a solution for the problem of ERC20 contract events being decoded to BackstopPool events? Or is that still a pending issue?

@ebma The solution I found is to try to decode the event as an ERC20 token event. In case it is, we simply skip the event.

I thought that the ERC20 tokens were being registered as BackstopPools, but then I decoded the addresses of the backstop pools, and it seems they are different contracts. I didn't know that we have 4 backstop pool contracts deployed on our network, haha.

Now, everything seems to be working well.