Graph Out
If you want to include the extractions logic in Substreams to benefit from the parallelization engine, you can use the EntityChanges model.
Essentially, this means that you will create a graph_out
module in Substreams, which will emit an EntityChanges structure representing the subgraph entities.
Requirements
Install the Substreams CLI.
Install the Graph CLI.
Create a Sample Project
Defining a Substreams package
A Substreams package is composed of types (defined as Protocol Buffers), modules (written in Rust), and a substreams.yaml
file which references the types, and specifies how modules are triggered.
The Substreams package in question detects contract deployments on Mainnet Ethereum, tracking the creation block and timestamp for all newly deployed contracts. To do this, there is a dedicated Contract
type in /proto/example.proto
(learn more about defining Protocol Buffers):
The core logic of the Substreams package is a map_contract
module in lib.rs
, which processes every block, filtering for Create calls which did not revert, returning Contracts
:
A Substreams package can be used by a subgraph as long as it has a module which outputs compatible entity changes. The example Substreams package has an additional graph_out
module in lib.rs
which returns a substreams_entity_change::pb::entity::EntityChanges
output, which can be processed by Graph Node.
The
substreams_entity_change
crate also has a dedicatedTables
function for simply generating entity changes (documentation). The Entity Changes generated must be compatible with theschema.graphql
entities defined in thesubgraph.graphql
of the corresponding subgraph.
These types and modules are pulled together in substreams.yaml
:
You can check the overall "flow" from a Block, to map_contract
to graph_out
by running substreams graph
:
To prepare this Substreams package for consumption by a subgraph, you must run the following commands:
These scripts are defined in the
package.json
file if you want to understand the underlying substreams commands
This generates a spkg
file based on the package name and version from substreams.yaml
. The spkg
file has all the information which Graph Node needs to ingest this Substreams package.
If you update the Substreams package, depending on the changes you make, you may need to run some or all of the above commands so that the
spkg
is up to date.
Defining a Substreams-powered subgraph
Substreams-powered subgraphs introduce a new kind
of data source, "substreams". Such subgraphs can only have one data source.
This data source must specify the indexed network, the Substreams package (spkg
) as a relative file location, and the module within that Substreams package which produces subgraph-compatible entity changes (in this case map_entity_changes
, from the Substreams package above). The mapping is specified, but simply identifies the mapping kind ("substreams/graph-entities") and the apiVersion.
Currently, Subgraph Studio and The Graph Network support Substreams-powered subgraphs which index
mainnet
(Mainnet Ethereum).
The subgraph.yaml
also references a schema file. The requirements for this file are unchanged, but the entities specified must be compatible with the entity changes produced by the Substreams module referenced in the subgraph.yaml
.
Given the above, subgraph developers can use Graph CLI to deploy this Substreams-powered subgraph.
Substreams-powered subgraphs indexing mainnet Ethereum can be deployed to the Subgraph Studio.
That's it! You have built and deployed a Substreams-powered subgraph.
Serving Substreams-powered subgraphs
In order to serve Substreams-powered subgraphs, Graph Node must be configured with a Substreams provider for the relevant network, as well as a Firehose or RPC to track the chain head. These providers can be configured via a config.toml
file:
Last updated