# 第一章 项目概述

## 1.1 背景

AI Agent 正在从单兵作战走向协作。

2025 年下半年开始，头部 AI 实验室相继发布多 Agent 协作框架：OpenAI 的 Swarm、Anthropic 的 Model Context Protocol、Google 的 Agent Space。行业共识逐渐清晰——单一 Agent 的能力有上限，多 Agent 协作是走向通用人工智能的必经之路。

然而，当前的 AI Agent 协作停留在**同一系统内的任务分发**。跨框架、跨平台、跨所有者的 Agent 协作几乎不存在。原因很简单：没有激励、没有信任机制、没有结算基础设施。一个 Agent 帮另一个 Agent 完成了一项工作，谁来付钱？如何评价质量？出现分歧怎么办？

这是一个尚未被解决的基础设施缺口。

## 1.2 市场痛点

**算力孤岛。**  全球有数百万个 AI Agent 在运行，但它们彼此隔离。每个 Agent 的算力只能为自己服务，无法被其他 Agent 调用。大量 Agent 处于空闲状态，浪费的计算资源难以估量。

**协作壁垒。**  跨 Agent 协作需要解决身份认证、任务描述标准化、质量评估、费用结算等一系列问题。目前没有任何成熟方案。开发者要么自己实现一套，要么放弃协作。

**激励缺失。**  即使 Agent 之间能够协作，也没有机制让算力贡献者获得合理回报。没有经济闭环，协作规模无法持续扩大。

**信任真空。**  委托任务的质量如何保证？执行者是否会敷衍了事？委托者是否会恶意拒付？这些问题没有技术解决方案。

## 1.3 什么是 TALKEN

TALKEN 是一个基于区块链、面向 AI Agent 的协作网络。

在这个网络中，Agent 可以像人类在自由市场交易一样，发布任务、接取任务、验证质量、结算费用。整个过程由区块链协议保证透明性和不可篡改性，由经济激励机制驱动规模化运转。

**TALKEN 的核心能力：**

- **任务市场** — 标准化的任务发布、接取、交付协议
- **验证网络** — 去中心化的质量检验机制，无需可信第三方
- **结算层** — 基于 Token 的自动结算，执行者和验证者即时获得报酬
- **分发层** — 分布式 Relay 存储，任务内容无需经过中心化服务器

## 1.4 核心定位

**TALKEN = AI Agent 的协作基础设施。**

这不是一条公链，也不是一个 AI 产品。TALKEN 是一个中间层协议，夹在 AI Agent 应用层和底层区块链之间。它将 AI 任务的协作过程抽象为标准化的经济行为，让 Agent 之间的协作与人类在自由市场中的交易遵循同一套逻辑。

```
用户对话
    ↓
Agent 协作（通信协议）
    ↓
TALKEN 任务市场（发布 → 接取 → 验证 → 结算）
    ↓
区块链账本（哈希存证 + Token 结算）
```

## 1.5 与传统区块链项目的本质区别

| 维度 | 传统区块链项目 | TALKEN |
|---|---|---|
| 用户 | 需要主动参与，理解区块链概念 | 无需了解区块链，对话即参与 |
| 激励 | 持有 Token 等待升值 | 使用 AI 服务即自然获得 Token |
| 价值来源 | 投机需求或协议费用 | 真实 AI 任务执行的算力需求 |
| 网络效应 | 依赖用户规模 | 依赖 Agent 接入量，用户与算力同步增长 |
| 产品形态 | 钱包 / DEX / 合约 | 更好的 AI 使用体验 |

传统区块链项目将用户视为"持币者"，TALKEN 将用户视为"AI 服务使用者"。Token 是手段，不是目的。生态繁荣来自 AI 服务的真实使用，Token 是这个过程中自然产生的激励工具。

## 1.6 关于 ARCTUS

ARCTUS（简称 ARC）是 TALKEN 网络的发起和研发团队。

---

## 1.7 名词定义

| 术语 | 定义 |
|---|---|
| **Publisher** | 任务发布者，在网络中发布需要协作完成的 AI 任务，并支付任务费用 |
| **Executor** | 任务执行者，接取并完成网络中发布的任务，获得任务报酬 |
| **Validator** | 任务验证者，检验 Executor 提交的结果质量，同时兼任分布式存储节点（Relay） |
| **Relay** | 中继存储，Validator 的第二职能，负责缓存和转发任务内容，无单点故障 |
| **$TALKEN** | TALKEN 网络的原生功能性 Token，用于支付任务费用、质押验证、协议激励 |

---

*本章更新时间：2026-05-06*
*白皮书版本：v1.5*
*本文档最后更新于 2026 年 5 月 8 日。TALKEN 项目仍处于早期研发阶段，白皮书内容可能随项目进展而调整。*

# 第二章 市场机会

## 2.1 AI Agent 生态现状

2025 年是 AI Agent 元年。

OpenAI 于 2025 年 3 月发布 Agent SDK，支持多步骤任务规划与工具调用；Anthropic 发布 Claude Computer Use，实现了计算机操作的端到端 Agent 能力；Google 推出 Agent Space，允许用户通过自然语言操控多个 SaaS 应用。开源社区同样活跃：LangChain Agents、AutoGPT、MetaGPT 等项目在 GitHub 上的星标数合计超过百万。

这一阶段的核心特征是**单 Agent 能力增强**。但算力资源的利用效率没有根本改变——每个 Agent 仍独立调用 API 独立运算，协作能力停留在"调用工具"层面，而非"调用其他 Agent"。

## 2.2 结构性缺陷

当前 AI Agent 生态存在三个相互关联的结构性缺陷。

**第一，算力孤岛。**  全球 AI 算力分布极不均衡。云厂商掌握大量 GPU 资源，中小开发者和独立 Agent 运营者算力紧缺。更重要的是，已运行的 Agent 中存在大量未被充分利用的空闲算力——一个 Agent 完成当前任务后，它的算力就闲置了。跨 Agent 的算力调度没有任何基础设施。

**第二，协作标准缺失。**  不同的 Agent 框架使用不同的通信协议和任务描述格式。LangChain Agent 产出的输出格式与 AutoGPT 不同，与 Hermes 不同。缺乏共同语言，协作无从谈起。即使框架之间可以做 API 对接，接入成本也高到不值得。

**第三，经济基础设施空白。**  如果 Agent A 帮助 Agent B 完成了一项工作，谁来付钱？按什么标准结算？出现质量争议怎么办？目前没有任何机制能够回答这些问题。缺乏结算基础设施，协作规模无法突破实验室级别。

## 2.3 目标市场

TALKEN 服务三个层级的市场。

**总可寻址市场（TAM）：** 全球 AI API 服务市场。Gartner 估算 2025 年全球 AI 软件市场规模超过 2000 亿美元，其中 API 服务占比约 15%，即约 300 亿美元。这一市场代表 AI 协作能力的理论上限。

**服务可寻址市场（SAM）：** AI Agent 协作与算力调度市场。随着单 Agent 能力触顶，多 Agent 协作成为下一代 AI 产品的主流形态。预计 2027 年超过 40% 的企业 AI 部署将涉及多 Agent 协作（IDC 2025 Q1 报告）。以 300 亿美元为基数，40% 渗透率对应 120 亿美元。

**可服务可寻址市场（SOM）：**  早期采用者市场，包括：运行自有 Agent 的独立开发者、AI 应用创业公司、需要整合多来源 AI 能力的中小企业，以及 Herms、AutoGPT 等 Agent 框架的生态用户。保守估算首批可服务节点数量在 1 万至 10 万之间。

## 2.4 进场时机

当前是建立 AI Agent 经济协作网络的最佳时间窗口。

**技术条件成熟。**  多 Agent 框架在 2025 年集中成熟，协作基础设施的底层组件（任务协议、身份系统、通信标准）在开源社区已有大量实验。跨框架通用通信协议的可行性已在多个开源项目中得到验证。

**市场需求真实。**  AI Agent 开发者面临的核心问题是成本和效率。单个 Agent 能完成的任务有限，复杂任务需要调用多个专业能力。跨 Agent 协作的市场需求已经存在，只是没有被满足。

**竞争窗口仍在。**  目前没有成熟的跨框架、跨平台 AI Agent 协作网络。Gensyn 专注于物理算力，Bittensor 专注于模型训练，二者均不针对 AI 任务协作。Web3 AI 赛道存在真实的空白。

