Data source templates / dynamic data sources

Also referred to as dynamic contract subscriptions, as this is currently the main use case.

This feature supports creating new data sources from templates while indexing the subgraph. The motivation behind this is to provide a natural way of indexing registry/factory contracts that reference many other (sub)contracts.

See Define a Subgraph: Dynamic Data Sources in the docs for more details.

Details about the implementation are described in the pull request that introduced the feature:

When starting a subgraph, the node now not only loads the manifest, it also loads the dynamic data sources from the store and fetches their files from IPFS. It then injects the data source instances into the subgraph instance before starting the indexing.

Whenever we we process a block and mappings request new data sources, these data sources are collected and, after having processed the block, are instantiated from templates. We then process the current block again but only with those new data sources. The entity operations from this are merged into the ones we already have for the block. After that, the dynamic data sources are persisted by adding the data sources to the subgraph instance and by adding entity operations to store them in the db (for 1.).

If new data sources have been added in a block, the block stream is restarted to incorporate events that are relevant for the new data sources going forward. We figured this would be easier to do (and it is) than modifying the block stream while it is already running.

Anonymous events

Anonymous Solidity events are used by projects like Maker. Supporting them requires filtering events not by their usual signature (e.g. Transfer(address,address)) but by their topic 0 value.

This version adds support for that by allowing event handlers to specify the topic0 value to filter by. For more information see Define a Subgraph: Anonymous Events in the docs.

Full support for GraphQL fragments

This releases finishes the support for GraphQL fragments both inline and spread in.

Query complexity limiting

Graph Node now supports limiting complexity of queries both in terms of potential number of entities returned and query depth, similar to how GitHub do it in their GraphQL API.

The following environment variables can be used for this:

• GRAPH_GRAPHQL_MAX_COMPLEXITY — limits the complexity of queries (default: unlimited).
• GRAPH_GRAPHQL_MAX_DEPTH — limits the depth of queries (default and maximum: 255).

Entity table splitting

Starting with this release, Graph Node stores entities and their history in a Postgres schema dedicated to the subgraph deployment. Every subgraph deployment now gets their own entities table, which speeds up queries significantly. Existing entity data in the global entities table can still be queried as before.

Other changes

• Fix list equality filters.
• Log smart contract call times.
• Reduce subgraph logging overall to reduce noise around event processing.
• Switch to the latest IPFS client version for HTTPS support.
• Add environment variables to control the block range size used while scanning the history of the chain (ETHEREUM_PARALLEL_BLOCK_RANGES) as well as the number of parallel block ranges to scan (ETHEREUM_BLOCK_RANGE_SIZE).