返回博客 公告

VCP v1.1：通过三层架构强化外部可验证性

发布VCP v1.1：所有层级强制外部锚定、清晰的三层架构、支持多租户部署的策略标识。

2025年12月26日 阅读时间12分钟 VeritasChain Standards Organization

VCP规范 v1.1 草案发布

与v1.0协议兼容 • 计划于2026年Q1正式发布

目录

执行摘要

今天，我们很高兴宣布VeritasChain Protocol（VCP）规范 v1.1草案的发布。此次更新引入了用于加密完整性的清晰三层架构，将外部锚定设为所有层级的强制要求，并添加了用于多租户部署的策略标识。

主要变更一览

变更内容 影响
三层架构 完整性机制的清晰分离
外部锚定 → 所有层级必需 Silver层级现需每日锚定
PrevHash → 可选 在不牺牲可验证性的情况下简化实现
策略标识 → 必需 支持多层级、多策略部署

VCP v1.1与v1.0协议兼容。现有实现将继续运行，但可能需要更新以获得v1.1 VC-Certified认证。

为什么是v1.1？更新背景

当我们在2025年11月发布VCP v1.0时，主要目标是为算法交易审计追踪建立一个稳健的基础。该规范获得了良好的反响，早期采用者成功地在Silver、Gold和Platinum各层级实现了VCP。

然而，随着我们与社区的交流——包括IETF SCITT工作组参与者、监管顾问和实施团队——一个结构性问题浮现出来。

v1.0中的逻辑不一致

在v1.0中，规范规定：

这在VCP的核心原则"不要信任，要验证"中造成了缺口。

问题在于：Merkle Tree的可信度取决于其根。如果Merkle Root从未被外部锚定，日志生产者理论上可以在事后重建整棵树。没有外部锚定，"不可篡改性"的保证依赖于对生产者的信任——这正是VCP设计要消除的。

解决方案：强制外部锚定

v1.1通过将外部锚定设为所有层级的强制要求来解决这个问题，同时为各层级提供适当的频率和Silver层级实现的轻量级选项。

这不是增加负担——而是确保即使是最简单的VCP部署也能提供监管机构和审计师真正需要的：可外部验证的完整性证明。

三层架构

v1.1中最重要的变化之一是引入了清晰的三层架构来保证完整性和安全性。这种结构阐明了不同加密机制如何协同工作，以及每层保证的来源。

┌─────────────────────────────────────────────────────────────────────┐ │ │ │ 第3层: 外部可验证性 │ │ ───────────────── │ │ 目的: 无需信任生产者即可进行第三方验证 │ │ │ │ 组件: │ │ ├─ 数字签名 (Ed25519/Dilithium): 必需 │ │ ├─ 时间戳 (ISO + int64双格式): 必需 │ │ └─ 外部锚定 (区块链/TSA): 必需 │ │ │ │ 频率: 取决于层级 (10分钟 / 1小时 / 24小时) │ │ │ ├─────────────────────────────────────────────────────────────────────┤ │ │ │ 第2层: 集合完整性 ← 外部可验证性的核心 │ │ ──────────────── │ │ 目的: 证明事件批次的完整性 │ │ │ │ 组件: │ │ ├─ Merkle Tree (RFC 6962): 必需 │ │ ├─ Merkle Root: 必需 │ │ └─ 审计路径 (用于验证): 必需 │ │ │ ├─────────────────────────────────────────────────────────────────────┤ │ │ │ 第1层: 事件完整性 │ │ ────────────── │ │ 目的: 单个事件的完整性 │ │ │ │ 组件: │ │ ├─ EventHash (规范化事件的SHA-256): 必需 │ │ └─ PrevHash (链接到前一事件): 可选 │ │ │ └─────────────────────────────────────────────────────────────────────┘

这种结构为何重要

第1层（事件完整性）确保每个单独的事件是完整且未被修改的。EventHash提供事件内容的指纹。

第2层（集合完整性）证明一批事件是完整的——没有在事后添加、删除或重新排序事件。Merkle Tree结构使得可以高效地验证任何单个事件是否包含在批次中。

第3层（外部可验证性）是VCP实现其核心价值主张的地方。通过将Merkle Root锚定到外部不可变目标（区块链、RFC 3161 TSA或认证数据库），我们创建了日志生产者无法事后修改的证据。

这就是"不要信任，要验证"得以实现的原因。第三方可以独立验证您审计追踪的完整性，而无需信任您。

PrevHash：从必需到可选

我们经常收到一个问题："为什么让哈希链变成可选？这不会削弱安全性吗？"

简短回答：不会。原因如下。

哈希链提供什么

在v1.0中，PrevHash（链接到前一事件哈希）是必需的。这创建了一个哈希链——如果任何事件被修改，所有后续哈希都会变得无效，提供实时篡改检测。

哈希链适用于：

哈希链不提供什么

然而，哈希链有一个限制：控制所有数据的人可以重建它。

如果恶意的日志生产者想要修改一个事件并更新所有后续哈希，只要他们还没有将Merkle Root外部锚定，他们就可以做到。

这就是为什么关键的完整性机制是外部锚定，而不是哈希链。

v1.1的方法

在v1.1中，我们将PrevHash设为可选，因为：

  1. Merkle Tree + 外部锚定提供了外部可验证性的本质保证
  2. 哈希链是补充但不能替代外部锚定
  3. 简化Silver层级实现降低了采用门槛

