Closed RusseII closed 2 years ago
https://thegraph.com/hosted-service/subgraph/gnosis/protocol does this give us the auction data we need? Looks like there are some subgraphs for gnosis auction already built.
We might need one on top of this / that integrates with this - but I'd be great if we can get auction data from that
- Figure out how exactly we can use this in our protocol - I'm thinking that we create a subgraph then query the subgraph to get the information needed on each of our product screens: https://github.com/porter-finance/product/tree/main/spec/pages
Looks like a good step forward
- Note down what data we'd need to expose from our smart contracts for the subgraph to enable our frontend
tbd
- Made a subgraph repo (public)
Repo made, requires a deployed contract to work tho. Tried to get it deployed locally via node and graph-cli and ganache-cli but ended up failing
- What would the costs of using the Graph be?
When deploying a brand new subgraph, you will consume between 125,000 and 150,000 gas
Then, once the initial Curator comes to signal on this subgraph, that transaction will initialize the curation share tokens initialize the bonding curve transfer tokens into the Graph Proxy burn 2.5% of those tokens issue the curation shares
This will consume roughly 1,300,000 gas, so about 10 times the amount of simply deploying.
- Estimate level of work to build out the full subgraph
Seems to be easy, we just provide it with a contract address and it gives us a good enough working subgraph
- Any better alternatives?
https://github.com/porter-finance/v1-core/issues/32#issuecomment-1036509657
@luckyrobot Did you figure out the answer to this? I'm curious if we can leverage one of the already existing gnosis graphs
yeah, we can totally use https://github.com/gnosis/dex-subgraph/blob/master/subgraph.yaml.mustache
their whole repo looks very forkable for us @RusseII
yeah, we can totally use https://github.com/gnosis/dex-subgraph/blob/master/subgraph.yaml.mustache
I think thats actually for a different contract - not gnosis auction.
I saw that ribbon seemed to deploy a subgraph for gnosis auction that we may be able to leverage:
https://thegraph.com/hosted-service/subgraph/stevenwal/gnosis-auction https://github.com/ribbon-finance/ribbon-subgraph/tree/main/v2/generated/GnosisAuction
I saw that ribbon seemed to deploy a subgraph for gnosis auction that we may be able to leverage:
Hmm - they actually modify it quite a bit to fit their use case. I saw another gnosis graph made by ribbon as well that seems closer to native: https://thegraph.com/hosted-service/subgraph/cjinghong/gnosis-auction-fast-index
i'm a little confused on the work required here
aren't subgraphs automatically generated from our contract abis? what additional effort is there?
subgraphs take the events from contracts and store their data automatically afaik
for example https://github.com/Uniswap/v2-subgraph/blob/master/subgraph.yaml
even the schema.json is created automatically for gql, graph codegen --output-dir ./generated
and a very basic example here, https://github.com/compound-finance/compound-v2-subgraph
you can check out their scripts for a better understanding
"scripts": {
"codegen": "graph codegen --output-dir src/types/",
"build": "graph build",
"create-local": "graph create compound-finance/compound-v2 --node http://127.0.0.1:8020",
"deploy-local": "graph deploy compound-finance/compound-v2 --debug --ipfs http://localhost:5001 --node http://127.0.0.1:8020/",
"deploy": "graph deploy compound-finance/compound-v2 --debug --ipfs https://api.thegraph.com/ipfs/ --node https://api.thegraph.com/deploy/",
"prodtest": "graph deploy davekaj/compound-v2 --debug --ipfs https://api.thegraph.com/ipfs/ --node https://api.thegraph.com/deploy/",
"deploy-staging": "graph deploy --debug --ipfs https://api.staging.thegraph.com/ipfs/ --node https://api.staging.thegraph.com/deploy/ davekaj/compoundv2",
"watch-local": "graph deploy compound-finance/compound-v2 --watch --debug --node http://127.0.0.1:8020/ --ipfs http://localhost:5001",
"prettier": "./node_modules/.bin/prettier —-write '**/*.ts'"
},
so with regards to "Note down what data we'd need to expose from our smart contracts for the subgraph to enable our frontend" i believe this is just whatever our contracts has set to external / public, will auto become available
let me know if im missing something, perhaps im not understanding the amoutn of work involved @RusseII
aren't subgraphs automatically generated from our contract abis? what additional effort is there?
I'm not really sure - It seems uniswap and compound have quite a few commits to their subgraphs.
What are they doing in those?
subgraphs take the events from contracts and store their data automatically afaik
Historical data as well? Or only data after the subgraph has been created?
so with regards to "Note down what data we'd need to expose from our smart contracts for the subgraph to enable our frontend" i believe this is just whatever our contracts has set to external / public, will auto become available
I was viewing this more from the perspective of "Based on our frontend mocks - what are the events and external variables that our smart contracts will need to expose"
Some example questions:
The answer to questions like those would help inform the smart contract design decisions. For example:
Since we are going to be wrapping EasyAuction
and will have access to all of their data, it might make sense to deploy an auto generated subgraph for https://github.com/gnosis/ido-contracts/blob/main/contracts/EasyAuction.sol and we can learn about the data that's accessible and the limitations.
aren't subgraphs automatically generated from our contract abis? what additional effort is there?
I'm not really sure - It seems uniswap and compound have quite a few commits to their subgraphs.
- https://github.com/Uniswap/v2-subgraph/commits/master
- https://github.com/compound-finance/compound-v2-subgraph/commits/master
What are they doing in those?
seems like uniswap is just updating token whitelist & price mapping
and compound is updating functions that take events to save them with addtl data
subgraphs take the events from contracts and store their data automatically afaik
Historical data as well? Or only data after the subgraph has been created?
historical as well, it'll index the contract by checking past events (if what i read is correct)
so with regards to "Note down what data we'd need to expose from our smart contracts for the subgraph to enable our frontend" i believe this is just whatever our contracts has set to external / public, will auto become available
I was viewing this more from the perspective of "Based on our frontend mocks - what are the events and external variables that our smart contracts will need to expose"
Some example questions:
- How would we query for a list of all bonds that exist?
- How would we query for all bond auctions?
- How would we query for total amount borrowed by all borrowers?
The answer to questions like those would help inform the smart contract design decisions. For example:
- Does the broker contract need to store an array of all the bonds that have been created? Or can that information be gathered from the events emitted upon bond creation?
it can all be gathered from The Graph, storing an array in the contract isn't necessary, and in fact it's advised to avoid this behavior
Since we are going to be wrapping
EasyAuction
and will have access to all of their data, it might make sense to deploy an auto generated subgraph for https://github.com/gnosis/ido-contracts/blob/main/contracts/EasyAuction.sol and we can learn about the data that's accessible and the limitations.
closing, seems like we have most answers here but pls reopen if not
There are a lot of examples of subgraphs.