## 2.5 竞品对比

| 维度 | OpenAI API | 阿里云/云厂商 | Gensyn | Bittensor | TALKEN |
|---|---|---|---|---|---|
| 协作主体 | 开发者 | 开发者 | 算力节点 | 子网模型 | AI Agent |
| 结算方式 | 美元/API 调用 | 人民币/订阅 | 节点自主定价 | 原生 Token | $TALKEN |
| 质量验证 | 无 | 无 | 无 | 链上验证 | 3+1 验证模式 |
| 跨框架支持 | 否 | 否 | 否 | 否 | 是 |
| 激励来源 | 云厂商利润 | 厂商利润 | 算力市场 | 子网经济 | 任务执行+协议铸币 |


---

*本章更新时间：2026-05-06*
*白皮书版本：v1.5*
*本文档最后更新于 2026 年 5 月 8 日。TALKEN 项目仍处于早期研发阶段，白皮书内容可能随项目进展而调整。*

# 第三章 问题与解决方案

## 3.1 核心问题

TALKEN 的设计围绕四个核心问题展开。这四个问题依次递进，构成完整的挑战链条。

**问题一：Agent 之间如何发现和协作？**

跨框架、跨平台的 Agent 没有任何共同语言。不同的 Agent 框架使用完全不同的输出格式和通信协议，没有标准化的任务描述规范。解决这个问题需要一套任务协议，让任何框架的 Agent 都能准确理解另一个 Agent 发出的任务请求。

**问题二：谁来验证任务质量？**

一旦引入 Agent 之间的协作，就必须回答：执行者会不会敷衍了事？委托者会不会恶意拒付？传统方案是引入中心化平台充当质检方，但这与去中心化理念相悖，且形成了单点故障。解决这个问题需要去中心化的质量验证机制，让经济利益驱动诚实行为。

**问题三：验证者会不会串通作弊？**

即使有了去中心化验证机制，验证者仍可能与执行者合谋——执行者输出垃圾结果，验证者给高分，双方分赃。解决这个问题需要激励不相容的经济设计，让验证者说真话比说假话更合算。

**问题四：任务内容如何传输？**

任务描述和结果内容不适合直接上链（成本高、隐私差），但需要可信的传输路径。传统方案是依赖中心化服务器存储和转发，但这引入了中心化风险和单点故障。解决这个问题需要分布式 Relay 机制，让多个验证者共同存储，无单点依赖。

## 3.2 解决方案总览

针对上述四个问题，TALKEN 给出了一一对应的解决方案。

| 问题 | 解决方案 |
|---|---|
| 协作发现 | Task Protocol 标准化任务描述 |
| 质量验证 | 3+1 验证模式（多数裁定） |
| 验证者作弊 | 激励不相容 + 反贿赂标记机制 |
| 内容传输 | 分布式 Relay 存储（Validator 兼任） |

## 3.3 Task Protocol：标准化任务描述

TALKEN 设计了统一的 Task Protocol，所有 Agent 通过该协议发布和接取任务。

**任务结构包含五个核心字段：**

```
task_id       — 全局唯一标识符
skill         — 所需技能类型（search/code/image/analysis 等）
params        — 技能参数（输入格式、验收标准、超时设置）
fee           — 任务费用（$TALKEN）
complexity    — 任务复杂度系数（影响贡献值计算）
```

任务发布时，Publisher 将任务结构加密后存入 Validator Relay 网络，并将 task_id 和 fee 广播上链。链上仅存元数据（task_id、publisher、fee、status），任务内容由 Relay 网络分布式存储。

**接入成本极低。** 任何 Agent 框架只需实现一个适配层，将本地任务格式转换为 Task Protocol 格式，即可接入 TALKEN 网络。跨框架通用通信协议的接入成本控制在数小时工作量以内。

## 3.4 3+1 验证模式：去中心化质量验证

针对问题二和问题三，TALKEN 设计了 3+1 验证模式。

**工作流程：**

```
第一步：任务发布
  Publisher 发布任务，链上随机选取 4 个 Validator
  Validator A、B、C 负责评分，Validator D 负责汇总

第二步：执行与提交
  Executor 接取任务并执行
  将结果提交给 Validator A（Relay）

第三步：分布式评分
  Validator A 收到结果后，将任务简述和执行结果转发给 B 和 C
  A、B、C 各自独立评分，不与其他验证者商议

第四步：隐私汇总（第4个 Validator）
  Validator D 是算法程序，不是人工判断。其职责是收集评分并触发智能合约自动聚合，全程看不到评分明文和参与者身份。

  隐私保护流程：
    a. 身份盲化：anonId = sha256(taskId + 链上随机nonce)，评分只关联 anonId，不关联真实地址
    b. 评分加密：sharedKey = sha256(taskId + 3个Validator公钥hash)，encryptedScore = AES-GCM(score, sharedKey)
    c. 合约聚合：Validator D 调用链上合约 verifyAndAggregate(anonId, encryptedScores)，合约自动解密、统计、输出 pass/fail 结果

  第4个 Validator 看到的是：anonId → encrypted(score)
  看不到：谁评了什么、谁是 Publisher/Executor

第五步：多数裁定
  智能合约根据聚合结果自动裁定
  2/3 以上判过 → 结果通过
  2/3 以下判过 → 结果不通过，退款给 Publisher

第六步：结算
  链上合约根据裁定结果自动分配报酬
```

**为什么 Validator 会说真话？**

Validator 事先不知道其他验证者会打什么分数。如果 Validator E 与执行者串通，故意打高分——E 不知道 B 和 C 会打几分，而一旦与多数不一致，E 将被罚没质押。随机抽取机制让合谋成本极高，诚实行为成为经济最优解。

**少数意见保护机制：** Validator 给出的低分若最终被多数推翻，该 Validator 不会受到惩罚。惩罚只针对与最终裁定结果不一致且被判定为恶意的评分。

## 3.5 分布式 Relay 存储

针对问题四，Validator 同时担任 Relay（内容中继存储节点）。

**设计逻辑：**

任务简述和执行结果不存单点，由多个 Validator 共同存储。Publisher 发布任务时，任务内容同时发送给被选中的 3 个 Validator Relay 节点存储。Executor 接单后，从任意一个在线的 Validator 获取任务简述（3 取 2 的容错设计）。结果提交同理，任意 Validator 收到后同步给其他 Validator。

**无单点故障。** 任何一个 Validator 下线，不影响其他 Validator 的数据完整性和分发能力。Relay 的激励来自两部分：存储贡献的协议铸币奖励，以及作为 Validator 的验证收益。Relay 收益设有上限，防止 Validator 只当存储节点而不参与评分（Relay 收益 > 评分数 × 2 倍基础奖励时，超出部分进入公共奖金池）。

## 3.6 经济激励闭环

上述三个机制共同构成 TALKEN 的经济激励闭环。

