ZEDEC pqOS / ZXV — 開発者ガイド・アーキテクチャ解説（全33章）

Posted at 2026-08-12

ZEDEC pqOS / ZXV — 開発者ガイド・アーキテクチャ解説（全33章）

M5 公理的カーネル基盤 — VOVINA SHAKINA エディション
バージョン 0.0.1（v0 プレリリース）対応 · 2026-08-12
著作者：H.M. Michael-Laurence Curzi (c) · 36N9 Genetics, LLC
ライセンス：OPL-1.1 + CC BY-SA 4.0 + シチリア王冠の王令 + SEL-3.3

本書について — 最初に読んでください

本書は ソースコードを実際に読み、ビルドし、起動して測定した結果 に基づいて書かれています。
リリースノートや設計文書の主張をそのまま転記していません。

本書では次の3つのタグを使い分けます。この区別が本書の価値の中心です。

タグ	意味
【実装済】	コンパイルされ、ELFにリンクされ、テスト用でない呼び出し元があり、起動ログまたは必須ゲート内のテストで挙動が観測されている
【部分的】	実在し呼び出し元もあるが、読者が見落としがちな明示的な適用範囲の制限がある
【設計のみ】	ヘッダまたは `PROVENANCE/` 文書に仕様が存在するだけ。コードパスが無い、または呼び出し元が無い

⚠️ 重要：リリースノートとの相違について

配布物のリリースノートには、実測と食い違う記述が含まれています。とくに暗号規格の節です。
詳細は 第28章 に全て記載しました。要点だけ先に述べます。

curzi8889a_hash / curzi8889a_seal / curzi8889a_open / curzi8889a_sign / curzi8889a_verify
— これら5つのうち4つは、ツリー内に1箇所も存在しません。（実在するのは curzi8889a_selfcheck() のみ）

「耐量子リング署名」— ポスト量子署名方式は一切実装されていません。 署名は全て古典的な Ed25519 です。

BOOTRISCV64.EFI / BOOTRISCV32.EFI / BOOTARM.EFI — 生成されていません。 実在するEFIローダは
BOOTX64.EFI と BOOTAA64.EFI の2つだけです。

これは非難ではなく、開発者が誤った前提でコードを書かないため の記載です。
本プロジェクトの文書文化は「自らの過大主張を撤回する」ことを繰り返してきました（第28章参照）。

第1章　全体像 — ZXVとは何か

ZXV は、-nostdlib の自立型（freestanding）カーネルです。単一の共有Cソース基盤（テストを除き約88,000行）から
5つの命令セット 向けにビルドされ、QEMU上で全アーキテクチャがシリアルに [BOOT_OK] を出力します。

対応アーキテクチャ：

アーキテクチャ	起動方式（実測）
arm64 (AArch64)	`-kernel` 直接起動、および UEFI ディスク（`BOOTAA64.EFI`）
x86_64	`-kernel` 直接起動、および UEFI ディスク（`BOOTX64.EFI`）
riscv64 (rv64)	OpenSBI → S-mode ペイロード（UEFIディスクではない）
riscv32 (rv32)	OpenSBI → S-mode ペイロード（UEFIディスクではない）
arm32 (ARMv7-A)	`-kernel` 直接起動（UEFIファームウェア無し）

技術的な独自性は、スケジューラでもファイルシステムでもありません。
各モジュールが自分自身の翻訳単位（TU）内で自らの能力契約を宣言し、起動時のゲートが
その宣言グラフの健全性を検証できない限り、いかなるモジュールも起動させないという点にあります。

製品としての独自性は、ユーザーインターフェースがゲームカートリッジ（MegaROM）である という構想です。
フォーマットは完全に実装・検証済みですが、そのタグラインを文字通りにするレンダラは未実装です（第30章）。

最も重要な一つの数値： --gc-sections により、書かれたコードの約70%がリンク時に破棄されます。
この数値は実測され、ツリー内に公開されており、他の全ての数値を較正する基準になります。

第2章　ビルドと起動 — 全てを再現する

bash build_system/build_all.sh

この1コマンドが、ツールチェーンを探索し（ハードコードは一切無し）、5アーキテクチャを並行ビルドし、
2つの静的ゲートを実行し、6行のQEMU起動を行い、PASS/FAIL マトリクスを出力します。
5つの qemu-system-* とクロスツールチェーンが必要で、欠けている場合はスキップせず終了コード3で停止します。

配布物のテストは macOS 上で：

bash deliverable/boot_test_mac.sh

SKIP は決して PASS ではありません。 SKIP は前提条件（ツール・ファームウェア・ファイル）の欠如を意味します。
FAIL は起動が [BOOT_OK] に到達しなかったか、実CPU例外が発生したことを意味します。

会計規律（build_all.sh:18-20）

「"ビルドできた" ≠ "リンクできた" ≠ "起動した" ≠ "グラフが健全"。
各列は実際の成果物（make の終了コード、nm に裏付けられたELF、QEMU の終了コード、起動ログ）から測定され、
前の列から推論されることは決してない。」

1行が PASS になるのは、8列すべてが PASS の場合のみです。

第3章　検証マトリクス — 実測値

Linux ビルドボックス（QEMU 6.2.0）上での build_all.sh の結果（RISC-V リンカ修正後、再ビルド済み）：

行	ELF	バイト数	DRC	LVS	QEMU rc	`[BOOT_OK]`	グラフゲート	障害
arm64 GICv3	`kernel_arm64.elf`	795,544	PASS	PASS	124	yes	OK	none
arm64 GICv2	`kernel_arm64.elf`	795,544	PASS	PASS	124	yes	OK	none
x86_64	`kernel_x86_64.elf`	176,632	PASS	PASS	124	yes	OK	none
riscv64	`kernel_riscv.elf`	213,192	PASS	PASS	124	yes	OK	none
riscv32	`kernel_riscv32.elf`	232,356	PASS	PASS	124	yes	OK	none
arm32	`zedec_xero_arm32.elf`	232,068	PASS	PASS	124	yes	OK	none

rc=124 は timeout(1) が「30秒後もまだ実行中」と報告した状態です。これが成功条件です。
カーネルは永久にイベントループでアイドルするため、強制終了されることが「合格」の姿です。
正常終了は「死んだ」ことを意味します。

macOS（QEMU 11.0.2, Apple Silicon）での boot_test_mac.sh：

[0] ファイル整合性  PASS  manifest (10 files) 全 sha256 一致
[1] カーネル起動    PASS  arm64 · x86_64 · arm32 · riscv64 · riscv32
[2] UEFIディスク    PASS  x86_64 · arm64 ヘッドレス · arm64 GOP
結果: 9 PASS   0 FAIL   0 SKIP

重要な限定

全てエミュレーション検証です。 シリコン上の起動証跡はツリー内に存在せず、実ハードウェアドライバは
一切リンクされていません。デバイス群は virtio とプラットフォームUART/タイマ/割込コントローラのみです。

第4章　コードベースの形

.git と .claude/worktrees（素朴に数えると約2倍に膨らむ重複チェックアウト）を除いた実測：

項目	数
`.c` ファイル（リポジトリ全体）	584
`.h` ファイル（全体）	359
C の行数（`.c` + `.h`）	211,489
`kernel/src` 配下の `.c`	441
非テストの `.c`（kernel/src）	299（87,899行）
`test_*.c`（kernel/ 配下）	143
`kernel/src` 直下のサブシステムディレクトリ	165
`ZXV_DECLARE` 宣言（本番）	92（+ curzi 追加後 93）

テスト対ソース比が異常に高いのは飾りではありません。143個のホストテストバイナリが
-std=c11 -Wall -Werror -Wextra でコンパイルされ、必須の make verify-all ゲート内で実行されます。

ディレクトリ地図

kernel/
  arch/           アーキテクチャ別エントリ、MMU、割込、UART
                  （arm64 x86_64 riscv arm32 ／ arm= 死んだレガシー）
  include/        zxv_decl.h（宣言マクロ）、m5_types.h（トリット／M5型）
  src/
    modbind/      宣言グラフ + 結合則 + 起動ゲート    ← ここから読む
    trispace/     S+/S−/S0 三空間モデル
    zab/          減衰VM（能力は内容から導出される）
    zxvfs/        ファイルシステム + zxvfs_tri
    invproof/     ZXI 逆witness
    loader/       ZSP 署名パッケージ + A/B ロールバック防止更新
    mlkem/        ML-KEM-768 + Keccak（自作、freestanding）
    curzi/        CURZI-8889-A 複合鍵確立（第23-27章）
    robin_debanks/ SHA-256, HMAC, AES-256-GCM, Ed25519（vendored）
    tolvovina/    TVUL MegaROM コンテナ + 幾何/ラスタ/ステレオ
    emu/          7 CPUコア、7コンソール機、dimfold、レンダラ
    desktop/      zxv_shell コンポジタ、13空間ラティス
    video/        ramfb フレームバッファ
build_system/     5つの Makefile + build_all.sh + ゲートスクリプト
PROVENANCE/       55文書、20,134行の実測結果と撤回記録

まず kernel/src/modbind/modbind.c と kernel/include/zxv_decl.h を読んでください。
他の全てが接続する組織原理がここに定義されています。

