graphprotocol / graphprotocol/graph-node

Refactor to ease adding new chains

Open
#3,260 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
Rust
Stars
3.2k
Forks
1.1k
Avg merge
4d 1h
Merged PRs (30d)
1

Description

Context

When we only had EVM compatible chains, adding new ones didn't require much change. To support NEAR (our first non EVM-compatible chain) required multiple refactors, trait additions, etc. When that got merged we wondered what could be improved to ease adding new chains, in the sense of code structure/reuse and boilerplate.

With the recent addition of Tendermint (PR) it's now more clear what could be improved.

Objective

This will be an umbrella issue connecting all possible improvements/refactors that we can do today to ease new chains being added on the code level, requiring less boilerplate code.

Possible improvements

The improvements/questions below were noted after a second revision of the Tendermint integration Pull Request.

  • Could we somehow concentrate all build.rs files logic into a single place? Since adding new Firehose chains will always require this to build prost (gRPC library)
  • About empty/default implementations:
    • TriggerFilter: could we have a default implementation for this that doesn't do anything?
    • NodeCapabilities: could we have a default when the chain doesn't require anything specific for this?
    • RuntimeAdapter: could we have an empty/default adapter when no logic is needed here?
  • DataSource:
    • Should we make the getter code here created by a macro? I mean in the sense that there are tons of similar getter functions that all chains have to do, the only difference are the fields/types themselves.
    • There are some checks that could be done for all chains (eg: handlers > 0). Should we have traits for each type of validation required so the chain chooses to implement what suits best?
  • ABI/AS code generation: this is being addressed by #2985
  • On main.rs (and related binaries) the part that instantiates the chain code is being addressed by a current refactor for graphman run that I'm currently working on (which will remove other code duplication there as well)

I would love to hear opinions from @tilacog @lutter @leoyvens @maoueh 🙂

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by comparing the chain-specific build.rs files and the Tendermint, NEAR, and EVM integration code, then inspect the shared traits, DataSource, and main.rs references named in the issue. Done means turning one or more of the listed ideas into a concrete, scoped refactor with agreement on the intended structure and preserved support for existing chains.

Written by the indexing model from the issue text.

Assessment

Tech stack
rust
Domain
blockchain
Issue type
Refactor
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.