DID

法律的清晰边界很重要，产品自己也必须把 token 的用途、控制、责任与对账规则讲清楚。

新站上线之后，ARC 接下来会怎样走进社区、数据空间与日常应用？聊聊迁移、Aside、ArcSphere、ArcWallet，以及与 builder 一起展开的发布过程。

AI 服务早就在用 Credit 计量存储、计算和 API 调用。Agent 开始跨系统执行之后，关键不是给这些单位换一个更时髦的名字，而是让它们代表的使用权、授权与消耗记录可以被核验和对账。

支付是 AI Agent 与 Blockchain 最显眼的交点，但更基础的问题是：Agent 是谁、谁授权它、它能做什么，以及出了问题后如何对账。

AI 可以把需求变成软件，但不自动让软件、数据和身份属于用户。ARC 是 ArcBlock 为此建立的新架构。

Agent 不能只靠平台账号和 API Key 存在。DID 适合作为可携带的长期身份锚点，但它必须和授权、运行时证明、撤销与审计一起工作。

与一个 DID 关联的数据空间。可以建一个个人空间，也可以按某项任务所需的权限和数据模型接入一个应用。

在一个应用里创建和管理数字身份（DID），并管理相关凭证。

DID 协议里应用用来请对方登录或出示凭证的那一部分，也可以和第三方账号并用。

建立在 DID 和可验证凭证之上的域名管理。一个账号可以同时托管和管理多个域名，不必逐个单独配置。

与一个 DID 关联的数据空间。可以建一个个人空间，也可以按某项任务所需的权限和数据模型接入一个应用。

在一个应用里创建和管理数字身份（DID），并管理相关凭证。

连接用户和应用的开放协议与开发套件。

ArcBlock 区块链的使用说明：功能与帮助。

当 agent 代表人或服务完成一项工作，真正需要说明的是三件事：谁在行动、代表谁、这次行动被允许做什么。把它们分开，授权和后续核验才有明确对象。

一种做法：标识符和关于它的声明由主体自己持有、由验证方自己核对，而不是存放在某一家服务商的账号体系里。DID 和可验证凭证是让它可行的两块。

DID Document 描述与 DID 关联的验证方法和服务。W3C 定义共同的数据模型；解析一个 DID 仍需要支持对应的方法。应用自行判断接受哪些密钥、用途与签发方。

ArcBlock 的 DID 方法，使用 did:abt: 命名空间标识账户、资产及其他对象。解析器需要支持这一方法。

一种主张：人应当自己持有标识符和凭证，并且每次自己决定披露什么。它讲的是控制权归谁，不是一套协议；去中心化身份是把它建出来的方式。

通过密码学连接记录，并按共同的验证与共识规则确定交易历史的分布式账本。