第5章　マルチカーネル設計

ZXV は Barrelfish モデルに従います：コア／セルごとのカーネル、明示的メッセージング、共有ではなく複製された状態。

実際には 4つの生きた kernel_main が5つのターゲットを担当 します：

メインファイル	行数	ターゲット
`kernel/arch/arm64/kernel_main_arm64.c`	3,852	arm64
`kernel/arch/x86_64/kernel_main_x86_64.c`	295	x86_64
`kernel/arch/riscv/kernel_main_riscv.c`	393	riscv64 + riscv32
`kernel/arch/arm32/kernel_main_arm32.c`	198	arm32
`kernel/arch/arm/kernel_main_arm.c`	302	どれでもない — 死んでいる

kernel/arch/arm/ はどの Makefile.<target> からも参照されていません。
grep -rn "modbind\|zxv_decl\|mb_carrier" kernel/arch/arm/ は0件です。
宣言グラフも、ゲートも、キャリアもありません。レガシーとして扱い、拡張しないでください。

サイズの非対称は実在の設計です。arm64 は EL0 ユーザー空間、CELL-001 ファブリック、
virtio net/input/snd、起動証跡台帳、デスクトップを担う参照プラットフォームです。
他の3つは意図的に薄く、プラットフォームを立ち上げ、同じ宣言ゲートを走らせ、イベントループに入ります。

第6章　4つのメインに共通するもの・異なるもの

共通

要素	arm64	x86_64	riscv	arm32
`mb_carrier_up()` を最初に	`:810`	`:171`	`:145`	`:64`
`zxv_decl_boot_gate(...)`	`:2361`	`:275`	`:316`	`:140`

各メインは、最後の modbind_reset() に対するゲート配置を正当化するコメントを持ちます。
そして arm64 以外の3つは、その配置が推測ではなく実測であると明記します。
grep -rn modbind kernel/arch/<arch> が空であるため、後ろに置くべき reset が存在せず、
arm64 の相対位置にゲートを置いた、という論理です。

異なる点

