ブログ一覧へ戻る アナウンス

VCP v1.1：三層アーキテクチャによる外部検証可能性の強化

全ティアで必須となるExternal Anchoring、明確な三層アーキテクチャ、マルチテナント展開向けのPolicy Identificationを含むVCP v1.1を発表。

2025年12月26日 12分で読めます VeritasChain Standards Organization

VCP仕様 v1.1 ドラフト版リリース

v1.0とプロトコル互換 • 2026年Q1に正式版リリース予定

目次

エグゼクティブサマリー

本日、VeritasChain Protocol（VCP）仕様 v1.1のドラフト版リリースを発表いたします。このアップデートでは、暗号学的完全性のための明確な三層アーキテクチャを導入し、External Anchoringを全ティアで必須とし、マルチテナント展開向けのPolicy Identificationを追加しています。

主要な変更点

変更内容 影響
三層アーキテクチャ 完全性メカニズムの明確な分離
External Anchor → 全ティアでREQUIRED Silverティアでも日次アンカリングが必須に
PrevHash → OPTIONAL 検証可能性を損なわずに実装を簡素化
Policy Identification → REQUIRED マルチティア・マルチポリシー展開が可能に

VCP v1.1はv1.0とプロトコル互換です。既存の実装は引き続き動作しますが、v1.1 VC-Certified認証を取得するには一部アップデートが必要になる場合があります。

なぜv1.1なのか？アップデートの背景

2025年11月にVCP v1.0をリリースした際、私たちの主な目標はアルゴリズム取引監査証跡の堅固な基盤を確立することでした。仕様は好評を博し、初期導入者はSilver、Gold、Platinumの各ティアでVCPを正常に実装しました。

しかし、IETF SCITT Working Groupの参加者、規制コンサルタント、実装チームを含むコミュニティとの対話を通じて、構造的な課題が浮かび上がってきました。

v1.0における論理的不整合

v1.0では、仕様に以下のように記載されていました：

これはVCPの核心原則である「信じるな、検証せよ」にギャップを生み出していました。

問題はこうです：Merkle Treeはそのルートの信頼性に依存します。Merkle Rootが一度も外部にアンカリングされなければ、ログ生成者が事後的にツリー全体を再構築することが理論上可能です。External Anchoringなしでは、「改ざん不可能性」の保証は生成者への信頼に依存していました—これはまさにVCPが排除しようとしていたものです。

解決策：必須のExternal Anchoring

v1.1では、External Anchoringを全ティアでREQUIREDとすることでこの問題を解決しました。各ティアに適切な頻度と、Silverティア実装向けの軽量オプションを用意しています。

これは負担を増やすことではありません。最もシンプルなVCP展開であっても、規制当局や監査人が本当に必要としているもの—外部から検証可能な完全性の証明—を提供することを確実にするためです。

三層アーキテクチャ

v1.1における最も重要な変更の一つは、完全性とセキュリティのための明確な三層アーキテクチャの導入です。この構造は、異なる暗号メカニズムがどのように連携し、各層の保証がどこから生まれるかを明確にします。

┌─────────────────────────────────────────────────────────────────────┐ │ │ │ 層3: 外部検証可能性 │ │ ───────────────────── │ │ 目的: 生成者を信頼せずに第三者が検証可能 │ │ │ │ コンポーネント: │ │ ├─ デジタル署名 (Ed25519/Dilithium): REQUIRED │ │ ├─ タイムスタンプ (ISO + int64デュアルフォーマット): REQUIRED │ │ └─ External Anchor (ブロックチェーン/TSA): REQUIRED │ │ │ │ 頻度: ティア依存 (10分 / 1時間 / 24時間) │ │ │ ├─────────────────────────────────────────────────────────────────────┤ │ │ │ 層2: コレクション完全性 ← 外部検証可能性の核心 │ │ ──────────────────────── │ │ 目的: イベントバッチの完全性を証明 │ │ │ │ コンポーネント: │ │ ├─ Merkle Tree (RFC 6962): REQUIRED │ │ ├─ Merkle Root: REQUIRED │ │ └─ 監査パス (検証用): REQUIRED │ │ │ ├─────────────────────────────────────────────────────────────────────┤ │ │ │ 層1: イベント完全性 │ │ ──────────────── │ │ 目的: 個々のイベントの完全性 │ │ │ │ コンポーネント: │ │ ├─ EventHash (正規化イベントのSHA-256): REQUIRED │ │ └─ PrevHash (前イベントへのリンク): OPTIONAL │ │ │ └─────────────────────────────────────────────────────────────────────┘

この構造が重要な理由

層1（イベント完全性）は、各イベントが完全で未改変であることを保証します。EventHashはイベント内容のフィンガープリントを提供します。

層2（コレクション完全性）は、イベントのバッチが完全であること—事後にイベントが追加、削除、または並べ替えられていないこと—を証明します。Merkle Tree構造により、バッチ内の任意のイベントの包含を効率的に検証できます。

