已验证操作上的动作流程

绝大多数需要处理数字系统的个人并不太关注从提交项目到确认信息之间发生了什么。你按下一个按钮，事情就会发生，仅此而已。然而，当这以凭证、资格、身份验证、协议、政府记录的形式执行时，中间实际发生的过程就变得非常重要。在 @SignOfficial 下，建立了一个定义明确、正式的流程，接受输入并将其转换为可以独立验证的内容，无需呼叫任何人，无需维护集中式数据库，也不会因为不便而使验证过时。

它始于没有任何数据的状态。在进行任何认证之前，必须首先建立模式（schema）的定义，基本上是信息结构的蓝图，包括信息的类型和形式。将模式视为在签名之前预先定义凭证应具有的样子。KYC 检查、大学学位、合规证书——它们的形状各异，所需字段不同，数据点之间的关系也不同。Schema Registry 是由 $SIGN 提供的这些模板的公共存储库，从而为使用特定模式的认证者提供了一个商定的标准。这使得任何下游第三方都可以读取和写入由此产生的认证内容。

有了模式，认证者、个人、机构或智能合约就可以生成认证。声明的有效性得到确认和认证。SIGN 使用符合注册模式的数字签名结构化数据，并在链上或链下进行安全存储。认证者填写必要的字段，用自己的密钥签名信息（借助数字签名），然后发送。这就是区分认证和纯粹记录的关键。它不仅证明了数据的存在，还证明了某个特定且可识别的方在某个时间点为其背书。

一旦认证被签名，协议会根据大小和用途决定存储位置。较小的认证可以全部存储在链上，以确保最大安全性，而较大的认证则将主要数据存储在链外——如 Arweave 或 IPFS——并与区块链建立加密连接。这是一个重要的设计决策。将所有内容都存储在链上对于政府使用的凭证系统来说成本高昂且不可行。SIGN 能够通过隔离证明锚点和数据主体，避免将所有字节存入加密注册表，从而在数百万个凭证上运行。区块链存储最重要的项目——验证指纹，其余部分存储在非易失性安全存储中。

验证发生在认证创建时，而非之后。称为 ISPHooks 的模式钩子在每次认证功能后被调用，允许在创建点执行其他检查和逻辑。钩子回滚会将整个事务回滚，因此不会捕获到错误数据。这比大多数系统采用的模型更简单。SIGN 在验证时就拒绝无效的认证，而不是事后标记。白名单检查、费用检查、格式检查——这些都在任何操作之前完成。当认证上链时，已经经过了验证。

认证可以被索引，其位置可以通过 SIGN 的索引和浏览层 SignScan 进行搜索。Sign Protocol 提供索引服务，通过 REST 和 GraphQL 接口以及直接使用 NPM SDK，快速找到和访问模式和认证信息。验证者可以是另一个智能合约、政府门户或第三方应用程序，通过其ID检索任何认证，验证签名、验证模式、验证时间戳、确认未被撤销。这一切都无需触及原始发行者。信任由基础设施保障。

这比文档更持久，比数据库记录更真实。它是一个链上托管的流程，包括输入、模式验证、加密签名、存储和最终检索，每个环节都可以追溯，且无需事后由人维护。$SIGN 代币在整个系统中流通，用于处理交易费、推动治理、激励网络运行。

这是真正的端到端验证设计，设计得正确。不是PDF，不是截图，也不是呼叫客服。是一种数字验证、模式约束、加密锚定的数据，随时可以向任何需要审查的方自我证明。