深入了解The Graph(上)

去年七月首次向外界介绍The Graph的时候,我们分享了为Web3开发去中心化索引协议的愿景。此后团队一直兢兢业业开发产品,今天我非常高兴能够详细分享第一版The Graph去中心化网络的方方面面。The Graph网络是Web3的核心基础架构——为去中心化应用提供用户级体验的必要组件。

深入了解The Graph(上)

发布时间:2019.10.21
原文作者:Brandon Ramirez
翻译:Chainslation
原文出处:https://thegraph.com/blog/the-graph-network-in-depth-part-1
中文翻译出处:https://zhuanlan.zhihu.com/p/196773044


去年七月首次向外界介绍The Graph的时候,我们分享了为Web3开发去中心化索引协议的愿景。此后团队一直兢兢业业开发产品,今天我非常高兴能够详细分享第一版The Graph去中心化网络的方方面面。The Graph网络是Web3的核心基础架构——为去中心化应用提供用户级体验的必要组件。

在阅读本文之前,我假设读者对The Graph具备基础的了解。如果您是第一次听说The Graph,那么我们的公告博客、文档或来自社区的几篇好文是一个很好的入门材料。

本文是探讨The Graph网络设计系列文章的第一部分。您可以查看第二部分。

全栈去中心化

The Graph的使命是赋能完全由公共基础架构所驱动的互联网应用。

全栈去中心化让应用具备应对商业失败和寻租的能力,同时带来前所未有的互操作性。用户和开发者都清楚知晓他们投入时间和资金打造的软件不会凭空消失。

为了实现完全去中心化应用(dApp)的愿景,有一点非常关键,就是我们要进行一个范式转移,从为应用正常运行所需的持续存储、计算和其他服务付费的业务模式,转变成用户直接为去中心化服务提供商网络付费。

目前大多数“去中心化”应用只是在堆栈的最底层(即区块链)采用这种模型,其中用户对应用状态进行修改都需要付费。而堆栈的其余部分仍然由中心化业务运营,并且受制于任意故障和寻租问题。

The Graph网络简介

The Graph网络对Web3的查询层和API层进行了去中心化,消除了dApp开发者目前面临的取舍难题:到底是开发一个高性能应用,还是开发一个完全去中心化的应用。

目前,开发者可以在自己的基础架构上运行一个Graph节点,也可以在我们的托管服务上开发一个。其中,开发者构建和部署从Web3数据源提取数据并为其编制索引的子图。目前已经有许多领先的以太坊项目创建了子图,包括Uniswap、ENS、DAOstack、Synthetix和Moloch等。在The Graph网络中,任何索引器都能够通过抵押Graph代币(GRT)参与到网络中,并在提供查询服务的过程赚取费用和通货膨胀奖励。

用户则按照使用次数进行付费,使用日益增长的索引器,此做法证明了供需规律也适用于该协议提供的服务。

协议角色

与The Graph系统交互的角色有好几种,他们的恰当参与保证了协议的正常运行,同时也有激励驱动他们这样做。

  • 用户(Comsumer)。用户向索引器支付查询费用。他们通常是终端用户,但也可能是集成The Graph的网络服务或中间件。
  • 索引器(Indexer)。索引器是The Graph的运行节点。其动力是赚取财务奖励。
  • 策展人(Curator)。策展人使用GRT代币来指明哪些子图值得索引。他们通常是开发者,也可能是支持他们在使用服务的终端用户,或者纯粹出于经济动机的一种角色。
  • 委托人(Delegator)。委托人向某个Indexer质押GRT代币,赚取一部分通货膨胀奖励和费用,他们无需亲自运行一个Graph节点。这类角色主要出于经济动机。
  • 渔夫(Fisherman)。渔夫们时刻检查查询响应是否正确,以此保护网络。渔夫动机是利他的,因此The Graph将率先为网络提供渔夫服务。
  • 仲裁员(Arbitrator)。在争议解决期间,仲裁员决定是否对索引器进行罚没。他们可能出于经济或利他动机。

用例

开发者

对开发者来说,构建子图的API与使用本地或托管Graph节点的API基本相同。

最大的不同之处在于开发者部署子图的方式。他们不选择将子图部署在本地或托管的Graph节点上,而是部署到以太坊托管的注册表,然后抵押一些GRT对子图进行策展。这为索引器传递了一个信号,表明该子图也应该被索引。

