Planning for the Schema for internal beta

graphprotocol / graph-network-subgraph

The subgraph, the smart contracts, the tests, and documents for the Graph Explorer Decentralized Application

MIT License

70 stars 45 forks source link

Planning for the Schema for internal beta #36

Closed davekaj closed 3 years ago

davekaj commented 4 years ago

This issue will be used to propose a schema. I will start off by making the first iteration, then I will bring people in on the team to discuss. We will decide in here and finalize an internal beta schema so we can all move forward in a coordinated fashion :)

davekaj commented 4 years ago

Needs review from @Ariel @brandon @Jannis @nena @yanivtal

I made a PR with the full schema diffed, so we can comment on it right in the code

https://github.com/graphprotocol/graph-network-subgraph/compare/dave/setup-clean-subgraph...dave/diffing-schema-for-review?expand=1

davekaj commented 4 years ago

Adding some notes: Query time calculations that are not included in the schema, since they are calculated at query time:

delegator and curator rewards earned through their shares. This is a constantly changing data that would be calculated at query time in the front end.
When a channel has hit its max epochs for allocations. It would be currentBlock > maxEpochs*blocksPerEpoch + createdAtBlockEpoch

Things I have not included

Time weighted entities. We can either do time travel queries, or we can pre calculate this stuff and store unique time entities. I need to think this through a bit more, to see what would be best for our situation. these include:
- Query fees (the amount of query fees the indexer has collected)
- indexing rewards (the amount an indexer has collected)
- return on stake (the amount of indexing rewards and query fees the indexer has collected as a percentage of (owner and delegated) stake

davekaj commented 4 years ago

Adding some open questions:

Query count - we can’t really get this in the subgraph as far as I can tell right now. it is settled in the channel, and not stored on chain. @Ariel and @brandon, thoughts???
Still confused on how GNS will work with the Subgraph type (parents and children, are we using this still?)
Are we still using SubgraphType (commons vs owned)
I can’t decide if we should name Channel as is, or name it Allocation. I think channel is more representative of what it is within the code, but calling it the Allocation might be easier for readers to understand.

abarmat commented 4 years ago

Query count: All the query counting works at the off-chain layer. Maybe there is a way to introduce this info with attestations or some sort of incentive, but not sure we want that. Fees I think is the closer proxy to work performed in the protocol. @Zerim
GNS: I think we should review at least a quick pass the scope of this contract for the Beta. Maybe we can strip all the domain and subdomain stuff and just leave names -> subgraphID mappings, update this mapping and transfer ownership.
Not sure what is a SubgraphType
I'm calling Allocation to the assignment of a chunk of IndexNode (and Delegators) stake to a particular subgraph. An allocation has a Channel with the data of it's off-chain payment link.

abarmat commented 4 years ago

I see there are network parameters in the GraphNetwork entity. How do we update those attributes if we change any of those in the contract? We could emit a ParameterUpdated(<name>) if needed. Let me know.

abarmat commented 4 years ago

As a heads up, I changed the distributor attributor in Curation to staking.

davekaj commented 4 years ago

I see there are network parameters in the GraphNetwork entity. How do we update those attributes if we change any of those in the contract? We could emit a ParameterUpdated(<name>) if needed. Let me know.

Yeah in general I think we will likely have to have an event emit when any parameter has been updated

Zerim commented 4 years ago

Agree with Ariel, regarding fees being the best proxy for work performed in the network.

Still confused on how GNS will work with the Subgraph type (parents and children, are we using this still?) Are we still using SubgraphType (commons vs owned).

We may revisit this sometime down the road, but for now we're opting for a much simpler flat naming system which we inherit from Github, ENS, Everest, etc. (starting with Github). For internal beta, the plan was to just have users enter their name without validation, but I think we should start thinking about the schema beyond internal beta (whether in this PR or another one I don't have strong opinions).

davekaj commented 4 years ago

Agreed with query fee being best proxy.

But the front end designs have query count as a display value... so I am wondering how this will be obtained? Subgraph seems a natural fit, but that would mean we would have to publish this on chain too