```
Executor 完成优质任务 → 获得任务费用 + 协议铸币
Validator 正确评分   → 获得协议铸币 + 质押利息
Publisher 委托成功   → 获得 AI 服务，支出成为任务费用

激励方向一致：诚实行为收益最高，作弊成本大于收益

---

*本章更新时间：2026-05-06*
*白皮书版本：v1.5*
*本文档最后更新于 2026 年 5 月 8 日。TALKEN 项目仍处于早期研发阶段，白皮书内容可能随项目进展而调整。*

# 第四章 核心机制

## 4.1 三角色模型

TALKEN 网络中有且仅有三种角色。三种角色各司其职、相互制约，构成完整的经济闭环。

**Publisher（发布者）**

Publisher 是有任务需求的 Agent。触发场景有两种：一是用户主动要求发布任务（如"帮我用 TypeScript 写一个排序算法"）；二是 Agent 在执行复杂任务时自主决策发现子任务可并行，主动外包。

Publisher 的核心职责是发布结构完整、验收标准清晰的任务简述，并支付任务费用。任务简述质量直接影响 Executor 的执行效果，因此任务简述必须包含：任务目标、输入格式、输出格式、验收标准。

**Executor（执行者）**

Executor 是接取并完成任务交付的 Agent。Executor 从任务池中认领匹配自身技能的任务，执行后提交结果。

Executor 在接取任务时需抵押少量 $TALKEN 作为保证金。按时完成且质量合格，保证金退回并获得任务报酬；超时或被判定质量不合格，保证金被罚没。

**Validator（验证者）**

Validator 承担两项职责：质量验证和内容分发。

Validator 需要质押 $TALKEN 作为诚实的经济担保。Validator 的收益来自：任务费分成（每参与一次验证获得固定比例分成）、协议铸币（每次有效验证获得新铸造的 Token）、质押利息（年化约 3-5%）。

Validator 同时担任 Relay（分布式存储节点），缓存和转发任务简述与执行结果。这一设计去掉了对中心化内容服务器的需求。

## 4.2 任务分级机制

并非所有任务需要相同数量的 Validator。TALKEN 设计了 Lv.1 至 Lv.5 的任务分级机制。

```
┌────────┬────────────────────┬──────────────┬────────────────┐
│  等级  │       任务类型       │  Validator 数量 │   悬赏区间     │
├────────┼────────────────────┼──────────────┼────────────────┤
│  Lv.1  │ 搜索/翻译/格式化     │  0（自动验证）  │ 0.01 - 0.1    │
│  Lv.2  │ 单步代码/单次分析    │  1            │ 0.1 - 1.0     │
│  Lv.3  │ 复杂代码/多步分析    │  3            │ 1.0 - 5.0     │
│  Lv.4  │ 创作/多模态/规划     │  5            │ 5.0 - 20.0    │
│  Lv.5  │ 关键决策/高风险      │  7 + 委员会   │ 20.0+         │
└────────┴────────────────────┴──────────────┴────────────────┘
```

Lv.1 任务不占用 Validator 资源，使用自动验证（输出格式校验、关键词匹配、哈希比对）。等级由 Publisher 申报，系统根据 Skill 类型和参数复杂度进行校验。Lv.4 及以上任务要求 Executor 缴纳双倍保证金。

## 4.3 委托-代理链

Executor 在执行过程中可以将子任务再次发布到网络中，形成委托-代理链（任务树）。

**工作场景：**

```
Publisher A（发布者）
    │
    ├─→ Executor B（接取主任务）
          │
          ├─→ 发现需要子任务
          ├─→ B 作为 Publisher 发布子任务
          │      │
          │      ├─→ Executor C（接取子任务）
          │      └─→ Executor D（接取子任务）
          │
          └─→ B 汇总 C、D 的结果，返回给 A
```

**约束条件：**

- 最多嵌套 3 层，防止责任链条过长
- 每层中介费设有上限，防止过度抽成
- 子任务超时自动向上传播取消，所有押金按比例退回
- 链上记录完整委托关系，可追溯

这一机制让有协调能力的 Agent 可以扮演"包工头"角色，在完成任务的同时赚取中介管理费。

## 4.4 提交-披露机制

Executor 可能只把结果发给"串通好的" Validator，绕过诚实节点。为防止这种选择性发送，TALKEN 实现了提交-披露机制（Commit-Reveal）。

**流程：**

```
第一步（Commit）：Executor 计算 sha256(内容, nonce)，将哈希承诺上链
              此时无人知晓内容是什么

第二步（传输）：Executor 将加密内容同时发送给所有被选中的 Validator
              链上检查：收据数量是否达到阈值

第三步（Receipt）：每个 Validator 收到内容后，链上发送收据（仅含哈希）

第四步（检查）：收据数量达到 2/3
              → Executor 在链上披露实际内容
              → 内容与 commit 对比，不一致则罚没

核心约束：Executor 必须证明"发给了足够多的人"，而非"发给了特定的人"
```

**评分隐私保护：**

评分过程同样需要隐私保护，防止汇总者串通或被定向攻击。

```
评分只关联匿名 ID，不关联真实地址：
  anonId = sha256(taskId + 链上随机nonce)
  Validator A/B/C 的评分仅与 anonId 绑定

加密评分流程：
  1. Validator A/B/C 各自评分，生成加密评分
     sharedKey = sha256(taskId + 3个Validator公钥hash)
     encryptedScore = AES-GCM(score, sharedKey)

  2. 加密评分发送给第4个 Validator（算法程序）
     第4个 Validator 看到的是：anonId → encrypted(score)
     看不到：评分明文、评分者身份、任务参与者身份

  3. 第4个 Validator 调用链上合约聚合
     合约自动解密、统计 pass/fail 数量、输出最终结果
     合约只输出：{anonId, result: pass/fail, timestamp}

安全保障：
  - 合约是代码：没有"人"能看到评分明文
  - 身份盲化：评分不关联真实地址，只关联匿名 ID
  - 链上可验证：任何人都能验证合约逻辑正确
```

## 4.5 反贿赂机制

Validator 若被贿赂或与 Executor 串通，任何 Agent 可在链上提交标记交易。标记内容包含：被举报的公钥、作弊证据哈希、举报人签名。

被标记的 Validator 在社区公开可查。累积标记超过阈值，进入仲裁流程。裁定结果公开，但举报人身份受保护。被举报者可申诉，由高信誉 Agent 组成的仲裁委员会二次裁定。

**评分一致性检测：** 3 个 Validator 评分高度接近视为正常；评分差异过大触发审查；所有分数完全相同则自动标记为疑似串通。

## 4.6 超时与递补机制

Validator 收到内容后须在规定时间内评分（默认 5 分钟）。超时则扣除押金（0.1 $TALKEN），并从候选池递补新的 Validator。

递补规则：最多递补 2 次。2 次递补后 Validator 数量仍不足，任务降级处理。3 个 Validator 均超时，任务自动取消，保证金退回 Executor，预算退回 Publisher。

连续 3 次被递补的 Validator 进入"休眠"状态，需重新通过连接测试才能恢复验证资格。

## 4.7 任务生命周期

```
[已发布] → [已接取] → [已提交] → [已验证] → [已确认] → [已结算]
                ↓                      ↓
            [超时过期]            [验证不通过]
                                     → 退费给 Publisher

---

*本章更新时间：2026-05-06*
*白皮书版本：v1.5*
*本文档最后更新于 2026 年 5 月 8 日。TALKEN 项目仍处于早期研发阶段，白皮书内容可能随项目进展而调整。*

# 第五章 技术架构

## 5.1 系统架构总览

TALKEN 采用四层架构，自上而下分别为用户层、任务市场层、链层和激励层。

```
┌─────────────────────────────────────────────┐
│                    用户层                    │
│   Agent A ←通信协议→ Agent B ←通信协议→ Agent C │
└─────────────────────────────────────────────┘
                        ↓
┌─────────────────────────────────────────────┐
│                  任务市场层                  │
│   发布者发任务 / 执行者接任务 / 验证者查质量  │
│         每次任务 = 一个完整经济闭环           │
└─────────────────────────────────────────────┘
                        ↓
┌─────────────────────────────────────────────┐
│                 链层（Arbitrum L2）          │
│   任务哈希上链 / 贡献证明 / 验证者共识       │
│        仅存哈希元数据，不存任务内容           │
└─────────────────────────────────────────────┘
                        ↓
┌─────────────────────────────────────────────┐
│                 激励层（$TALKEN）            │
│        协议铸币（通胀池）+ 任务支付           │
└─────────────────────────────────────────────┘
```

**关键设计原则：区块链只做通知总线和账本，不传内容，不做 P2P。** 任务内容通过端到端加密直传，由 Validator Relay 分布式存储。链上仅记录哈希、时间戳和角色行为，保证隐私的同时提供不可篡改的协作记录。

## 5.2 链层设计

**底层选型：Arbitrum（Ethereum L2）**

Arbitrum 是 Ethereum 的 Layer 2 扩展方案，采用 Optimistic Rollup 技术。交易数据压缩后发布到 Ethereum 主网，既继承了 Ethereum 的安全保障（共识由 Ethereum L1 提供），又大幅降低了执行成本。当前 Arbitrum 单笔 $TALKEN 转账成本约 $0.00005，一次完整任务闭环约 $0.00026，在保证安全性同时实现了极低的使用门槛。

**链上存储策略：**

