The following doc explores how we'd go about updating the codebase to support cross chain integrations.
These requires a lot of documentation + strict guidelines which engineering WILL have to f ollow to ensure we can get a decent implementation of the idea listed below of it.
Currently the following are tightly coupled with Ethereum + Metamask.
- Frontend (FE)
- Backend (BE)
- Data Model (DB)
^ Decoupling that and make it super generic is what I've based my ideas on
This would inolve rewriting the every product one by one! As that is not a small task -> It makes sense to start with the smallest product we've got aka TIPS.
NOTE: A couple of terms I refer to in the below description are described here in detail _FE + BE : frontend + backend _ core business logic : concerned with the logic on how the tips feature works irrespective of the underlying blockchain used orchestrator : responsible/smart enough to deciding which blockchain flow to invoke psuedo-interface : a well documented README consisting of what function every blockchain would have to implement. Every function in the psuedo interface WOULD have be defined in the blockchain implementation.
When we onboard a new blockchain, the core business logic for tips should not change (except for a few lines of code of integrating) The FE + BE would both have their version of orchestrator and this what the core business logic would interact with
Since python + JS don't support interfaces, we'd have to create a pseudo interface to ensure easy onboarding of new chains can be done in an isolated manner without touching the rest of the app
Ideally we'd have have something along the lines of
// frontend
psuedo-interface Tip {
send() {} // Business logic to send money to address
recieve() {} // Business logic to recieve money from address
}
// backend
psuedo-interface Tip {
send() {} // Business logic + save money to address
recieve() {} // Business logic to recieve money from address
}
The FE / BE would talk to it's respective orchestrator which would be responsible for for deciding which implementation of the interface to be invoked.
Following Seperation of Concern : Cleaned way would be creating a new model for each blockchain
Tip Model which would store generic infomration which we would need
Tip Model - { id, from_profile, to_profile, amount}
Aka Ethereum Tips would have Model Tip-Ethereum - {id, tip_id, gas_fees, address}
While Ontology Tips would have Model Tip-Ontology - {id, tip_id, xyz} // we don't know what xyz could be
Anything we need to store in terms of the Tips on Gitcoin would be in Tip Model,
Any remotely specific field to a particular blockchain and not the Tips product itself would reside in it's own model
Adding a new chain would involve
- creating a new implementation for FE + BE which would talk to it's respective data model
- wiring it to the FE + BE orchestrator
Removing a chain would involve
- removing the blockchain implmentation of the interface
- remove the handling logic within the orchestrator in FE + BE
what if we design the implementation for the FE + backend to assume very little about a chain. dont assume they have a metamask equivilent. dont assume they support smart contracts. dont assume they have an ERC20 standard.
maybe we even get into the area of product simplifications: dont even assume that people have to "stake" their coins on the task in order to post it.
just assume that they have a public / private key pair structure; keys are alphanumeric and < 1000 chars, and that they have transaction ids & block numbers.
by assuming as little as possible about each chain, we build a system that minimizes the complexity of the FE + BE orchestrator, thereby reducing the complexity of the state machine we are handling.