技術的詳細情報

バリデータスタック・アーキテクチャ

JSC の「バリデータスタック¹」アーキテクチャは、Ethereum の実行およびコンセンサスプロトコルの最新の進展と変更を取り入れながら、許可制バリデータクライアント群と基本的なコンプライアンス機能を両立できるよう設計されています。

JSC バリデータスタックは、実行クライアント（Execution Client）、コンセンサスクライアント（Consensus Client）、バリデータクライアント（Validator Client）の 3 つのコンポーネントで構成されています。実行クライアントとコンセンサスクライアントは標準的な Ethereum ソフトウェアコンポーネントであり、バリデータクライアントオペレーターに指定されていない者でも、主に読み取り専用の形で個別に稼働できます。

• バリデータクライアント

  • JSC は、バリデータクライアントを実行できる主体をホワイトリストで限定し、高水準のトークン閾値を設定しています。
  • プロトコルは、ネットワークの安全性とコンセンサス維持に貢献した対価として彼らに報酬を付与します。
  • バリデータクライアントの主な役割はブロック提案、ブロックの妥当性アテステーション、およびライトクライアント²の同期支援です。

• コンセンサスクライアント

  • PoS コンセンサスプロトコルに基づき、バリデータクライアントの「ビーコン」状態を管理し、フォークチョイスとファイナリティを担保します。
  • 複数のバリデータクライアントを調整し、メッセージの受け渡しやブロック提案などの職務割当を行います。
  • 他のコンセンサスクライアントと P2P ネットワーク上でコンセンサスメッセージを交換します。

実行クライアント

• 実行クライアント
  • 他の実行クライアントとの P2P ネットワークで保留中トランザクションを受信およびゴシップします。
  • トランザクションをバリデータクライアントが提案するペイロードにパッケージ化します。
  • Ethereum Virtual Machine（EVM）上でブロックを実行し、ブロックチェーン状態を更新します。
  • JSON-RPC API を公開し、ユーザーがトランザクション送信やエクスプローラーでのチェーン参照を行えるようにします。
  • EVM のロジックを保持します。

コンセンサスプロトコル - Proof of Stake

JSC は、Proof of Stake（PoS）コンセンサスプロトコルを採用した EVM 互換のブロックチェーンネットワークです。このブロックチェーンは、ジャパンスマートチェーン財団（JSCF）が定める厳格なハードウェアおよびソフトウェア基準に従い、日本国内に設置された 21 のバリデータクライアントオペレーター（各オペレーターがバリデータクライアントを稼働）によってバリデートされます。

JSC では、許可制バリデータクライアントに対しコンセンサス業務が定期的に割り当てられ、正確かつ迅速に遂行した場合は報酬が与えられ、業務を怠るか誤って遂行したことが証明された場合にはペナルティが科される PoS 方式を適用しています。

Mizuhiki スイート：分散型識別子と検証可能な資格情報の活用

Mizuhiki は JSC ネットワーク向けに最適化されたユニバーサル・アイデンティティ・プロトコルです。この包括的なスイートの核となる「Mizuhiki ID」により、信頼できる Mizuhiki アテスターが利用者のブロックチェーンアドレスへ検証可能なプレゼンテーション（VP）³ または**ソウルバウンドトークン（SBT）**を発行できます。

Mizuhiki アテスターは、日本の主権下でライセンスを受けたコンプライアンス準拠のアテスター網であり、個人・法人等の実世界のアイデンティティとデジタルアイデンティティを結び付ける「信頼の根」を形成します。アテスターは利用者の分散型識別子（DID）に検証可能な資格情報（VC）を発行できます。VC に含まれる個人データはオンチェーンに保存されず、JSC のクライアントオペレーターやバリデータからも不可視です。利用者はゼロ知識証明を提示することで個人情報を一切開示することなしにVC の有効性のみを開示し、必要なオンチェーンアクションの資格を証明することができます。これは VP または SBT、およびその両方の形をとります。