層3（外部検証可能性）は、VCPがその核心的価値を提供する場所です。Merkle Rootを外部の不変ターゲット（ブロックチェーン、RFC 3161 TSA、または認証済みデータベース）にアンカリングすることで、ログ生成者が事後に修正できない証拠を作成します。

これが「信じるな、検証せよ」を可能にするものです。第三者は、あなたを信頼することなく、監査証跡の完全性を独立して検証できます。

PrevHash：REQUIREDからOPTIONALへ

よく寄せられる質問があります：「なぜハッシュチェーンをオプションにするのか？セキュリティが弱くなるのでは？」

短い答え：いいえ。その理由を説明します。

ハッシュチェーンが提供するもの

v1.0では、PrevHash（前イベントのハッシュへのリンク）はREQUIREDでした。これによりハッシュチェーンが作られ、いずれかのイベントが変更されると、それ以降のすべてのハッシュが無効になり、リアルタイムの改ざん検知を提供します。

ハッシュチェーンは以下に有用です：

ハッシュチェーンが提供しないもの

しかし、ハッシュチェーンには制限があります：すべてのデータを制御する者は誰でも再構築できます。

悪意のあるログ生成者がイベントを変更し、それ以降のすべてのハッシュを更新したいと思えば、Merkle Rootをまだ外部にアンカリングしていない限り、それは可能です。

そのため、重要な完全性メカニズムはハッシュチェーンではなく、External Anchoringです。

v1.1のアプローチ

v1.1では、PrevHashをOPTIONALとしました。その理由は：

  1. Merkle Tree + External Anchorが外部検証可能性の本質的な保証を提供する
  2. ハッシュチェーンは補完するが、External Anchoringを代替しない
  3. Silverティアの実装を簡素化することで導入障壁を下げる

規制対応ユースケースへの推奨

規制対応ユースケース（MiFID II RTS 25、SEC CAT Rule 613）を対象とする実装では、ハッシュチェーンの有効化を推奨します。GoldおよびPlatinumティアの実装では、PrevHashをベストプラクティスと見なすべきです。

Policy Identification：マルチテナント展開のサポート

v1.1では、Policy IdentificationをREQUIREDフィールドとして導入します。この一見小さな追加が、エンタープライズ展開に大きな影響を与えます。

問題

実際の展開では、組織はしばしば以下を必要とします：

明示的なポリシー宣言がなければ、検証者は特定のイベントストリームにどのルールが適用されるか推測しなければなりません。

解決策

すべての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

External Anchoring：全ティアで必須に

v1.1における最も影響の大きな変更は、External Anchoringを全ティアでREQUIREDとすることです。

ティア別要件

ティア 頻度 アンカーターゲット 証明タイプ
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 External Anchorの存在
POL-001 Policy Identification

認証ガバナンスについて

VC-Certified認証は、VSOから直接ではなく、VSOが認定した適合性評価機関（CAB）によって発行されます。VSOはスキームオーナーとして機能し、標準の開発とCABの認定を担当します。

この構造は、PCI-DSS、ISOなどの成熟した認証スキームで確立されたモデルに従い、標準策定と認証の独立性を確保します。

移行ガイド

既存のv1.0実装向け

VCP v1.1はv1.0とプロトコル互換です。既存の実装は引き続き動作します。ただし、v1.1 VC-Certifiedステータスを取得するには、以下の追加が必要な場合があります：

あなたのティア 必要な変更
Silver External Anchoring（日次）を追加、Policy Identificationを追加
Gold Policy Identificationを追加、アンカリングが要件を満たすか確認
Platinum Policy Identificationを追加、アンカリングが要件を満たすか確認

猶予期間

要件 猶予期間 最終期限
External Anchor（Silver） 6か月 2026年6月25日
Policy Identification 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は、「信じるな、検証せよ」の原則への私たちのコミットメントを強化します。

External Anchoringを全ティアで必須とすることで、開発者のMT5バックテスト環境から高頻度取引会社の本番システムまで、あらゆるVCP展開が同じ基本的保証を提供することを確実にします：

第三者は、あなたを信頼することなく、監査証跡の完全性を検証できる。

これがアルゴリズム取引に必要なものです。これが規制当局が求めているものです。
そしてこれが、VCP v1.1が提供するものです。

リソース

参加方法

v1.1ドラフト仕様へのフィードバックを歓迎します。参加方法は以下の通りです：

v1.1仕様はドラフトステータスです。コミュニティからのフィードバックを取り入れた後、2026年Q1に正式版をリリースする予定です。

「事故が起きる前に学ぶことができる文明を。」

この記事は、VeritasChain Standards Organization（VSO）が技術教育目的で提供しています。

お問い合わせ：info@veritaschain.org

この記事をシェア：

VCPリソースを探索

VCPと規制要件への対応方法についてさらに詳しく学びましょう。

仕様を読む Explorerを試す ブログ一覧へ