深入了解The Graph Web3的核心基础架构—(4)

在Graph网络中，Graph浏览器是一个基于子图顶层的dApp，其中子图能够对Graph协议的智能合约（元数据，我知道！）进行索引，包括Graph域名服务（GNS，一个子图的链上注册表）。

子图是由子图清单定义的，该清单存储在IPFS上，不可篡改。不可篡改特性对于具有确定性和可复制性的查询进行验证和解决争端非常重要。GNS允许团队为子图添加一个名称，因此它的角色很重要，然后用户可以使用该名称指向连续、无法篡改的子图“版本”。

这种人性化的名称以及GNS中存储的其他元数据，让Graph浏览器的用户更好地理解子图的目标和可能的用途，而字母数字字符和已编译WASM字节码的随机字符串则无法做到这一点。

在Graph网络中，发现有用的子图更加重要，因为我们会调整子图的组成。与单纯支持dApp在多个单独的子图上构建不同，子图组合还能引入全新的子图，让它们直接引用现有子图中的实体。

让多个dApp和其他子图能重复使用相同的子图是Graph具备的核心效率之一。我们来对比一下现状，目前每个新的应用都会部署自己的数据库和API服务器，但他们通常没有得到充分利用。

限额小额付款

我们的支付层旨尽可能最小化消费者与索引器之间的信任。付款渠道是一项针对可扩展、链下、最小化信任付款而开发的技术。它涉及到交易双方，他们将资金锁定到链上托管，其中资金只能在它们之间进行链下的交易，除非提出从托管中提现资金的链上交易。

传统的支付渠道通常强调安全地在链下发送小额付款，而不考虑服务或商品实际上是否已经收到。

The Graph在一些数字商品或外包计算微支付的原子交换方面已经取得了一些成果，我们把该架构称为波浪锁（WAVE Lock）。波浪代表了任务、证明、验证和到期时间，其总体设计如下：

任务。用户发送锁定的小额付款，同时指明需要执行的工作。该项工作即为小额付款的锁。

证明。服务提供商按照用户请求，返还数字商品或服务以及已正确完成任务的签名证明。

验证。使用某种方法对上述签名证明进行验证。如果无法正确执行任务，可能会存在一些惩罚（如罚没）。

到期时间。服务提供商必须在小额付款锁定到期之前收到用户收据确认，或者在链上提交证明，来获取他们的小额付款。

在付款渠道上进行锁定并非新鲜事，Lightning和Raiden的论文都探讨了通过哈希原象对小额支付进行解锁。该方法在多hop小额支付中特别有用，其中每个hop都用同一个哈希值锁定，通过一个原象值解锁，该数值会在输入到指定的哈希函数时生成。

虽然我们可以推出自己专门设计嵌入锁定机制的付款通道方案，但目前使用状态通道是最实际的。

我们可以将状态通道看成支付通道，将以太坊等智能合约区块链看成比特币。他们可以处理简单的支付场景，也可以编码更复杂的状态切换，同时保持着支付通道的可扩展性和安全性。

支付和状态通道的共同点在于，它们的基本形式是在预先认识的两个参与方之间进行价值交换或状态更新。在上文提到的多hop小额付款中，任何两个参与者之间进行支付都需要在多个其他参与者之间形成一个支付通道链，将两个原始参与方连接起来。

目前有许多不错的项目正在处理不同形式的Graph遍历，为任意两个参与者方提供小额付款。为简单起见，Graph网络最初会使用轴辐式（hub and spoke）的结构。

这意味着如果要用The Graph，用户需要通过状态通道轴在链上开启一个状态通道，该通道使用用户选择的稳定代币或ETH。同时索引器也要在轴开通一个状态通道来接收GRT。

状态通道轴需要质押GRT并设置付款面额与GRT之间的汇率，让所有小额付款都以同一单位结算。

验证

为了确保波浪锁的构造和索引器质押发挥效果，必须要有一个有效的验证机制，该机制能够重现索引器执行的任务、识别故障并惩罚恶意的索引器。

在Graph网络的第一阶段，这一点通过链上争议解决流程来处理，最终结果由仲裁院决定。