返回博客
VCP v1.2 PRD
技术 EU AI Act MiFID II 后量子

VCP v1.2 — 公开评审草案即将发布:实施者预览

什么在变化,什么保持不变,以及今天您可以准备什么。VCP v1.2是v1.1的词汇扩展 — 密码学基础不变,无事件格式破坏性变更,所有v1.0/v1.1锚点在v1.2验证工具下仍然有效。

2026年5月7日 21分钟阅读 VeritasChain Standards Organization
45
天评审期
5
新CORE字段
5
监管配置文件
0
破坏性变更
继续之前需要了解的五件事
  1. VCP v1.2是v1.1的词汇扩展。密码学基础 — COSE_Sign1、RFC 6962 Merkle、RFC 8785 JCS、RFC 3161 / eIDAS / SCITT外部锚定 — 不变。无事件格式破坏性变更。
  2. 所有v1.0和v1.1锚点在v1.2验证工具下仍然有效。历史事件无需重新发行、重新签名或重新锚定。
  3. 所有新的v1.2字段在v1.2.0中以OPTIONAL状态引入。升级到SHOULD和MUST的升级棘轮与目标版本一起提前发布。
  4. 两个v1.1硬性截止日期保持不变。Policy Identification强制日期2026年3月25日(已生效),Silver-tier外部锚定强制日期2026年6月25日。
  5. 这是预发布公告。PRD将于本周在github.com/veritaschain/vcp-spec开放。公开评审将持续45天。

v1.2是什么 — 以及不是什么

VCP v1.1(规范日期2025年12月30日,公开发布2026年1月1日)将协议从"防篡改证据"重新定位为"第三方可验证性 + 完整性保证"。三个承诺支撑它:三层架构(Event / Collection / External Integrity)、全层级外部锚定和强制性Policy Identification。这些承诺在v1.2中不变地继承。

v1.2添加了什么(一句话)

EU AI Act第12/19/26/72条、ESMA 2026年2月算法交易监管简报以及ESMA Q&A 2825/2826期望在审计追踪中看到的词汇。不引入新的密码学原语。不破坏任何现有事件。不移动任何截止日期。

更细致地说:v1.1事件通过v1.2验证器仍然验证成功。缺少新可选字段的v1.2事件仍然验证成功。需要特殊处理的v1.2事件类别只有携带ed25519+mldsa65混合签名的事件 — 即使这在v1.2.0中也定位为MAY。

模式级别变更:字节级别之旅

CORE模块

CORE是每个合规部署中唯一必需的模块。v1.2扩展在v1.1模式之上添加了五个字段,在v1.2.0中全部为可选:

与v1.1事件在语义上无法区分的最小v1.2.0事件:

{
  "vcp_version": "1.2",
  "event_id":    "0196a98b-4980-7abc-8123-4567890def01",
  "event_type":  "trade.order",
  "issuer_id":   "did:web:example-firm.eu",
  "policy_id":   "example-policy-2026-01",
  "issued_at":   "2026-05-07T09:00:00.000Z",
  "payload_hash":"a1b2…",
  "hash_alg":    "sha-256",
  "sig_alg":     "ed25519",
  "signature":   "MEUCI…",
  "external_anchor": {
    "anchor_type":  "RFC3161",
    "anchor_value": "MIICk…",
    "anchor_time":  "2026-05-07T09:00:05Z"
  }
}

仅将vcp_version常量从"1.1"更新为"1.2"的现有v1.1发射器,在regulatory_profile = NONE配置文件下产生合规的v1.2.0事件。对于最简单的迁移路径,不需要进一步的代码更改。

监管配置文件选择器

监管配置文件是v1.2的核心运营添加。它声明部署打算可读的规则手册。

含义 触发的义务
NONE 无特定监管映射 仅v1.1基线
AI_ACT_HRAI 根据Reg (EU) 2024/1689的高风险AI Art. 12(1)–(2) MUST; Art. 12(3)条件性; PMM Manifest SHOULD; ClockEvidence SHOULD
MIFID_ALGO 根据MiFID II Art. 4(1)(39)的算法交易 RTS 6 GOV字段MUST; PTCSnapshot SHOULD; ClockEvidence MUST
MIFID_HFT 高频算法交易 所有MIFID_ALGO加上: Platinum层级MUST; PTPv2 ClockEvidence MUST
MIXED_FINANCIAL_AI AI Act高风险和MiFID均适用 以上的联合

暂定值(不用于生产认证):US_BD_RECORDSFINRA_MARGINCFTC_DCMEIOPA_INSURANCE_AIJFSA_AI_DP。这些可能在GA之前重命名、合并或撤回。

ClockEvidence结构

clock_evidence对象是ESMA Q&A 2825(2026年4月1日)和Commission Delegated Regulation (EU) 2025/1155 Annex IV时间戳期望的运营化。