终端用户

对于终端用户,主要区别是他们需要付费查询索引器的去中心化网络,而不是与有补贴的中心化API进行交互。这一点是通过他们计算机上运行的查询引擎(无论是浏览器中的插件,或者是内置在dApp中)来实现的。

查询引擎确保了用户安全地查询存储在The Graph上的大量数据,无需亲自处理计算和存储数据的工作。查询引擎还充当了交易引擎,根据使用的dApp或用户偏好,决定选择哪个索引器,需要支付多少费用等。

查询引擎为了提供良好的用户体验,它将代表用户自动对小额支付交易进行签名,而不是每笔交易都需要提示签名。我们正在与基于以太坊的多个状态通道团队进行合作,确保他们的钱包和功能满足按使用次数进行计价协议的需求(如The Graph)。同时,我们提供了一个允许dApp对用户查询进行补贴的网关。

索引器

索引者通过质押GRT代币,运行一个Graph节点版本参与到The Graph中。

他们还希望运行一个索引器代理,自动化监控索引器资源的使用情况、设置查询价格、确定对哪些子图进行索引。索引器代理是可插入式的,并且我们希望节点运营商尝试使用自己的定价模型和策略,从而在市场上获得竞争优势。

策展人和委托人

策展人和委托人通过Graph浏览器进行策展和委托。当我们上线网络后,Graph浏览器将成为一个完全去中心化的应用,只需一个支持dApp的浏览器和一个以太坊钱包就能使用。

架构

The Graph网络包含以太坊上的智能合约,以及链下运行的各种其他服务和客户端。

查询市场

查询市场的用途与传统基于云服务应用的API类似——通过一个运行在用户设备的前端,有效提供所需的数据。其主要区别是传统的API某一个经济实体运营,用户毫无发言权;而The Graph的查询市场由去中心化索引器网络组成,它们彼此竞争,以最低的价格提供最好的服务。

The Graph网络的这种冗余意味着即使单个索引器宕机,但是只要存在查询数据的需求,就会激励其他索引器去完成这些任务。

查询市场中的交易由处理查询所需的带宽和计算资源所决定。

我们来看一下用户与查询市场交互的典型流程。

  • 服务发现。用户询问The Graph有哪些索引器提供他们感兴趣的数据。
  • 索引器选择。用户选择他们认为最有可能以最低价格提供最好服务的索引器。
  • 查询+限额小额付款。用户向索引器发送查询以及限额小额支付,指明他们愿意为计算和带宽支付的费用。
  • 响应+证明。如果索引器接受用户的出价,那么他们就会处理查询请求,返还查询结果,并证明该响应是正确的。提供了证明后,就会收到用户的限额小额付款。

这个证明的产生是确定性的,对索引器来说它也是唯一性的(用于验证目的),争议解决则由协议的其他板块负责。

某个去中心化应用查询The Graph时可利用不同索引器提供的多个子图,该情况下每个被查询的子图都要经历上述流程。

Graph 代币

为了支持查询市场的功能,The Graph协议引入了一种原生代币:Graph代币(GRT)。

Graph代币在协议中主要有两个用途:

  • 索引器质押。索引器质押Graph代币,以便自身被查询市场所发现,同时在执行工作过程中提供经济安全。
  • 策展人信号。策展人将Graph代币质押到策展市场中,预测哪些子图对网络具备价值,他们因为正确预测而获得奖励。

用户能够支付ETH或DAI进行查询。但是最终的结算将以GRT进行,以确保整个协议中使用一种通用的帐户单位。

此外,持有原生代币还能够通过通货膨胀来激励特定行为。动态调整通货膨胀货币政策的能力是工具箱中的一个强大手段。

阅读更多

至此,我们已经介绍了The Graph的多个核心概念。但是,还需要其他机制来提供一个有效的查询市场、高性能协议以及更良好的开发者体验。

我们将在第二部分继续探索这些组件,包括Graph代币的各种用途,例如索引器质押、策展市场以及通胀奖励。

我们还将介绍小额支付的基础设施、如何验证查询响应以及终端用户如何使用去中心化Graph浏览器与协议进行交互。

我们下期见!