背景：Blockfrost 发生了什么

2026 年 6 月 26 日，Blockfrost 团队向 Cardano 链上治理提交了一笔 Treasury 提款提案，请求 9,832,979 ADA（约 983 万 ADA），用于将其托管基础设施过渡为社区治理的非营利组织，并继续运营免费公开 API。

此前 Blockfrost 曾提交过一个更庞大的提案（合并了 Project Cayley 去中心化索引架构），未获足够的治理支持。本次提案范围收窄，仅聚焦于所有权移交、服务延续和社区监督。

提案的关键时间线：

Charles Hoskinson 明确表态：无论提案结果如何，IOG 对 Blockfrost 的所有权和运营责任都将在 2026 年底结束。如果提案通过，Blockfrost 将有序移交社区非营利组织，API 继续运行；如果提案被拒，Blockfrost 将逐步关停其 hosted API 服务。

"关停 Hosted API"具体意味着什么

Blockfrost 提供的不是"一条 API"而是三层服务：

1. Cardano 数据查询层——通过 REST API 查询区块、交易、地址、UTxO、原生资产、质押信息等。这是最常见的用法。
2. 交易提交层——通过 submit API 向链上提交交易。钱包和 dApp 依赖这个功能将用户交易广播到网络。
3. IPFS/Filecoin 网关——存储和检索 IPFS 数据（主要与 NFT 元数据相关）。

关停的顺序和影响：

• Free / Hobby / Developer / Enterprise 所有 tier 逐步下线，Starter tier 曾标注"till hell freezes over"但实际为 marketing 措辞，不受承诺保护
• 依赖 Blockfrost 的钱包（如 Eternl、Typhoon、Flint）和 dApp 前端需要紧急切换数据源
• Cardano 主网约 50% 以上的交易流量经过 Blockfrost 的 submit API（根据 Hoskinson 的陈述），关停后这部分流量需要被其他 submit API 承载
• 对于 SPO 的出块操作本身无影响（SPO 直接运行 cardano-node，不依赖 Blockfrost），但依赖 Blockfrost 的周边工具和查询脚本会失效

如果提案通过会怎样

即使提案通过，过渡也需要时间：

在过渡期间，Blockfrost 承诺保持 99% 月度正常运行时间。过渡结束后，新设的非营利组织将继续运营一个免费的公共 API，不设付费 tier。

换句话说：最好的情况下，你在 2027 年 Q1 之前需要迁移。最坏的情况下，你现在就需要迁移。

Koios 是什么

Koios（发音 /ˈkɔɪ.ɒs/，源自古希腊语 Κοιος，意为"提问、探究"，也是泰坦神族的智慧之神）是一个去中心化、弹性、完全开源的 Cardano 区块链 REST API 查询层。

项目始于 2021 年，由 Guild Operators（Cardano 社区最资深的 SPO 工具开发者群体）创建和维护。采用 MIT 开源协议，核心代码、SQL 查询、API 规范、测试套件全部托管于 GitHub。

一句话概括：Blockfrost 能查的数据 Koios 都能查，而且不需要 API Key，没有单点故障，不会被关停。

设计目标

Koios 的设计围绕四个原则：

弹性（Elastic） ——任何人都可以运行自己的实例，也可以选择加入公共集群。节点越多，集群越强。不像传统中心化 API 那样，用户增加 = 供应商成本增加 = 涨价或限流。

去中心化（Decentralized） ——没有单一实体控制 API 层。即使 Koios DAO 明天解散，所有已部署的开源代码和数据库 schema 仍然存在，任何人都可以继续运行。

开放标准（Open Standards） ——所有 SQL 查询、端点定义、测试用例公开。开发者可以审查每一个端点返回的数据是否准确，也可以提交改进。

低门槛（Low Barrier） ——公共端不需要注册、不需要 API Key、不需要 gas 费。5,000 次/天免费额度对个人工具和原型开发完全够用。

架构深度解析

