ryanhuang (ryanhuang)

【翻译】Solana Actions 与 Blinks 文档

ryanhuang — Wed, 03 Jul 2024 12:01:32 +0800

原文链接：https://solana.com/docs/advanced/actions

Solana Actions是符合规范的应用程序接口，可返回 Solana 区块链上的交易，以便在二维码、按钮 + 小工具和互联网网站等各种环境中进行预览、签名和发送。Actions 使开发人员可以轻松地将 Solana 生态系统中的各种操作集成到自己的环境中，允许你在不需要跳转到其他应用或网页的情况下执行区块链交易。

区块链链接（或 blinks）可将任何 Solana Action 转化为可共享、元数据丰富的链接。Blinks 允许支持 Action 的客户端（钱包浏览器插件、机器人）为用户显示额外的功能。在网站上，Blink 可能会立即触发钱包中的交易预览，而无需进入去中心化应用程序；在 Discord 中，机器人可能会将 Blink 扩展为一组交互式按钮。这使得在任何能够显示 URL 的网页界面上进行链上交互成为可能。

开始使用

快速开始创建自定义 Solana Action：

npm install @solana/actions

在应用程序中安装Solana Actions SDK
创建一个 API 端点，接收GET 请求返回有关 Action 的元数据
创建一个 API 端点，接收POST 请求并返回用户可签署交易

你还可以在此处找到执行本地 SOL 转账操作的源代码，并在此软件仓库中找到其他几个操作示例。

将自定义 Solana Action 部署到生产环境：

确保你的应用程序在域根目录下有一个有效的 actions.json 文件
确保应用程序在所有 Action 端点（包括actions.json文件）响应时包含跨域 Headers

如果你正在寻找有关构建 Action 和 Blink 的灵感，请查看Awesome Blinks资源库中的一些社区作品，以及新创意作品。

Actions

Solana Actions 规范使用一套标准 API，将可签名交易（以及最终需签名数据）从应用程序直接传送给用户。它们托管在可公开访问的 URL 上，任何客户端都可以通过 URL 与之交互。

提示

你可以将 Action 视为一个应用程序接口端点，它会返回元数据和一些需用户使用区块链钱包签名（交易或认证信息）的内容。

Action API 包括向 Action URL 端点发出简单的GET和POST请求，以及遵循 Actions 接口规范处理响应。

GET 请求会返回元数据，为客户端提供有关该 URL 上可用 Action 的可读信息，以及相关操作的可选列表。
POST 请求会返回一个可签名的交易或数据，然后客户端会提示用户使用钱包签名，并在区块链或其他链外服务中执行。

Action 执行和生命周期

实际上，与 Actions 的交互和与常见的 REST API 的交互非常相似：

客户端向 Action URL 发出初始GET请求，以获取可用 Action 的元数据
端点返回的响应包括端点的元数据（如应用程序的标题和图标）以及该端点的可用 Action 列表
客户端应用程序（如移动钱包、聊天机器人或网站）显示用户界面，供用户执行操作
用户选择操作（点击按钮）后，客户端会向端点发出POST请求，发送交易数据供用户签名
用户使用钱包签署交易，并最终将交易发送至区块链进行确认

Solana Action 的执行和生命周期
图片来源 MasterCui
原图请看 https://solana-developer-content.vercel.app/assets/docs/action-execution-and-lifecycle.png

从 Action URL 接收交易时，客户端应将这些交易提交到区块链，并管理其状态生命周期。

Action 还支持在执行前进行一定程度的失效验证。GET和POST请求可能会返回一些元数据，说明该操作是否可以被执行（如disabled字段）。

例如，如果有一个 Action 端点用于 DAO 治理提案进行投票，但投票窗口已关闭，那么初始GET 请求可能会返回错误信息 "此提案不再进行投票"，并且 "投赞成票 "和 "投反对票 "按钮被 "禁用"。

Blinks

Blinks（区块链链接）是客户端应用程序，可分析 Action 应用程序接口，并基于 Action 交互和执行构建用户界面。

支持 Blinks 的客户端应用程序检测与 Action 兼容的 URL，对其进行解析，并允许用户在标准化界面上与之交互。

提示

任何完整分析 Action API 以构建其完整界面的客户端程序被称为 Blink，并非所有使用 Action API 的客户端都是 Blink。

Blink URL 规范

Blink URL 描述的是一个客户端应用程序，它能让用户完成执行 Action的整个生命周期，包括使用钱包进行签名。

https://example.domain/?action=<action_url>

客户端应用程序成为 Blink 的条件：

Blink URL 必须包含一个action查询参数，其值为 URL 编码的 Action URL。该值必须进行 URL 编码，以免与其他协议参数冲突。
客户端应用程序必须对action查询参数进行 URL 解码，并分析所提供的 Action API（请参阅 Action URL 协议）。
客户端必须提供丰富的用户界面，使用户能够完成执行 Action 的整个生命周期，包括使用钱包进行签名。

提示

并非所有 Blink 客户端应用程序（如网站或 dApps）都支持全部 Action。应用程序开发人员可以选择在其 Blink 界面中支持哪些 Action。

下面的示例演示了一个有效的 blink URL，其action值为 solana-action:https://actions.alice.com/donate 编码后的数据：

https://example.domain/?action=solana-action%3Ahttps%3A%2F%2Factions.alice.com%2Fdonate

Blinks 识别 Action

Blinks 至少可以通过三种方式识别 Action：

显示展示 Action URL：solana-action:https://actions.alice.com/donate

在这种情况下，只有支持的客户端才能正常展示。不会有 fallback 链接预览，也不会有可以在非支持客户端之外访问的网站。

在网站域名根目录上放置 actions.json 文件。

例如，https://alice.com/actions.json 将 https://alice.com/donate（向 Alice 捐赠的网页 URL）映射到 API URL https://actions.alice.com/donate（向 Alice 捐赠的 Action 托管在该 URL）。

在 "插页式" 网站 URL 中嵌入 Action URL，该 URL 支持解析 Action。
```
https://example.domain/?action=<action_url>
```

支持 Blink 的客户端应能接受上述任何格式，并正确呈现界面，以便直接在客户端执行操作。

对于不支持 Blink 的客户端，应该有一个底层网页（使浏览器成为通用的备用工具）。

如果用户在客户端上点击不是 Action 按钮或文本输入框的任何地方，会进入底层网页。

Blink 测试与验证

虽然 Solana Action 和 Blink 是一种无权限协议/规范，但仍需客户端应用程序和钱包来最终帮助用户签署交易。

