Create SubQuery indexer for multisig accounts

[pgolovkin]

For multisig account discover the multisig account indexer is required.
The approach should be the same as for Multix.

The subquery-proxy project may be used as a reference for the SubQuery indexer.
Questions about development may be addressed to @Asmadek.
Questions about deployment and testing may be addressed to @stepanLav

• Prepare the code
• Create a repository in Novasamatech organisation together with @pgolovkin
• Deploy indexer for Polkadot, Kusama, Moonbeam, Wested together with @stepanLav

[Tbaut]

@Asmadek @stepanLav @tuul-wq

1. Should we really have a separate repo for the multisig indexer? This sounds weird to me, we would effectively have 2 DBs, 2 indexers, 2 graphQL servers, for proxy and for multisig, although these are super small in terms of resources and they could coexist without problem I think. Let me know.
2. Regarding the schema, with Multix I went with something that is very similar to the Rust implementation in the pallets, it's very flexible, but it is a little complex. It looks like this

# An account can be a multisig, or a normal account (like a signatory)
type Account @entity {
  id: ID!
  address: String!
  # if this account is the signatory on one or many multisigs, this will link to an array of multisigs
  multisigs: [AccountMultisig] @derivedFrom(field: "signatory")
  isMultisig: Boolean
  # if this account is a multisig, this will link to an array of signatories
  signatories: [AccountMultisig!] @derivedFrom(field: "multisig")
  # this is only needed in the case of a multisig
  threshold: Int
}

# entity for linking accounts and multisigs
type AccountMultisig @entity {
  id: ID!
  multisig: Account!
  signatory: Account!
}

Note that the schema for Multix is more complex than this, as we have pure proxies in there as well, and an Account can be a pure proxy, or it can be the proxied, see here https://github.com/ChainSafe/Multix/blob/main/squid/schema.graphql#L1-13 but I thought I'd start by keeping it simple.
Let me know if this sounds all right to you.

[valentunn]

1. From our past experience writing both separate and joint subquery projects I can list the following pros and cons of both approaches:

Separate projects:
Pros:
More granular reindexing - each feature can he adjusted and reindexed independently, with one slow feature not becoming a bottleneck for others
Cons:
Maintenance, infrastructure overhead. Separated codebase (e.g. some shared utility functions has to be put under separate package and imported to both projects)

One project:
Pros:
One codebase, easer maintenance and deployment
Cons:
Potentially indexing bottlenecks

In our situation I am personally more inclined towards single project since we don't really have big amount of data to index, both multisigs and proxies have very low number of events to index

2. The overall structure looks reasonable but I have one concern: given that we are planning to support nested multisigs it might be beneficial for the database structure to facilitate nested multisig lookups. Not sure how we can do that with proposed structure. To be honest I am not sure whether it is possible to perform such "recursive" queries with GraphQL

[pgolovkin]

@Tbaut Thanks for pointing to it. Seems that we're not going to scan every block with the indexer we can make a single indexer for proxies and multisig accounts. The SubQuery dictionary is used and it improves the indexing speed.

Regarding nested multisigs, proxies. I don't think the recursive search should be implemented by SubQuery. We should use segregation of duty:

1. SubQuery is in charge of storing data about multisigs (signatories' accounts, threshold)
2. Nova Spektr is in charge of business logic.

You can find the UML sequence diagram below. Here Nova Spektr is in charge of orchestration and choreography.

@valentunn @tuul-wq FYI

[Tbaut]

Addressed in novasamatech/subquery-proxy#6