始め方

コードはすべて Rust で、依存を固定する lock ファイルはリポジトリに含めてある。ライブラリのテストは、Rust が動く環境ならどこでも走る。ネットワークを使う受入ゲート（合否を判定する試験）には Linux が必要で、AvalancheGo は自分で用意して置き場所を指定する。MPC を通る経路には、公式の MP-SPDZ の checkout も要る。スクリプトが外部のバイナリを勝手にダウンロードすることはない。

clone してテストする

git clone https://github.com/zkFMI/defmi.git
cd defmi/rust
cargo test -j 4 --locked --workspace

同じコマンドは zkpi と qomm でも使える。独立した crate では、次の四つのゲートを順に通す。

git clone https://github.com/zkFMI/dekyx.git   # or deccp, aethel
cd dekyx
cargo test --workspace --locked
cargo clippy --workspace --all-targets --locked -- -D warnings
cargo fmt --all -- --check
cargo build --workspace --release --locked

rust-toolchain.toml は置いていない。評価を始めるときに rustc --version を記録し、ビルドに使う機械の間で同じ版に固定すること。統合用の Docker ビルドは現在 Rust 1.97.1 を参照している。

指図のテストベクタを検査する

zkpi-verify --check-vectors artifacts/zkpi_vectors
zkpi-verify --self-test

ライブラリ 2 つ（qomm-proofs、qomm-transport）とバイナリ 1 つ（qomm-avalanche-vm）には、経緯上の qomm- 接頭辞が残る。それ以外のパッケージは、いまは層の名前を持つ。このページのコマンドは、いま動く名前で書いてある。

終了コードは、0 が受理、1 が拒否、2 が判定できなかったことを表す。受理されるベクタは、復号して再符号化したときに元と同じバイト列に戻らなければならない。--vectors <dir> でベクタを作り直すのは、形式が変わったときだけである。検査結果が食い違ったからという理由で作り直してはならない。

検証者 5 台の L1 ゲートを走らせる

defmi/ で実行する。承認済みの版の AvalancheGo と avalanche-network-runner を先に用意しておく。

cargo build --release --manifest-path rust/Cargo.toml -p defmi-avalanche-vm -p defmi-harness
# launchers and configuration under avalanche/defmivm/
cargo run --release --manifest-path rust/Cargo.toml -p defmi-harness --bin run_avalanche_l1_acceptance

実行すると artifacts/avalanche_l1_acceptance.json が書き出される。企業向け PoC ガイド（日本語）は、次の手順を順に案内する。ソースの固定、VM のビルド、ネットワークの起動、取引シナリオ、追加の署名なしで通る QOMM の経路、必須の拒否試験と障害試験、残すべき証拠、合格条件。その先には、企業が自分で評価するための章が続く。ハードウェアの見積、プロセスの分離、ネットワーク設計、genesis、鍵管理、バックアップ、監視、障害注入である。

QOMM の座席デモを試す

cd qomm
cargo run -j 4 --release --manifest-path rust/Cargo.toml -p qomm-harness --bin serve_demo
# then hand out seats:
#   http://<host>:8800/?seat=taker
#   http://<host>:8800/?seat=maker:1&label=Ann
#   http://<host>:8800/?seat=node:3&label=Rin
#   http://<host>:8800/?seat=observer

各ブラウザには、その座席の役割が本来見られるものだけを送る。observer（観察者）の座席だけはすべてを表示する。この眺めは実際の配置には存在しないことを、画面の毎フレームに表示する。

OCLOB のゲートを走らせる

OCLOB のビルドとテストは、リモートホスト上の Linux コンテナの中でだけ行う。Makefile がソースをそこへ送る。

make release-gate REMOTE_TEST_HOST=<linux-host> REMOTE_TEST_REUSE_IMAGE=0
make remote-distributed-e2e REMOTE_TEST_HOST=<linux-host>
make remote-integrated-e2e  REMOTE_TEST_HOST=<linux-host>

結果は artifacts/oclob_rough_e2e.json、oclob_distributed_e2e.json、oclob_distributed_avalanche_acceptance.json に書き出される。どのファイルにも、主張しないことを列挙した non_claims と、秘匿の範囲を示す privacy_boundary のフィールドが入っている。

計測結果（artifact）から文書を作り直す

cd defmi
make defmi-doc      # DEFMI.md from artifacts/*.json; no number typed by hand
cd ../qomm
make audit-doc      # AUDIT.md likewise

企業向け PoC ガイド

DeFMI: 導入、役割の分離、障害事例、証拠、受入、そして 41 節の運用指針。
QOMM、DeKYX、DeCCP、Aethel、OCLOB。

いずれも日本語で書いてある。前提は、合成した資産、使い捨ての鍵、インターネットに出さないネットワークである。どの証拠を残すべきかも述べている。後から監査人が、言葉を信じるのではなく実行そのものを検査できるようにするためである。

ライセンス

7 つのリポジトリはすべて MIT ライセンスである。取り込んだ外部コードが求める場合は、第三者の著作権表示を添えている。

← 今後の計画用語集 →