graphprotocol / graphprotocol/graph-node
Refactor to ease adding new chains
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.rsfiles logic into a single place? Since adding new Firehose chains will always require this to buildprost(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?
- Should we make the getter code here created by a
- 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 forgraphman runthat 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
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- 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