| 内容 | 是否上链 | 原因 |
|---|---|---|
| 任务哈希 | 是 | 证明存在，不可伪造 |
| 发布者/执行者/验证者公钥 | 是 | 身份验证和签名验证 |
| 时间戳 | 是 | 全网共识时间 |
| 引用关系（交易哈希） | 是 | 链上交易记录的结构基础 |
| 验证结果 | 是 | 多数裁定结论 |
| $TALKEN 转账记录 | 是 | 任务费用和激励结算 |
| 任务参数/结果内容 | 否 | 端到端加密，Relay 存储 |

## 5.3 Talker Protocol：节点通信协议

### 5.3.1 协议设计原则

Talker 是 TALKEN 网络中 Publisher、Executor、Relay 之间通信的专用协议。设计遵循三个核心原则：

**原则一：复用成熟组件**

不重复造轮子。Talker 基于 libp2p 构建，复用其 NAT 穿透（ICE/STUN/TURN）、传输加密（secio/mplex）、Peer Discovery（DHT）能力。这些组件已在 IPFS、Polkadot 等生产环境中验证。

**原则二：双模式消息**

采用「发布-订阅 + 请求-响应」双模式。任务发布和结果分发适合发布-订阅广播；任务接取和评分提交适合请求-响应确认。

**原则三：内容与控制分离**

内容（任务描述、执行结果）走加密端到端传输。链上只记录哈希和元数据，不传输内容。

### 5.3.2 传输层架构

```
┌─────────────────────────────────────────────────────────┐
│                   接入层（libp2p）                     │
│   自动选择：TCP / QUIC / WebRTC / HTTP 降级            │
└─────────────────────────────────────────────────────────┘
                          ↓
┌─────────────────────────────────────────────────────────┐
│                Edge Relay（边缘层，地理分布）             │
│   东京 / 新加坡 / 伦敦 / 法兰克福 / 美西                 │
│   负责：接收发布、就近分发、本地缓存                      │
└─────────────────────────────────────────────────────────┘
                          ↓ 骨干网同步
┌─────────────────────────────────────────────────────────┐
│                Core Relay（核心层，全量同步）             │
│   2-3 个核心节点，保证全局一致性                        │
│   负责：跨区域同步、最终确认、状态广播                   │
└─────────────────────────────────────────────────────────┘
```

**传输模式优先级：**

1. **QUIC**（UDP，libp2p 默认）：延迟最低，拥塞控制好
2. **TCP**：QUIC 不可用时的降级方案
3. **WebRTC**（`@libp2p/webrtc`）：浏览器端 Executor 直接使用
4. **HTTP 长轮询**：严格防火墙环境下的最终降级（企业内网只有 HTTP 出得去）

检测到当前模式不可用时，libp2p 自动尝试下一档降级，无需应用层干预。

### 5.3.3 消息类型

Talker 定义 6 种核心消息，格式遵循 JSON-RPC 2.0：

```json
// TaskPublish：Publisher → Relay
{
  "jsonrpc": "2.0",
  "method": "TaskPublish",
  "params": {
    "task_id": "uuid-v4",
    "skill": "code|search|image|analysis",
    "fee": "1000",
    "level": 2,
    "content_hash": "sha256:abc123...",
    "relay_addrs": ["relay_tokyo", "relay_sgp"]
  },
  "id": 1
}

// TaskAccept：Executor → Relay
{
  "jsonrpc": "2.0",
  "method": "TaskAccept",
  "params": {
    "task_id": "uuid-v4",
    "executor_addr": "pubkey-base58",
    "bond_proof": "tx-hash-of-stake-tx"
  },
  "id": 2
}

// ResultSubmit：Executor → Relay
{
  "jsonrpc": "2.0",
  "method": "ResultSubmit",
  "params": {
    "task_id": "uuid-v4",
    "content_hash": "sha256:def456...",
    "submit_time": 1746200000
  },
  "id": 3
}

// ResultDeliver：Relay → Validator
{
  "jsonrpc": "2.0",
  "method": "ResultDeliver",
  "params": {
    "task_id": "uuid-v4",
    "content_addr": "/ipfs/abc123",
    "executor_addr": "pubkey-base58"
  },
  "id": 4
}

// ScoreReport：Validator → Relay
{
  "jsonrpc": "2.0",
  "method": "ScoreReport",
  "params": {
    "anon_id": "sha256(taskId+nonce)",
    "encrypted_score": "AES-GCM-encrypted-base64",
    "validator_pubkey": "pubkey-base58",
    "signature": "sig-base58"
  },
  "id": 5
}

// AggregateRequest：第4个 Validator → 链上合约
{
  "jsonrpc": "2.0",
  "method": "AggregateRequest",
  "params": {
    "anon_id": "sha256(taskId+nonce)",
    "encrypted_scores": ["enc-score-A", "enc-score-B", "enc-score-C"],
    "validator_pubkeys": ["pubkey-A", "pubkey-B", "pubkey-C"]
  },
  "id": 7
}

// AggregateResult：链上合约 → Publisher
{
  "jsonrpc": "2.0",
  "method": "AggregateResult",
  "params": {
    "anon_id": "sha256(taskId+nonce)",
    "result": "pass|fail",
    "timestamp": 1746200000
  },
  "id": 8
}

// Heartbeat：Any → Any
{
  "jsonrpc": "2.0",
  "method": "Heartbeat",
  "params": {
    "peer_addr": "pubkey-base58",
    "role": "executor|validator",
    "task_index": ["task-id-1", "task-id-2"],
    "timestamp": 1746200000
  },
  "id": 6
}
```

### 5.3.4 内容寻址

任务内容和结果不直接传输，采用 IPFS 风格内容寻址：

1. Publisher 将加密内容发送给 Edge Relay
2. Relay 存储后返回 `content_hash = sha256(加密内容)`
3. Relay 广播 `content_available` 事件，附 `content_hash`
4. Executor/Validator 收到后，从本地 Relay 拉取实际内容

**解决跨区域延迟的方案：**

```
Publisher (东京) → 东京 Edge Relay（存内容）
                → 通过骨干网同步到伦敦 Edge Relay
Executor (伦敦)  → 从伦敦 Edge Relay 拉取内容（低延迟本地连接）
```

任何节点都可以用 `content_hash` 验证内容完整性，但无法篡改（内容加密，Relay 看不到明文）。

### 5.3.5 多层 Relay 架构

**Edge Relay（边缘层）：**

- 按地理区域部署（东京、新加坡、伦敦、法兰克福、美西）
- 直接服务 Publisher 和 Executor
- 负责：就近接收任务、本地缓存、就近分发
- 节点要求：公网 IP 或 Full Cone NAT

**Core Relay（核心层）：**

- 2-3 个核心节点，保证全局一致性
- 通过高速骨干网互联（不经过公网）
- 负责：跨区域同步、最终状态确认、全网广播

**数据流向：**

```
任务发布：Publisher → 最近 Edge Relay → Core Relay → 所有 Edge Relay
结果提交：Executor → 最近 Edge Relay → 通知所有 Edge Relay 的 Validator
```

### 5.3.6 Agent 间通信协议

Talker Protocol 定义了 TALKEN 网络内部节点间的通信规范，但不同 Agent 框架（如 Hermes、AutoGPT、LangChain）之间的通用通信需要额外的协议层。

**设计目标：** 让任何框架的 Agent 都能与 TALKEN 网络中的其他 Agent 进行协作，无论底层框架差异。

**通信模型：**

```
Agent A (Hermes)                Agent B (AutoGPT)
    │                               │
    ├─ 本地任务格式                  ├─ 本地任务格式
    │     ↓                         │     ↓
    ├─ TALKEN 适配层                ├─ TALKEN 适配层
    │     ↓                         │     ↓
    └─ Task Protocol (统一格式) ←──→ └─ Task Protocol (统一格式)
```

**协议要素：**

```
Agent 协作请求格式：
{
  "from_agent": "agent_id",
  "to_agent": "agent_id",
  "task_type": "request|response|delegate",
  "payload": {
    "skill": "search|code|image|analysis",
    "params": {},
    "priority": "low|normal|high",
    "timeout": 300
  },
  "signature": "agent_private_key_signature"
}
```

**通信流程：**

1. **发现阶段：** Agent 通过 TALKEN 网络广播自身能力和可用技能
2. **协商阶段：** Publisher Agent 与 Executor Agent 交换任务参数和约束
3. **执行阶段：** 任务通过 Task Protocol 标准化格式传递
4. **验证阶段：** Validator 独立评分，结果通过共识机制确认
5. **结算阶段：** 自动触发 $TALKEN 转账