コンソールアダプタ。 arm64 のみが行バッファリングアダプタ gate_puts を渡し、
[ で始まる行を boot_msg 経由でハッシュ化された起動証跡台帳に流します。
他の3つは生の uart_puts を渡します。理由は x86_64 側に明記されています
——ゲートの出力はグラフ診断であり、x86_64 ではそのハッシュに依存するものが何も無いためです。

自己テストブロック。 arm64 のみが modbind_compose フィクスチャと modbind_selfcheck() を
ゲート前に実行します。これがゲート配置の論拠が異なる理由そのものです。

第7章　宣言グラフ — システムの中核

プログラマが最初に理解すべき部分です。ツリー全体がこの機構を軸に組織されているためです。

7.1 これが解決する問題

--gc-sections を使う freestanding カーネルでは、4つの異なる概念が日常的に混同されます：

コンパイルできる — TU がビルドされる
リンクされる — オブジェクトが KERNEL_SRCS にある
存在する — シンボルが --gc-sections を生き延びてELFに入った
到達された — 起動時に実際に何かが呼んだ

モジュールは 1 と 2 を満たしながら、バイナリから完全に消えていることがあります。
本プロジェクトはまさにそれを実測しました（Makefile.arm64:564-566）：

「2026-08-09 実測：tls/x25519/aead/hkdf、oseq、chiglet はいずれも KERNEL_SRCS に
追加した直後の時点で ELF 内のシンボルが 0 個だった。」

第8章　ZXV_DECLARE マクロ

各モジュールは自分自身の .c のファイルスコープで自らを宣言します：

ZXV_DECLARE(sms,
    ZXV_PROVIDES(sms_console_ready),
    ZXV_REQUIRES(z80_cpu_ready),
    ZXV_BRINGUP(zxvd_sms_bringup));

ZXV_DECLARE（kernel/include/zxv_decl.h:249-256）は3つのオブジェクトを生成します：
mb_module_t、それを起動関数に束ねる zxv_decl_t、そして
__attribute__((used, retain)) 付きで .rodata.zxv_decl に置かれるそのポインタです。

なぜ「レコード」ではなく「ポインタ」なのか

セクションが保持するのはポインタであり、レコードではありません。
これによりストライドが構造上 sizeof(void*) になります——64ビットで8、32ビットで4——
同じ走査コードが両方の幅で動作します。

各リンカスクリプトはこのセクションをワイルドカードより前に手で配置し、
__zxv_decl_start / __zxv_decl_end マーカーを置きます。この手動配置は神経質さではありません：
かつてオーファン配置された .note.gnu.build-id が .text の上に着地し、
QEMU がカーネルを拒否したことがあります（zxv_decl.h:39-53）。
同じクラスのバグが2026年に RISC-V で再発しました——第21章と第13章を参照。

補助マクロ

ZXV_PROVIDES_NONE / ZXV_REQUIRES_NONE は明示が必須です。
省略された節は、忘れられた節と区別がつかないためです。

引数カウント機構は能力1〜4個まで書き下されています。5個目は ZXV_CAPS5 を生成し、
それは存在しないため設計上のコンパイルエラーになります。

第9章　位相 — 誰も入力しない唯一の数値

ZXV_DECLARE は .phase を ZXV_PHASE_OF_<name> から設定します。
これは zxv_phase_table.h に由来し、ビルド時に生成され、決してコミットされません。
生成元は build_system/gen_phase_table.sh で、モジュールの DRC 階層から導出されます。
生成器が見つけられないモジュールは 'ZXV_PHASE_OF_<name>' undeclared でコンパイルに失敗します。

生成器は verify_layers.sh から layer_of() を切り出して呼び出します。
規則を再記述しないため、両者が乖離することがありません。

却下された3つの代替導出（`gen_phase_table.sh:13-33`）

いずれも構築され、実測され、証拠に基づいて却下されました：

能力から導出 — 退化する。 提供側と要求側が同じトークンから同じ数値を計算するため、
全ての辺で dφ ≡ 0 になります。ここから、スクリプトが大文字で記す補題が導かれます：
「位相はモジュールの属性であり、決して能力の属性ではない」
requires グラフの深さ — 自己参照的であり、どの辺も全力で結合しなくなります
名前のハッシュ — 物理法則が綴りの関数になってしまいます

階層が採用されたのは、13階層がシステム自身のアリティだからです。

⚠️ 実践的な落とし穴（本セッションで実測）

ビルドボックスに 9エントリしか無い古い kernel/include/zxv_phase_table.h が残っていました。
このファイルは生成専用でソースツリーに存在してはいけません。-Ikernel/include が
-Ibuild/arm64/gen より先に来るため、正しい98エントリの生成済みテーブルを遮蔽していました。
結果、コンパイラは「シンボルが未宣言」と主張し続け、正しいテーブルはすぐ隣に存在していました。
find kernel -name zxv_phase_table.h は常に空であるべきです。

第10章　起動ゲート

zxv_decl_boot_gate(puts)（kernel/src/modbind/zxv_decl_gate.c:607-754）は
コールバックを puts の1つだけ取ります。5つのメインがコンソールについて合意しておらず、
arm32 のメインには put_dec すら無いためです。

10進数の整形は uint32_t 演算のみで自前実装します。64ビットの可変除算は __udivdi3 に落ち、
Makefile.riscv32 は libgcc を供給しないためです。
全ての名前は24文字で境界付きに出力されます。mb_module_t.name は NUL 終端が保証されないためです。

手順

宣言を数えて登録し、collected= registered= refused= を出力
電力読み出しを意図的に先に出力。5アーキテクチャ中4つは歴史的に健全分岐に到達しなかったため
found == 0 → 問題として報告。「何もすることが無い」とは決して言わない
refused != 0 → 問題
modbind_verify_graph() → 失敗時は全問題を名指しし、起動を完全に拒否
成功時：準備完了を解決し、保留モジュールを全て名指しし、起動関数を実行し、否定テストを実行

puts == NULL は 0 ではなく 1 を返します：報告できなかったゲートは、合格ではなく問題である。

第11章　3つの失敗クラス

modbind_verify_graph（modbind.c:783-846）：

クラス	検査内容
UNPROVIDED (7)	全ての `requires` は、いずれかの `provides` に名前で一致しなければならない
CONTRACT (9)	1つの能力を異なる契約バージョンで提供する2つのモジュール。代替提供は合法だが、不一致は実行時のコイン投げではなくビルド失敗にする
CYCLE (8)	準備完了不動点を実行し、`MB_HOLD_CYCLE` のみを数える

保留分類は局所テストではなく不動点です。列挙型は根本原因が継承原因より上位になるよう順序付けられ、
モジュールの理由は下方向にしか動かないため、ループが有界になります：
NONE 0 < UNPROVIDED 1 < PHASE 2 < WITHDRAWN 3 < CYCLE 4

modbind_resolve は撤回されていない全モジュールを HELD にリセットし、
要求が全て利用可能なモジュールを、変化が無くなるまで昇格させます。
順序非依存・コア非依存であり、これがマルチカーネルで安全な理由です。

第12章　HELD は FAILED ではない

MB_BRINGUP_HELD = 0x48454C44 — ASCII で 'HELD'。
0 とも errno 形式の負値とも衝突せず、レジスタダンプで可読になるよう選ばれています。

起動関数の戻り値	分類	`up` に数える？	`[FAIL]` を出す？
`0`	UP (S+)	はい	いいえ
`MB_BRINGUP_HELD`	HELD (S0)	いいえ	いいえ
その他の非0	FAILED	いいえ	はい

bringup == NULL の READY モジュールは declared_only として別に数えられ、up に含まれません。
理由は明記されています：「失敗し得ない報告は、このゲートが除去するために存在するのと同じ自己証明の欠陥である」

ツリー内で MB_BRINGUP_HELD を返すモジュールはちょうど1つ：
kernel/arch/arm32/arm32_mmu.c:90 — MMU がオフのとき、その能力は所有されているが準備できていない状態であり、
成功でも失敗でもありません。arm32 の起動ログで実際に観測されます。
機構は実在し、ちょうど1経路で行使されています。

第13章　位相結合則

システムの象徴的な発想であり、過大に語らないよう正確に記述する必要があります。

モジュールは13の位相位置からなる環の1つに座ります（MB_PHASES = 13）。
結合強度は生の余弦ではなく、光学的干渉縞です：

/* modbind.c:595-616 */
uint32_t mb_power_factor(uint8_t a, uint8_t b) {
    uint32_t k = |a - b| % 13;
    return (uint32_t)((1000 + COS13_PERMILLE[k]) / 2);   /* = cos²(Δφ/2) */
}

Δφ	0	1	2	3	4	5	6	7	8	9	10	11	12
電力 ‰	1000	942	784	560	322	125	14	14	125	322	560	784	942

逆位相（Δφ = 6）は最弱の結合（14‰）であり、反転した強結合ではありません。
これは以前の |cos| モデルからの意図的な修正です。極性は別の軸が担います。

実効電力（mb_real_power）は、5つの逐次的拒否の後に1つの積を計算します：

NULL ガード
キャリア — if (!mb_carrier()) return 0; 位相はキャリアに対して測られる。基準が無ければ位相差は何も意味しない。これにより起動順序が意味を持つ
電圧 — 能力名が一致しなければならない（24バイト）。異なる名前はそもそも回路ではない
契約 — バージョン不一致は損失のある回路ではなく開放回路
電流 — トリット振幅 → パーミル：TRUE 1000, GLUT_PLUS 750, GLUT_NEUTRAL 500, GLUT_MINUS 250, FALSE 0
P = I × pf / 1000、トリット電荷で符号付け

準備完了述語は > 0 ではなく != 0 です：強度と極性は別の軸であり、
負電荷の束縛も結合します。

振幅定数は、両方の番号体系を見る唯一のTU内で5つの _Static_assert によりピン留めされています
（modbind.c:20-24）。trit_t の改名は物理法則を静かに変えるのではなくビルドを壊します。

第14章　準備完了不変量 — そして正直な帰結

13 は奇数であるため余弦は −1000 に到達せず、最小電力係数は (1000 − 971)/2 = 14‰ です。
最小の非ゼロ電流は 250‰。したがって最小の非ゼロ実効電力は 250 × 14 / 1000 = 3 ——
切り捨てられますが非ゼロです。

帰結：位相だけでは回路を開くことができず、準備完了を変えることもできません。

名前が一致する回路を開けるのは3つだけです：契約不一致、振幅ゼロ、キャリア停止。

ソースはこれを願望ではなく測定として記し、「ゼロに十分近い」しきい値の追加を拒否します。
理由は「許可検査における許容誤差は脆弱性である」ためです。
ゲートは明示的に 「NOT APPLIED（未適用）」 とラベル付けされたしきい値スイープを出力します。

要約時には正確に述べてください： 配線された位相則は測定・診断層であり、ゲート層ではありません。
2つのモジュールがどれだけ強く結合するかを教えますが、結合してよいかを現時点で決定しません。
MB_HOLD_PHASE は出荷構成では事実上到達不能です——3つの真の逆位相辺（14‰）が存在するにもかかわらず、
実測 S0 held = 0 です。

実測（arm64）

13位相のうち11が使用され、79本の辺が Δφ 別に
0→39, 1→5, 2→5, 3→5, 4→4, 5→15, 6→3, 9→3 と分布します。
14‰ の逆位相辺3本は名指しされています：vino←rmag、vino_stores←edp_risk、pirate_apps←ipfs。

否定テストはフィクスチャではなく生きたグラフ上で実行されます：
rmag_ready（要求元10）を撤回すると ready が 88 → 72 に落ち、復元すると正確に 88 に戻ります。
キャリアを落とすと、何も要求しない41モジュールだけが残ります。

第15章　三空間（Tri-space）

全ての成果物は**三対（triad）**です（kernel/src/trispace/trispace.h）：

役割	列挙子	ソース拡張子	コンパイル済拡張子	意味
S+ 正	`TRI_POSITIVE`	`.n9n63`	`.zxvc`	プログラムが何をするか
S− 負	`TRI_NEGATIVE`	`.9n63`	`.cedez`	逆・禁止・取り消し
S0 中性	`TRI_NEUTRAL`	`.0n0`	`.cedec`	未解決の剰余

tri_bind() が強制する5つの必須要件：

三者すべてが存在し束縛されていること。さもなくば S0 に隔離
S− の能力は S+ の能力の部分集合であること
S0 はいかなる生産効果能力も保持しないこと
不可逆な効果は厳密な逆を主張してはならない
生成された S− を証明済みの逆として提示してはならない

逆の5種：EXACT, COMPENSATING, RESTORING, CONSTRAINING, OBSERVATIONAL

第16章　ZAB — GRANT命令を持たない理由

セキュリティモデルで最も鋭い発想です。

上記の要件2は元々 tri_member_t.capability_set ——作者が宣言する uint32_t ——に対して
検査されていました。敵対的な S− は capability_set = 0 と宣言し、任意の権能を持ち、
規則を通過し、封印がその嘘を覆うことができました。

自明な修正は、プログラムが欲する能力を名指しする GRANT 命令です。ツリーはこれを明示的に却下します
（zab.h:16-27）：

「それは同じ自己申告を1階層下げただけである。効果のある命令を使いながら GRANT を省略する作者は、
再び嘘をついている。」

したがって ZAB には grant 命令がありません。 効果のある全ての命令はその能力を含意し、
導出される集合は存在する全命令の和です。
能力を持つには、それを使う命令を含まねばならず、その命令を含むことが即ち能力を持つことです。

11個の命令：NOP, OBSERVE, READ, WRITE, FS_READ, FS_WRITE, POST, SEND, SPAWN, EMIT, END
——GRANT/DELEGATE が無いことに注目してください。

安全性の背骨

全域的（TOTAL） — 分岐・呼出・ループ無し、256命令以下。停止性は構造的であり、停止問題もガス計量も不要
アドレス無し — プログラムはメモリを名指しできない
有界 — 未知命令は無視ではなく拒否。未知命令 → ZAB_CAP_ALL、未知スコープ種別 → ZAB_CAP_NONE。どちらも拒否を指す
封印済 — FNV-1a をフィールド単位で計算。パディングが影響できない。封印は決して0を返さない
解析の全域性 — データは CAP_NONE、不正なプログラムは拒否。「解析不能ゆえに信頼」という категория は存在しない

実行時（zab_execute）は実行しようとしている当のバイト列に対して検証器を再実行し（TOCTOU 対策）、
命令ごとに4つの連言ゲートを適用します。

スコープが追加されたのは、以前は権限がハンドラ単位で束縛され、
FS_WRITE が「このファイルを書く」ではなく「ファイルシステムを書く」を意味していたためです。
スコープセレクタはホストのみが書く表を索引します：
「プログラムは提供されたものの中から選ぶだけであり、オブジェクトを発明することは決してできない。」

ZCA との対比

kernel/src/cards/zca.h（物理カードから OCR された프로그램用の言語）は
GRANT 命令を持ちます（既知の4能力ビットにマスク）。これが許容されるのは、
ZCA の書き込み可能面が呼び出し元提供の構造体1つだけだからです——
「悪意あるカードにできる最悪のことは、合法なカードであることだ。」
能力アイテムは ZCA ではなく ZAB の上に構築しなければなりません。

第17章　三対をストレージ単位とする（zxvfs_tri）

zxvfs_tri は三対あたり4ファイルを保存します（.zxvc, .cedez, .cedec, .tri）。

コミット順序が保証です：役割ペイロードが先に書かれ、それらは不活性です。
記述子が最後に書かれ、それだけが三対を観測可能にします。

規則はストレージ層で再実装されません——ダイジェストを計算し tri_bind() を呼びます。
隔離は永続化されるため、拒否は再起動を生き延びます。

テストは網羅的なクラッシュ注入を行います——全てのデバイス書き込み添字でクラッシュさせ、
各回で再マウントし、いかなるクラッシュ点でも束縛された S+ が束縛された S−/S0 なしに露出しないことを表明します。

【部分的】ソースに明記された制限

書き換えは fail-closed だがアトミックではない（クラッシュで新バイトが旧記述子の下に残る → ダイジェスト不一致 → 隔離。安全だが「旧か新か」のアトミック性ではない）。シャドウイングはエクステントアロケータ待ち
強制はこのAPI上のみ。生の zxvfs_t を持つ呼び出し元は役割ファイルを直接読める
MVP 容量は64ファイル ≈ 16三対

ZXI（kernel/src/invproof/）は逆witness形式です：ランレングス差分を適用することで検証し、
取り消しが記録された事前状態にバイト単位で正確に着地しなければなりません。

第18章　メモリ管理と MMU

アーキテクチャ	ファイル	`mm_ready` 提供者
arm64	`arch/arm64/arm64_mmu.c`（284行）	`:282`
arm32	`arch/arm32/arm32_mmu.c`（96行）	`:94`
riscv	`arch/riscv/riscv_mmu.c`（132行）	`:130`
x86_64	`arch/x86_64/ring3.c`（403行）	`:401`

注目すべき設計点：正直な能力会計

無条件に0を返す起動関数は「構成上真」であり、明示的に却下されます。
arm32 では MMU オフは能力が S0/HELD に留まることを意味します——所有されているが準備できていない、
UNPROVIDED とは異なる状態——そしてそれを要求する全ての消費者が S0 で共に待ちます。
これが MB_BRINGUP_HELD が存在する理由です。

arm64 は 4KB グラニュール、3レベルの恒等写像を使い、RAM 先頭1GBを4KBページまで細分化して
.text/.rodata を読み取り専用にできるようにします。
デバイス／通常メモリ属性は QEMU virt へのハードコードではなく board_profile.h の
UART/GIC ベースアドレスから計算されます——ファイル冒頭に実測された MediaTek の失敗モードが記録されています。

RISC-V は Sv39/Sv32 恒等写像を使い、satp を書いた後に読み戻して確認します。

アロケータ、そしてアロケータでないもの

arm64 のユーザーページは解放経路の無い静的プール上のバンプアロケータから取られます
kernel/src/mm/mm.h は32ビットx86の形（1024エントリ表）であり、arm64 の経路ではありません
kernel/src/alloc/ はメモリアロケータではありません — 資本配分モジュールです。そう引用しないでください
ZXVFS にエクステントアロケータはありません

第19章　W^X と EL0 ユーザーコピー — arm64 のみ

ユーザーコードは RO+X、データは RW+NX、全ユーザーページに PXN 強制。
カーネル .text/.rodata は読み取り専用。

proc_user_range_check() はそのプロセス自身の L3 表を歩き、4KBページごとに要求します：
有効な PTE、AP[1] セット（EL0 アクセス可能）、そしてカーネルが書く場合は AP[2] クリア（書き込み可能）。
加えてオーバーフロー（va + len < va）と窓境界。

need_write 側が存在するのは実測されたレッドチームDoSのためです：
読み取り専用のRECVバッファが EL1 で例外を起こし、fail-closed の中止ハンドラがカーネルを停止させました。

明記すべき欠落

x86_64、riscv、riscv32、arm32 に同等の copy_from_user/copy_to_user は存在しません。
ユーザーコピー強化は arm64 限定です。

主張されているメモリ安全性

存在するもの： ページ権限による W^X、PXN/UXN、検証済みユーザーポインタコピー（arm64）、
セキュリティモジュールにおける freestanding 整数のみの規律、非信頼入力パーサの ASan+UBSan ファジング。

存在しないもの： MTE 無し、PAC/BTI 無し、KASLR 無し、ガードページ無し、
SMAP/SMEP 相当の強制無し、いずれのアーキテクチャの CFLAGS にもスタックカナリア無し、
境界検査アロケータ無し。
メモリ安全性はアーキテクチャ的（ページ権限）かつ検証器レベルであり、言語レベルでもハードウェア緩和レベルでもありません。

第20章　暗号 — 実装されているもの

プリミティブ	状態	備考
ML-KEM-768（FIPS 203）	【実装済】自作	EK 1184 / DK 2400 / CT 1088 / SS 32。NIST ACVP 検証済（第22章）
Keccak-f[1600] / SHA-3 / SHAKE（FIPS 202）	【実装済】自作	2026-08-12 に重大バグ修正（第21章）
SHA-256	【実装済】自作、182行
HMAC-SHA256, AES-256-GCM	【実装済】	AES は必須ゲート内で KAT 検証
Ed25519 検証	【実装済】— vendored（public-domain orlp/ed25519）	名前空間分離済
TLS スライス（x25519, HKDF, AEAD, record, handshake）	【実装済】ホストテスト付き
CURZI-8889-A	【実装済】（第23-27章）	層0/1/2/3/4/5 実装・検証・起動済

第21章　Keccak の重大バグ — 本ガイド最重要の章

CURZI-8889-A を構築する前に、その土台となる ML-KEM 実装を公開ベクタで検証する必要がありました。
その検証は全面的に失敗しました。

21.1 何が間違っていたか

static uint64_t rotl64(uint64_t x, int n) {
    return (uint64_t)((x << n) | (x >> (64 - n)));
}

Keccak の回転表は rho[0][0] == 0 であるため、レーン(0,0)は全ラウンド・全置換で n == 0 で
この関数を呼びます。それは x >> 64 を評価します。
型の幅以上のシフトは C では未定義動作であり、no-op ではありません。
-O0 では ARM と x86 がシフト量を6ビットにマスクするため動作しているように見えます。
-O2 ではコンパイラは式全体を任意に畳んでよく、実際にそうしました。

修正前の実測（-O2 ビルド）：

関数	出力	正解（FIPS 202）
`sha3_256("abc")`	`2f0e85d6…`	`3a985da7…`
`sha3_512("")`	`cffb17ac…`	`a69f73cc…`

OS 内の全ての SHA-3 / SHAKE 出力が間違っていました。
ML-KEM は全ての鍵・係数・共有秘密を SHAKE と SHA-3 経由で導出するため、
システムがそれまでに生成した全ての ML-KEM 鍵が間違っていました。

21.2 なぜ何も検出しなかったか

このバグをはるかに超えて一般化する、内面化すべき部分です。

既存の検証器 mlkem768_validate.c は、カプセル化と脱カプセル化が互いに一致するかを
10試行で検査していました。一致していました——完璧に。
一様に間違った実装は完璧に自己整合的です。 自分自身と一致し、安定した往復を生み、
全ての内部不変量を通過し、地球上のいかなる実装とも相互運用しません。

自己整合性は一様な誤りを検出できない。公開された解答だけがそれを検出できる。

修正は1行です：

return n ? (uint64_t)((x << n) | (x >> (64 - n))) : x;

この n == 0 分岐は最適化ではなく、SHA-3 の正しさそのものです。単純化して戻さないでください。

第22章　ML-KEM-768 と NIST ACVP 既知解テスト

真正な NIST ACVP ベクタを usnistgov/ACVP-Server から取得し、
要約モデルを経路に挟まずバイト厳密に解析し、
転記誤りを防ぐため最初のケースを独立した第2経路で相互確認しました。

ML-KEM-768 vs NIST ACVP 既知解ベクタ
[1] KeyGen_internal(d,z)   —  5 ベクタ（1184バイト ek / 2400バイト dk 全体比較）
[2] Encaps_internal(ek,m)  —  5 ベクタ（1088バイト ct / 32バイト K）
[3] Decaps_internal(dk,c)  — 10 ベクタ（うち5件は改竄暗号文）
30 比較, 0 失敗
[PASS] NIST ACVP ベクタとバイト単位で一致

なぜ改竄暗号文ケースが最重要か

FIPS 203 の脱カプセル化は可視的に失敗してはなりません。
不正な暗号文に対しては疑似ランダム値 J(z‖c) を返し、呼び出し元からは本物の共有秘密と区別できません。
代わりにエラーやゼロ鍵を返す実装は、攻撃者にオラクルを与え、選択暗号文攻撃による鍵回復が続きます。
正常系だけを試験するスイートは、そのような実装を通してしまいます。

この KAT は make verify-all に必須ゲートとして配線済みです。

読者への帰結： ZXV が真正で標準準拠の ML-KEM-768 を持つのは 2026-08-12 以降 です。
それ以前に生成された鍵材料は、弱いのではなく 無効（void） と見なさなければなりません。

第23章　CURZI-8889-A — 層構成

CURZI-8889-A は発明ではなく合成です。

層	内容	目的
0 — 困難性	ML-KEM-768 / 1024、無改変	ポスト量子安全性
1 — ハイブリッド	+ X25519、全トランスクリプト上で結合	両方が破られた場合のみ破綻
2 — 閾値	33インスタンス、GF(2⁸) 上 Shamir k=17/33	単一障害点の排除
3 — 符号	Hamming [8,4,4] + Golay [24,12,8]、6×24 = 144ビットフレーム	誤り訂正 + 正準定数
4 — 位相	M5 論理状態による KDF ドメイン分離	文脈間の隔離
5 — 階層	144ドメイン × 61レベル、降下不能な一方向	全復号せずに部分アクセス

主張すること、拒否すること

主張（擁護可能）： ML-KEM-768 単独より厳密に強い。ML-KEM を含み、
さらに攻撃者に X25519 の突破と33インスタンス中17の突破を要求する。

拒否： ML-KEM の格子安全性を「上回る」という主張、および既知の全暗号を凌駕するという主張。
含んでいるものを上回ることはできません。

23.1 層0 は不可侵

ML-KEM の内部は、このファイルの他の全ての層にとって立入禁止です。

層3の符号を ML-KEM のメッセージ符号化の内側に押し込みたくなります。復号失敗率を根本で下げられるからです。
その誘惑は拒否しなければなりません：他のいかなる実装も読めない暗号文を生み、
そのコードを信頼できる唯一の根拠である KAT を無効化します。
複合はML-KEMを包みます。決してその内部に手を入れません。

第24章　層2 — 閾値、そして協働が文字通り強さである理由

33の独立に種付けされたインスタンス。セッション秘密は GF(2⁸) 上の Shamir 秘密分散で閾値 k = 17 に分割されます。

性質	保証
秘匿性	16個の侵害インスタンスは何も学ばない——情報理論的に
可用性	16個を失っても鍵は復元できる
集約困難性	33 × 1024 = 33,792 次元の独立な格子困難性

「何も学ばない」は強度の見積もりではなく文字通りです。閾値未満では Shamir はゼロの情報しか漏らしません：
16個の share はあらゆる可能な秘密と整合します。

これは例示ではなく網羅的に検証されました——k=3 について 65,536 通りの係数対すべてを
実際の curzi_split に通し、観測される share への写像が全単射であることを確認しました。
一様な係数は厳密に一様な事後分布を誘導します。

24.1 社会的性質

この層は「より多くの人が協働するほど全員が強くなる」という直観の形式的内容です。
それが修辞ではなく数学的に真である稀な事例の一つです：

n を増やすと攻撃者の必要作業量が増える（侵害すべきインスタンスが増える）
k 固定で n を増やすと、各参加者の個別露出が下がり、耐障害性が上がる

安全性は、各人が単独で守る希少資源ではなく、コミュニティと共に成長する共有資産になります。

24.2 実装ノート

体演算は AES 多項式 0x11b の GF(2⁸)——調整されたものではなく正準。
乗算はキャリーレスのシフト・還元、逆元は254乗による冪。
log/antilog 表は使いません。秘密バイトで索引される表はキャッシュタイミング漏洩だからです。

定数時間性は仮定ではなく逆アセンブルで検証されました：
arm64 -O1 で curzi_gf_mul は15命令、メモリロード0、分岐はループカウンタの1つのみ。
x86-64 -O2 ではループが展開され、7つの cmovne と分岐0になります。

share 添字 0 は拒否されます——f(0) が秘密そのものだからです。

第25章　層3 — 正準符号（E8 と Leech の正しい居場所）

2つの二元符号。それぞれ、既知で最も密な格子の Construction A 符号です：

符号	パラメータ	格子	訂正能力
拡張ハミング	[8, 4, 4]	E8	1誤り
拡張ゴレイ	[24, 12, 8]	Leech (Λ24)	3誤り

6つのゴレイブロックが144ビットフレームを構成：6 × 24 = 144、合計最大18誤りを訂正。

25.1 バックドア不在の指紋

ゴレイ符号は記憶から貼り付けたものではありません。実装は平方剰余構成から生成し、
テストがその重み分布——符号の偽造不能な指紋——を検証します：

重み:  0 → 1     8 → 759     12 → 2576     16 → 759     24 → 1

この759個の重み8符号語は、まさに Steiner 系 S(5,8,24) のオクタッドです。
誤った、改変された、あるいは悪意を持って選ばれた表は、この分布を再現できません。

実施された検証：

4096符号語が相異なることを確認、最小距離がちょうど8
9,523,200回の復号 — 全ての重み0/1/2/3の誤りパターン（2,325通り）× 全4,096符号語
全 C(24,4) = 10,626 の4誤りパターン × 256符号語（訂正半径外の挙動を特徴づけるため）
ハミング符号を GF(2)³ の列から独立に再導出し、出荷表と比較

これが「定数にバックドアは無い」を、受け入れるしかない約束ではなく、第三者が再計算で検査できる主張にします。

25.2 なぜ E8/Λ24 を困難性に使わないのか

暗号学的困難性は構成の性質ではなく、構成の歴史の性質です。

次元。 ML-KEM-768 の実効格子次元は768。公開されたSVP記録は学術ハードウェアで
古典的に180次元を超えています。次元8、24、144の困難性仮定は、量子計算機なしで現在破られます
E8 と Λ24 は最悪の困難性候補です。 数学で最も完全に理解された2つの格子であり、
最適基底・自己同型群・効率的復号器が全て公開されています。
E8 と Leech の高速有界距離復号は、まさにそれらが符号理論で使われる理由です。CVP が容易＝安全性ゼロ。

「不規則性」の追加はこれを修復しません。研究された問題への帰着を破壊し、
暗号解析を一切追加せず、通常は攻撃面を作ります。複雑さは困難性ではありません。

第26章　層5 — 階層アクセスと P2P への帰結

144ドメイン × 61レベルにわたる階層的一方向鍵導出。

ドメインルート：H(system_root ‖ "CURZI-8889-A/domain" ‖ domain)
レベル鍵：H(parent ‖ "CURZI-8889-A/level" ‖ domain ‖ level)、レベルごとに1段連鎖

(ドメイン d, レベル L) の鍵を持てば、ドメイン d 内の L より上の全レベルを導出でき、
それより下は導出できず、他のドメインでは何も導出できません。
降下は計算量的に不可能（各段が原像問題）であり、かつ API で構造的に拒否されます（CURZI_E_TIER_DESCEND）。
1つの付与は32バイトです。

P2P への帰結こそが要点です

コンテンツはチャンク化され、各チャンクは自分の階層鍵で封印されます。
ピアは読めない暗号文を保存・配信できます。
帯域を提供することが平文へのアクセスを意味することは決してなく、
ネットワークは真に社会的でありながらデータは私的なままで、
どの参加者も一部を配信するために全ストアを復号する必要がありません。

26.1 記録された算術の訂正

仕様の初稿は 8,889個の付与可能階層 を主張しつつ、同時に 144 × 61 = 8,784 と記していました。
両方が真であることはあり得ず、階層テストがこの矛盾を検出しました。

格子を選び直しても救えません：8889 = 3 × 2963、2963は素数であるため、
因数対は 1 × 8889 と 3 × 2963 のみ——どちらの因数も 255 以下ではなく、
(uint16 domain, uint8 level) のいかなる矩形もこれを生みません。

解決は、ラベルに合わせて105個の埋め草階層を発明することではなく、仕様を訂正することでした：

量	値
付与可能階層	8,784（144 × 61）
構造ルート（付与されない）	145（1システム + 144ドメイン）
アドレス可能鍵	8,929
8889	この規格の識別名であり、個数ではない

テストは現在これらをハード失敗として表明します。誰かが後に定数を名前に合わせて編集すると
失敗するテストも含まれます。数が間違っていたので、数を変えた——測定を変えたのではない。

第27章　層1・層4 とカーネル統合

27.1 ハイブリッド結合器

K = SHAKE256( label ‖ ss_pq ‖ ss_classical ‖ phase ‖ role ‖ ring ‖ transcript )

出力は両方の共有秘密に依存するため、攻撃者は ML-KEM と X25519 の両方を破らねばなりません。
片方を回復しても、KDF 入力にはまだ32バイトの未知が残ります。

長さ前置の符号化規則（実攻撃を防ぐ）： KDF に渡される全ての可変長フィールドは長さ前置されます。
長さ無しの連結はスタイルの好みではありません：("ab","c") と ("a","bc") は同一バイト列を生むため、
フィールド境界を制御する攻撃者は、異なる2つのトランスクリプトに同じ鍵を導出させられます。

27.2 六位相は五位相である

trit_t は6つの列挙子で5つの状態を表します。TRIT_GLUT(2) は TRIT_GLUT_NEUTRAL(5) の
非推奨の綴りであり、m5_types.h は常設規則を明記しています——
「TRIT_GLUT はどこでも受け入れよ。決して出力するな」、TRIT_CANONICAL_COUNT == 5。

これは装飾的な数え間違いではありません。6つの列挙子に6つの KDF ドメインを割り当てると、
共に「中性」を意図しながら綴りが異なる2つのピアが、異なる鍵を導出し、
理由を説明するものが何も無いまま静かに通信に失敗します。

したがって全ての位相は入口で正規化され、CURZI_PHASES は 5 です。
自己検査のテスト4は GLUT と GLUT_NEUTRAL が同じ鍵を生むことを表明し、
誰かが正規化を除去すると失敗します。

8889階層数と同じ解決：仕様を訂正し、コードをそれに合わせて曲げませんでした。

27.3 カーネル統合 — 起動したカーネル上での実測

CURZI-8889-A は modbind グラフに自らを宣言し、その起動関数が複合自己検査を実行します。
したがって curzi_ready 能力は否定テストが通った場合にのみ提供されます。

arm64 QEMU 上で、このモジュールが存在しなかった同じカーネルと比較した実測：

	導入前	導入後
宣言収集／登録	88 / 88	89 / 89
拒否	0	0
S+ ready	88	89
起動関数実行／失敗	47 / 0	48 / 0

収集と実行の双方が +1、failed=0 であることが、curzi8889a がカーネル内部で立ち上がった証拠です。
curzi8889a_selfcheck() はホスト上だけでなくターゲット上で 0 を返しました。
[BOOT_OK] 到達、LVS バナーゲート通過。

第28章　⚠️ リリースノートの訂正 — 必読

リリースノートの「暗号規格：CURZI-8889-A（統合済み）」節には、実測と食い違う記述があります。
開発者が誤った前提でコードを書かないよう、逐一訂正します。

28.1 存在しない API

grep -rn <name> kernel/ --include='*.c' --include='*.h' による実測：

リリースノートの主張	出現回数	実際
`curzi8889a_hash`（8889ビット素数格子スポンジ）	0	存在しません
`curzi8889a_seal`（ポスト量子対称AEAD）	0	存在しません
`curzi8889a_open`	0	存在しません
`curzi8889a_sign`（耐量子リング署名）	0	存在しません
`curzi8889a_verify`	0	存在しません
`curzi8889a_selfcheck()`	5	実在します（第27章）

28.2 「8889ビット素数格子スポンジ」について

8889 は格子のビット数ではありません。この規格の識別名です。
第26章に示した通り、8889 = 3 × 2963（2963は素数）であり、
(uint16, uint8) のいかなる階層格子もこの数を生みません。
実際の数値は 8,784 付与可能 / 8,929 アドレス可能です。

実装されている困難性は ML-KEM（Module-LWE、格子次元768） であり、
8889ビットの独自格子ではありません。独自格子を実装しなかった理由は第25.2章に述べた通りです。

28.3 「耐量子リング署名」について — 最も重大な訂正

ポスト量子署名方式はこのシステムに一切存在しません。

実測：dilithium、ML-DSA、ml_dsa、sphincs、falcon を含むファイルは0件です。
ツリー内の該当箇所は全てコメント中の願望的記述であり、
あるヘッダは読者に FIPS 204 の参照実装を取得するよう文字通り指示しています。

署名は全て古典的 Ed25519 です。

これは強度パラメータのどれよりも重要です：
認証されない KEM は、どれだけ強くても中間者攻撃を受けます。
認証なき機密性は誰も守りません。33インスタンス閾値ハイブリッドを攻撃者と交渉して確立した鍵は、
攻撃者以外の全員に対して完璧に安全です。

ML-DSA の実装が、残る全項目に優先する次の作業です。

28.4 EFI ブートローダについて

リリースノートは BOOTRISCV64.EFI / BOOTRISCV32.EFI / BOOTARM.EFI を挙げますが、
build_system/mk_efi_disc.sh が生成するのは BOOTX64.EFI と BOOTAA64.EFI の2つだけです。

riscv64 / riscv32 / arm32 は UEFI ディスクではなく、
OpenSBI または -kernel 直接起動で立ち上がります。
deliverable/discs/<arch>/boot.sh にその旨が明記されています
（例：「NOT a UEFI disc (no edk2-riscv on box)」）。

28.5 訂正の文化について

これらを指摘するのは非難のためではありません。
本プロジェクトの PROVENANCE/ は自らの過大主張を少なくとも4回撤回しています——
「5/5アーキテクチャ起動」→「1つのみ検証済み」、フィボナッチ次元主張、
REDUNDANT 判定、音響 DARK→ABSENT。

GEOMETRY_VERIFIED.md は、E8 のシータ級数（240/2160）を厳密に計算して見せた上で、
自らの中心的主張を撤回します：

「フィボナッチ次元の主張——弱い。私は過大主張した。以下が撤回である。」

このツリーで最も価値ある成果物は、その撤回記録です。
本章はその文化の継続であり、逸脱ではありません。

第29章　署名と鍵儀式

オフラインルート方針は実在し、機械的に強制され、production 鍵については意図的に未実行です。

build_system/keyceremony_root.sh：

デフォルトルートが存在する場合は実行を拒否（ネットワーク接続機での生成を防ぐ）
本物の OpenSSL を要求（LibreSSL は Ed25519 の raw 署名ができない）
既存鍵の上書きを拒否
ed25519 -aes256 を生成、chmod 400
key_id = SHA-256(raw pubkey) の先頭8バイト

上書きフラグは 「この鍵は production 級ではない」 と印字します。

build_system/sign_release_offline.sh：

暗号化されていない鍵を拒否（ツリー内開発鍵を指してしまう事故を捕捉するため）
要求全体を印字し、операторに sign と正確に入力させる
署名がちょうど64バイトであることを表明
パスフレーズを argv や環境変数から決して取らない

ダイジェストのみの儀式： ビルドホストはダイジェスト一覧の要求を出力し、
エアギャップを越えるのはそれだけです。成果物は移動せず、鍵は出ません。

正直な状態

production ルート鍵は一度も生成されていません。 PROVENANCE/ にあるのは ROOT_TRUST_ANCHOR.txt.template のみ
カーネルにコンパイル済みのトラストアンカーはテスト用フィクスチャであり production ルートではありません
対話的 run 経路は zsp_verify()（完全性+署名のみ）を使い、バージョン/アーキテクチャ/key-id を強制しません。完全な v2 強制は A/B 更新経路のみ
インストーラの鍵ピン留めは、アンカー未設定時に失敗せず警告します
出荷される全成果物は UNSIGNED であり、そう明記されています

ZSP v2 — 署名付き実行とロールバック防止【実装済】

v2 の署名対象前像は magic、ヘッダ長、ABI、バージョン、アーキテクチャ、能力、ペイロード長、key id、
identity、ペイロードハッシュを覆います。
したがってバージョン・アーキテクチャ・ABI・能力・key id は署名を壊さずに差し替えられません。
zsp_verify2 はさらに key_id == SHA-256(root_pubkey)[0:8]、アーキテクチャ一致、
version >= min_version（確定時に引き上げられる単調ロールバック下限）を強制します。
v1 パッケージは v2 に拒否されます。

第30章　MegaROM / TVUL — 「インターフェースがカートリッジである」

30.1 TVUL コンテナ【実装済】

バイト像の上のセクションディレクトリであり、そのディレクトリが含意する RAM ワーキングセットの導出です。
明示的にローダではありません：「ここでは何も確保せず、展開せず、描画せず、起動しない。」

ヘッダ60バイト：magic TVUL、バージョン、role（三空間の面）、セクション数、
向きルート、hoard レベル、チャンクサイズ、32バイト witness、
そしてヘッダとセクション表全体を覆う切り詰め SHA-256d 封印
セクションエントリ48バイト：kind, form, residency, channel, 予約（0必須）, offset, stored, 32バイトダイジェスト
WORLD セクション内の世界グラフ「hoard」：hold（進入可能な場所——hold はアプリケーションである）と
gate（コストと可視性を持つ有向辺）。上限：128 hold、512 gate

RAM は宣言されず導出されます。 ram_bytes フィールドは存在しません。
ストリーミング予算は hold にわたる1ステップ近傍の最大値であり、総和ではありません。
フレーム／AI 予算は呼び出し元が実ハードウェアから供給し、既定値はありません。

16の拒否理由、34の変異テスト。 各テストは拒否と正確な期待コードと
拒否画像で RAM 値が0を返すことを要求します。

一つの導出、二つの担体： ホストツール mk_megarom.c はカーネルと同じ翻訳単位をリンクし、
自身のパーサが拒否するものは書き出しません。

30.2 起動時統合【実装済・観測済】

tvl_rom.c は5つ全てのアーキテクチャの Makefile に含まれます。
arm64 と x86_64 は boot_features_init → tvl_bringup 経由で登録し、
riscv と arm32 は tvl_rom_register_boot() を直接呼びます（その init が起動経路上に無いため）。

5アーキテクチャ全てで実際に観測：

[MEGAROM] slot N: 'TOL VOVINA UPAAH LOT' — MR_KIND_GAME registered
          (container embedded; identical bytes on attached virtio-blk drive
          as MEGAROM.TVL); registry count=1

30.3 【設計のみ】— 決定的な区別

「インターフェースが MegaROM である」は現時点でタグライン文字列であり、コードパスではありません。
以下の各欠落は、隠されているのではなくソース自身に明記されています。

活性化フックは何もしません。 static void tvl_boot(void){ g_boots++; } — コメント付き：「これは世界を画面に出さない」
全てのカートリッジ起動フックが空のスタブです — Cinder、Quill、次元デスクトップ、TVUL
デスクトップは無条件に描画されます — 直接呼び出しで、レジストリを完全に迂回
解析された世界を読むものが何もありません — hold/gate/RAM アクセサはモジュール外に呼び出し元ゼロ
ディスク読み出し経路がありません — 登録されるのは埋め込みの双子
出荷される世界は content ではなく probe です — 3 hold、3 gate、埋め草バイト
カートリッジ選択 UI は存在しません

また PROVENANCE/TVUL_ROM_FORMAT.md は実装に対して陳腐化しています
（44 vs 48バイトのセクションエントリ、展開後 vs 保存バイトのダイジェスト、CRC vs 封印）。コードを信頼してください。

第31章　コンソールエミュレーションと Game Master

31.1 7コア・7機種【実装済】

6502、Z80（CB/ED/DD/FD プレフィックスページ付き）、65816、LR35902、ARM7TDMI、68000、HuC6280 が
NES、SMS、SNES、Game Boy、GBA、Genesis、PC Engine を駆動します。

machine_t の vtable はありません。 共有契約は規約です：
各コアが reset/step/interrupt をread/write コールバック対の上に公開するため、
それらを差し替えるだけで同じコアが全システムに写ります。

31.2 生存判定は挙動ベース — その論理が良い

各機種は「動いているか？」を命令数ではなく
PPU/VDP/VDC 設定済み + フレーム同期観測 + 割込受理から報告します。
理由が記録されています：6502 は不正命令を NOP するため、ランダムデータでも予算を使い切ります。
実際に効く判別子は不正命令率——ノイズで約50%、実ROMで約0%です。

31.3 【部分的】適用範囲の制限 — 正直な見出し

7機種すべてが「init とメインループを走らせ生存を証明する」エミュレータです。ゲームフレームを1枚も描画しません。
kernel/src/emu/ のどこにも PPU/VDP/VDC のピクセルパイプラインは存在しません。
各機種のヘッダが自らの欠落を명記しています（NES はマッパー0のみ、SNES は SPC700 も実PPUもDMAも無し、GBA の SWI は no-op、等）。

31.4 M5-RELATE

互換性のない2つのコア（6502 と Z80）を共有プローブ上で並列実行し、
その関係を M5 5-tuple として分類します。論理成分は実トリットです：
TRUE（協和）、GLUT±（矛盾）、FALSE（不在）。
直交性は構造的です——各軸は2実行の互いに素なスライスから計算されるため、
「論理軸は文字通りクロックを見ることができません」。

31.5 Game Master

ROM を virtio-blk 経由でカーネルに投入し、カーネル障害を監視するホストハーネス。
実測キャンペーン（gamemaster_logs_33k_v9/summary.txt）：

16,200 実行 · 16,198 合格 · カーネル障害 2 ·
S+ 8,120（障害2）/ S− 8,080（障害0）· ホットスポット proc_restore_el0 +0x2c, +0x3c

ハーネスには重要な正直さの性質があります：--preflight は、カーネルが
[WATCH]/[ARMED] の爆弾処理マーカーを出力しない限り実行を拒否します。
それらが無ければ全実行がコーパス全体にわたって偽の CLEAN を報告するためです。

第32章　グラフィックスとレンダリング

モジュール	状態	内容
Cinder	【実装済】	列レイキャスタ、16.16固定小数、手続き的テクスチャ、libm不使用。GPLクリーンな再実装であり id Tech は開発上の参照のみ
Quill	【実装済】	ピクセル単位Zバッファ、透視補正テクスチャ、ライトマップ、全て整数
render_lineage	【実装済】	レンダラではない——エンジンごとの8次元能力署名で、ライセンスにより統合可否をゲート：許容的2 / コピーレフト1 / プロプライエタリ0＝拒否
`tvl_geom`	【実装済】未配線	E8/icosian 構成から厳密 ℤ[φ] で二十面体向きフレームを導出。環を出るのは投影の一度だけ
`tvl_raster`	【実装済】未配線	整数三角形ラスタライザ。64ビット可変除数をどこにも使わないため `__udivdi3` が出ない
`tvl_stereo`	【実装済】未配線	通常の1フレームバッファ上の補色チャネルステレオ。S+ が手前、S− が奥、S0 は視差ちょうど0を返し非ステレオ画素をバイト単位で再現
ramfb + virtio-input	【実装済】	fw_cfg DMA フレームバッファ、キーボード/マウス
`zxv_shell`	【実装済】	約49KBの整数コンポジタ。Fruit-of-Life 幾何上の13空間ラティス、Metatron 隣接、実辺に沿った cos²θ 最大化による方向ナビ

13のラティス空間は本当に生きています — 空間に入ると実サブシステムAPI
（vino_transfer、art_fill_rect、wyrm_judge、br_price_capital_future、badge_score 等）を呼びます。
モックテキストではありません。

32.1 レンダリング適用範囲 — 実測、そして不均一

「5アーキテクチャで起動する」は「5アーキテクチャで描画する」を意味しません：

アーキテクチャ	フレームバッファ立ち上げ	状態
arm64	`kernel_main_arm64.c` の完全経路：`pb_render_frame` → `zxv_display_negotiate`（GOP ハンドオフがあればそこから、無ければ裏付け可能な最大モード。ハードコード無し）→ GOP fb 採用または fw_cfg DMA 経由 `ramfb_init` → `vbe_init_fb` → `zxv_shell_frame` + `lattice_dim_render` → `zxv_present`	【実装済】実証済
riscv64 / riscv32 / arm32	`zxv_render_boot()`（`kernel/src/desktop/render_boot.c`）。全アーキテクチャにリンクされながら arm64 からのみ呼ばれていた連鎖に対する共有呼び出し点	【実装済】配線済
x86_64	無し。メインに ramfb/vbe/scanout/present への参照ゼロ。EFI スタブは GOP を探さず bootinfo も公開しない	未配線

描画の証明（arm64）： -device ramfb -display none と QEMU モニタソケットで起動し screendump を送信 →
2560×1440 の P6 PPM で、サンプル画素が 4,726色に分布。
空白や単色塗りではこの分布は生じないため、インターフェースは実際に描画されました。

32.2 発見され修正されたハング

kernel/arch/arm64/efi_stub.c は GOP を必須として扱い、LocateProtocol が EFI_NOT_FOUND を返すと
for(;;) __asm__("wfi") に入りました。ディスプレイデバイスの無いマシンは UEFI 下で一切起動しませんでした。

現在 GOP は任意です——スタブはヘッドレスシリアル起動に劣化し、
固定ハンドオフアドレスの古い値がフレームバッファと誤読されないよう bootinfo 番兵を明示的にゼロ化します。
両方の経路が boot_test_mac.sh の恒久的な行になっています：
ヘッドレス（ディスプレイデバイス無し、ハングしてはならない）と GOP（virtio-gpu-pci、ハンドオフ取得）。

第33章　貢献の指針と残作業

33.1 較正のための2つの数値

5アーキテクチャ6行中6行が、拒否された宣言0で合格。 本当に、再現可能に、主張する全ての場所で起動します
kernel/src の 2,369 シンボル中 1,679（70.9%）が --gc-sections で破棄されます。 書かれたコードの約70%はバイナリに入っていません

両方とも真です。どちらも他方を打ち消しません。

33.2 到達可能性（実測）

kernel_arm64.elf で定義済み2,301シンボル中628が到達可能。1,673（73%）が破棄
非テスト .c 278ファイル中123（44%、約41,000行）がバイナリに不在
完全に到達可能なファイルは30のみ、部分的が125
最悪例：digital_dna.c 59/60が死、holo.c 48/49が死、surplus.c 24シンボル中23が死
ディレクトリ粒度の全アーキテクチャ横断カバレッジ：126/168 = 75%。シンボル粒度：1,348/5,271 = 25.6%

33.3 仕様対バイナリ

15の仕様文書のうち3つを監査した43の能力主張：
2 LIVE（4.7%）、13 PARTIAL（30.2%）、9 DARK（20.9%）、19 ABSENT（44.2%）。12文書は未監査。

33.4 消費者準備度 — プロジェクト自身の監査

起動と実行15%、データ安全性12%、セキュリティ姿勢22%、加重約16%——
明示的に「楽観的な上限であり中央値ではない」。
判定：「否。これは今日消費者に出荷できるものではなく、その近くにもない。」

33.5 「配線されているが実際には動いていない」一覧

項目	実態
位相則	結合を測定する。起動をゲートできない（第14章）
`modbind_verify` のポート側	フィクスチャに対してのみ検査。出荷グラフに対しては一度も
UI としての MegaROM	フォーマットは実装済。全起動フックが空のスタブ
`tvl_geom`/`raster`/`stereo`	実装・自己検証済、外部呼び出し元ゼロ
Chiglet	`chg_infer` がバイナリに不在。能力0で呼ばれる
ML-KEM	実装・KAT検証済。CURZI 以外の消費者は起動自己テストのみ
PQ 署名	存在しない。署名は全て Ed25519
production ルート鍵	一度も生成されていない（意図的）
コンソールエミュレーション	生存判定のみ。フレームを描画する機種は無い
セル	グラフ閉包。単体でコンパイル・起動されたセルは無い
ユーザーコピー強化	arm64 のみ
x86_64 レンダリング	未配線
`kernel/arch/arm/`	死んでいる——グラフ無し、ゲート無し、キャリア無し

33.6 引用してはいけない陳腐化した成果物

PROVENANCE/build_all_output.txt（08:04Z）は RISC-V リンカ修正と5アーキテクチャ再ビルドより前です。ELF サイズがどの出荷成果物とも一致しません
リポジトリルートの kernel_arm64.elf は現在の modbind 作業より前です。nm に mb_real_power も zxv_decl_boot_gate も無く、宣言セクションは88ではなく13ポインタです
PROVENANCE/TVUL_ROM_FORMAT.md は実装に対して陳腐化しています

33.7 GC_ROOTS の禁止事項 — 到達可能性を「修正」する前に読むこと

GC_ROOTS は意図的に空です（Makefile.arm64:166-180）：

「ルートを残せば、その連鎖が動くか否かに関わらず nm が『存在する』と言うようになる——
このゲートの要点は、保持が使用を偽装できてはならないということだ。」

参照されないモジュールを ELF に出現させるために -Wl,--undefined= を追加してはいけません。

「全モジュールを存在させる」はリンカフラグでは達成できません。
一部のモジュールは __muldc3 / __fixunsdfdi / __udivti3 を引きます——
freestanding 32ビットターゲットに存在しない libgcc の浮動小数点／128ビットヘルパです——
強制的に入れるとイメージが壊れます。
本当の道は、それらのモジュールを整数／Q32.32 演算に書き直すことです。モジュール単位で、実測しながら。

33.8 優先順位付きの残作業

ML-DSA（FIPS 204） — 他の全てに優先します。認証されない KEM は中間者攻撃を受けます
ML-KEM-1024 パラメータセットの配線（ベクタ取得済）
x86_64 のレンダリング経路配線
MegaROM レジストリ → レンダラの接続（カートリッジ起動フックの実装）
modbind_verify のポート側を出荷グラフに対して実行
エクステントアロケータ → 三対書き換えのアトミック化
arm64 以外へのユーザーコピー強化の展開
verify-experimental の Ed25519 KAT を必須ゲートへ移動

33.9 読み始める順序

kernel/include/zxv_decl.h — 宣言マクロと、なぜ位相が生成されるのか
kernel/src/modbind/modbind.c — 結合則、不動点、保留分類
kernel/src/modbind/zxv_decl_gate.c — 起動が実際に強制するもの
kernel/src/zab/zab.h — ツリー内で最良の論証（なぜ GRANT 命令が無いのか）
kernel/src/curzi/curzi8889a.h — CURZI-8889-A の形式仕様
kernel/src/tolvovina/tvl_rom.h — コンテナと「宣言せず導出する」規律
build_system/build_all.sh — 再現の入口点と、その判定規律
PROVENANCE/GEOMETRY_VERIFIED.md と CONSUMER_READINESS_AUDIT.md — 証拠水準を最もよく示す2文書。どちらも著者自身の主張を撤回しているため

結び — 本ガイドの姿勢について

本作業で最も価値ある成果は、新しい構成ではありませんでした。
オペレーティングシステムの暗号基盤が、その存在期間の全体にわたって、
全アーキテクチャ・全ハッシュで誤った出力を生み続けていたこと、
そしてコードベースの全ての自己整合性テストがその間ずっと成功を報告していたことの発見でした。

それが本システムの設計思想全体への論拠です。

安全性は、外部の公開された基準に対する測定から生まれる。
内部の一致からは決して生まれず、設計の洗練からも決して生まれない。
自分自身に対して自分を検査するシステムは、たまたま自分がしていることが何であれ、それを是認する。

本ガイドの全ての数値は、記載日時にコードを実行して得られたものです。
実装されていないものについては、実装されていないと明記しました。

著作者：H.M. Michael-Laurence Curzi (c) · 36N9 Genetics, LLC — 取消不能、次元間
ライセンス：OPL-1.1 + CC BY-SA 4.0 + シチリア王冠の王令 + SEL-3.3（Share-alike はバイナリと共に旅する）

https://github.com/sykomiked/ZXV & https://zenodo.org/records/21897602 & https://codeberg.org/36n9gen/ZXV/src/branch/main/ & IPFS bafybeiczex44xz7kre4xdq2akfunedpuwfpldqtqauw2kewybsz2foyld4 & IPFS bafybeieuscjtce6vrj5jub4dwypyrhe54ovrgbwfrru56zczkyubc4rqum & https://sourcecraft.dev/mlcurzi-gmail-com/zxv/

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up

ZEDEC pqOS / ZXV — 開発者ガイド・アーキテクチャ解説（全33章）

ZEDEC pqOS / ZXV — 開発者ガイド・アーキテクチャ解説（全33章）

本書について — 最初に読んでください

⚠️ 重要：リリースノートとの相違について

第1章 全体像 — ZXVとは何か

第2章 ビルドと起動 — 全てを再現する

会計規律（build_all.sh:18-20）

第3章 検証マトリクス — 実測値

重要な限定

第4章 コードベースの形

ディレクトリ地図

第5章 マルチカーネル設計

第6章 4つのメインに共通するもの・異なるもの

共通

異なる点

第7章 宣言グラフ — システムの中核

7.1 これが解決する問題

第8章 ZXV_DECLARE マクロ

なぜ「レコード」ではなく「ポインタ」なのか

補助マクロ

第9章 位相 — 誰も入力しない唯一の数値

却下された3つの代替導出（gen_phase_table.sh:13-33）

⚠️ 実践的な落とし穴（本セッションで実測）

第10章 起動ゲート

手順

第11章 3つの失敗クラス

第12章 HELD は FAILED ではない

第13章 位相結合則

第14章 準備完了不変量 — そして正直な帰結

帰結：位相だけでは回路を開くことができず、準備完了を変えることもできません。

実測（arm64）

第15章 三空間（Tri-space）

第16章 ZAB — GRANT命令を持たない理由

安全性の背骨

ZCA との対比

第17章 三対をストレージ単位とする（zxvfs_tri）

【部分的】ソースに明記された制限

第18章 メモリ管理と MMU

注目すべき設計点：正直な能力会計

アロケータ、そしてアロケータでないもの

第19章 W^X と EL0 ユーザーコピー — arm64 のみ

明記すべき欠落

主張されているメモリ安全性

第20章 暗号 — 実装されているもの

第21章 Keccak の重大バグ — 本ガイド最重要の章

21.1 何が間違っていたか

21.2 なぜ何も検出しなかったか

自己整合性は一様な誤りを検出できない。公開された解答だけがそれを検出できる。

第22章 ML-KEM-768 と NIST ACVP 既知解テスト

なぜ改竄暗号文ケースが最重要か

第23章 CURZI-8889-A — 層構成

主張すること、拒否すること

23.1 層0 は不可侵

第24章 層2 — 閾値、そして協働が文字通り強さである理由

24.1 社会的性質

24.2 実装ノート

第25章 層3 — 正準符号（E8 と Leech の正しい居場所）

25.1 バックドア不在の指紋

25.2 なぜ E8/Λ24 を困難性に使わないのか

第26章 層5 — 階層アクセスと P2P への帰結

P2P への帰結こそが要点です

26.1 記録された算術の訂正

第27章 層1・層4 とカーネル統合

27.1 ハイブリッド結合器

27.2 六位相は五位相である

27.3 カーネル統合 — 起動したカーネル上での実測

第28章 ⚠️ リリースノートの訂正 — 必読

28.1 存在しない API

28.2 「8889ビット素数格子スポンジ」について

28.3 「耐量子リング署名」について — 最も重大な訂正

28.4 EFI ブートローダについて

28.5 訂正の文化について

第29章 署名と鍵儀式

正直な状態

ZSP v2 — 署名付き実行とロールバック防止【実装済】

第30章 MegaROM / TVUL — 「インターフェースがカートリッジである」

30.1 TVUL コンテナ【実装済】

30.2 起動時統合【実装済・観測済】

30.3 【設計のみ】— 決定的な区別

第31章 コンソールエミュレーションと Game Master

第1章　全体像 — ZXVとは何か

第2章　ビルドと起動 — 全てを再現する

第3章　検証マトリクス — 実測値

第4章　コードベースの形

第5章　マルチカーネル設計

第6章　4つのメインに共通するもの・異なるもの

第7章　宣言グラフ — システムの中核

第8章　ZXV_DECLARE マクロ

第9章　位相 — 誰も入力しない唯一の数値

却下された3つの代替導出（`gen_phase_table.sh:13-33`）

第10章　起動ゲート

第11章　3つの失敗クラス

第12章　HELD は FAILED ではない

第13章　位相結合則

第14章　準備完了不変量 — そして正直な帰結

第15章　三空間（Tri-space）

第16章　ZAB — GRANT命令を持たない理由

第17章　三対をストレージ単位とする（zxvfs_tri）

第18章　メモリ管理と MMU

第19章　W^X と EL0 ユーザーコピー — arm64 のみ

第20章　暗号 — 実装されているもの

第21章　Keccak の重大バグ — 本ガイド最重要の章

第22章　ML-KEM-768 と NIST ACVP 既知解テスト

第23章　CURZI-8889-A — 層構成

第24章　層2 — 閾値、そして協働が文字通り強さである理由

第25章　層3 — 正準符号（E8 と Leech の正しい居場所）

第26章　層5 — 階層アクセスと P2P への帰結

第27章　層1・層4 とカーネル統合

第28章　⚠️ リリースノートの訂正 — 必読

第29章　署名と鍵儀式

第30章　MegaROM / TVUL — 「インターフェースがカートリッジである」

第31章　コンソールエミュレーションと Game Master

第32章　グラフィックスとレンダリング

第33章　貢献の指針と残作業