This month in Curation #9 | November

General Ecosystem Updates
1

This month:

  • Utilizing StreamingFast’s Firehose interface, The Graph now supports NEAR!

  • Over $1.5M were allocated in Wave 3 grants.

  • Grants for core development work are an integral part of protocol decentralization. The Foundation reviews the grants that have funded core development to date, provide updates on the core developers’ activities, and chart the future for this important source of decentralization in The Graph.



NearPartnership
NearPartnership2880×1616 319 KB

The Graph Integrates with NEAR

  • The graph now supports indexing of the Layer-1 blockchain NEAR!

    • NEAR is the first non-EVM compatible blockchain supported by Graph-Node
    • NEAR is available in beta on The Graph’s Hosted Service.

  • The integration utilizes StreamingFast’s Firehose interface.

  • I recommend reading the announcement for more information.

  • Already building on NEAR, and want to make your first subgraph? Check out the NEAR specific docs.



Moonbeam
Moonbeam1801×151 201 KB

Moonriver Integration

  • The Graph’s Hosted Service is now supporting Moonriver Network, expanding further into the Polkadot and Kusama ecosystem.

  • Read the twitter thread here.



GrantsWave3
GrantsWave31613×151 288 KB

Wave 3 grants

  • Over $1.5M in grants were allocated in wave 3.

  • I highly recommend you check out the announcement as well as the detailed description of the grants. A few highlights that will impact Subgraph Developers and Curators:

    • Limechain is developing Matchstick, a unit testing framework for subgraphs. They have been granted $65,000 to continue their work on Subgraph Tooling. If you are interested in using Matchstick when developing your subgraph, we recorded a tutorial video in our Developer Highlights series. You can find the video here.

    • GraphGod has been allocated $15,000 to develop a CurationStation Web-portal. The goal of this portal is for Curators to work in a collaborative manner, deciding where and when to signal and unsignal.

    • 17 grants, totaling over $230k were allocated in the dApp/Subgraph category. Whether you are an experienced Subgraph Developer or a Curator looking to learn a new skill, I recommend you check out the Subgraph RFP page. There are also

    • This wave, we saw a large focus on educational initiatives. Over $220k were allocated to educational initiatives and scholarships.

    • Jackson Blau was allocated $1,500 for his Curation Guide.

    • Ryan Burdett was allocated $3,000 for creating Curation Video Guides

  • If you have ideas for Wave 4, I highly recommend you apply for a grant.



Government
Government1182×93 83.5 KB

Governance

  • The Graph Governance Process | Forum

    • Forum post clarifying The Graph Governance Process.

  • GIP-0013: Reduce Curation Tax (Implemented) | Forum | Proposal | Community Vote

    • This was a proposal to reduce the curation tax parameter from 2.5% to 1.0%.

    • This proposal had broad community support. There was a Community Vote on snapshot, where 99.01% of the votes agreed with the proposal.

    • The GIP was implemented on October 18th.



CoreDevs
CoreDevs1822×160 185 KB

Graph Core Developer Grants

  • Decentralization is one of the key principles of web3. It means that any user can contribute to development and governance. The Graph Foundation believes deeply in the importance and inevitability of decentralization.

  • Grants for core development work are an integral part of protocol decentralization. They ensure that no single team or individual is responsible for the network’s growth and sustainability.

  • A blogpost was written on The Graph Core Developer Grants. It reviews the grants that have funded core development to date, provides updates on the core developers’ activities, and charts the future for this important source of decentralization in The Graph.

  • I recommend reading the blogpost in its entirety. Some key takeaways for the future of Core Developer Grants:

    • The Foundation is expanding the kind of work eligible to receive core dev grants. Going forward, the core dev grant program will no longer be separate from Foundation protocol grants. All teams contributing to protocol R&D will be eligible for longer-term, higher-value grants.

    • The Foundation is actively exploring ways to directly involve the community in grant governance. The foundation will be announcing more details about these changes in the coming months.

4 Likes
2

Great update Slim.

Something noteworthy, I’m looking into discussing it with @GraphGod, but something that could be very productive for a curation portal is a WebAssembly verification tool that uses github hooks to compile the latest release of a subgraph and check that it matches the bytecode/WASM for the deployed subgraph. The system would simply check the metadata for the deployed subgraph, visit the source code link and search for a sugbraph folder (recursively?), and attempt to compile it and check against the IPFS data found in the subgraph manifest.

As far as I know, there isn’t currently a way to validate the WASM code uploaded to IPFS for curators, and this would be a big step in verification for curators going forward.

Just something to think about for the curation community :man_shrugging:

3 Likes
3

I think this is a great idea, we would need to have a way to pull the github code and compile it and potentially upload it to IPFS to see if the hashes match.

This could help us detect code changes but it wouldn’t necessarily identify if a malicious publisher forked the code.

As we have more subgraphs migrating to the mainnet, presumably the forking user will not be able to deploy the exact same code (and would be less effective as well) since the deployment id will have active signal.

1 Like
4

potentially upload it to IPFS to see if the hashes match.

I don’t think this would be necessary, since you could just do a read/compile from github, a read from IPFS, and a local DIFF on the frontend/backend of the portal to check if the bytecode matches. Otherwise you’d need to have a local IPFS node and then worry about load balancing etc etc.

This could help us detect code changes but it wouldn’t necessarily identify if a malicious publisher forked the code.

Agreed! This would be mostly for curation evaluation outside of the realm of “legitimacy/ownership evaluation”, in regards to the efficiency of the subgraph. It’s a smaller metric for evaluation, but many curators (myself included) do wish to see how a subgraph works to make sure it’s working efficiently and/or to check for code quality- having github code be verifiable would be a great option to have.

2 Likes
5

I might not be sure what you mean here- as far as I know, uniqueness of a subgraph isn’t dependent on it’s bytecode, but rather by the user account coupled with the number of subgraphs currently deployed. See: https://github.com/graphprotocol/contracts/blob/dev/contracts/discovery/GNS.sol#L249

As far as I am aware, duplicate bytecode can be published by a forking user as long as the deployment ID is not the same as an existing subgraph.

1 Like
6

There is when publishing a version that if the deployment already exists on the mainnet and has active curation that the publishing transaction fails. (This is to prevent upgrading curators into a trap)

7

Totally agreed! Definitely a good item to have!