不同的客户端应用程序或钱包中的可能有不同的要求，即他们的客户端将自动展开哪些 Action 端点，在社交媒体上直接向用户展示哪些内容。

例如，有些客户端可能会采用 "白名单 "方法，在为用户展开 Action（如 Dialect 的 Action 注册表（详见下文））之前可能需要验证。

所有的 blink 会在 Dialect 的 dial.to blinks 中间页上呈现，并允许签名，同时它们的注册状态会显示在 blink 中。

Dialect Actions 注册表

Dialect Actions 注册表是 Solana 生态系统的公共产品，Dialect在 Solana 基金会和其他社区成员的帮助下，其维护了一个公共注册表，包含已验证的区块链链接。自发布之日起，只有在 Dialect 注册表中注册的 Action 才能在 Twitter feed 中发布。

客户端应用程序和钱包可以自由选择使用该公共注册表或其他解决方案，以确保用户资产安全。如果未通过 Dialect 注册表验证，区块链链接将不会被 blink 客户端解析，而是展示为一个普通 URL。

开发人员可在此处申请 Dialect 验证：https://dial.to/register

规范

Solana Action 规范由请求/响应交互流程中的如下关键部分组成

Solana Action URL 协议
Action URL 的 OPTIONS 响应，满足 CORS 要求
向 Action URL 发送 GET 请求
服务器的 GET 响应
向 Action URL 发送 POST 请求
服务器的 POST 响应

Action 客户端（如钱包应用、浏览器扩展、dApp、网站等）发送请求，收集用户界面需要的元数据，并实现用户输入接入 Action API。

应用程序（如网站、服务器后台等）生成需签名的交易或数据，并返回给 Action 客户端，提示用户确认、签名并发送到区块链。

URL 协议

Solana Action URL 定义了使用solana-action协议发起交互式请求。

请求是交互式的，客户端会使用 URL 中的参数发出一系列标准化 HTTP 请求，以创建可签名的交易或信息，供用户使用钱包签名。

需要一个单独的link字段作为路径名。该值需要是按需进行 URL 编码的 HTTPS 绝对路径。
如果 URL 包含查询参数，则必须进行 URL 编码。对 URL 值进行编码可避免与其他 Actions 协议参数发生冲突，协议参数可能随着协议规范更新而添加。
如果 URL 不包含查询参数，则不应进行 URL 编码。这样可以生成更短的 URL 和更简洁的二维码。

无论哪种情况，客户端都必须对值进行 URL 解码。如果值未进行 URL 编码，也不会有副作用。如果解码后不是 HTTPS 绝对路径，钱包必须将其视为格式错误，不能进行处理。

OPTIONS 响应

为了允许在 Action 客户端（包括 Blink）内进行跨源资源共享(CORS)，所有 Action 端点都应使用有效的标头来响应OPTIONS方法的 HTTP 请求，从而允许客户端通过 CORS 检查，处理其所有后续请求。

Action 客户端可向 Action URL 端点发起"预检"请求，以检查对 Action URL 的后续 GET 请求是否能通过所有 CORS 检查。这些 CORS 预检检查是使用OPTIONSHTTP 方法进行的，并响应所有必要的 HTTP headers，以便 Action 客户端（如 blinks）从其源域正确发出所有后续请求。

所需的 HTTP headers 至少包括

Access-Control-Allow-Origin : *。
确保所有 Action 客户端发出的请求都能正常通过 CORS 检查
Access-Control-Allow-Methods : GET、POST、PUT、OPTIONS
- 确保 Action 支持所有必要的 HTTP 请求方法
Access-Control-Allow-Headers : 至少包含Content-Type、Authorization、Content-Encoding、Accept-Encoding

为简单起见，开发人员可考虑对OPTIONS请求返回与 GET 响应相同的响应和 headers。

actions.json 的跨源 Header

对于`actions.json`文件的`GET`和`OPTIONS`请求，响应还必须返回有效的 Cross-Origin headers，特别是`Access-Control-Allow-Origin` headers 值为`*`。