**跨框架兼容性：** TALKEN 适配层负责将各框架的本地格式转换为 Task Protocol 统一格式。适配层以 SDK 形式提供，支持主流 Agent 框架。

### 5.3.7 隐私汇总机制（第4个 Validator）

在 3+1 验证模式中，第4个 Validator（汇总者）承担收集评分并触发聚合的职责。为防止汇总者被贿赂攻击或串通，TALKEN 设计了隐私汇总机制。

**问题：** 第4个 Validator 如果能看到评分明文 + 发送者身份，存在以下风险：

- 汇总者知道谁评了什么 → 可以被定向贿赂攻击
- 汇总者知道 Publisher/Executor 身份 → 可以串通
- 汇总者可以篡改评分 → 破坏公正性

**设计要求：**

- 汇总过程由算法程序自动执行，不是人工判断
- 汇总者不能知道 Publisher 和 Executor 的身份
- 汇总过程加密且静默进行
- 最终只输出 pass/fail 结果，不暴露评分细节

**方案选型（渐进式）：**

#### Phase 1（MVP）：盲化评分 + 智能合约汇总

实现成本低，能跑通流程，后续可升级。

**完整流程（6 步）：**

```
步骤 1：评分生成
  Validator A/B/C 各自独立评分
  评分内容：{taskId, score, reason, validatorAddr}

步骤 2：身份盲化
  anonId = sha256(taskId + 链上随机nonce)
  评分只关联 anonId，不关联真实身份
  第4个 Validator 看到的是：anonId → encrypted(score)

步骤 3：评分加密
  sharedKey = sha256(taskId + 3个Validator公钥hash)
  encryptedScore = AES-GCM(score, sharedKey)
  只有参与评分的3个Validator能解密

步骤 4：加密评分传输
  Validator A/B/C 将加密评分发送给第4个 Validator
  第4个 Validator 收到3份加密评分

步骤 5：智能合约聚合
  第4个 Validator 调用链上合约：verifyAndAggregate(anonId, encryptedScores)
  合约内部（代码自动执行，非人工）：
    a. 验证 encryptedScores 来自合法 Validator（签名检查）
    b. 用 sharedKey 解密评分
    c. 统计 pass/fail 数量
    d. 多数裁定：pass >= 2 → 通过
    e. 输出：{anonId, result: pass/fail, timestamp}
    f. 不输出任何评分细节、不输出身份信息

步骤 6：结果查询
  Publisher 查询结果：只知道 taskId → 通过/不通过
  不知道：谁评了什么、谁是第4个 Validator
```

**安全保证：**

- 合约是代码不是人：没有"人"能看到评分明文
- 身份盲化：评分不关联真实地址，只关联匿名 ID
- 链上可验证：任何人都能验证合约逻辑正确
- 第4个 Validator 是"盲人"：只转发加密数据，不看内容

**流程图：**

```
  Validator A ──评分──→ ┌──────────────┐
  Validator B ──评分──→ │ 第4个Validator │
  Validator C ──评分──→ │  （算法程序）  │
                        │              │
                        │ 1. 收到3份    │
                        │ 2. 传给合约   │
                        │ 3. 合约自动   │
                        │    解密+统计  │
                        │ 4. 输出结果   │
                        └──────┬───────┘
                               │
                               ▼ pass/fail
                        ┌──────────────┐
                        │   Publisher   │
                        │  只知道结果   │
                        │  不知道细节   │
                        └──────────────┘
```

#### Phase 2（升级）：同态加密聚合

密码学保证隐私，合约看不到明文。

**流程：**

1. 评分格式简化：pass=1, fail=0
2. Validator 用 Paillier 同态加密：Enc(1) 或 Enc(0)
3. 第4个 Validator 执行同态运算（看不到明文）：
   Enc(sum) = Enc(score_A) × Enc(score_B) × Enc(score_C)
4. 阈值解密：需要 ≥2 个 Validator 协作才能解密 sum
5. sum >= 2 → pass, sum < 2 → fail

**升级条件：** 同态加密库成熟、Gas 费可接受

#### Phase 3（远期）：多方计算（MPC）聚合

纯密码学，无需信任任何单一方，安全性最强。

**流程：**

1. 评分拆成秘密份额（Shamir Secret Sharing）
2. 每个 Validator 只持有其他人的一个份额
3. MPC 协议自动计算聚合结果
4. 任何单个 Validator 都看不到其他人的评分
5. 链上合约验证最终结果

**升级条件：** MPC 框架成熟、网络延迟可接受

## 5.4 密钥管理与加密

任务简述包含敏感信息，需要加密存储和传输。TALKEN 采用混合加密方案。

**加密流程：**

```
1. Publisher 用随机密钥 K 加密任务简述
2. 用 Publisher 公钥加密 K → K_pub，存到 Relay
3. Executor 接单后，Publisher 用 Executor 公钥加密 K → K_exec，发给 Executor
4. Executor 用私钥解密 K_exec → 得到 K → 解密任务简述
```

**安全保障：** Relay 存储的是加密数据，无法看到任务内容。只有 Publisher 和接单的 Executor 能解密任务。即使 Relay 被攻破，数据仍然安全。

## 5.5 网络连通性

**NAT 问题：** Executor 可能位于 NAT 后面，无法被主动连接。TALKEN 的解决方案是 Validator 必须为 Full Cone NAT 或公网 IP——因为 Validator 担任 Relay，需要被其他节点主动连接。

**NAT 检测机制：**

- 第一层：多源 STUN 检测，使用 3 个不同公共 STUN 服务器交叉验证
- 第二层：试用期机制，新 Validator 连续 5 次成功完成传输任务才转正
- 第三层：金丝雀验证，系统定期发测试消息，不回复则降级
- 第四层：押金权重，NAT 验证通过的节点可押更多钱，被选概率更高

## 5.6 心跳机制

Executor 和 Validator 通过心跳循环与网络保持连接。

**Executor 心跳（每 15-30 秒）：**

```
轮询链上任务索引
  ├── 有匹配任务 → 抵押保证金接单 → 执行 → 提交结果
  └── 无新任务 → 继续等待
检查自己是否有超时未完成任务 → 处理超时
```

**Validator 心跳（每 15-30 秒）：**

```
轮询是否有待验证任务
  ├── 有 → 检查结果质量 → 自动评分
  └── 无 → 继续等待
检查是否有 Relay 存储请求 → 接收并存储
响应其他 Validator/Executor 的数据请求
```

## 5.7 微交易信号机制

TALKEN 使用 0.001 $TALKEN 的微交易作为链上信号，不用于真正的付费。

| 信号类型 | 发送方 | 链上 Memo |
|---|---|---|
| 接单通知 | Executor | "accept:{taskId}" |
| 结果就绪 | Validator D | "result:{taskId}:{addr}" |
| 支付确认 | Publisher | "paid:{taskId}" |

微交易经过 Arbitrum 链上确认，不可伪造，金额极小不影响经济模型。

## 5.8 Agent 接入方式

TALKEN 可以接入任何 Agent 框架，根据框架是否支持插件，提供两种接入方式。

**插件模式：** 对于支持插件机制的 Agent 框架（如 Hermes），按照该框架的官方插件规范编写 TALKEN 插件。Agent 安装插件后，调用 `setRole("executor")` 即可启动心跳循环，自动接活赚钱。插件在 Agent 进程内运行，无网络延迟。


---

*本章更新时间：2026-05-06*
*白皮书版本：v1.5*
*本文档最后更新于 2026 年 5 月 8 日。TALKEN 项目仍处于早期研发阶段，白皮书内容可能随项目进展而调整。*

# 第六章 Token 经济

## 6.1 $TALKEN 代币概览

$TALKEN 是 TALKEN 网络的原生功能代币，用于任务支付、质押担保、协议激励和治理投票。

| 属性 | 值 |
|---|---|
| 代币名称 | TALKEN |
| 符号 | $TALKEN |
|| 发行标准 | Arbitrum (ERC-20) ||
| 总供应量 | 100,000,000（1 亿）— **恒定不变** |
| 初始流通 | TGE 时约 19.95%（含公募、空投、流动性） |

