Request 网络是一个用于存储支付请求的协议。Request 网络解决的核心问题是：区块链交易缺乏交易发生的背景信息。比如说，当一笔交易发生时，可以看到交易的发送地址、接收地址等信息，但是不知道这笔交易的背景、原因和目的，这正是 Request 网络中存储的内容。

Request 网络生态系统提供了一系列的去中心化技术，用于存储额外的交易背景信息。

在 Request 网络的输入端（参照图示左边），有很多用于创建 Request 的应用程序，比如会计应用、发票应用和支付应用等。比如我希望你付给我 5 USDC ，我可以在应用程序中创建一个新的 Request。用户还可以在应用程序中查看自己的身份，或者查看与自己身份关联的所有 Request 。另外，这些应用程序还集成了自动审计、税务报告、计费等相关功能，可以让用户更加方便的来创建、支付和管理其财务发票及相关服务。

在 Request 网络的输出端（参照图示右边），还有很多其他的应用程序。有的应用将使用用户存储的交易数据信息，来创建信用评分。有的应用将根据用户是否按时支付发票，来评估风险，比如贷款人和流动性提供者需要使用这些信息，来确定支付者在未来是否有支付能力，以便评估贷款风险。在保险协议或筹款协议中也有类似的需求，他们也希望获得这种承保信息。同时这种交易数据信息，还对自动合规、自动审计、自动税务报告等工具有用，可以为用户提供廉价自动实时的审计报告、税务报告、财务报表等。

一个 Request 流程主要包括三个部分：创建 Request、支付 Request、检索 Request / 检测付款。

付款人或收款人先构造一个 JSON 格式的请求数据，并签署这条消息，消息内容包括收款人地址、付款人地址、货币、金额、付款详细信息和其他任意内容数据。然后使用 SDK 调用创建 Request 的 API 接口即可。API 接口会将内容数据写入 IPFS 中，然后从 IPFS 里获取一个内容可寻址的 CID（哈希），并将 CID 存储在 Gnosis 链上的智能合约中。存储 CID 的智能合约支持很多不同的链，但以 Gnosis 链为主，同时支持 Goerli 和 Sepolia 测试网。可以选择对 Request 进行加密，以便只有收款人、付款人和批准的第三方才能查看请求内容。

Request 创建后可以对其更新。收款人可以选择取消请求或增加 / 减少预期金额，付款人可以选择接受请求，表明他们打算付款。如果 Request 被加密，收款人和付款人都可以添加第三方利益相关者。

支付 Request 与 IPFS 中存储的 Request 通过支付引用联系起来，智能合约需要获取支付引用这个标识，用于处理指定的 Request。在支付 Request 时，使用另一组智能合约进行支付，合约中简单封装了一个典型的转账功能，在支付时会产生一个事件，用于支付检测系统索引和跟踪，事件内容包括交易币种、收款人地址、支付金额、支付引用（Indexed，可被索引）等。

另外，一次 Request 支持多次付款，当付款方支付时，可以选择小金额多次支付，而不是全额支付。

应用程序可以从 IPFS 中检索 Request 内容，并根据支付子图 (subgraph) 跟踪的付款事件计算 Request 余额，然后将 Request 余额与 Request 内容进行合并，合并后的数据可用于前端仪表盘显示。Request 余额的计算方法是，将所有具有相同支付引用的事件金额相加，也就是到目前为止支付给该 Request 的总金额。

用户使用客户端来创建和检索 Request，向节点发送消息，然后节点将与网络中的 IPFS 集群交互，保存 Request 内容并检索 CIDS，这样存储子图就能够索引 IPFS 中的新数据和链上存储智能合约中产生的事件，存储子图将所有这些数据都返回给节点。另外，Request 节点还允许从支付子图中查询数据，每一个链都有一个单独的支付子图，它用于索引支付智能合约产生的事件。

Request 网络协议将 Request 内容保留在 IPFS 上，但是大部分用户不希望公开他们的发票信息，因此，协议 SDK 支持在读写 IPFS 前对请求内容进行加解密。加密方式和 https 协议类似，使用一个通道密钥来加密 Request 内容，这是一个对称密钥，也就是加密和解密所使用的密钥相同，使用对称加密的原因是对称加密比非对称加密成本低。同时需要使用用户的公钥（非对称）来加密通道密钥。

存储 IPFS 时，加密流程如下： 

第 1 步：SDK 创建 Request，并发送 Request 内容和用户公钥。 

第 2 步：SDK 生成随机 AES 密钥（对称加密密钥）。 

第 3 步：SDK 用 AES 密钥加密 Request 内容。 

第 4 步：SDK 使用用户公钥加密 AES 密钥。加密的 Request 内容和加密的 AES 密钥将保存到 IPFS。

读取 IPFS 时，解密流程如下： 

第 1 步：SDK 从 IPFS 中检索用户加密后的 AES 密钥（IPFS 中存储的是 AES 密钥密文）。 

第 2 步：SDK 使用用户私钥解密 AES 密钥（解密后为 AES 密钥明文）。 

第 3 步：SDK 使用 AES 密钥解密 Request 内容（解密后为 Request 内容明文），并将 Request 内容返回给用户。

本次使用 Request network 官网的代码沙盒 +MetaMask 钱包进行演示。详见官方文档。

填写 Request 内容，各字段字段解释如下：（* 号字段为必填项）

• Payee Identity *：收款人身份地址，为连接的 MetaMask 钱包账户地址。创建请求需要收款人身份或付款人身份的签名。此演示仅支持使用收款人身份进行签名。

• Storage Chain *：存储链，用于存储 Request 内容的哈希值（IPFS CID）。

• Amount *：支付金额。

• Currency *：货币名称。

• Payment Recipient：收款地址，默认为收款人身份地址。

• Payer Identity：付款人身份地址。

• Due Date：支付截止日期。

• Reason：请求的原因，支付的背景信息。本次演示填写：dl request network test reason

在 MetaMask 钱包中签名消息，签名后注意查看下方返回的报文信息，报文将按如下顺序依次更新。

1. 报文更新：把 Request 内容写入 IPFS

App status: persisting to ipfs

2.报文更新：把 CID 写入区块链

App status: persisting on-chain 

Request state: pending

3.报文更新：request 创建完成

App status: request confirmed 

Request state: created

在 MetaMask 钱包中授权支付份额，注意查看浏览器弹出的提示框，将按如下顺序依次提示。

1.弹框提示：检查付款人账户金额是否充足

2. 弹框提示：检查结果，金额充足

3.弹框提示：检测到 request ，检查是否已授权

4.弹框提示：检查结果，已授权

5.报文更新：已授权

App status: approved 

Request state: created

在 MetaMask 钱包中，需要付款人确认支付。

报文更新：已支付 

App status: request paid 

Request state: created

可以修改代码沙盒中的 page.tsx 文件，将用户地址修改为创建 Request 时填写的用户地址，即可查看 Request 相关信息，此处可以看到 reason 字段内容为 dl request network test reason，与创建时填写一致。

检索结果如下：

Request Network 官方文档：

https://docs.request.network/