Summary
Hey everyone!
Last month has seen an incredible push on the Substreams stack, the performance, solving a bunch of determinism issues, readying the technology for the decentralized network.
Shiippppeedd
Our efforts have focused on delivering a drop-in replacement for UNIswap v3’s subgraph (see GitHub - streamingfast/substreams-uniswap-v3 ). We also shipped a high-speed key/value store backed for Uniswap, to query at much higher speeds certain graphs that used to be slow when querying postgres through the Subgraph GraphQL interface. (see GitHub - streamingfast/substreams-uniswap-v3-info ), all with minimal changes to the UNIswap v3 info site (see Comparing Uniswap:master...streamingfast:master · Uniswap/v3-info · GitHub )
We also have stress-tested graph-load, the high-speed injection tool that we used to speed up the indexing of the Uniswap v3 subgraph. GitHub - streamingfast/substreams-graph-load: Substreams sink to write CSV files compatible with graph-node postgresql database It produces csv files out of Substreams output, and has a drop-in replacement for initial sync into postgres, all with POIs parity. It then hands off control to the graph-node to continue the injection and keep it real-time. All from a single Substreams graph_out module.
We’ve shipped one of the very first Substreams-based Subgraphs on the Network: Substreams Uniswap v3 Ethereum | Graph Explorer and encourage you to start doing the same! Feel the power. When we demo’d this to the UNIswap team, the sync showed 6h. Total sync time took 20h in reality. But in comparison to the 2 months it usually took, everyone was flabergasted!
We’ve put up a forum post to propose to the Graph Council the adoption of the technology for the network here: GGP-0025 - Enabling Substreams-based Subgraphs
Next steps
Next steps is working to bring more chains, more Layer 1, improving documentation, and continuing our push for performances.
A revisiting of the Substreams Scheduler (the thing that ships jobs to backing tier2 services) is underway, with the goal to multiple by another 3x the perfs. More parallelized execution within a block’s execution should squeeze more juice.
We’re working on tooling to help indexers ramp up on the stack. We’re also working on easier upgrade paths to increase the data agility of Substreams developers, being able to ship it to the network much faster.
Hiring
We’re hiring for a devrel position: StreamingFast hiring Developer Relations in Canada | LinkedIn
We’re also interested in hearing from fellow Rust developers interested in building on Substreams technology, as well as Go developers interested in working in the depths of the heart of Substreams.