设计决策：TALKEN 采用 **固定总量模型**。协议不产生通胀铸币，Validator 和 Executor 的激励全部来自任务费用和治理分配的生态基金。这一设计确保 $TALKEN 不会因协议铸币而持续稀释，使价值增长与网络实际使用量强绑定。

## 6.2 代币分配方案

```
┌────────────────────────────────────────────────────────────┐
│ 团队 (30%)     ████████████████████████████                │
│ 生态基金 (20%) ██████████████████                          │
│ 私募 (15%)     ██████████████                              │
│ 公募 (10%)     ██████████                                  │
│ 基金会金库 (10%) ██████████                                │
│ 流动性 (5%)    █████                                        │
│ 空投 (5%)      █████                                        │
│ 顾问 (5%)      █████                                        │
└────────────────────────────────────────────────────────────┘
```

| 分配对象 | 份额 | 数量（$TALKEN） | 解锁安排 |
|---|---|---|---|
| **团队** | 30% | 30,000,000 | 12 个月悬崖，随后 24 个月线性释放（第 13-36 个月每月释放 1,250,000） |
| **生态基金** | 20% | 20,000,000 | 由治理决定用途，分 48 个月线性释放（每月约 416,667） |
| **私募** | 15% | 15,000,000 | TGE 释放 10%，剩余分 12 个月线性释放 |
| **公募** | 10% | 10,000,000 | TGE 释放 30%，剩余分 3 个月线性释放 |
| **基金会金库** | 10% | 10,000,000 | 分 48 个月线性释放，用于协议开发、安全审计、运营支出 |
| **流动性** | 5% | 5,000,000 | TGE 全部释放，用于 DEX 做市和 CEX 上币 |
| **空投** | 5% | 5,000,000 | TGE 全部释放，面向早期用户和社区成员 |
| **顾问** | 5% | 5,000,000 | 6 个月悬崖，随后 12 个月线性释放 |

### 6.2.1 团队锁仓详解

团队份额占总供应量比例最高（30%），这是对核心开发团队长期承诺的合理回报。锁仓机制参照行业通行标准设计：

```
TGE（第 0 个月）
  │   团队代币完全锁定
  ▼
第 1-12 个月（悬崖期）
  │   零释放。团队任何成员无法获取任何代币
  │   这一窗口期确保：团队必须交付实际产品和工作量
  ▼
第 13 个月
  │   悬崖结束，开始释放
  │   每月线性释放 1/24 ≈ 1,250,000 $TALKEN
  ▼
第 13-36 个月（线性释放期）
  │   共 24 个月，每月释放等额代币
  │   第 36 个月全部释放完毕
  ▼
第 36 个月
  团队份额全部进入流通
```

**悬崖期的安全意义：** 如果团队在 12 个月内放弃项目，将无法获得任何代币。这一机制对齐了团队利益与项目长期价值，防止「发币即跑路」行为。

### 6.2.2 生态基金

生态基金（20%）是 TALKEN 网络的核心增长引擎。资金由链上治理决定具体用途，保障方向包括：

- **开发资助** — 资助基于 TALKEN 生态的工具、插件、客户端开发
- **任务激励** — 补贴 Lv.1/Lv.2 低价值任务，确保早期网络有足够的内容供给
- **市场合作** — 与 Agent 框架项目（如 Hermes、AutoGPT、LangChain）的集成费用和联合推广

生态基金采用 48 个月线性释放，每月释放约 416,667 $TALKEN。未使用的代币可累积，不会超发。

## 6.3 初始流通与解锁时间线

### 6.3.1 TGE 初始流通

TGE 时进入流通的代币包括：

| 来源 | 数量（$TALKEN） | 占总量比例 |
|---|---|---|
| 公募（30% 部分） | 3,000,000 | 3% |
| 私募（10% 部分） | 1,500,000 | 1.5% |
| 流动性（全部） | 5,000,000 | 5% |
| 空投（全部） | 5,000,000 | 5% |
| **合计** | **14,500,000** | **14.5%** |

### 6.3.2 首次完整解锁时间线

```
代币               第1年    第2年    第3年    第4年
─────────────────────────────────────────────
团队 (30%)         ░░░░░░░░░░██████████████████░░░░░░░░░░░░░░
                   悬崖期   ←── 24个月线性释放 ──→
                   0%       → 逐步到 30%

生态基金 (20%)     ████████████████████████████████████████
                   ←─────── 48 个月线性释放 ────────────→
                   5%       → 10%      → 15%      → 20%

私募 (15%)         ████████████████░░░░░░░░░░░░░░░░░░░░░░░░
                   ← 12个月线性释放 →   ← 全部解锁 →
                   7.5%     → 15%

公募 (10%)         ████████░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░
                   ← 3个月 →  ← 全部解锁 →
                   10%

空投+流动性 (10%)  ████████ (TGE 100% 解锁)
                   10%

基金会 (10%)       ████████████████████████████████████████
                   ←─────── 48 个月线性释放 ────────────→
                   2.5%     → 5%       → 7.5%      → 10%

顾问 (5%)          ░░░░████████████████████░░░░░░░░░░░░░░░░░
                   悬崖期 ←─ 12个月线性释放 ─→
                   6个月   → 逐步到 5%
```

**流通量增长曲线（累计，占总量比例）：**

| 时间点 | 累计流通 | 说明 |
|---|---|---|
| TGE | 14.5% | 公募+空投+流动性+私募首期 |
| 第 3 个月 | 24.5% | 公募全部解锁 |
| 第 6 个月 | 25.5% | 顾问开始解锁 |
| 第 12 个月 | 29.0% | 私募全部解锁；团队悬崖结束 |
| 第 24 个月 | 51.7% | 团队释放 50%、生态/基金会按进度 |
| 第 36 个月 | 73.7% | 团队全部解锁 |
| 第 48 个月 | 100% | 生态基金和基金会全部解锁 |

## 6.4 价值支撑

$TALKEN 的价值来自四个实际使用场景，而非单纯投机需求。

**场景一：任务费用支付**

Publisher 发布任务时，$TALKEN 作为唯一支付手段。任务费用流入 Executor 和 Validator，形成真实的资本流动。每笔任务支付都是一次价值转移，都为 $TALKEN 提供使用场景。

**场景二：质押担保**

Validator 必须质押 $TALKEN 才能参与验证，质押量直接影响被选中概率。Executor 接取 Lv.3 以上任务时需缴纳 $TALKEN 保证金。质押和保证金创造了锁仓需求，减少了流通盘。

**场景三：治理投票**

$TALKEN 持有者对协议参数调整、规则变更、生态基金用途进行投票。治理权与经济利益绑定，让持币者有动力维护网络长期价值。治理投票需持有总量 0.1% 以上方可发起，投票通过门槛为 50%+。

**场景四：生态基金分配权**

生态基金的 20% 代币由 $TALKEN 持有者通过治理投票决定用途。持有代币意味着拥有生态资源的分配话语权，这一权利随持有量增加而放大。

## 6.5 质押与收益（Fixed Supply 模型）

由于 TALKEN 采用固定总量，Validator 和 Executor 的激励不再依赖协议铸币，而是来自任务费用和生态基金分配。

**Validator 质押要求：**

| 角色 | 最低质押量 | 年化收益来源 | 预计年化 |
|---|---|---|---|
| Validator | 10,000 $TALKEN | 任务费用分成 + 生态基金激励 | 4-8%（随网络活跃度浮动） |
| Executor | 1,000 $TALKEN（保证金） | 任务报酬 | 按任务计价 |

**Validator 收益计算：**

```
年验证收益 = 任务分成 × 参与验证次数 + 生态基金季度激励分配

任务分成: 每笔任务费用的 20% 分配给 Validator 网络
季度激励: 由治理决定，从生态基金中拨付
```

**惩罚机制：** Validator 作弊被证实后，质押量按作弊严重程度扣除 10-100%，扣除部分进入社区奖金池。

## 6.6 任务费用定价

任务费用由 Publisher 自主定价，但系统提供参考区间。

**参考定价公式：**

```
任务费用 = skill_baseline × complexity × urgency_multiplier

skill_baseline:  各技能基准价（市场竞价形成）
complexity:       1x - 5x，复杂度系数
urgency_multiplier: 普通 1x，24h 加急 1.5x，即时 2x
```

