Indexer-agent supports operating on multiple Graph Network protocol chains

[fordN]

In order to support smooth subgraph deployment migrations from the L1 network to the L2 network the indexer-agent will need to be able to operate for both an L1 and L2 indexer account but use a single, shared graph-node backend.

Changes

• Query multiple network subgraphs for potential subgraph allocations and update SubgraphDeployment to include a protocolNetwork property
• Add a protocolNetwork property to indexing rules.
  • In the case of a deployment specific rule it will consider this the preferred network; if the deployment doesn't exist on the preferred network it will use the other.
  • In the case of a global rule consider the protocolNetwork absolute not just preference, never use this rule on the other network
• When comparing indexing rules and potential subgraphs the output should include the protocol network where the allocation will be created
• Actions get queued with protocolNetwork specified
• Actions worker will read in the protocolNetwork when taking actions, sending transactions to the appropriate network's contracts
• Update Network.create() to support creating multiple Network class instances; it will now return a map containing all the networks the indexer has passed in.
• Use default allocationAmount for the new rule on L2 created during migration

Interface updates

• Allow n number of chains:
  • Provide multiple values to --network, --networkSubgraphDeployment, and --networkSubgraphEndpointAdd
• Add L2 RPC provider endpoint,
• Add protocolNetwork to indexing rules
• Add protocolNetwork to actions queue

Examples of passing in network params to indexer-agent

Multi-network scenario

--network-rpc goerli:http://rpc-endpoint, mainnet:http://rpc-endpoint
--networkSubgraphDeployment goerli:Qm..., mainnet:Qm...
--networkSubgraphEndpoint goerli:http:..., mainnet:http://

Single-network scenario

--ethereum or --network http://rpc-endpoint
--networkSubgraphDeployment Qm..

Open questions

• Do we need to any changes to indexer-service? Might not need to make changes; there will need to be an indexer-service running for each network.

Next steps

• Turn this into a milestone
  • Break out the tasks into their own issues under the milestone

[fordN]

There is a potential alternative approach where the indexer-agent code is updated, so that multiple indexer-agents can be operating with a shared backend. I personally think that approach would be more complex, but we can explore it more deeply to confirm. cc: @hopeyen

Benefits of the above proposed approach:

• Indexers can use a shared infra backend (graph-nodes and DBs) across multiple Graph networks such as Eth Goerli and Mainnet.
• The indexer-agent will have information from both networks and be able to make decisions across the two instead of an indexer having to separately manage strategy across two separate indexer-agent instances.
• A single indexer-agent approach makes the subgraph migration to L2 story simpler; the indexer-agent can automate supporting the new subgraph on the L2 when the subgraph owner starts the migration process.
• While there are many code changes they are not conceptually very complex whereas it is not obvious to me how to allow multiple agents connected to the same DB without them "stepping on each other's toes".

[hopeyen]

Thanks for taking the time to consider the alternative approach, please bear with me thinking this through

Indexers can use a shared infra backend (graph-nodes and DBs) across multiple Graph networks such as Eth Goerli and Mainnet.

It makes sense to me to share infra backend across L1 and L2 networks, but not sure about sharing across mainnet and testnet. Testnet seems to be a place that allows messing up with no real consequences and to freely play with beta software, is it safe to share DB and software versions between Eth Goerli and Mainnet?

On the other 3 points,

In either solutions, indexer-agent will have to track multiple indexer identities and network subgraphs and has separate allocation strategies apart of migrations.

Thinking through the differences on a high level

• If there's 1 agent for multiple networks, then it will also need to
  • track by multiple contracts and operator wallet and all subsequent structs by protocol networks
  • repeat similar logic with clear labels of the intended networks
  • indexer can manage everything in one space
  • protocolNetwork column for rules and actions and separate global rules would safeguard human operations
• If there's 1 agent for each network, then agent will require
  • new logic on understanding which protocol network it is acting on top of and its identity on the other networks
  • separate indexer management DBs but shares graph node DBs
  • at reconciliation of deployment and allocation decisions, agent would need to access other management db and network subgraphs (maybe concat all info) to avoid conflicts to deployments in graph node

There's probably more, but with this I agree that the complexity of one agent for multiple networks is less than separate agent for each network, and agree the migration story is simpler for indexers. Furthermore if we consider a future where there's multiple L2s, then the new network dimension for the agent seems to make more sense as well.

thanks again for entertaining this idea!:)

[fordN]

Thanks for thinking through it @hopeyen! I agree with your conclusion; it was what I had intuitively assumed, but I really appreciate you going through the detailed comparison to confirm.