# The Graph 调查研究

**Published by:** [Jenny](https://paragraph.com/@jenny-6/)
**Published on:** 2023-05-03
**URL:** https://paragraph.com/@jenny-6/the-graph

## Content

最近准备研究一下区块链的数据类的项目，主要是用于整理和记录个人理解还有自己投资的分析的依据。准备写The graph和Dune, 这篇主要是写The graph. 一般对于项目的分析，会包含几部分，项目主要解决的问题是什么，项目的应用场景(或者也叫消费者)，基本技术架构去实现要解决的问题(由于每个项目语言不一样，虽然我是技术出身，但是也只能是一个大概介绍），项目基本情况数据(团队/投资/运营情况等等)，项目的经济模型.The Graph是什么？Ethereum或者比特币的数据都是存储在区块链上，每个区块都是按时间顺序的交易流水或者也可以叫状态变化信息。这种情况下，如果要对链上的数据进行一些非常复杂的更接近现实要求的高级查询就会非常的困难，比如在uniswap上面的top 5的交易对，或者查询某些特征的数据，比如具体某一特征的Ape NFT的交易记录。因为需要读取所有相关块得到top 5的，或者NFT需要去读取IPFS上面的metadata定位到对于的块，而这些是直接读取区块链的信息不会提供的。通常自己搭建一个节点，然后根据条件把所有相关块，计算一遍才能得到结果，而这个需要花好几个小时甚至好几天的时间。 The graph就是为了解决上面的问题，它提供了一个API,用户可以使用这个提供的API接口获取到区块链上的或者IPFS上面的数据, 并且进行聚合/复杂的查询，快速获得结果，并且不需要自己搭建本地服务器。The graph是去中心化的(之前是hosted service的，现在过渡正在过渡到去中心化的the graph network)。The Graph的适用场景The graph的目标用户是dapp的开发人员/项目。 开发人员/项目可以自己开发(Graph SQL，比较简单)或者使用别人做好的graph的api获取链上的数据，只是需要付一些费用，而不需要自己开发一套工具去实现这个功能。这对于特别是一些中小型项目特别的方便，应用范围很广泛。个人觉得如果Dapp的蓬勃发展的话会需要获取链上的数据进行分析或者进行相关功能的开发，那么the graph是一个不错的选择。 现在看起来，感觉很多是自己项目要用什么数据，就自己使用graph开发自己的一套api这种情况比较多一点。The graph也有query market，我自己看了几个，感觉开发人员，并不是特别容易找到自己合适的api或者说没有那么友好去找到合适的api. 现在支持Ethereum/Avalanche/Gnosischain/Arbitrum One/Celo*(官网)链上的数据查询. Uniswap, Synthetix等很多应用都使用了the graph.The graph的经济模型在开始介绍它的经济模型之前，先介绍一下graph network里面的生态。Graph生态的4个角色Developer: 开发人员，开发子图（subgraph) Indexer:提供索者，这个就是提供硬件和软件服务，graph node跑在这个上面，当用户需要查询图的时候，索引者提供查询数据的服务，从而获得费用 Curator: 策展人，通过质押GRT来标注(signel)某个图(subgraph), 然后对应的子图获得高级别，即同一个查询时，子图single高的优先被使用，这个主要是为了更高质量的子图被使用的更多，根据signed的subgraph的情况，获得收益 Delegator: 和Curator很像的一个概念，普通用户通过质押自己的 grt来获取收益 consumer: 还有最后一个消费者，即进行数据查询，要付费的。 在the graph生态中，使用token GRT。The graph在2020年年末发布了它的token GRT, 总供应量100亿（到2023年6月份，解锁总供应量的 70.6%），每年新增3%的GRT token作为抵御通货膨胀，会发给indexer. 同时，每年有部分的GRT token会被burn掉，Delegator-0.5%的delegate tax,Curator-1%的新图管理tax,Consumer-1%的查询费用。根据现在的数据，大概2.5年burn掉了2万5千的token。从年份看，21年burn最多，22年少一些，23年看起来比22年同比1-4月增长了一倍。基本技术架构The graph有Graph Node和smart contract部分。The graph node：部署在各个节点，分布式的，Rust语言的，开发的subgraph(图)部署在the graph node, 它基本包括几个方面，1).subgraph的部署存储(最终ipfs或者本地数据库？) 2).把数据块从链上读取下来，并且存储到对应的subgraph里面，这里需要跟对应的链通信 3). 处理dApp对应对应的subgraph的查询要求，并返回对应的数据。 个人理解，当开发人员把subgraph部署到node的时候，node会把对应的subgraph的一些信息也同步到以太坊上面的smart contract, 后续的delegator/curator/indexer的质押信息都会记录是以太坊上面的smart contract里面。当开发人员部署subgraph的时候，node会根据subgraph的定义同时过一遍历史的数据块，获取到subgraph的信息存储在ipfs或者本地数据库，当对应的subgraph监听的合同事件有变动时，node会更新subgraph对应的信息，这样可以达到快速返回查询数据的目的。不过，刚开始部署的时候，由于需要过一遍历史数据，所以需要花不少时间才会部署成功。 这里有一个我没有想明白的地方，既然是分布式部署node,那么是怎么处理共识部分？认为这个是subgraph的信息应该更新为xxx？Smart Contract: 这个是由The graph deploy到以太坊的。delegator/curator/indexer的质押信息都会记录是在这个smart contract里面。同时这个smart contract也会监控subgraph的对应的事件变化（这个需要验证是不是这样的). The graph也支持L2的数据，比如abritrum, 具体它怎么实现的，需要后续再看看资料。 还有一些The graph提供的开发subgraph的工具，和消费者使用的subgraph browser（显示所有可用的subgraph）基本的访问流程如下，dApp用graphQL API 发起一个查询，graph node收到请求，处理请求并返回数据给dApp. 至于graph node怎么知道subgraph的数据，如在上面node提到的过程项目基本情况数据 项目开始于2018年，被Uniswap，Synthetix，Aragon，aAVE，Gnosis，Balancer，Livepeer，DAostack，Decentraland 和许多其他的 daps。 Decentralized subgraphs - 809, hosted service subgraphs- 39816 Active Delegator - 11,384, Active indexer - 471,Totla Curator - 2927 团队信息，找了半天没有找到一个完整的介绍，据说是创始人在mulesoft工作过，mulesoft也是提供各种api的，跟还是比较类似 Twitter有 6000多个关注者，技术人员的话，人数还可以。发推频率还是比较稳定的。 个人浅见，还有很多的不足，需要不断调整。下一个准备看看Dune和The graph的区别和适用场景有什么不同。

## Publication Information

- [Jenny](https://paragraph.com/@jenny-6/): Publication homepage
- [All Posts](https://paragraph.com/@jenny-6/): More posts from this publication
- [RSS Feed](https://api.paragraph.com/blogs/rss/@jenny-6): Subscribe to updates