更多详情，请参阅下面的[actions.json](https://solana.com/docs/advanced/actions#actionsjson)。

GET 请求

Action 客户端（如钱包、浏览器扩展等）向 Action URL 端点发出 HTTPGETJSON 请求。

请求不应指定钱包或用户。
发起请求时应包含Accept-Encoding Header。
发起请求时需显示 URL 域名。

GET 响应

Action URL 端点（如应用程序或服务器后端）应返回 HTTPOKJSON 响应（正文中包含有效的 Payload）或 HTTP 错误码。

客户端必须处理 HTTP 客户端错误、服务器错误和重定向响应。
返回值需包含Content-Encoding Header，以便进行 HTTP 压缩。
返回中的Content-Type Header 应为application/json。
除非 HTTP 缓存响应 Header 明确设置，客户端不应缓存响应。
客户端应向用户显示title和icon图像。

GET 响应正文

带有 HTTPOKJSON 响应的GET响应应包括遵循接口规范的正文有效 Payload：

export interface ActionGetResponse {
  /** image url that represents the source of the action request */
  icon: string;
  /** describes the source of the action request */
  title: string;
  /** brief summary of the action to be performed */
  description: string;
  /** button text rendered to the user */
  label: string;
  /** UI state for the button being rendered to the user */
  disabled?: boolean;
  links?: {
    /** list of related Actions a user could perform */
    actions: LinkedAction[];
  };
  /** non-fatal error message to be displayed to the user */
  error?: ActionError;
}

icon- 图标的 HTTP 或 HTTPS 绝对路径。格式支持 SVG、PNG 或 WebP，其他格式客户端/钱包必须将其作为格式错误图标拒绝。
title- 表示 Action 请求来源的 UTF-8 字符串。例如，发起请求的品牌、商店、应用程序或个人的名称。
description- 提供 Action 信息的 UTF-8 字符串。需要显示给用户。
label- 一个 UTF-8 字符串，将显示在按钮上供用户点击。所有标签不应超过 5 个词组，并应以动词开头，以明确用户希望采取的操作。例如，"Mint NFT"、"Vote Yes "或 "Stake 1 SOL"。
disabled - 布尔值，表示渲染按钮（显示label字符串）的禁用状态。如果返回中不包含该值，则disabled默认为false（即默认为启用）。例如，如果治理投票 Action 端点已关闭，则设置disabled=true，label就会显示 "Vote Closed（投票已关闭）"。
error - 用于非致命错误的可选错误指示。如果存在，客户端应将其显示给用户，但不应阻止 Action 的解析与显示。错误可与disabled一起用于显示错误原因，例如：业务限制、权限、状态或外部资源异常等

export interface ActionError {
  /** non-fatal error message to be displayed to the user */
  message: string;
}

links.actions - 端点相关操作的可选数组。应为用户展示出所有列表，并要求只执行其中一项。例如，治理投票 Action 端点可能会向用户返回三个选项："投赞成票"、"投反对票 "和 "弃权票"。
- 如果未提供links.actions，客户端应使用根label字符串渲染单个按钮，并向与 GET 请求相同的 Action URL 端点发出 POST 请求。
- 如果提供了links.action，客户端应仅根据links.actions字段中列出的项目显示按钮和输入字段。客户端不应为根label的内容显示按钮。

export interface LinkedAction {
  /** URL endpoint for an action */
  href: string;
  /** button text rendered to the user */
  label: string;
  /** Parameter to accept user input within an action */
  parameters?: [ActionParameter];
}

/** Parameter to accept user input within an action */
export interface ActionParameter {
  /** parameter name in url */
  name: string;
  /** placeholder text for the user input field */
  label?: string;
  /** declare if this field is required (defaults to `false`) */
  required?: boolean;
}

GET 响应示例

下面的响应示例提供了一个单一的 Action 操作，向用户展示一个标签为 "申请访问令牌 "的单一按钮：

{
  "title": "HackerHouse Events",
  "icon": "<url-to-image>",
  "description": "Claim your Hackerhouse access token.",
  "label": "Claim Access Token" // button text
}

下面的响应示例提供了 3 个相关操作链接，允许用户点击 3 个按钮中的一个，为 DAO 提案投票：

{
  "title": "Realms DAO Platform",
  "icon": "<url-to-image>",
  "description": "Vote on DAO governance proposals #1234.",
  "label": "Vote",
  "links": {
    "actions": [
      {
        "label": "Vote Yes", // button text
        "href": "/api/proposal/1234/vote?choice=yes"
      },
      {
        "label": "Vote No", // button text
        "href": "/api/proposal/1234/vote?choice=no"
      },
      {
        "label": "Abstain from Vote", // button text
        "href": "/api/proposal/1234/vote?choice=abstain"
      }
    ]
  }
}

带参数的 GET 响应示例

下面的响应示例演示了如何接受用户的文本输入（通过parameters参数），并将该输入包含在最终的POST请求端点中（通过LinkedAction 中的href字段）：

下面的响应示例为用户提供了 3 个链接的操作，以质押 SOL：一个标有 "Stake 1 SOL "的按钮，另一个标有 "Stake 5 SOL "的按钮，以及一个允许用户输入特定 "金额"值的文本输入框，该值会被发送到 Action API：

{
  "title": "Stake-o-matic",
  "icon": "<url-to-image>",
  "description": "Stake SOL to help secure the Solana network.",
  "label": "Stake SOL", // not displayed since `links.actions` are provided
  "links": {
    "actions": [
      {
        "label": "Stake 1 SOL", // button text
        "href": "/api/stake?amount=1"
        // no `parameters` therefore not a text input field
      },
      {
        "label": "Stake 5 SOL", // button text
        "href": "/api/stake?amount=5"
        // no `parameters` therefore not a text input field
      },
      {
        "label": "Stake", // button text
        "href": "/api/stake?amount={amount}",
        "parameters": [
          {
            "name": "amount", // field name
            "label": "SOL amount" // text input placeholder
          }
        ]
      }
    ]
  }
}

下面的响应示例提供了一个输入框，供用户输入金额，该值在 POST 请求中使用（可以作为查询参数，也可以使用 URL 路径）：

{
  "icon": "<url-to-image>",
  "label": "Donate SOL",
  "title": "Donate to GoodCause Charity",
  "description": "Help support this charity by donating SOL.",
  "links": {
    "actions": [
      {
        "label": "Donate", // button text
        "href": "/api/donate/{amount}", // or /api/donate?amount={amount}
        "parameters": [
          // {amount} input field
          {
            "name": "amount", // input field name
            "label": "SOL amount" // text input placeholder
          }
        ]
      }
    ]
  }
}

POST 请求

客户端向 ACTION URL 发出 HTTPPOSTJSON 请求，其正文有效 Payload 为

{
  "account": "<account>"
}

account - 可以签署交易的账户公钥 base58 编码。

客户端应使用 Accept-Encoding Header 发出请求，应用程序可使用 Content-Encoding Header 响应 HTTP 压缩。

客户端应在发出请求时显示 Action URL 的域名。如果发出的是GET请求，客户端还应显示标题，并从渲染 GET 响应中的图标。

POST 响应

Action POST 端点应返回 HTTPOKJSON 响应（正文中包含有效的有效 Payload）或恰当的 HTTP 错误码。

客户端必须处理 HTTP 客户端错误、服务器错误和重定向响应。
响应包含Content-Type Header，值为application/json。

POST 响应正文

带有 HTTPOKJSON 响应的POST响应应包含以下内容的正文有效 Payload：

export interface ActionPostResponse {
  /** base64 encoded serialized transaction */
  transaction: string;
  /** describes the nature of the transaction */
  message?: string;
}

transaction - base64 编码的序列化数据。客户端需对交易进行 base64 解码并反序列化。
message - UTF-8 字符串，用于描述响应中包含的交易的说明。客户端应将此值显示给用户。例如，所购物品的名称、可用购买折扣或感谢信。
客户端和应用程序应允许在请求正文和响应正文中增加额外字段，这些字段可能会在未来的规范更新中添加。

提示

应用程序可能会响应部分或完全签名的交易。客户端和钱包必须将该交易视为不可信。

POST 响应 - 交易

如果交易签名为空，或者交易没有被签名：

客户端必须忽略交易中的feePayer，并将feePayer设置为请求中的account。
客户端必须忽略交易中的recentBlockhash，并将recentBlockhash设置为最新的 blockhash。
客户端必须在签署前序列化和反序列化交易，以确保账户密钥顺序的一致性，从而解决这一问题。

如果交易已部分签署：

客户不得更改feePayer或recentBlockhash，否则将导致所有现有签名无效。
客户机必须验证现有签名，如果有任一签名无效，客户机必须将其视为格式错误交易予以拒绝。

客户端必须仅使用请求中的account对交易进行签名，且仅在预期需要该账户的签名时才能这样做。

如果请求中需要除account签名之外的任何签名，则客户端必须拒绝该交易，将其视为恶意交易。

actions.json

actions.json文件的目的是让应用程序指示客户端哪些 URL 支持 Solana 操作，并提供可用于向 Action API 服务器执行 GET 请求的映射。

CROSS-ORIGIN HEADERS

对于`GET`和`OPTIONS`请求，`actions.json`文件响应还必须返回有效的 Cross-Origin 标头，特别是`Access-Control-Allow-Origin`值为`*`。

更多详情，请参阅上文的 [OPTIONS 响应](https://solana.com/docs/advanced/actions#options-response)。

actions.json文件应存储在域的根目录下，并可开放访问。

例如，如果你的网络应用程序部署在my-site.com，那么actions.json文件应可通过https://my-site.com/actions.json 访问。该文件还应可通过任何浏览器跨源访问，Access-Control-Allow-Origin Header 值应为*。

规则

rules 字段允许应用程序将一组相对路径映射到一组其他路径。

类型： ActionRuleObject 数组。

interface ActionRuleObject {
  /** relative (preferred) or absolute path to perform the rule mapping from */
  pathPattern: string;
  /** relative (preferred) or absolute path that supports Action requests */
  apiPath: string;
}

pathPattern- 输入路径匹配表达式。
apiPath- 映射后的绝对路径或外部 URL 地址。

规则 - pathPattern

匹配输入路径的表达式。可以是绝对路径或相对路径，并支持以下格式：

精确匹配：精确匹配 URL 路径。
- 示例/exact-path
- 示例https://website.com/exact-path
通配符匹配：使用通配符匹配 URL 路径中的字符序列。可以匹配单个（使用*）或多个字符（使用**）（请参阅下面的路径匹配）。
- 示例/trade/*将匹配/trade/123 和/trade/abc，通配符只匹配/trade/ 后的第一段。
- 示例/category/*/item/**将匹配/category/123/item/456和/category/abc/item/def。
- 示例/api/actions/trade/*/confirm将匹配/api/actions/trade/123/confirm。

规则 - apiPath

Action 请求的目标路径。可以是绝对路径或外部 URL。

示例/api/exact-path
示例https://api.example.com/v1/donate/*
示例/api/category/*/item/*
示例/api/swap/**

规则 - 查询参数

原始 URL 中的查询参数会附加到映射的 URL 中。

规则 - 路径匹配

下表概述了路径匹配模式的语法：

操作符	匹配内容
`*`	单个路径段，不包括路径分隔符/。
`**`	匹配零个或多个字符，包括多个路径段之间的路径分隔符/。如果包含其他操作符，`**`操作符必须是最后一个操作符。
`?`	不支持

规则示例

下面的示例演示了一个精确匹配规则，将/buy请求映射到相对于网站根目录的精确路径/api/buy：

{
  "rules": [
    {
      "pathPattern": "/buy",
      "apiPath": "/api/buy"
    }
  ]
}

下面的示例使用通配符路径匹配，将请求/actions/下的任何路径（不包括子路径）映射到相对于网站根目录的/api/actions/下的相应路径：

{
  "rules": [
    {
      "pathPattern": "/actions/*",
      "apiPath": "/api/actions/*"
    }
  ]
}

下面的示例使用通配符路径匹配，将/donate/下任何路径（不包括子路径）的请求映射到外部网站上相应的绝对路径https://api.dialect.com/api/v1/donate/

{
  "rules": [
    {
      "pathPattern": "/donate/*",
      "apiPath": "https://api.dialect.com/api/v1/donate/*"
    }
  ]
}

下面的示例使用通配符路径匹配幂等规则，将请求从网站根目录映射到/api/actions/下的任何路径（包括子路径）：

提示

幂等规则使 blink 客户端更轻松地确定给定路径是否支持 Action API 请求，而无需使用solana-action.URI 作为前缀或执行额外的响应测试。

{
  "rules": [
    {
      "pathPattern": "/api/actions/**",
      "apiPath": "/api/actions/**"
    }
  ]
}

Action 身份

Action 端点可在其 POST 响应中包含一个 Action 身份，供用户签名。这样，索引器和分析平台就能以可验证的方式轻松地将链上活动归属于特定的 Action 提供者（即服务）。

Action 身份是一个密钥对，用于签署使用 memo 指令包含在交易中的特殊格式信息。该身份信息可验证归属于特定的 Action 身份，从而将交易归属于特定的 Action 提供者。

交易本身不需要密钥对签名。这样，当返回给用户的交易上没有其他签名时，钱包和应用程序就能提高交易的可交付性（参见 POST 响应交易）。

如果 Action 提供者的用例要求其后端服务在用户之前对交易进行预签名，则应使用此密钥对作为其 Action 身份。这样，交易中就可以少包含一个账户，使交易数据量减少 32 字节。

Action 身份信息

Action 身份信息是使用单条 SPL memo指令包含在交易中的冒号分隔的 UTF-8 字符串。

protocol - 使用的协议值（根据上述URL 协议设置为solana-action）。
identity - Action 身份密钥对公钥的 base58 编码
reference - Base58 编码的 32 字节数组。这个数组可能是公钥或非公钥，可能与 Solana 上的账户对应，也可能不对应。
signature - 由 Action 身份密钥对创建的 base58 编码签名，仅对reference签名。

reference在单个交易中只能使用一次。在将交易与 Action 提供程序关联时，只有第一次使用reference才被视为有效。

交易可能有多个 memo 指令。执行getSignaturesForAddress 时，结果中memo字段将以单个字符串形式返回每个 memo 指令的信息，每个信息之间用分号隔开。

身份识别信息的 memo 指令不应包含其他数据。

identity和reference应作为只读、非签名密钥包含在交易中，这些密钥所在的指令不应是标识消息 memo 指令。

标识符消息 memo 指令必须不提供任何账户。如果提供了任何账户，memo 程序要求这些账户必须是有效的签名者。为了识别操作的目的，却限制了灵活性并可能降低用户体验。因此，这被视为一种反模式，必须避免使用。

Action 身份验证

任何包含identity账户的交易都可以通过多个步骤通过 Action 提供者进行验证

获取给定identity的所有交易。
解析并验证每笔交易的备注字符串，确保signature对所存储的reference有效。
验证特定交易是否是链上reference的首次出现：
- 如果该交易是首次出现，则认为该交易已通过验证，可以安全地归属于 "Action 提供者"。
- 如果该交易不是首次出现，则视为无效，因此不能归属于 "Action 提供者"。

由于 Solana 验证器根据账户密钥对交易进行索引，因此可以使用getSignaturesForAddressRPC 方法定位包括identity账户在内的所有交易。

此 RPC 方法的响应包括memo字段中的所有 memo 数据。如果交易中使用了多个 memo 指令，则每个 memo 信息都将包含在此memo字段中，验证程序必须对其进行相应的解析，以获得身份验证信息。

这些交易最初应视为未验证。这是因为不需要identity信息来签署交易，从而允许任何交易将此账户作为非签署者。可能会人为夸大归属和使用次数。

需检查确保signature是由签署reference的identity创建的。如果签名验证失败，则交易无效，应归属于 Action 提供者。

如果签名验证成功，验证者应确保该交易是reference在链上的首次出现。如果不是，则认为该交易无效。

DePIN：虚假的希望还是真实的曙光？

ryanhuang — Wed, 12 Jun 2024 00:12:54 +0800

原文：https://medium.com/@poporuii/critiquing-depin-false-hope-or-real-dawn-cce8932c0872

作者：@Rui

随着对现实世界应用的日益重视和 Solana 的兴起，DePIN 在 2024 年重新获得了巨大的人气。然而，DePIN 并不是一个新概念。在我看来，DePIN 的本质是将参与者变成利益相关者的代币经济模型，而不是创造新的生产力。

在之前的牛市中，Arweave、Filecoin 和 Helium等项目脱颖而出，而其他许多项目表现不佳，价值甚至跌至零。现在，我们接近下一个牛市的风口浪尖，我们面临的挑战在于辨别昙花一现的风潮和真正可持续的创新，这些创新将引领我们进入现实世界应用的新时代。

这篇文章旨在对 DePIN 的过往缺点进行中肯的分析，探讨监管障碍、需求不足、有缺陷的代币经济学和 Rug 风险等领域。尽管如此，它也展示了这一领域的巨大前景，包括克服利润率、价值锚、代币激励和强大的社区参与。我将提供一个 DePIN 评估框架，以及 DePIN 项目的详细案例研究。希望这篇文章能为读者提供洞见和工具，以在 DePIN 领域更好的构建、研究和投资。

内容

简介
参与方：硬件商、矿工、协议、运营商和用户
生态系统
DePIN 项目：目的、类型和市场
区块链和中间件：通用链和 DePIN 专用链
本质：
- 为什么不 Work：监管、需求、代币经济、护城河和 Rug
- 为什么有机会：利润空间、锚点、加速器和社区
评审标准：
- 总价值 = 产品 X 经济模型 X 叙事吸引力
- 持续时间 = 被验证或被否定的时间跨度
- 决定因素 = 合规性 X 团队实力
案例研究：
- Helium：5G 网络
- io.net：AI/ML 共享 GPU

简介

多年来，区块链领域一直专注于基础设施开发，强调扩展解决方案（Layer2s、数据可用性）、隐私增强（零知识）和用户体验改善（账户抽象），为大规模应用做准备。现在比以往任何时候都更加明显地需要现实世界的大规模应用。致力于合规的交易所和 ETF 进入传统市场等举措取得了重大进展，并为我们铺平了道路。

DePIN 不是一个特定的领域，这个术语最初由 Messari 提出，是去中心化物理基础设施网络（Decentralized Physical Infrastructure Networks）的缩写。它代表了一个由代币激励的社区驱动的去中心化硬件网络。其主要目标是取代垄断巨头，并使用原生代币将参与者转变为网络的利益相关者。自上一轮牛市以来，AI/ML、5G、WiFi、带宽、车载、能源等高价值领域出现了显著扩张。

那么，DePIN 在这个领域中带来了什么新东西呢？

资产：类型、分布、交易方式

纵观成功的加密项目，通常以具有通用属性的资产为特色，并不断完善这些资产的功能和使用场景。DePIN 项目可以合并物理资产，将硬件提供的服务或收集的数据转换为代币化资产。这种代币化促进了无许可的交易和质押，为更广泛的金融活动铺平了道路。
参与者：角色、数量、粘性和关系

DePIN 通过多样化的角色来增强生态系统，创建一个由硬件制造商、矿工、网络应用程序、用户等组成的有凝聚力的网络。减少进入壁垒和扩大地理覆盖范围吸引了更广泛的参与者。更重要的是，DePIN 通过加密资产将所有相关方转变为利益相关者，促进了劳动贡献和消费。这种方法确保了持续的参与，增加了生态系统的粘性，并超越了传统的、简单的买卖关系。通过促进复杂的互连，DePIN 大大增强了其生态系统的稳健性和可持续性。
场景：溢价、频率和可扩展性

DePIN 立足于真实场景，满足现有需求。除了关注加密投资者之外，该网络的通用价值还可以从购买者的数量、每笔交易的价值和交易频率中得到。如果这些因素中的任何两个表现出色，就可以取得成功。例如，5G 用户群庞大，美国大约有 1 亿多人每月支付一次 80 美元。虽然与 5G 消费者相比，单个人工智能公司可能代表的交易量较小，但在广泛需求的推动下，这些高频高价值交易凸显了巨大的机会。

除了初始优势，还有几个关键因素值得关注：即使供应充足，实现产品与市场的契合仍然是成功的关键;实施确保分区容忍度和抗审查性的协议设计对于避免新形式的审查至关重要;此外，必须精心制定激励措施，以避免不可持续的通货膨胀。我们将在下面更详细地探讨这些方面。

参与方

这部分研究了其五个参与方的角色和目标：硬件制造商、托管商（为了便于记忆称为矿工）、网络提供商（协议）、运营商和最终用户。

硬件制造商：提供服务或收集数据的物理设备

制造商演进：

从集中式、有门槛的制造商过渡到无许可的系统是一个自然的演进过程。最初，依靠单个实体来生产可靠的硬件是合理的。然而，为了防止单一供应商形成垄断威胁或网络增长的瓶颈，向更多合格的硬件制造商开放生态系统是明智的。最终，开放市场可以促进充分竞争，以公平的价格向矿工提供最好的产品（例如 Helium HIP19）。

矿工：将硬件作为网络节点运行的实体

成本考虑：

矿工成本，包括硬件、接入、维护和运营（如果适用）费用。与网络相关的时间和注意力成本也很重要。
奖励制度：

搭建物理网络后，矿工会看重奖励方式，计算投资回收期。对测试版的直接激励对旷工很有吸引力，此外，协议也应该遏制疯狂的通货膨胀，纳入强大的通货紧缩设计和质押机制，以确保矿工的长期收入。许多项目都采用了Burn-Mint-Equilibrium(BME)模型。
用户体验：

这个过程应该简单直接，降低参与者的学习曲线，从而实现一个低门槛和可扩展的网络。

协议：网络的协调核心

Price Structure: 价格结构：

商品化服务的价格在协议层面是固定的，而决策应谨慎做出以实现可持续性。以 io.net 的定价模型为例：价格受 web2 竞争对手价格、高峰时段、硬件性能、互联网带宽、加密收益等多维度因素影响。
规则透明度：

奖励机制应该是透明的，公众可以了解。即使在链下，执行的结果也应该是可验证的，并最终使整个过程自动化。链上自动化是最佳选择，可以保证公平性，但它可能会牺牲灵活性来换取持续发展。
数据完整性和真实性：

建立透明可验证的程序，从硬件获取数据，将其上传到数据库，并将其体现在奖励中。
安全措施：

预测恶意行为并实施随机活体检查和有效数据验证等措施。可能涉及 KYC（了解您的客户）流程，并且声誉系统可以奖励诚实行为同时惩罚不诚实行为。
隐私与合规：

从参与者那里收集数据可以提高协议的稳健性和效率，但会带来隐私风险。在只收集必要数据的同时，项目还应考虑实施零知识证明（ZKP）。

运营商：将网络资源打包成服务的实体

运营商实体多样性：

起初，可能由网络基金会中的单一运营商设置冷启动的架构。随着时间的推移，允许更多运营商加入可以扩大市场覆盖范围，最大限度地利用矿工资源，并实现充分竞争。
收入模式：

除了向矿工支付费用，运营商通常会对打包服务收取费用。运营商可以用利润在营销上增加投入，补贴用户等等。

购买者：网络用户

目标和需求：

不同的用户有不同的目标，例如成本效益、节省时间、安全性、可访问性或性能。网络应有效地满足这些基本需求。
用户体验：

无缝的接入和付款流程至关重要。用户是否需要了解加密货币取决于服务设计，但目标应该是简化交易，将法定支付选项与加密货币相结合。

生态系统

DePIN 网络

DePIN 项目差异很大，但是为了更好地理解，我们可以按目的、类型和市场对 DePIN 项目进行分类。

目的

计算：

这包括使用计算系统处理和交流信息。例如，Rollup 解决了区块链的计算挑战，而去中心化的 GPU 和 CPU 资源则满足了链下计算的需求。
存储：

存储项目可确保保留数据以供将来检索和使用。这个更广泛的概念包括Arweave和Filecoin等文件存储解决方案，以及KwilDB等数据库。
网络：

网络项目有助于通过网络获取和传输真实世界的数据，实现不同节点之间的通信并将它们连接到用户。通常，项目利用物联网传感器和无线网络来收集数据并提供服务。

类型

服务网络：服务是核心资产

服务网络的核心是有效利用未使用或可用的资源来提供服务。该协议聚合用户的需求，将其与矿工的资源相匹配，并相应地分配任务。示例包括 io.net，它将 GPU 资源与 AI 公司连接起来; Helium，将小型蜂窝主机与 5G 用户连接起来; Teleport 将司机与乘客联系起来。
数据网络：聚合数据是核心资产

数据网络鼓励数据贡献以积累大型数据集。它们标准化数据格式，确保数据的有效性和质量，并且可能涉及数据清理和训练，然后再将它们包装成数据集、API 或其他格式用于商业用途。例如，DIMO收集车辆数据，以获得对保险或天然气公司有用的见解; Hivemapper 捕获街道图像，为运输和智慧城市项目创建地图数据。

市场

AI 和 ML：

全球 ML 市场规模预计将从 2023 年的 260.3 亿美元增长到 2030 年的 2259.1 亿美元。web3 中的 AI/ML 机会在于数据、计算和模型。在数据方面，像 grass 这样的项目使 AI 公司能够大规模共享带宽，以大规模获取数据;对于计算，与 web2 相比，io.net 等项目以更低的成本汇集数据中心计算能力;对于模型，像 Bittensor 这样的项目支持模型的资产化。
5G：

2023 年全球 5G 市场规模为 843.1 亿美元。向 5G 的过渡需要更多的蜂窝基站，而 web2 垄断企业获得了可观的利润空间。DePIN 5G 项目，如 Helium，旨在通过利用小型蜂窝、免费频段和 eSIM 卡来构建分散的、负担得起的网络。
车辆：

预计 2023 年汽车市场规模将从 1452.4 亿美元增长。DePIN 车辆网络通过专门的硬件和软件收集数据，为保险、维护、天然气和其他业务提供有价值的见解。像 DIMO 这样的项目利用代币激励司机共享数据。
打车：

2023 年全球网约车服务市场价值达到 1766 亿美元。DePIN 网约车服务通过使用代币促进增长、提供公平的定价以及比 Web2 中介机构更低的交易费用，颠覆了网约车市场。著名的项目包括 Teleport 和 Drife。
地图：

2022 年全球数字地图市场规模估计为 181.8 亿美元。DePIN 地图项目通过用代币奖励社区贡献来解决数据碎片化和对主要科技公司的过度依赖，提供公平的数据共享模型。示例包括 Hivemapper、2blox 和 Natix。

区块链和中间件

目前，大多数 DePIN 项目仅将代币置于链上，而大部分功能处于链下状态。自 2023 年 4 月起，Helium 已从其专有的区块链过渡到 Solana。这一转变主要是为了应对维护成本和可扩展性挑战的需求。DePIN 项目的特性，包括小额且频繁的交易以及及时奖励，需要一个快速、成本效益高且可扩展的区块链基础设施。

对于通用区块链，性能、成本和生态系统至关重要：

Solana 的 DePIN 市值约为 $2.4B，已成为 Helium、io.net、Teleport、Hivemappers、Render、Nosana 等重大项目的最受欢迎的选择。Solana 非常符合 DePIN 项目对快速和低成本交易的需求，因为其独特的历史证明（PoH）机制降低了计算负载，并且其高硬件要求提高了处理性能。其次，可扩展性至关重要，例如，Helium 每月需要数百万笔交易，并在迁移到 Solana 时为订阅者铸造了 900k NFT。Solana 需要在高峰期保持稳健，并以较低的价格实现快速大规模铸造。项目可以与其他 Solana 生态系统项目进行交互，Solana 也在升级以更好地满足 DePIN 需求。最近推出的代币扩展支持对 SPL 进行高级定制，例如阈值交易、隐私模式和委托，这将使 DePIN 协议在构建链上组件方面具有更大的灵活性。

另一方面，DePIN 专用区块链正在受到关注。这些区块链解决了数据可信度、身份管理和可验证性等关键问题。通过提供自动化和可验证的数据，DePIN 项目可以节省重复的运营工作，避免风险，并更好地专注于网络开发。

IoTeX 作为 Layer 1 区块链，推出了其 Layer 2 解决方案“W3bstream”，该解决方案可实现安全的物联网数据收集，利用灵活的数据可用性层，将大量链下数据聚合为可验证的零知识证明（ZKP）并触发链上交易。
Peaq 是用于 DePIN 的多链 Layer1 区块链。在低成本、高交易速度的同时，它还提供模块化 DePIN 功能，如多链机器 ID、支付、基于角色的机器访问、三层数据验证、AI 代理、数据存储和索引。Peaq 与 Wormhole 整合流动性，并与博世等相关合作伙伴建立了牢固的关系。Peaq 将于 2024 年推出。

面临挑战 - 为什么不 Work？

监管难度：

在物理领域管理网络需要驾驭无数的法规，可行性和成本因市场而异。例如，叫车项目必须管理差旅数据，遵守当地治理报告要求，并遵守人身安全标准。同样，5G 项目在不同国家/地区也受到不同的许可法规的约束。

Helium 的 LoRa 规范

需求难题：

供给侧的增长并不能保证需求侧的采用。DePIN 项目利用代币来快速激励矿工扩张，接入费用通常再投资以提高网络价值。然而，没有相应用途的供应过剩可能会有问题。为了防止这种情况，确保每个项目真正适合产品市场至关重要。此外，有效的营销、销售策略和业务发展是与大型 Web2 供应商竞争的关键。

DePIN 项目用户，https://dune.com/metalight/dewi-project-users

代币经济矛盾：

DePIN 项目通常从第一天起就有他们的代币，其机制的设计是成功的关键决定因素。然而，这种代币经济学专业知识对源自 Web2 制造商的项目提出了挑战，他们倾向于依赖先例来制定他们的代币策略。有时，他们往往会采取大规模激励措施来吸引参与者，从而导致不可持续的通货膨胀。工作代币模型（Stake for Access）通常用于具有固定协议级服务费用的商品化服务。BME（Burn-Mint-Equilibrium）可以采用双代币系统，将可交易的、寻求价值的代币与与法币挂钩的支付代币相结合，允许为服务提供固定的法币定价。

某著名 DePIN 项目的代币价格

性能注意事项：

中心化具有集中协调、适应性强和高性能等优点。尽管去中心化项目可以以其较低的费用吸引人们的注意力，但与中心化服务的性能相匹配仍然是一个重大的不确定性。以共享 GPU 为例，与数据中心相比，GPU 在不同位置的分布使将它们整合到单个集群中的任务变得复杂，从而导致密集型 ML 应用程序的潜在延迟。如果分散式系统无法实现与集中式服务的性能同等，那么它们的成本优势将不足以提供有竞争力的替代方案。

Akash 仪表板

难以建立护城河：

这一挑战在商品化服务中尤为严重，在商品化服务中，标准化和可互换的产品使供应商和客户都可以轻松切换网络以追求更好的收入或更低的费用。即使在 Web2 业务中，这种缺乏强大护城河的情况也很明显。然而，某些因素可以创造竞争优势：确保先行者地位以建立品牌知名度，提供最佳用户体验，以及开发专有的、受专利保护的软件或硬件。

Helium 5G 与 RedPocket 5G

RUG 售卖叙事：

与其他领域不同，DePIN 参与者（矿工）通常需要最初在硬件上投入大量资金才能开始获得奖励，尽管这可能因用例而异。这带来了潜在的欺诈风险，基金会可能会发布一个有前途的路线图，建立一个叙事，请有影响力的人推广和销售其硬件，然后突然把钱砸掉并消失。

某 Rug 项目的价格趋势

为什么还有机会

你的利润空间就是我的商业机会：

Web2 是 FAT。在当前的 Web2 格局中，亚马逊和 Microsoft 等大公司享有高毛利率。DePINs 可以通过使个人和较小的实体与这些巨头竞争来破坏这种状况。通过利用这一利润空间，DePIN 可以提供更具成本效益的解决方案，削弱老牌企业的高利润模式，并将节省的成本返还给用户。
价值锚定以最小化泡沫：

DePIN 通过硬件设备、服务和数据提供了切实的价值。这种实际的效用充当了稳定因素，锚定了商业模式并缓解了投机泡沫的风险。通过提供现实世界的应用和益处，DePIN 确保了一条稳固和可持续的增长路径。
代币作为业务助推器：
- 初始资金：DePIN 可以从风险投资中筹集大量资金、出售硬件并推出叙事驱动的代币。这笔初始资金启动了业务。
- 增长补贴：利用筹集的资金的一部分来补贴服务费和奖励用户，DePIN 可以迅速扩展其网络，拥有更多的节点和用户，从而培养一个强大而广泛的社区。
- 可持续扩展：虽然硬件覆盖范围有其局限性（例如，覆盖一个区域需要一定数量的热点），但从长远来看，一个完善的网络可以自我维持。一旦初始资金被使用，成熟的网络应该能够自我维持，由其自身的动力和用户群驱动。
社区驱动、自下而上的方法：

通过利用社区驱动的模型，与传统的自上而下的方法相比，DePIN 可以实现更具成本效益和敏捷性的开发。这种草根策略不仅降低了成本，还增强了用户对平台的参与度和投资意愿，创造了一个忠诚和活跃的社区。

评价标准

案例研究

Helium 5G

简而言之，Helium Mobile 正在应对广阔的美国 5G 市场，该市场现已扩展到墨西哥，是 DePIN 领域的先驱和最大的市场之一。它是 Solana、DePIN 和 5G 创新的重要举措。Helium Mobile 提供每月 20 美元的 5G 计划，目前为美国超过 43,000 名用户提供服务。其 BME 方法、通货紧缩代币模型和挂钩法币概念为众多项目开创了先例。

背景：

Helium 是 DePIN 网络的先驱和最大的网络之一，最初于 2019 年推出以应对物联网挑战。通过有效的代币激励，它在短短两年内成为世界上最大的物联网网络，在 182 个国家/地区拥有超过 100,000 个热点。在上一轮牛市的巅峰时期，其 FDV 达到 117 亿美元，彰显其强大实力。尽管物联网需求量存在争议，Helium 仍在继续探索和开发。2022 年，它通过两个子 DAO 进军物联网和移动领域，并开始专注于 5G 热点市场。与 T-Mobile 合作增强了网络可访问性，并在 2023 年迁移到 Solana，巩固了其作为该平台上主要 DePIN 项目的地位。截至 2024 年 1 月，Helium 已部署了 8,000 个 5G 热点，每月拥有超过 43,000 名 5G 用户。
网络：
社区驱动的 5G 服务为什么成为可能？

AT&T、Verizon 和 T-Mobile 等传统 5G 提供商主导着美国无线市场，在频段许可和基础设施方面投入了巨资。然而，DePIN 5G 通过三个关键发展开始崭露头角：eSIM 技术的兴起，允许用户无缝切换到虚拟提供商;CBRS 频段可供公众使用，无需昂贵的许可证;以及个人可以托管的小型蜂窝的出现，在密集部署时提供足够的覆盖范围。
Helium 5G 网络的目标是什么？

考虑到小型蜂窝的覆盖范围有限（仅覆盖 100 码到一英里），完全取代传统的 5G 网络是不可行的。相反，Helium 的 5G 网络旨在作为补充漫游服务，尤其是在人口稠密的地区，以提供更实惠的连接方式。
Helium 网络如何工作？

该网络由五个角色组成：硬件供应商、矿工、网络、运营商和用户。供应商生产和销售 5G 热点，矿工以 1000-2598 美元的价格购买并运营这些热点，为网络覆盖做出贡献。矿工因其积极有效的服务而获得奖励。网络管理这些节点，并将数据价格保持在 0.5 USD/GB。运营商Nova Labs 将这种基础设施打包成一项用户服务，为用户提供每月 20 美元的 5G 订阅计划。
代币：
代币类型：

Helium 使用$HNT 作为代币，用户使用网络需要烧掉$HNT 以获得数据信用（DC），这是一种与美元挂钩的货币。$MOBILE 和$IOT 代币则用来奖励其子 DAO 的参与者。

$HNT 和 BME：

$HNT 的上限为 2.23 亿，每两年减半一次。到 2064 年，使用量最终将减少到每月 1 HNT。为了避免耗尽奖励，Helium 采用了 Burn-and-Mint Equivalence（BME）方法，并确保不会超过最大供应量。用户必须购买$HNT 并将其销毁以获得数据积分（DC）才能使用网络。然后，燃烧的$HNT 被回收到排放池中。为了施加通缩压力，设定了一个上限，确保任何超过净发行量 1%（目前为每天 1644 个）的销毁代币被永久移除。
$HNT 和$MOBILE：

$MOBILE 的价值以$HNT 为基础。$HNT 的每日铸造包括净排放池中的回收量和新排放量，会全部分配给各个参与者。大约 30% 归投资者所有，其余部分根据 DC 消耗、热点数量和 ve-HNT 持有量组合而成的公式在两个子 DAO 之间分配。这种分配机制决定了对 MOBILE DAO 金库的分配，从而影响$MOBILE 的价值。
$MOBILE: $MOBILE：

$MOBILE 直接影响参与者的奖励，最大供应量设定为 2500 亿，每两年减半。每日释放分配如下：20% 给运营商（Nova Labs），4% 给预言机，60% 给硬件供应商和矿工，10% 给地图贡献者（共享位置的用户），3% 给质押者，3% 给运营资金。
理论飞轮效应：

更高的$HNT 价格会提高$MOBILE 的价值，会增加矿工和测绘者的奖励。这鼓励了更多的参与者加入，导致更多的$HNT 被销毁，进一步推高$HNT 的价格，为生态系统的增长和价值创造一个积极的反馈循环。
本质：

虽然投资活动可以显著影响网络估值，但网络的可持续增长从根本上取决于增加用户基数和矿工参与度。
- 用户增长：运营驱动
目前，作为唯一的网络运营商，Helium Mobile 提供每月 20 美元的计划，其中包含大约 43,000 张激活的 SIM 卡，估计每月收入为 860,000 美元（并不精确，因为不包括每月 5 美元的迈阿密计划）。然而，根据链上数据，只有 8%-15% 的收入为网络的收益做出了贡献。假设运营商有足够的资金用于营销和支付 T-Mobile 合作伙伴关系等费用，那么吸引用户的策略包括有吸引力的 20 美元无限制 5G 优惠。此外，他们还推出了创新的激励措施，对分享其位置的用户给与$MOBILE 奖励，该计划的用户参与率为 88%。这些$MOBILE 代币可用于抵扣订阅费用。转介计划是另一种正在使用的策略。
- 矿工增长：受$MOBILE 波动影响
矿工主要关心的是投资回报和奖励。矿工的初始成本，包括硬件购买和设置，从 1,025 美元到 2,624 美元不等。网络里拥有 7,672 个活跃热点，这是矿工产生的重要价值。然而，由于$MOBILE 的波动性，回报波动很大;例如，2023 年 11 月矿工的平均日收入约为 12.47 美元，在 2023 年 12 月随着 Solana 的价值飙升而飙升至 147.63 美元，但随后又有所下降。为吸引更多旷工加入，需提高$MOBILE 的价值，从根本上取决于提升$HNT 的价值，创造购买场景，以及探索其他策略来提振购买需求。

IO.NET AI/ML

概括来说，io.net 瞄准了人工智能机器学习市场，尤其是 GPU 即服务市场。与 AWS 和 Goggle Cloud 等 web2 提供商相比，它的高端 GPU 价格便宜约 82%，并且在 web3 竞争对手中它的 GPU 数量最多，尤其是高端 GPU。它引入了类似于 Helium 的 BME。

背景：

机器学习作为人工智能的基本算法，正在经历显著的市场增长。机器学习训练和推理领域涉及 CPU、ASIC 等计算元素，尤其是 GPU，它们是最基本的资源。然而，大规模机器学习所需的高端 GPU 供应明显短缺。因此，许多 AI/ML 企业，尤其是那些缺乏必要基础设施和专业知识的企业，越来越多地转向云 GPU 服务。这些服务提供了一种既经济又实用的租赁模式，用于运行机器学习任务。
网络：
为什么 web3 云 GPU 服务有用武之地？

“你的利润空间就是我的商业机会”，io.net 的价格为 A100（$0.89/小时），522 RTX 3090（$0.38/小时），301 RTX3080（$0.23/小时），8426 张照片 RTX A6000（$0.75/小时），1988 张照片 RTX，A4000K8S（$0.23/小时）。以 A100 为例，比谷歌 Cloud 便宜 82.45%，比亚马逊 AWS便宜 82.62%。
io.net 的目标是什么？

旨在成为全球最大、最具成本效益的 GPU 云服务商，为 AI/ML 训练/推理提供无限的可扩展性。
io.net 网络是如何运作的？

io.net 聚合未充分利用的资源（如独立数据中心、加密矿工和 Filecoin、Render 等加密项目）的 GPU 来解决成本和可用性问题。GPU 算力会加入 GPU 池，池子按其速度、位置、芯片制造商和型号对 GPU 进行分组，GPU 不仅可以获得实际工作奖励，还可以获得用于推理的空闲奖励。消费者可以在 90 秒内创建一个集群：首先，创建一个自定义 GPU 集群，使用 Sphere 支付，并使用 VSCode 部署 ML 任务，监控执行进度。