{
  "clock_evidence": {
    "utc_source":     "PTP-grandmaster:dc1",
    "offset_us":      12.4,
    "max_error_us":   38.0,
    "holdover_state": "LOCKED",
    "sync_method":    "PTPv2_LOCKED",
    "last_sync_at":   "2026-05-07T08:59:55Z",
    "clock_state":    "NOMINAL",
    "attestation_ref":"https://example-firm.eu/clock/2026-05-07.json"
  }
}

层级义务:

新的证据通道

五个证据通道是v1.1和v1.2之间运营差异在审计时实际显现的地方:

1. gov.change_event

运营化ESMA监管简报的六类重大变更分类法。在变更在生产环境中生效之前发出。类别:logic_changeexecution_behaviorrisk_control_changeexternal_dependency_changeadaptive_retrainingscope_change

2. trade.ptc_snapshot和trade.ptc_breach

RTS 6第13条要求从事算法交易的投资公司维护交易前控制。ptc_snapshot记录控制的状态;ptc_breach记录控制触发时发生了什么。

3. gov.provider_dependency

记录运营商对第三方依赖项的尽职调查。dependency_kindMARKET_DATAEXECUTION_ALGORISK_ENGINEMODEL_HOSTINGCLOUD_INFRAMCP_TOOL_PROVIDER

4. gov.pmm_manifest

AI Act第72条要求对高风险AI系统进行上市后监控。PMM Manifest是一个指针和哈希包,让监管者验证运营商在评审时认为他们拥有的证据。

5. recovery.*事件类型

五种标准化恢复事件:recovery.policyrecovery.outage_public_noticerecovery.outage_ctp_noticerecovery.clock_degradedrecovery.data_feed_switchrecovery.model_retrainedrecovery.integrity_test

后量子签名路径

v1.2的密码学添加是将ed25519+mldsa65作为规范混合SignAlgo标识符进行预留。线格式遵循draft-ietf-lamps-pq-composite-sigs-06:经典Ed25519(RFC 8032)和ML-DSA-65(FIPS 204 Level 3)。

版本 验证混合 发出混合
v1.2.0(本PRD) 所有层级MAY 所有层级MAY;注册表预留ed25519+mldsa65
v1.2.1(2027年Q1目标) Platinum MUST,Gold SHOULD Platinum SHOULD,Gold和Silver MAY
v1.3.0 Platinum MUST,Gold MUST Platinum MUST,Gold SHOULD

这对今天的实施者意味着什么:

监管证据包

v1.2的结构性创新是监管证据包(REB) — 一个打包契约,让运营商能够按需交付一套自包含的工件集,审计员或监管者可以独立验证。

管理REB的三条规范性规则
  • 可复现性。两个独立的组装器,给定相同的期间、范围和源账本,必须产生相同的内容哈希。
  • 配置文件特定的最小值。每个监管配置文件都有最小组件集。
  • 签名。REB必须由发行运营商签名,应由运营商的合规职能共同签名。

迁移:从v1.1到v1.2

对于大多数v1.1部署,迁移到v1.2.0是一行代码的更改。

  1. 步骤1 — 升级协议版本常量。"vcp_version": "1.1"更改为"vcp_version": "1.2"
  2. 步骤2 — 选择监管配置文件。如果不知道哪个配置文件适用,设置regulatory_profile: "NONE"
  3. 步骤3 — 如果您的层级或配置文件需要,填充clock_evidence
  4. 步骤4 — 在您的运营需要时发出新的证据通道。
  5. 步骤5 — 按需组装REB。
您不需要做的事情
  • 重新发行、重新签名或重新锚定v1.0或v1.1事件。它们在v1.2验证工具下仍然有效。
  • 在v1.2.0中迁移到混合签名。ed25519+mldsa65的预留是前瞻性定位,不是v1.2.0的要求。
  • 采用每个暂定监管配置文件。它们保留用于社区评论,可能会更改。

诚实的范围界定:VCP v1.2仍然不做什么

如何参与公开评审

公开评审与本周的PRD发布一起开放,持续45天

提交评论的地方:github.com/veritaschain/vcp-spec的GitHub Issues,使用公开评审评论模板。

我们从实施者那里寻求的内容:

安全发现:私下报告给security@veritaschain.org。90天负责任披露时间线。

资源

PRD开放后(本周):

引用的监管参考:

文档ID:VSO-BLOG-VCP-V12-PRD-2026-001-ZH

版本:1.0

发布日期:2026年5月7日

组织:VeritasChain Standards Organization · 日本东京

联系方式:info@veritaschain.org | standards@veritaschain.org | technical@veritaschain.org

许可证:CC BY 4.0 International

"Verify, Don't Trust"

日本金融科技协会会员 · D-U-N-S: 698368529