Koios 完整节点（称为 gRest）是一个五层堆栈。理解这五层有助于你判断：你需要在哪一层介入。

                                    ┌──────────────────────────────┐
                                    │      HAProxy (端口 8053)      │ ← 暴露层
                                    │  负载均衡 / 健康检查 / SSL    │
                                    └──────────┬───────────────────┘
                                               │
                                    ┌──────────▼───────────────────┐
                                    │     PostgREST (端口 8050)     │ ← 接口层
                                    │   SQL → JSON RESTful API     │
                                    └──────────┬───────────────────┘
                                               │
                                    ┌──────────▼───────────────────┐
                                    │    PostgreSQL (端口 5432)      │ ← 存储层
                                    │  规范化的索引数据 + 缓存表     │
                                    └──────────┬───────────────────┘
                                               │
                                    ┌──────────▼───────────────────┐
                                    │  cardano-db-sync              │ ← 解析层
                                    │ 链上数据 → 关系型数据库        │
                                    └──────────┬───────────────────┘
                                               │
                                    ┌──────────▼───────────────────┐
                                    │   cardano-node (端口 6000)    │ ← 基底层
                                    │   P2P 同步、验证、存储         │
                                    └──────────────────────────────┘

第 1 层：Cardano Node（基底层）

就是标准的 cardano-node 进程，通过 P2P 网络同步完整的 Cardano 区块链数据。如果你已经是 SPO，你这层已经跑着，不需要额外配置。

关键配置点：

• 拓扑文件（topology.json）配置 peer 连接
• 数据库路径（--database-path）建议放在 SSD 上
• 需要启用 --socket-path 供 db-sync 连接

第 2 层：DBSync（解析层）

cardano-db-sync 进程持续读取 cardano-node 的链上数据，将其解析并写入 PostgreSQL。这是整个堆栈中最消耗资源的部分。

数据覆盖范围：

• 区块头、区块体、交易
• 输入/输出（UTxO）
• 地址、质押地址
• 原生资产（Native Assets）——包括 NFT
• Plutus 脚本和 datum
• 池注册、更新、退休
• 委托操作
• 奖励和 MIR
• 治理操作

全量同步耗时（主网）：

• 从 0 开始：约 24-48 小时（取决于硬件和网络）
• 持续同步：基本实时，滞后通常 < 10 秒

第 3 层：PostgreSQL（存储层）

存储 db-sync 写入的原始数据，外加 Koios 自定义的缓存表和物化视图。这是 Koios 性能优化的核心——预计算耗时查询（如池的活跃质押量、地址资产余额），避免每次请求都扫描全表。

关键表（非完整列表）：

Koios 额外创建的缓存表（以 grekoios schema 存储）：

• grekoios.account_info_cache——质押地址缓存信息
• grekoios.epoch_active_stake_cache——每个 epoch 的活跃质押量
• grekoios.pool_history_cache——池历史汇总
• grekoios.asset_registry_cache——代币注册表元数据

第 4 层：PostgREST（接口层）

PostgREST 是一个工具：它读取 PostgreSQL 数据库 schema，自动为每个表/视图生成 RESTful 端点。Koios 团队编写了专门的 SQL 函数（RPC），映射到每个 API 端点。

例如，account_info 端点的背后是一个 PostgreSQL 函数：

CREATE FUNCTION grekoios.api_account_info(_stake_addresses text[])
RETURNS TABLE (
    stake_address text,
    status text,
    delegated_pool text,
    total_balance numeric,
    utxo_balance numeric,
    rewards_available numeric,
    ...
) LANGUAGE plpgsql STABLE
AS $$
    -- 复杂的多表 JOIN 和聚合查询
$$;

PostgREST 将这个函数暴露为 POST /rpc/account_info（在 Koios 中路由为 POST /api/v0/account_info）。

这种设计的优势：

• 查询逻辑完全透明——所有 SQL 在 GitHub 上公开可审查
• 性能可预测——每个端点的查询计划（query plan）固定
• 扩展方便——社区成员可直接贡献新的 SQL 函数

第 5 层：HAProxy（暴露层）

HAProxy 作为反向代理，提供：

• TLS 终止——将外部 HTTPS 请求转换为内部 HTTP
• 健康检查——定期检查后端 postgREST 是否响应、数据是否最新（通过对比 tip 时间戳）
• 负载均衡——在多实例集群下分发请求
• 速率限制——根据 tier 级别控制请求频率
• DDoS 防护——尖峰流量时的请求排队和丢弃策略

健康检查的核心逻辑：HAProxy 定期调用 /tip 端点，检查返回的 block_no 是否在可接受的时间窗口内（通常 < 60 秒）。如果某个实例落后太多，HAProxy 自动将其从集群中移除，直到它重新追上。

与 Blockfrost 的详细对比

通用维度

API 能力维度

数据一致性维度

API 端点逐一详解

以下按功能类别列出每个端点及其典型用途、请求示例和响应字段说明。

账户（Account）

GET /api/v0/account_list

