This month in curation #19 | November 22

General Ecosystem Updates
,
1

This Month:

  • The Graph Network is turning 2 years in December!

  • The Graph now supports Solana powered by Substreams!

  • Graph Improvement proposals detailing an Arbitrum layer 2 deployment, Curation 1.x and the Epoch Block Oracle



Birthday
Birthday900×450 422 KB

The Graph Network is turning 2 years!

  • On december 17th 2020, The Graph Network launched on mainnet. Since then, over 200 Indexers, 10,000 Delegators and 2,500 Curators have joined the journey. Come celebrate The Graph’s birthday at one of six community-led birthday events worldwide, or tune in to the special birthday twitter spaces on december 15th.

  • Join members of The Graph community for an evening of celebration filled with tasty food, refreshing beverages, and a special birthday POAP. In addition to celebrating this milestone and the decentralized future, this event is also a great opportunity to learn more about the latest with The Graph and meet participants in The Graph ecosystem that live in your area! Space is limited - RSVPs are required. Looking forward to an interstellar evening with you!

    • Amsterdam | Dec 17th - RSVP
    • Buenos Aires | Dec 17th - RSVP
    • Dubai | Dec 16th - RSVP
    • Lagos | Dec 16th - RSVP
    • San Francisco | Dec 16th - RSVP
    • Singapore | Dec 17th - RSVP

  • Can’t make it to one of the in-person events? Be sure to join the community on The Graph Twitter for a special birthday Twitter Spaces on Thursday, December 15th at 9:00 am PST. During this special online event, you will hear from core developers and other leaders in the ecosystem! Set a reminder for the Space on Twitter.



Solana
Solana2880×1616 174 KB

The Graph Now Supports Solana with Substreams

The Graph Foundation is excited to announce support for Solana with substreams

  • Read the full announcement here.

  • The Solana developer community can now begin using The Graph to build lightning-fast dapps.

    • By using the new substreams technology, developers can efficiently extract and interpret on-chain data from Solana’s mainnet-beta to feed their applications.
    • A free-to-use hosted service for this technology will be available until it is deployed on The Graph Network.

  • Substreams are developed by StreamingFast , a core developer in The Graph ecosystem.

    • Substreams open new and exciting use cases, such as cross-chain bridges, large-scale analytics, refined intelligence for block explorers, trading engines, and any application in need of a rich, consistent data stream.
    • Substreams are new data sources on The Graph that more efficiently extract enriched data through modules built in Rust. While substreams can be used independently, there are ongoing efforts to integrate substreams to power subgraphs and be supported on The Graph Network.



rome
rome1920×1280 489 KB

Graph Improvement Proposals


GIP-0037: The Graph Arbitrum deployment with linear rewards minted in L2 | Forum | Radicle | HackMD

  • Like GIP-0034, this proposal introduces a new deployment of The Graph’s smart contracts to the Arbitrum One Layer 2 blockchain

  • The Layer 2 implementation on Arbitrum was discussed during The Graph Core Devs Call #16 from 28:08. This call covered GIP-0037, as well as GIP-0034 and GIP-0031.

  • This GIP is presented as an alternative to GIP-0034: The Graph Arbitrum deployment with a new rewards issuance and distribution mechanism

    • You can find more information about GIP-0034 here: Forum | HackMD | PR#571 | PR#582
    • The implementation of GIP-0034 turned out ot be quite complex, and would require a lot of monitoring to ensure the drip is working correctly. The L1-L2 messaging also makes the system seem less robust.

  • The main differences between GIP-0037 and GIP-0034 are as following

    • Indexer rewards issuance is changed to be linear (fixed issuance per block)
    • Layer 2 rewards are minted directly on layer 2
    • The L1-L2 communication for Indexer rewards is no longer needed, and removed. This makes the code much simpler and more robust.
    • The bridge is modifyed to mint tokens if needed, but up to an allowance. This allowance equals the total rewards minted on layer 2.



GIP-0038: Epoch Block Oracle | Forum

  • When indexers are indexing a subgraph, they allocate some of their stake towards that subgraph. Indexers may serve queries on subgraphs with open allocations, and they will accrue Indexing rewards. To collect these Indexing rewards, allocations must be closed with a valid proof of indexing (POI) for the first block of the current epoch.
  • If the network is to support indexing rewards for subgraphs indexing networks other than Ethereum mainnet, Indexers need to know which block POI to submit when closing an allocation.
  • This proposal introduce an “Epoch Block Oracle” to specify the currentEpochBlock on other chains.
    • An Epoch Block Oracle subgraph will index a simple on-chain Data Edge, which will track the “Epoch Block” for all networks supported for indexing rewards. Indexers will use block hashes specified by the subgraph to close their allocations for subgraphs indexing a given network.



GIP-0039: Curation v1.x | Forum

  • This proposal aims to improve the experience of subgraph- and dapp developers.

  • Curators signal to the network that a particular subgraph contains valuable data by depositing GRT into a bonding curve, minting curation shares. They may also burn their curation shares to withdraw GRT. Today, the bonding curve is not flat. The GRT valuation of curation shares will increase or decrease when curators mint or burn curation shares respectively.

  • GIP-0039 propose to flatten the bonding curves for subgraphs deployed on Arbitrum.

    • This will result in a curation pool for each subgraph rather than a bonding curve. Curators will no longer be able to realize gains at the expense of other Curators’ signal, and will be rewarded exclusively by query fees.

  • Curation v1.x and the roadmap to Curation 2.0 was discussed during The Graph Core Devs Call#16 from 41:32.



GIP-0040: L2 Bridge and Protocol Deployment | Forum

  • This proposal outlines a gradual move to Abitrum Layer 2. Most of the contracts will be deployed with no functional changes, so staking and curation can be done in the same way as in L1. Users can move GRT to L2 using the bridge proposed in GIP-0031. **The L2 deployment is proposed to happen over 3 stages:
    • Stage 1: Deploy a mirror of the L1 contracts to L2 Arbitrum with Indexing rewards disabled. This stage includes an L1-L2 bridge as proposed in GIP-0031. Curation will be deployed with flattened bonding curves as proposed in GIP-0039.
    • Stage 2: Upgrade the protocol to support indexing rewards on L2.
    • Stage 3: Add migration helpers to facilitate users moving stake, delegations and subgraphs from L1 to L2.
  • GIP-0040 is for the deployment of Stage 1. In the future, separate GIPs will be written for stage 2 and stage 3.
2 Likes