GGP 0023: Add Mainnet Support for Fantom and Polygon Data Sources

Summary

This GGP proposal now updates the previously ratified Feature Support Matrix (GGP-0022) to include two new data sources: Fantom and Polygon.

Polygon and Fantom QoS Analysis

The table below summarises the gateway-based QoS metrics extracted for the two-week period MIPs participants were actively serving MIPs subgraphs on Goerli.

Chain / metric	Unique indexers	total_queries	num_failed_queries	success_rate	median_blocks_behind	median_blocks_behind (s) & ~ block time	median_latency_ms	latency_90th_pctl_ms	latency_99th_pctl_ms
Gnosis		8598567	56007	0.987967	3.0	15 (5s)	170	489	1847
Arbitrum		40252971	6796	0.998203	74.0	18 (235 ms)	495	2360	5251
Avalanche		19963197	337	0.956189	12.0	24 (2s)	866	5623	11574
Celo		186043	372	0.998198	4.0	20 (5s)	371	677	1221
Fantom	346	92953179	1600189	0.992686	39.0	39 (1s)	558	1448	3866
Polygon	296	16919043	47410	0.998677	17.0	34 (2s)	387	1157	3199

The list of subgraphs Indexers have synced and served can be found here for Polygon and Fantom.

Potential Risks

Fantom

Apart from a lack of client diversity, no major issues have been verified during Goerli testing.

• Indexers have been running Fantom archive nodes with no issues.
• No outages have been recorded, and the underlying client is stable and worked reliably under average query load.

Polygon

Contrary to Fantom, there are some risks with Polygon clients (canonical Erigon and Polygon-forked Erigon).

Even though the Polygon and Erigon team have worked together since the recent hard fork to fix most of the issues which prevented Indexers from reliably serving Polygon subgraphs, it is still unclear if Erigon will formally accept a grant from the Polygon Foundation to maintain the canonical Erigon (which would result in Polygon deprecating their fork).

A summary of risks related to Polygon:

• The official Polygon-provided snapshot has missing state sync transactions, which prevents Indexers from syncing subgraphs.
  • This can be mitigated by syncing a new archive node with Erigon’s built-in snapshot feature turned off. The Polygon team is aware of the problem, but as of April 28, 2023, there’s no one working to resolve due to a lack of bandwidth.
  • There are community-based snapshots Indexers are now sharing. These have been verified to work (no missing state sync transactions), allowing Erigon to continue running when syncing subgraphs.
• Erigon’s default configuration options are not suitable for Polygon archive nodes. Graph Indexers must specify specific config parameters to ensure the node doesn’t get into read-only mode past the 7.2 TB database size mark. Read more here.
  • This can be mitigated with proper official Indexer-focused documentation under thegraph.com/docs. Different guides have been written for the program, which should now be added to our official docs.

It’s also important to note there’s a geth-based Firehose implementation, which has been tested heavily by core development teams like Edge & Node, Streaming Fast, and Pinax when serving the needs of the hosted service and Subgraph Studio. However, as of April 28, 2023, Indexers still need an Erigon-based archive node for the eth_call JSON-RPC method.

Lastly, data integrity is not verified as part of MIPs missions. This will change with the GIP-based chain integration process that’ll be in effect post-MIPs.

---

Proposed Updated Feature Support Matrix

The proposed updated Feature Support Matrix can be found below, and this PR will be merged once this proposal is accepted.

graph-node: ≥0.30.0 <0.31.0
valid from: 787
upgrade window: 795

Subgraph Feature	Aliases	Implemented	Experimental	Query Arbitration	Indexing Arbitration	Indexing Rewards
Core Features
Full-text Search		Yes	No	No	Yes	Yes
Non-Fatal Errors		Yes	Yes	Yes	Yes	Yes
Grafting		Yes	Yes	Yes	Yes	Yes
Data Source Types
eip155:*	*	Yes	No	No	No	No
eip155:1	mainnet	Yes	No	Yes	Yes	Yes
eip155:100	gnosis	Yes	Yes	Yes	Yes	Yes
near:*	*	Yes	Yes	No	No	No
cosmos:*	*	Yes	Yes	No	No	No
arweave:*	*	Yes	Yes	No	No	No
eip155:42161	arbitrum-one	Yes	Yes	Yes	Yes	Yes
eip155:42220	celo	Yes	Yes	Yes	Yes	Yes
eip155:43114	avalanche	Yes	Yes	Yes	Yes	Yes
eip155:250	fantom	Yes	Yes	Yes	Yes	Yes
eip155:137	polygon	Yes	Yes	Yes	Yes	Yes
Data Source Features
ipfs.cat in mappings		Yes	Yes	No	No	No
ENS		Yes	Yes	No	No	No
File data sources: IPFS		Yes	Yes	No	Yes	Yes

Epoch Block Oracle (EBO) Multisig Transaction

At a protocol-level, adding experimental support for the two new chains with support for indexing rewards and arbitration is a matter of registering these two chains into the canonical EBO (Data Edge contract). The details can be found below.

RegisterNetworks EBO message:

[
  {
    "add": [
      "eip155:250",
      "eip155:137"
    ],
    "message": "RegisterNetworks",
    "remove": []
  }
]

Resulting calldata:

a1dce33200000000000000000000000000000000000000000000000000000000000000200000000000000000000000000000000000000000000000000000000000000019030105156569703135353a323530156569703135353a31333700000000000000

The calldata can be verified with https://graphprotocol.github.io/block-oracle/

CAIP2-ID <> Network name

fantom:  eip155:250
polygon: eip155:137

Next Steps

Once this proposal is accepted:

1. The resulting call data will be signed by Council members and executed against the following ratified EBO (Epoch Block Oracle) instances:

   Ethereum Mainnet DataEdge contract**:** 0xADE906194C923b28F03F48BC5D9D987AAE21fFab Arbitrum One DataEdge contract: 0x633bb9790d7c4c59991cebd377c0ed6501a35ebe

2. The PR with the proposed updated feature matrix support will be merged.

3. Anyone will be able to publish Fantom and Polygon subgraphs to the network (Ethereum and Arbitrum One), including through Subgraph Studio.

4. Indexers will be able to serve any Polygon subgraph on Ethereum and Arbitrum One, earning indexing rewards.