-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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 Automated type generation for new chains (Rust <> AS types) #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 🙂