对监管用例的建议

对于针对监管用例（MiFID II RTS 25、SEC CAT Rule 613）的实现，我们建议启用哈希链。Gold和Platinum层级的实现应将PrevHash视为最佳实践。

策略标识：支持多租户部署

v1.1引入了策略标识作为必需字段。这个看似小的添加对企业部署有重大影响。

问题

在实际部署中，组织通常需要：

没有明确的策略声明，验证者必须猜测哪些规则适用于给定的事件流。

解决方案

每个VCP事件现在都明确声明其合规层级和注册策略：

{
  "PolicyIdentification": {
    "Version": "1.1",
    "PolicyID": "org.veritaschain.prod:hft-system-001",
    "ConformanceTier": "PLATINUM",
    "RegistrationPolicy": {
      "Issuer": "VeritasChain Inc.",
      "PolicyURI": "https://veritaschain.org/policies/prod-hft",
      "EffectiveDate": 1735084800000
    },
    "VerificationDepth": {
      "HashChainValidation": true,
      "MerkleProofRequired": true,
      "ExternalAnchorRequired": true
    }
  }
}

PolicyID命名约定

为确保全球唯一性而无需中央注册表，我们建议使用发行者域名 + 本地ID格式：

PolicyID = <反向域名>:<本地标识符>

示例:
  org.veritaschain.prod:hft-system-001
  com.acme.trading:gold-algo-v2
  jp.co.broker:silver-mt5-bridge

外部锚定：所有层级强制要求

v1.1中影响最大的变化是将外部锚定设为所有层级的强制要求。

各层级要求

层级 频率 锚定目标 证明类型
Platinum 每10分钟 区块链或RFC 3161 TSA 完整Merkle证明
Gold 每1小时 RFC 3161 TSA或认证数据库 Merkle Root + 审计路径
Silver 每24小时 公共时间戳服务或认证数据库 仅Merkle Root

Silver层级：轻量级选项

我们认识到Silver层级服务于开发、测试和非监管交易场景。要求区块链锚定是过度的。

因此，我们明确允许Silver使用轻量级锚定机制：

认证数据库：什么符合条件？

对于Gold和Silver层级，"认证数据库"是可接受的锚定目标。但什么使数据库成为"认证"的呢？

标准 要求
第三方审计 独立机构年度审计
篡改检测 加密完整性检查
访问控制 SOC 2 Type II或同等
保留策略 ≥ 7年
可用性SLA ≥ 99.9%正常运行时间

测试和认证更新

新的关键测试

v1.1引入了实现必须通过才能获得认证的新关键测试：

测试ID 描述
MKL-001 Merkle Tree构建
MKL-002 Merkle证明验证
ANC-001 外部锚定存在
POL-001 策略标识

认证治理提醒

VC-Certified认证由VSO认可的合格评定机构（CAB）颁发，而非直接由VSO颁发。VSO作为方案所有者，负责标准制定和CAB认可。

这种结构确保了标准制定和认证之间的独立性，遵循PCI-DSS、ISO等成熟认证方案建立的模式。

迁移指南

对于现有v1.0实现

VCP v1.1与v1.0协议兼容。您现有的实现将继续工作。但是，要获得v1.1 VC-Certified状态，您可能需要添加：

您的层级 所需变更
Silver 添加外部锚定（每日），添加策略标识
Gold 添加策略标识，验证锚定是否满足要求
Platinum 添加策略标识，验证锚定是否满足要求

宽限期

要求 宽限期 最终期限
外部锚定（Silver） 6个月 2026年6月25日
策略标识 3个月 2026年3月25日

最终期限后，仅v1.0的实现将无法获得新认证的VC-Certified状态。

展望未来：后量子密码学

虽然不是v1.1的规范性要求，但我们添加了附录E：后量子密码学迁移指南，帮助实现为量子时代做准备。

推荐方法：双重签名

在PQC过渡期间，实现可以使用双重签名：

{
  "Security": {
    "Signature": "base64(Ed25519_signature)",
    "SignAlgo": "ED25519",
    "PQCSignature": "base64(Dilithium2_signature)",
    "PQCSignAlgo": "DILITHIUM2"
  }
}

迁移时间线（建议）

阶段 时间 行动
准备 2025-2026 实现双重签名能力
混合 2027-2029 在生产环境部署双重签名
过渡 2030年后 逐步淘汰仅经典签名

结论：不要信任，要验证

VCP v1.1强化了我们对"不要信任，要验证"原则的承诺。

通过将外部锚定设为所有层级的强制要求，我们确保每个VCP部署——从开发者的MT5回测环境到高频交易公司的生产系统——都提供相同的基本保证：

第三方可以验证您审计追踪的完整性，而无需信任您。

这是算法交易所需要的。这是监管机构正在要求的。
这就是VCP v1.1所提供的。

资源

参与方式

我们欢迎对v1.1草案规范的反馈。参与方式如下：

v1.1规范处于草案状态。我们计划在纳入社区反馈后，于2026年Q1最终确定并发布正式版本。

"一个能够在事故发生之前学习的文明。"

本文由VeritasChain Standards Organization（VSO）提供，仅供技术教育目的。

联系方式：info@veritaschain.org

分享本文：

探索VCP资源

了解更多关于VCP及其如何应对监管要求的信息。

阅读规范 试用Explorer 返回博客