検証可能な資格情報（Verifiable Credentials, VC）は W3C 勧告に基づく仕様で、分散型識別子と組み合わせて資格情報の発行・保持・提示・検証を行います⁴。資格情報には、大学の卒業証明書、運転免許証、身分証明書など、さまざまな文書が含まれる可能性があります。Mizuhiki ID ツールキットには、日本国内で所定の KYC・スクリーニングを完了したことを示すオンチェーン VP「Mizuhiki Verified」 が用意され、規制対象アプリケーションとの相互運用を可能にします。

Mizuhiki が VC・VP・SBT（VP の一形態と考えることができる）を活用できるのは、分散型識別子の採用によるものです。

分散型識別子（Decentralized Identifiers, DID）は、分散環境での主体の認証可能な識別を目的に、W3C ワーキンググループ⁵によって推奨されたデジタル識別子です。

各 DID は URI として構造化されており、識別子によって参照される文書を解決および検証するための方法に関する情報を含んでいます。

分散型識別子（DID）の一例⁶

Mizuhiki スイートは、「Mizuhiki DID（Mizuhiki DID メソッド）」と呼ばれる W3C の仕様に準拠した独自の DID メソッドを備えています。このメソッドは、接頭辞 did:mizuhiki で始まる分散型識別子（DID）およびその DID ドキュメントに対し、構文・リゾルブ・検証・認可の各プロセスを規定します。

Mizuhiki DID レジストリ は、犯罪収益移転防止法に基づく KYC を完了したユーザーの一意な DID と DID ドキュメントのメタデータを記録するスマートコントラクトレジストリです。

KYC は 「Mizuhiki コントローラー」 により実施され、同コントローラーは登録済み JPKI サービスプロバイダーである必要があります⁷。

エンドユーザー向け Mizuhiki ID 利用手順

Mizuhiki ID プロセスを完了し、JSC 上で「Mizuhiki Verified」アドレスを取得するためのエンドユーザーのフローは以下のステップで構成されます。

DID の生成と登録

1. ユーザーはMizuhiki コントローラー（以下「コントローラー」）とともに Mizuhiki ID 確認プロセスを開始し、本人確認に必要な書類を提出します。プライバシー保護のため、コントローラーは本人確認と書類チェックを完全にオフチェーンで実施します。

2. Mizuhiki アテスターが Mizuhiki SDK（開発中）を用いて、ユーザーの DID をオンチェーンに生成・登録します。

Mizuhiki Verified ソウルバウンドトークン

3. ユーザーは Mizuhiki SDK または対応アプリ上で、該当 DID の所有者として認証された後、自身の JSC アドレスへ「Mizuhiki Verified」ソウルバウンドトークン（SBT）を発行できます。

4. ソウルバウンドトークンは Mizuhiki コントローラーによって発行され、譲渡不可ですが、コントローラーまたはユーザー（またはその両者）によりバーンが可能です。重要な点として、ソウルバウンドトークンは DID をはじめとした個人を特定できる情報（PII）を含みません。

検証可能な資格情報（Verifiable Credentials, VC）

5. ユーザーが追加の資格情報を管理したい場合、大学や登録済み団体などの信頼できる機関（「Mizuhiki アテスター」）に VC の発行を依頼しなければなりません。この機関は Mizuhiki DID メソッドと W3C VC 仕様に準拠している必要があります。

6. VC のリクエストを受けた後、Mizuhiki アテスターはオフチェーンでユーザーに VC を発行します。VC はユーザーの Mizuhiki DID に安全・非公開の形でひも付けられます。ユーザーは DID の verification method で認可を完了すると VC にアクセスできます。

VC には生年月日・GPA・住所など複数の主張（クレーム）が含まれます。必要に応じ、ユーザーはその一部だけをバリデータへ提示する「検証可能なプレゼンテーション（VP）」を作成できます。言い換えると、ユーザーは生年月日を非公開のまま年齢層を開示したり、居住地の住所を隠したままエリアを開示したりすることが可能です。

検証可能プレゼンテーション（Verifiable Presentations, VP）