获取所有至少有一笔交易的质押地址列表。通常在需要遍历所有活跃账户时使用。

请求参数：

• ?order=asc——排序方向
• ?limit=1000——每页数量

响应示例（精简）：

[
  {"stake_address": "stake1u9...", "first_tx_time": 1623456789},
  {"stake_address": "stake1ux...", "first_tx_time": 1623456790}
]

POST /api/v0/account_info

查询一个或多个质押地址的完整信息。这是最常用的端点之一。

请求体：

{
  "_stake_addresses": [
    "stake1u9fzv...",
    "stake1uxp3..."
  ]
}

响应字段：

GET /api/v0/account_utxos

查询给定质押地址下的所有 UTxO。

请求参数：?stake_address=stake1u9...

过滤参数：

• &order=desc——按交易时间降序
• &limit=50——每页 50 条
• &offset=0——偏移量

响应字段：

POST /api/v0/account_assets

查询质押地址持有的所有原生资产（含 NFT）。如果你需要查某个地址下有哪些 NFT，就是用这个端点。

请求体：

{
  "_stake_addresses": ["stake1u9fzv..."]
}

响应字段：

POST /api/v0/account_rewards

查询质押地址的奖励历史（含 MIR）。

请求体：

{
  "_stake_addresses": ["stake1u9fzv..."]
}

过滤参数：?epoch_no=500（指定 epoch）

响应字段：

POST /api/v0/account_updates

查询质押地址的变更历史：注册、注销、委托更新、提现。

请求体：

{
  "_stake_addresses": ["stake1u9fzv..."]
}

响应字段：

POST /api/v0/account_history

查询质押地址在每个 epoch 的委托状态和余额历史。

请求体：

{
  "_stake_addresses": ["stake1u9fzv..."]
}

响应字段：

地址（Address）

POST /api/v0/address_info

查询一个或多个地址的详细信息。

请求体：

{
  "_addresses": ["addr1qx...", "addr1qy..."]
}

响应字段：

POST /api/v0/address_txs

查询地址的交易历史（可选指定起始区块高度）。

请求体：

{
  "_addresses": ["addr1qx..."],
  "_after_block_height": 9000000
}

响应字段：

POST /api/v0/address_assets

查询地址持有的所有原生资产。如果你需要在非质押地址（如合约地址）下查资产，用这个而不是 account_assets。

请求体：

{
  "_addresses": ["addr1qx..."]
}

响应： 每个资产的 policy_id、asset_name、quantity。

资产 / NFT（Asset）

GET /api/v0/asset_list

获取所有已铸造的原生资产分页列表。数据量极大（主网已超过 1,000 万种资产），通常配合搜索使用。

过滤参数：

• ?policy_id=...——按 policy 过滤
• ?asset_name=...——按名称过滤（hex）

POST /api/v0/asset_info

批量查询资产的详细信息。查 NFT 元数据（metadata、name、description、image URL 等）就用这个端点。

请求体：

{
  "_asset_list": [
    "policy_id_hex.asset_name_hex",
    "policy_id_hex.asset_name_hex"
  ]
}

响应字段：

GET /api/v0/asset_history

查询资产的铸造（mint）和销毁（burn）历史。

请求参数：?asset_policy=policy_id_hex&asset_name=asset_name_hex

响应字段：

GET /api/v0/asset_addresses

查询持有某资产的所有地址。注意：对于高交易量的资产（如热门 NFT 项目），数据量极大，公共层可能超时。

GET /api/v0/policy_asset_info | policy_asset_list | policy_asset_addresses

这三组端点与资产类似，但作用域是一个 policy ID 下的所有资产。适合查"同一个 NFT 集合下的所有资产"。

交易（Transaction）

POST /api/v0/tx_info

批量查询交易详情。这是 Koios 相对 Blockfrost 的核心优势之一——一次查多条交易。

请求体：

{
  "_tx_hashes": [
    "abc123...",
    "def456..."
  ]
}

响应字段（每个交易）：

GET /api/v0/tx_utxos

查询交易的 UTxO 详情。

响应与 tx_info 的输出类似，但展开为每输入/输出一条记录。

POST /api/v0/tx_status

查询交易是否在链上被确认。

请求体：

{
  "_tx_hashes": ["abc123..."]
}

响应：

池（Pool）

GET /api/v0/pool_list

所有当前注册或正在退休（未完成退休）的池列表。

过滤参数：?status=registered（或 retiring）

POST /api/v0/pool_info

查询一个或多个池的详细信息。SPO 查自己或其他池的数据，这是最主要的端点之一。