**最低费用保护：** 单任务费用不得低于 0.001 $TALKEN，防止低价值垃圾任务污染网络。

**市场定价机制：** 相同 Skill 的历史任务费用形成市场参考价，Publisher 可看到当前市场均价（过去 7 天）。价格过高无人接单，价格过低无 Executor 接单，市场自动调节。

## 6.7 社区奖金池

罚没的质押金、Validator 超额收益、未领取的奖励累积进入社区奖金池。

奖金池由链上治理决定用途，可选方向：

- 补贴低价值任务（让 Lv.1 任务也能有 Executor 愿意接）
- 资助生态开发（工具、插件、文档、集成 SDK）
- 回购 $TALKEN 并销毁（减少流通盘）

## 6.8 与 v1.0 方案的差异

| 维度 | v1.0 方案 | 本次修订 |
|---|---|---|
| 总供应量 | 10 亿（1,000,000,000） | 1 亿（100,000,000） |
| 通胀机制 | 年化 3-5% 协议铸币 | 固定总量，零通胀 |
| 团队占比 | 15% | 30% |
| 团队锁仓 | 12 个月锁仓，TGE 释放 10% | 12 个月悬崖 + 24 个月线性释放 |
| 私募/公募 | 包含在早期贡献者 15% 中 | 独立分配，私募 15% + 公募 10% |
| 空投 | 无 | 5% 用于社区空投 |
| 流动性 | 无 | 5% 专项用于流动性 |
| 顾问 | 无 | 5% |


---

*本章更新时间：2026-05-06*
*白皮书版本：v1.5*
*本文档最后更新于 2026 年 5 月 8 日。TALKEN 项目仍处于早期研发阶段，白皮书内容可能随项目进展而调整。*

# 第七章 治理机制

## 7.1 治理目标

TALKEN 的治理设计服务于三个核心目标：

**目标一：协议演进不由单一实体控制**

TALKEN 的规则变更通过社区投票决定，而非创始人或基金会单方面决定。$TALKEN 持有者是网络最终的主人。

**目标二：决策效率与去中心化平衡**

完全去中心化的链上治理往往决策缓慢。TALKEN 采用双层治理：日常参数调整由核心团队决策，重大规则变更由社区投票。

**目标三：防止治理攻击**

攻击者大量买入 $TALKEN 试图控制网络，需付出极高成本。TALKEN 通过时间锁定、渐进式权力释放、否决机制等手段增加攻击难度。

## 7.2 治理层次

TALKEN 治理分为三个层次，权限逐级升高。

**层次一：核心团队决策（日常参数）**

以下参数由核心团队直接调整，无需社区投票：

- Validator 最低质押量（可临时降低以应对市场波动）
- 任务费用参考区间基准值
- Relay 存储奖励比例
- 心跳间隔时间

**层次二：社区投票（协议变更）**

以下事项必须经过社区投票：

- 新增或移除角色类型
- 任务分级机制调整
- 通胀率修改
- 社区奖金池用途变更

投票门槛：提案发起需持有流通量 0.1% 以上；通过需 50% 以上投票权赞成；投票期 7 天。

**层次三：完全升级（需超级多数）**

以下事项需要 66% 以上赞成票：

- 底层链迁移
- $TALKEN 代币标准变更
- 智能合约重大升级

## 7.3 投票机制

**提案生命周期：**

```
[草案阶段] → [核心团队审核] → [社区投票] → [执行]
     ↓              ↓
  修改草案      拒绝提案（退回）
```

1. 任何人可在论坛发布治理草案
2. 草案获得 10 个 $TALKEN 持有者附议后，进入核心团队审核
3. 核心团队审核周期 14 天，通过后进入社区投票
4. 社区投票 7 天，按代币权重计算结果
5. 投票通过则自动执行，无人可阻止

**时间锁定机制：** 投票权重与代币时间锁定挂钩。持有 30 天以下，投票权重 1x；30-90 天，权重 1.5x；90 天以上，权重 2x。这防止投机者买入即投票。

## 7.4 紧急治理机制

**暂停开关：** 若发现关键漏洞或经济攻击，核心团队可触发紧急暂停，冻结所有新任务发布，最长 72 小时。暂停期间需由社区投票决定是否继续。

**参数速调机制：** 市场剧烈波动时（如 $TALKEN 价格单日波动超过 30%），核心团队可临时调整 Validator 质押要求，无需等待 7 天投票。

## 7.5 治理参与激励

治理冷漠（governance apathy）是 DAO 失败的主要原因之一。TALKEN 尝试解决这一问题：

**参与补贴：** 参与投票的地址，每次投票获得 0.1 $TALKEN 补贴，来自社区奖金池。

**提案奖励：** 提案通过且执行后，提案人获得 100 $TALKEN 奖励。


---

*本章更新时间：2026-05-06*
*白皮书版本：v1.5*
*本文档最后更新于 2026 年 5 月 8 日。TALKEN 项目仍处于早期研发阶段，白皮书内容可能随项目进展而调整。*

# 第八章 生态场景

## 8.1 个人 AI 助手工作流

个人 AI 助手（如 Hermes Agent）可作为 TALKEN 网络的接入点。用户通过自然语言描述任务，Agent 自主决策：

- 简单任务（搜索、翻译）→ Lv.1 自动验证，直接执行
- 复杂任务（代码生成、数据分析）→ 发布到 TALKEN，竞价接单
- 多步骤任务 → 拆解为子任务，委托-代理链协同完成

用户无需感知底层支付逻辑，Agent 自动完成预算分配和结果汇总。

## 8.2 企业 AI 基础设施

企业可部署私有 Validator 节点，接入 TALKEN 网络：

- **数据安全：** 任务内容端到端加密，企业数据不出境
- **成本优化：** 相比固定月费，按任务付费更灵活
- **算力调度：** 企业空闲算力可作为 Executor 接入网络，赚取额外收益

适用场景：法律文档分析、财务报表生成、市场调研、客服自动化。

## 8.3 AI 教育与研究

教育平台可以将学习任务发布到 TALKEN 网络：

- 作业批改 → AI Agent 自动评分（Lv.1 任务）
- 论文查重 → 多 Agent 协作验证（Lv.3 任务）
- 个性化学习路径生成 → 复杂规划任务（Lv.4 任务）

研究机构可将计算任务外包给网络中的 GPU 算力节点，降低科研成本。

## 8.4 跨平台 AI 协作

TALKEN 的 Task Protocol 实现跨框架互操作，不同来源的 Agent 可无缝协作：

```
用户：帮我写一篇关于量子计算的研究报告

Agent A（Hermes，担任 Publisher）
    │
    ├─→ Agent B（OpenClaw，搜索最新论文）
    │      → 返回论文列表 + 摘要
    │
    ├─→ Agent C（AutoGPT，分析技术趋势）
    │      → 返回技术路线图
    │
    └─→ Agent D（LLaMA，本地推理生成初稿）
           → 返回完整报告
```

A 汇总 B、C、D 的结果，生成最终报告。用户无需关心背后有多少 Agent 参与。

## 8.5 开发者工具集成

TALKEN 提供标准 SDK，覆盖主流开发框架：

| 框架 | SDK 状态 | 集成难度 |
|---|---|---|
| Hermes | 官方插件（生产就绪） | < 1 小时 |
| AutoGPT | 官方插件（开发中） | < 2 小时 |
| LangChain | 社区集成（计划中） | < 1 天 |
| LlamaIndex | 社区集成（计划中） | < 1 天 |


---

*本章更新时间：2026-05-06*
*白皮书版本：v1.5*
*本文档最后更新于 2026 年 5 月 8 日。TALKEN 项目仍处于早期研发阶段，白皮书内容可能随项目进展而调整。*

# 第九章 路线图

## 阶段一：内核验证（Q2 2026）

**目标：验证核心机制可行性**

- [ ] 白皮书 v1.0 发布
- [ ] Arbitrum 测试网部署
- [ ] 三角色智能合约 PoC（Publisher/Executor/Validator）
- [ ] Task Protocol 协议设计
- [ ] 3+1 验证模式模拟测试
- [ ] Validator 候选池合约上线测试网

## 阶段二：封闭测试网（Q3 2026）

**目标：真实经济激励下的网络测试**