7. ユーザーは Mizuhiki SDK を通じて、保有する検証可能な資格情報（VC）を基に、JSC アドレスや JSC 上の他アプリケーションへ ― たとえばソウルバウンドトークン（SBT）形式で ― オンチェーン互換の検証可能なプレゼンテーション（VP）を生成・発行できます。VP は VC を保持するユーザー自身、またはその VC の発行者のいずれかが発行可能なものです。オンチェーン VP には、DID を含むいかなる個人識別情報（PII）も含めることはできません。VP はオフチェーン形式でも提供でき、その場合は PII を含むことがあります。

2c) ユーザーが検証可能な資格情報を含む JSC トランザクションを送信 ユーザーが JSC 上で規制対象の活動（例: 金融取引）に参加する場合、検証済み資格情報（およびその適格性）を JSC アプリケーションに提示します。 ゼロ知識証明が使用される場合、ユーザーのプライバシーが保護され、公開されることなく Mizuhiki アテスターによって検証可能です。 検証可能な資格情報には生年月日、GPA、住所などの主張が含まれる場合があります。ユーザーはこれらの主張の一部のみ（例: 生年月日だけ）を提示することも可能です。このプロセスを検証可能なプレゼンテーション（Verifiable Presentation, VP）と呼びます。

SBT／VC を用いたコンプライアンス＆リスク管理ルールエンジン

ユーザーが JSC 上で規制対象の活動（例：金融取引）を行う場合、Mizuhiki スイートを介して自分の SBT／VC を提示し、当該規制サービスを提供する JSC アプリケーションに対して適格性を証明できます。

Footnotes

1. Ethereum が Proof of Stake へ移行して以来、「バリデータ」「バリデータノード」「フルノード」という用語が混用され、開発者や政策立案者の間で混乱を招いている。JSC では「バリデータクライアント」「フルノード」「許可制システムオペレーター」を区別するために、実行クライアント・コンセンサスクライアント・バリデータクライアントの三つすべてを稼働させるインフラ構成を「バリデータスタック」と呼び、これを運営する許可制バリデータクライアント事業者を「バリデータクライアントオペレーター」と定義する。バリデータクライアントオペレーターに指定されていない者はバリデータクライアントを稼働できず、実行クライアントとコンセンサスクライアントのみをパーミッションレスで稼働できる。文法上、当面は固有名詞としてバリデータスタックを用いる。「バリデータクライアント」は引き続き個別ソフトウェアクライアントを指す語として使用し、混乱を避けるため単独で「バリデータ」という語を用いることは控える。詳細は付録 A を参照。 ↩

2. ライトクライアントとは、実行クライアントまたはコンセンサスクライアント（あるいはその両方）の軽量版であり、ローカルにデータを保存する代わりに必要に応じてブロックチェーンからデータを取得する。そのため、フルの実行クライアントやコンセンサスクライアントを稼働させる場合に比べ、ライトクライアントのハードウェア要件は大幅に低い。 ↩

3. 検証可能なプレゼンテーション（Verifiable Presentations）は、同一の検証可能な資格情報を場面に応じて異なる形で提示するための仕組みである。その一形態としてゼロ知識表現があり、資格情報の所有者は資格情報そのものを開示することなく、内容に関する主張が真実であることだけを証明できる。詳細は W3C, Verifiable Credentials Data Model — Zero Knowledge Proofs, Candidate Recommendation Draft, Oct. 2024. [Online]. Available: https://www.w3.org/TR/vc-data-model-2.0/#zero-knowledge-proofs ↩

4. W3C, Verifiable Credentials Overview, Group Note, Oct. 2024. [Online]. Available: https://www.w3.org/TR/2024/NOTE-vc-overview-20241022/ ↩

5. アテスターは、日本主権型のネットワークであり、適切なライセンスを持つ Mizuhiki プロトコルのアテスターで構成される。これらのアテスターは、個人、機関、その他の主体の実世界のアイデンティティとデジタルアイデンティティの結びつきを確立する「信頼の根幹（root of trust）」を担う。 ↩

6. 同上 ↩

7. Japan Public Key Infrastructure（JPKI）公式ガイド. [Online]. Available: https://www.jpki.go.jp/jpkiguide/index.html ↩