请求体：

{
  "_pool_bech32_ids": ["pool1..." , "pool1..."]
}

响应字段：

GET /api/v0/pool_stake_snapshot

获取池的 Mark、Set、Go 三个快照点数据。这对 SPO 计算 leaderlog（出块概率）极其关键。

请求参数：?pool_bech32=pool1...

响应：

GET /api/v0/pool_delegators

查池的所有委托人和各自的质押量。

请求参数：?pool_bech32=pool1...

响应：

GET /api/v0/pool_blocks

查池的出块记录。

请求参数：?pool_bech32=pool1...&epoch_no=500

响应：

GET /api/v0/pool_history

查池的历史数据：每个 epoch 的委托量、奖励、费用。

响应：

POST /api/v0/pool_metadata

查池的链上元数据（名称、描述、网站、logo URL 等）。

请求体：

{
  "_pool_bech32_ids": ["pool1..."]
}

响应：

Epoch & 网络

GET /api/v0/epoch_info

查 epoch 信息。可选指定 epoch 编号，不指定则返回当前 epoch。

请求参数：?epoch_no=500

响应：

GET /api/v0/tip

查链的当前尖端——最新区块号、哈希和 slot。

响应：

脚本（Script）

POST /api/v0/datum_info

查询 datum 信息。对 Plutus 智能合约开发者有用。

请求体：

{
  "_datum_hashes": ["hash1..."]
}

从 Blockfrost 迁移：逐端点的具体对照

curl 示例对照

查询地址详情

Blockfrost（GET + API Key）：

curl -H "project_id: mainnetXXX" \
  "https://cardano-mainnet.blockfrost.io/api/v0/addresses/addr1qx..."

Koios（POST，无需认证）：

curl -X POST "https://api.koios.rest/api/v0/address_info" \
  -H "Content-Type: application/json" \
  -d '{"_addresses": ["addr1qx..."]}'

查询地址 UTxO

Blockfrost：

curl -H "project_id: mainnetXXX" \
  "https://cardano-mainnet.blockfrost.io/api/v0/addresses/addr1qx.../utxos"

Koios：

curl -X GET "https://api.koios.rest/api/v0/account_utxos?stake_address=stake1u9..."

查询资产/NFT 信息

Blockfrost：

curl -H "project_id: mainnetXXX" \
  "https://cardano-mainnet.blockfrost.io/api/v0/assets/policy_id_hexasset_name_hex"

Koios（批量查）：

curl -X POST "https://api.koios.rest/api/v0/asset_info" \
  -H "Content-Type: application/json" \
  -d '{"_asset_list": ["policy_id_hex.asset_name_hex"]}'

查询池详情

Blockfrost：

curl -H "project_id: mainnetXXX" \
  "https://cardano-mainnet.blockfrost.io/api/v0/pools/pool1..."

Koios：

curl -X POST "https://api.koios.rest/api/v0/pool_info" \
  -H "Content-Type: application/json" \
  -d '{"_pool_bech32_ids": ["pool1..."]}'

查询池委托人

Blockfrost：

curl -H "project_id: mainnetXXX" \
  "https://cardano-mainnet.blockfrost.io/api/v0/pools/pool1.../delegators"

Koios：

curl -X GET "https://api.koios.rest/api/v0/pool_delegators?pool_bech32=pool1..."

关键迁移注意事项

1. 认证从 header 改为无 — 移除所有 project_id header
2. 路径模式变化 — Blockfrost 用路径参数（/pools/{pool_id}），Koios 用 POST body（{_pool_bech32_ids: [...]}）或 query 参数
3. 批量查询利用 — Blockfrost 逐条查的地方，Koios 可以合并为一次 POST 批量查，大幅减少请求次数
4. 返回字段名不同 — 例如 Blockfrost 的 amount 在 Koios 中可能是 total_balance，需要对照 API 文档逐个映射
5. 分页方式 — Blockfrost 使用 cursor 分页（page/page_total），Koios 使用标准 limit/offset 分页
6. 速率控制 — 公共层 100 请求/10 秒，如果现有代码在 Blockfrost 上用量较高，迁移后需要调整请求间隔

费率层级详解

对 SPO 而言：

• 个人查询和监控脚本：Public 层（5,000 次/天）绰绰有余
• 池网站/工具产品化：注册 Free 层（50,000 次/天），0 成本
• 高流量商业应用：Pro 或 Premium 层