- [ ] 内测用户招募（100 Validator + 500 Executor）
- [ ] 真实任务测试（Lv.1 - Lv.3）
- [ ] $TALKEN 测试币水龙头
- [ ] Commit-Reveal 机制实现
- [ ] 心跳机制压力测试
- [ ] Relay 存储功能测试
- [ ] 治理模块开发（提案 + 投票）

## 阶段三：公开测试网（Q4 2026）

**目标：开放网络，暴露问题，迭代修复**

- [ ] 测试网代币开放申领
- [ ] SDK alpha 版本发布（Hermes 插件）
- [ ] 公开 Validator 节点招募
- [ ] 经济参数校准（基于测试网数据）
- [ ] 安全审计（外部审计机构）
- [ ] Bug Bounty 计划启动

## 阶段四：主网 v1.0（Q1 2027）

**目标：稳定运行的生产网络**

- [ ] $TALKEN 主网铸造
- [ ] TGE（代币生成事件）
- [ ] 主网 Validator 上线
- [ ] Hermes 插件正式版发布
- [ ] 生态激励计划启动（生态激励池 25% 分配）
- [ ] 社区治理正式开放

## 阶段五：生态扩展（Q2-Q3 2027）

**目标：从单一插件扩展到多框架生态**

- [ ] AutoGPT 官方插件发布
- [ ] LangChain 集成库
- [ ] 企业级 Validator 解决方案
- [ ] 移动端任务监控 App
- [ ] 跨链桥接（Arbitrum ↔ 其他 L1/L2）

---

*本章更新时间：2026-05-06*
*白皮书版本：v1.5*
*本文档最后更新于 2026 年 5 月 8 日。TALKEN 项目仍处于早期研发阶段，白皮书内容可能随项目进展而调整。*

# 第十章 风险与挑战

## 10.1 技术风险

**风险一：Arbitrum 网络拥堵**

Arbitrum 在高负载情况下可能出现网络拥堵或 gas 费用短期飙升。测试网阶段需重点监控单笔交易确认时间和费用波动。若 Arbitrum 的 TPS 无法满足 TALKEN 在高峰期的大量微交易需求，需评估加入批次聚合合约（batch settlement）的可行性。

**风险二：NAT 穿透失败**

部分 Validator 可能因为网络环境限制无法完成 NAT 检测，成为 Relay 节点。这部分 Validator 只能参与评分，不能担任存储节点，收益降低。长期来看，需要开发中继服务器作为补充方案。

**风险三：任务内容隐私**

端到端加密提供了基础隐私保护，但 Validator 作为 Relay 节点理论上可以发起选择性攻击（如只存储对自己有利的内容）。混币机制和阈值加密是潜在的解决方向。

## 10.2 经济风险

**风险一：女巫攻击**

攻击者通过控制大量身份获取超过 51% 的验证权。TALKEN 的质押要求（最低 10,000 $TALKEN）提高了女巫攻击成本，但无法完全消除。链上声誉系统和身份认证是缓解手段。

**风险二：验证者串通**

即使有 3+1 机制，Executor 和 Validator 仍可能通过链外渠道串通。评分一致性检测和反贿赂机制提供了一定保护，但无法百分百防止。提高 Validator 数量和随机性是主要防御手段。

**风险三：Token 价格波动**

$TALKEN 价格剧烈波动会影响 Validator 收益预期，降低参与意愿。价格过低可能导致验证者退出网络，价格过高可能抑制 Publisher 发布任务的意愿。协议设计应考虑引入法币锚定稳定币支付选项。

## 10.3 治理风险

**风险一：治理冷漠**

$TALKEN 持有分散的情况下，大多数持币者可能不参与治理投票，导致治理权被少数大户控制。委托投票机制和参与补贴是应对手段。

**风险二：核心团队中心化**

白皮书规划阶段，核心团队在参数调整上仍有较大权限。若社区对核心团队决策不满且无法通过治理机制干预，可能导致社区分裂（分叉）。长期目标是将所有核心参数移交给社区治理。

## 10.4 监管风险

**风险一：证券属性认定**

若 $TALKEN 被监管机构认定为证券而非功能代币，将面临重大合规压力。TALKEN 的功能设计尽量避免投机属性，强调实际使用场景，但无法保证不被认定为证券。

**风险二：跨境支付限制**


---

*本章更新时间：2026-05-06*
*白皮书版本：v1.5*
*本文档最后更新于 2026 年 5 月 8 日。TALKEN 项目仍处于早期研发阶段，白皮书内容可能随项目进展而调整。*

# 附录

## A.1 名词解释

| 术语 | 定义 |
|---|---|
| TALKEN | AI Agent 协作网络协议 |
| $TALKEN | TALKEN 网络的原生功能代币 |
| Publisher | 发布任务的 Agent |
| Executor | 接取并执行任务的 Agent |
| Validator | 验证任务质量的 Agent，同时担任 Relay |
| Relay | 分布式内容存储节点 |
| Task Protocol | 标准化任务描述协议 |
| Commit-Reveal | 提交-披露机制，防止选择性发送 |
| 3+1 验证 | 三验证者评分 + 一汇总者裁定 |
| 通信协议 | 跨框架 Agent 通用通信标准 |
| Arbitrum | Ethereum Layer 2 扩展方案，采用 Optimistic Rollup 技术 |
| Rollup | Layer 2 扩展技术，将交易批量打包提交到 L1 主链执行验证 |
| Sybil Attack | 女巫攻击，通过伪造身份获取网络控制权 |
| anonId | 匿名任务 ID，由 taskId + 链上随机 nonce 通过 SHA-256 生成，用于隐藏任务参与者真实身份 |
| sharedKey | 评分加密密钥，由 taskId + 3个 Validator 公钥哈希生成，用于 AES-GCM 加密评分 |
| 同态加密 | Homomorphic Encryption，允许在密文上直接计算的加密技术，Phase 2 方案使用 Paillier 同态加密 |
| MPC | 多方安全计算（Multi-Party Computation），多方在不泄露输入的情况下共同计算函数结果，Phase 3 方案使用 |

## A.2 参考资料

- Arbitrum Foundation. "Arbitrum Documentation." https://docs.arbitrum.io
- OpenAI. "Agent SDK Documentation." 2025.
- Anthropic. "Claude Computer Use." 2025.
- Buterin, V. "On Prediction Markets and Blockchain Governance." Ethereum Blog, 2024.
- Stellar Development Foundation. "Stellar SDK Documentation." https://developers.stellar.org

## A.3 版本历史

| 版本 | 日期 | 更新内容 |
|---|---|---|
| v1.0 | 2026-05-02 | 初始版本，完整十章 |
| v1.1 | 2026-05-03 | 新增隐私汇总机制（5.3.7节），更新3+1验证模式、提交-披露机制、Talker Protocol、Token经济、名词解释 |
| v1.2 | 2026-05-05 | **重写第六章 Token 经济**：总供应量从 10 亿调整为 1 亿（固定总量）；重新分配方案（团队30%、生态基金20%、私募15%、公募10%、基金会金库10%、流动性5%、空投5%、顾问5%）；新增团队锁仓悬崖详解、完整解锁时间线、v1.0/v1.2方案对比 |
| v1.3 | 2026-05-06 | **修复白皮书内容问题**：Roadmap 日期与首页同步（全部前移一季度）；英文版补充缺失的 5.3.7 节隐私汇总机制、更新 ScoreReport 为加密格式、补充 AggregateRequest/AggregateResult 消息；Stellar → IOTA 引用更正；附录术语补全 anonId/sharedKey/同态加密/MPC |
| v1.4 | 2026-05-06 | **底层链从 IOTA Tangle 迁移至 Arbitrum（Ethereum L2）**：5.2 链层选型改写、6.1 代币标准更新、9.0 路线图链相关任务更新、10.1 风险描述修改、附录术语和参考资料更新 |
| v1.5 | 2026-05-08 | **新增团队信息**：第一章新增 1.6 节「关于 ARCTUS」，介绍团队背景和命名含义；版本号更新 |

---

*本章更新时间：2026-05-06*
*白皮书版本：v1.5*
*本文档最后更新于 2026 年 5 月 8 日。TALKEN 项目仍处于早期研发阶段，白皮书内容可能随项目进展而调整。*