注：API token 在主网和测试网之间分开计数，但 Preview 和 Preprod 共享额度。

SPO 工具生态

前面提到 Koios 的核心维护者就是 Guild Operators 社区。这个社区不只是做 API，Cardano SPO 日常运营的核心工具全部来自他们。

CNTools

功能覆盖：

CNTools 底层已经集成了 Koios 查询层。如果你之前用的是 CNTools，你已经在间接使用 Koios。

gLiveView

运行方式：

# 启动交互界面
./gLiveView.sh

# 一次输出
./gLiveView.sh -o

实时显示数据面板：

┌─────────────────────────────────────────────────────────┐
│ Cardano Node Live View - Mainnet                        │
├─────────────────────────────────────────────────────────┤
│ Synced          : 99.98%    Tip             : 11234567  │
│ Block           : 11234567  Slot            : 98765432  │
│ Epoch           : 512       SlotInEpoch     : 345678    │
│ Forks           : 0         Seconds         : 0.3s      │
│ Mem (RSS)       : 2.4GB     Peers (In/Out)  : 3/8      │
│ Disk            : 98.3GB    Uptime          : 47d 12h   │
│ Version         : 10.1.3    Protocol        : Conway    │
└─────────────────────────────────────────────────────────┘

其他 Guild Operators 工具

所有这些工具都不依赖 Blockfrost。它们通过 cardano-node 的本地 Unix socket 或 Koios API 获取数据。

自建实例：分步指南

如果你决定跑自己的实例，有两种部署方式：

方式一：Guild Operators 一键脚本（推荐）

# 1. 安装 guild-operators 脚本库
git clone https://github.com/cardano-community/guild-operators.git
cd guild-operators
./prereqs.sh

# 2. 运行 gRest 部署脚本
./setup-grest.sh -f -i prmcd -q -b main

参数说明：

• -f：完整安装（所有组件）
• -i prmcd：安装模式（PostgreSQL + PostgREST + HAProxy + 监控 + 自定义端点）
• -q：静默安装
• -b main：分支名

脚本会自动：

• 安装和配置 PostgreSQL 14+
• 部署 PostgREST
• 配置 HAProxy
• 创建 Koios schema 和 RPC 函数
• 设置 systemd 服务
• 安装 Prometheus 指标导出器

方式二：Docker 部署

# PostgreSQL
docker run -d --name koios-postgres \
  -e POSTGRES_PASSWORD=secret \
  -v koios-pg-data:/var/lib/postgresql/data \
  postgres:14

# cardano-node + db-sync（通过 docker-compose 管理）
# 参考 https://github.com/input-output-hk/cardano-db-sync

# PostgREST（连接已有 PG）
docker run -d --name koios-postgrest \
  -e PGRST_DB_URI=postgres://user:pass@host:5432/cexplorer \
  -e PGRST_DB_SCHEMA=grekoios \
  -e PGRST_DB_ANON_ROLE=grekoios_anon \
  -p 8050:3000 \
  postgrest/postgrest

硬件建议

加入公共集群

自建实例后，如果你愿意分享资源给社区：

1. 在 koios-artifacts/topology 提交 PR，提供你的节点连接信息
2. 向监控实例开放 Prometheus Exporter 端口（8059）、HAProxy 端口（8053）和 Submit API 端口（8090）
3. 跟进版本发布（通常周六 UTC 8:00，有变更日志预告）
4. HAProxy 的健康检查会自动检测你的节点状态，通过后流量开始分发到你的实例

社区与治理

组织结构

Koios 由 Koios DAO 治理，不隶属于任何公司。治理结构：

• 核心开发者：Guild Operators 的核心成员，负责代码审查、版本发布、架构决策
• 实例提供者：运行 Koios 节点并加入公共集群的 SPO 和机构
• DAO 参与者：持有治理 token 的社区成员（通过委托投票影响决策）

核心开发者来源于 Cardano 社区中最资深的贡献者——他们运营着自己的质押池，日常使用自己写的工具，有切身利益确保代码质量。

透明度

• 所有代码：GitHub 公开
• 开发进度：GitHub Project Board
• 实例状态：公共 Grafana 仪表板（显示每个节点的同步状态、延迟、健康度）
• 会议记录：双周公开会议（每月第 2 和第 4 个周四），讨论内容发布在 Telegram

如何参与

沟通渠道

总结：你现在应该做什么

优先级检查清单

最终一张表

开始迁移：koios.rest | API 文档：api.koios.rest | GitHub：cardano-community/koios-artifacts