矛盾許容（パラコンシステント）決済アーキテクチャの完全解説

Posted at 2026-10-23

矛盾許容（パラコンシステント）決済アーキテクチャの完全解説

— 四値論理による決済不変条件とNEARブロックチェーン上の実装（ZXV）—

著者: ZXVプロトコル開発チーム（ZEDEC / 36N9 Genetics, LLC）
公開: Qiita（技術記事）
最終更新: 2026年10月22日
対象読者: 分散システム設計者、スマートコントラクト開発者、形式論理に興味のあるエンジニア

要旨（Abstract）

本稿は、矛盾許容論理（paraconsistent logic） に基づく決済アーキテクチャを理論と実装の両面から完全解説する。従来の分散システムは「真実の競合」に直面したとき、凍結・最終書き込み優先・多数決による強制・パニックのいずれかで対処するが、いずれも矛盾をバグとして扱う。これに対し、矛盾許容論理は矛盾を情報として扱う。本稿で解説するアーキテクチャは、四値論理（TRUE / FALSE / NEITHER / BOTH） により「真のみが決済される（only TRUE settles）」という不変条件を実現し、矛盾を記録・保持しつつ強制しない。この理論は、NEARブロックチェーン上に実装されたZXVプロトコル（110キット・136ケイパビリティ・単一マイクロコントラクト）として実際に稼働しており、敵対的監査（ゼロバグ）を通過している。本稿では、理論基盤、アーキテクチャ、各コンポーネントの実装詳細、検証方法、品質保証の全容を解説する。

はじめに：分散システムが直面する「真実の競合」
矛盾許容論理の理論基盤
- 2.1 古典論理の限界
- 2.2 四値論理（Belnap型の拡張）
- 2.3 決済不変条件：only TRUE settles
アーキテクチャ設計
- 3.1 全体構成
- 3.2 単一マイクロコントラクト方式
- 3.3 状態互換アップグレード方式
コンポーネント詳細
- 4.1 ゲート（Gate）：決済の中核
- 4.2 トレジャリー（Treasury）：労働基盤型経済
- 4.3 レール（Rails）：カードネットワーク
- 4.4 レシート（Receipts）：ハッシュチェーン監査台帳
- 4.5 ヴェネツィア・ガスステーション（Venice Gas Station）
- 4.6 ネオ・シチリア港（Port of Neo-Sicily）：外部レジストリ
- 4.7 YHVH循環（YHVH Circulation）
- 4.8 流動性プール（Liquidity Pool）
- 4.9 ソブリン令（Sovereign Decrees）：フォークなきフォーク
- 4.10 ユニバーサルインターフェース（Universal Interface）
実装詳細
- 5.1 スマートコントラクト構成
- 5.2 状態管理とストレージ
- 5.3 イベントと監査
- 5.4 ガス効率とコスト設計
検証と品質保証
- 6.1 QCハーネス（カーネルCソースとの照合）
- 6.2 敵対的監査
- 6.3 ガス壁テスト
- 6.4 登録監査
NEARブロックチェーン上の展開
- 7.1 契約アドレスとルーティング
- 7.2 カノニカルアドレス：zedec.near
- 7.3 オンチェーン文書化
今後の展望
結論
付録：検証コマンド集

1. はじめに：分散システムが直面する「真実の競合」

あらゆる分散システムは、最終的に同じ壁に直面する。複数の情報源が真実をめぐって対立したとき、システムはどう対処すべきかという問題である。

従来の解決策は、いずれも失敗モードの変種である：

戦略	挙動	問題点
凍結（Freeze）	取引が停止し、台帳がロックされる	不一致がデッドロックになる
最終書き込み優先（Last-writer-wins）	最新の主張が古い主張を黙って上書き	不一致がデータ消失になる
多数決による強制（Majority coercion）	最大票が紛争を強制的に解決	不一致が真実ではなく権力になる
パニック（Panic）	コントラクトが例外を投げ、状態を巻き戻す	不一致が例外になる

これら四つの戦略はすべて、矛盾をバグとして扱う。どれも、矛盾が内包する情報を保存しない。本稿で解説するアーキテクチャは、この前提そのものを覆す。

2. 矛盾許容論理の理論基盤

2.1 古典論理の限界

古典二値論理（排中律）では、任意の命題Pに対して「Pまたは¬P」が必ず成立する。すなわち、矛盾（P∧¬P）は爆発原理（principle of explosion） により、そこから任意の命題が導出可能となる。分散システムにこれを適用すると、矛盾を検出した時点でシステム全体が無意味になる（爆発する）ため、実装側は矛盾を検出した瞬間に凍結・強制・パニックのいずれかで回避せざるを得ない。

2.2 四値論理（Belnap型の拡張）

矛盾許容論理の代表的な形式として、Belnapの四値論理がある。本アーキテクチャはこれをチェーン整合性のために拡張した四値状態を採用する：

状態	値	意味	挙動
`TRUE`	0x01	合意・証明済み	決済される
`FALSE`	0x02	明示的に反駁済み	拒否される
`NEITHER`	0x00	未だ証拠なし	待機する
`BOTH`	0x03	矛盾・保持	記録され、決して強制されない

重要なのは、結合演算（conjoin）がBelnapの束（lattice）そのままではなく、カーネルのチェーン順序に従う点である。すなわち、BOTHやNEITHERがTRUEになることはない。これにより、以下の不変条件が成立する：

真のみが決済される：矛盾の上では何も動かない。
BOTHは吸収的：多数決は記録済みの矛盾を強制できない。いかなる投票もBOTHをTRUEにできない。
不一致は破壊されず記録される：紛争は証拠として監査台帳に入る。

2.3 決済不変条件：only TRUE settles

本アーキテクチャの核心は、次の不変条件である：

only TRUE settles. TRUE + FALSE = BOTH — contradictions are recorded,
never coerced, never a panic.

（真のみが決済される。真＋偽＝真偽両値——矛盾は記録され、決して強制されず、パニックにならない。）

この不変条件により、以下の性質が保証される：

紛争時の決済：支払いやエスクローで紛争が発生した場合、「資金を保持し、紛争を記録し、証拠が解決するまで待つ」—「最後に押した者に解放する」でも「永久ロック」でもない。
オラクルの競合：二つの価格オラクルが対立する場合、無意味な平均値に潰すのではなく、矛盾を保持する。
マルチエージェント協調：異なる信念を持つ自律エージェントが、グローバルな合意ハンマーなしに取引できる。各矛盾は記録され、真の合意のみが価値を動かす。

3. アーキテクチャ設計

3.1 全体構成

本アーキテクチャは、以下の階層で構成される：

発見（Discovery）     → レジストリ（136ケイパビリティ）
決済（Settlement）    → ゲート（真のみが決済される）
通貨（Money）         → トレジャリー（50/25/15/10 労働基盤型経済）
同一性（Identity）    → レール（Dragon/Phoenix/Thunderbirdカード）
監査（Audit）         → レシート（ハッシュチェーン台帳）
実行（Execution）     → ヴェネツィア・ガスステーション（TRUEで2倍マッチ）
誘因（Incentives）    → 報酬（rewards）+ プレイヤー（player）
運用（Operations）    → ops（境界・レート制限・タイムロック）
アクセス（Access）    → ユニバーサルインターフェース
相互運用（Interop）   → ブリッジ（任意のリレイヤーが実装可能）
知能（Intelligence）  → AI層（chiglet DNA + aipiエスクロー）

3.2 単一マイクロコントラクト方式

本アーキテクチャの特徴の一つは、110キットを単一のマイクロコントラクトに集約している点である。従来の「機能ごとに別コントラクト」方式と比較して：

ストレージ費用の大幅削減（初期の約72万バイト/7.21 NEARから約15万バイト/1.50 NEARへ）
単一のランタイム・単一のストレージ支払い
名前空間化されたメソッド（gate_*, treasury_*, port_*, sd_* など）

3.3 状態互換アップグレード方式

本アーキテクチャの重要な設計原則は、状態互換（state-compatible）アップグレードである：

シリアライズされたトップレベル構造体を変更しない
新機能の状態は既存のストアマップの予約済み名前空間に格納する
メソッド追加のみでアップグレードする

これにより、デプロイ済み状態を破壊することなく、無制限に機能を追加できる。過去に構造体にフィールドを追加してBorsh状態のデシリアライズに失敗した事例があり、以後この原則が厳守されている。

4. コンポーネント詳細

4.1 ゲート（Gate）：決済の中核

ゲートは四値論理の決済判定を提供する：

conjoin(inputs) → 結合結果（4値）
is_settleable(state) → state == TRUE の場合のみ true

検証例（オンチェーン、ガス不要）：

conjoin {"inputs":[1,2]} → "FALSE"（TRUE＋FALSE＝FALSE）
is_settleable {"state":"BOTH"} → false（矛盾は決済されない）
is_settleable {"state":"TRUE"} → true（合意は決済される）

4.2 トレジャリー（Treasury）：労働基盤型経済

トレジャリーは労働基盤型（work-based） の経済を実装する：

報酬は検証済みレシートごとの報奨金（bounty）として支払われる
労働者は没収可能な保証金（slashable bond）を預ける
アイドル資本には何も支払われない（Howeyテスト第4要素に対応）
配分は 50/25/15/10 の労働報奨金ルールに従う

4.3 レール（Rails）：カードネットワーク

レールは、ISO/IEC 7812の外部にある20桁のLuhn検証可能なカード番号を発行する：

ネットワーク	プレフィックス	内部チェック
Dragon	`8809`	ISO/IEC 7064 MOD 11,10
Phoenix	`8829`	Damm
Thunderbird	`8849`	Verhoeff

4.4 レシート（Receipts）：ハッシュチェーン監査台帳

レシートはハッシュチェーンとして連結され、すべての決済が検証可能である：

verify_chain {"from":0} → true（全レシートが連結検証される）

4.5 ヴェネツィア・ガスステーション（Venice Gas Station）

自己資金型実行エンベロープ（Self-Funded Execution Envelope）：

クレジット台帳：ユーザーはNEAR/wYHVHを専用の実行残高（ガスエンベロープ）に預け入れる。自己完結型エスクローであり、再担保化（rehypothecation）されない。
マッチルール：状態がTRUEで決済された場合、プロトコルは15%インフラプールからガス負担の50%をマッチする（実効2倍）。
ドレインシールド：BOTH/FALSEではマッチを放棄し、ユーザーが100%を支払う（無料グリーフィングの防止）。
30%ガス還付ループバック：NEARプロトコルの焼却ガス30%還付をマッチリザーブに循環させる。

検証済みの経済性：TRUEでマッチ500（2倍）、BOTHでマッチ0（ドレインシールド）。

4.6 ネオ・シチリア港（Port of Neo-Sicily）：外部レジストリ

外部レジストリであり、内部の136ケイパビリティとは分離されている：

port_register — DAO/プロトコルが外部登録（アカウントごとに1件、重複防止）
port_plugin — プロトコルが自前のアプリケーションプラグインを形成
port_lookup / port_count / port_open — 共有空間の参照

4.7 YHVH循環（YHVH Circulation）

持続可能かつ労働基盤型のトークン循環：

オンボーディング付与：初回のみ5,000 YHVH（プラットフォーム内で使用可能、譲渡不可。ウォレットスパム対策）
エポック発行：循環供給量の年2%の上限付き発行（インフレ防止）
労働報奨金：検証済みアクションごとの報奨金（aipi_quorum 100, port_dao 200）

4.8 流動性プール（Liquidity Pool）

エコシステムへの参入口：

pool_provide — プロバイダーが流動性を追加
pool_quote — 0.08889%の保証トールを適用したスワップ見積もり
pool_enter — プールを通じてエコシステムに参入

4.9 ソブリン令（Sovereign Decrees）：フォークなきフォーク

本アーキテクチャのガバナンスはフォークなきフォーク（forks without forking） を実現する：

sd_issue — 個人が自らのソブリン令（改善提案）を発行。発行者と署名者に適用
sd_sign — 令への署名（適用者のレジストリ）
sd_shift — 遵守対象の令を自由に切り替え（往復可能、履歴はジャーナル化）
sd_prefabs / sd_choose — 6種類の既製構成（sovereign-default, conservative-treasury, maximal-gas-match, low-toll-community, work-first-bounties, paraconsistent-pure）
sd_require / sd_check — プロトコルが参加に令ファミリーを要求

なぜ「フォークなきフォーク」か：令Aが一方を、令Bが反対を主張しても、両方が存在し、両方が遵守者にとって有効である。矛盾許容ゲートは矛盾を強制解決せず、人々は自由に移行できる。並列的なガバナンス共同体が同一チェーン上に共存する。

4.10 ユニバーサルインターフェース（Universal Interface）

任意のクライアント（最も単純なボットから最先端のAI、最良の人間オペレーターまで）が同一の自己記述インターフェースを読む：

ux_manifest → システム全体のスキーマ
ux_help {"topic":"start"} → 5ステップのオンボーディング
ux_help {"topic":"onboard"} → YHVH取得方法
ux_help {"topic":"port"} → ネオ・シチリア港
ux_help {"topic":"pool"} → 流動性プール
ux_help {"topic":"sd"} → ソブリン令
ux_help {"topic":"gas"} → ヴェネツィア・ガスステーション

5. 実装詳細

5.1 スマートコントラクト構成

カノニカルアドレス：zedec.near（ルーティングコントラクト、全プロトコルへの入口）
プロトコルアドレス：f18889ea8bc108de53b899df3a3417c76995cbb55fb2174ff08d2e0abee99bcf（110キット）
レジストリ：7eaa2c6f37ef7dd1dc073c4630533b67f303274d31d411e4047eb0d9401ef01a（136ケイパビリティ）
ゲート：6ca890f766fdaeccd6c934da325f5f06ebc63ca9be4f5f1b44d0686af93c64a8

5.2 状態管理とストレージ

すべてのキット状態は既存のストアマップの予約済み範囲に格納
構造体は不変（状態互換原則）
ストレージコストは機能ごとに約2KB単位で増加

5.3 イベントと監査

NEP-297形式のEVENT_JSONをすべての状態変更で発行
ハッシュチェーン台帳（レシート）が全決済を連結

5.4 ガス効率とコスト設計

内部エンベロープ論理は < 1.2 Tgas
全体の実行は < 10 Tgas
読み取りはすべてガス不要（ビューコール）

6. 検証と品質保証

6.1 QCハーネス（カーネルCソースとの照合）

QCハーネスは、実際のCカーネルソースを参照オラクルとして照合する：55/55 PASS、ゼロバグ。

6.2 敵対的監査

完全オンチェーン監査：24/24 PASS（全レイヤーをライブ検証）
耐久性ストレステスト：70/70 継続呼び出し、ゼロ失敗

6.3 ガス壁テスト

読み取り専用：125/125 有効呼び出し、ガス壁なし
書き込みパス：10/10 サイクル（ストレージ壁は資金補填で解決、整合性保持）

6.4 登録監査

136/136 ケイパビリティが既知の稼働中コントラクトに解決

7. NEARブロックチェーン上の展開

7.1 契約アドレスとルーティング

カノニカルアドレスzedec.nearは、ライブコントラクトとして全プロトコルにルーティングする：

zedec.near → route() → 完全なトポロジー
zedec.near → protocol_meta() → 公開レコード
zedec.near → is_settleable() → 不変条件

7.2 カノニカルアドレス：zedec.near

zedec.nearはライブのルーティングコントラクトであり、以下の完全なトポロジーを返す：

canonical=zedec.near|registry=7eaa2c6f...|gate=6ca890f7...|core=f18889ea...

7.3 オンチェーン文書化

完全マスターマニュアルがオンチェーンに保存されている
パラコンシステント論理の解説記事もオンチェーン化
フォレンジック台帳（§1-§62）が完全な履歴を記録

8. 今後の展望

NEP（NEAR Enhancement Proposal）提出：正式な標準化パイプラインへの参入
外部パートナーの参入：ネオ・シチリア港への実DAO登録、流動性プールへの実供給
インデクサー連携：NEP-297イベントを消費するインデクサーの構築
クロスチェーン展開：ブリッジ標準の実装拡大

9. 結論

本稿では、矛盾許容論理に基づく決済アーキテクチャを理論と実装の両面から解説した。四値論理による「真のみが決済される」という不変条件は、分散システムが伝統的に回避してきた「真実の競合」問題に対して、凍結・強制・パニックではなく情報としての記録という解答を与える。この理論はNEARブロックチェーン上に110キット・136ケイパビリティの実装として稼働しており、ゼロバグの敵対的監査を通過し、カノニカルアドレスzedec.nearから全プロトコルに自然にルーティングされる。

システムは開かれている。システムはオープンである。構築せよ。

10. 付録：検証コマンド集

# 不変条件の検証（ガス不要）
#   conjoin {"inputs":[1,2]}        → "FALSE"
#   is_settleable {"state":"BOTH"}  → false
#   is_settleable {"state":"TRUE"}  → true

# カノニカルルーティング
#   zedec.near → route()
#   zedec.near → protocol_meta()

# ユニバーサルインターフェース
#   ux_manifest
#   ux_help {"topic":"start"}

# レジストリ（発見）
#   vm_capabilities on 7eaa2c6f... → 136

# オンボーディング
#   mint_onboard {} → 5,000 YHVH（使用可能・譲渡不可）

# ネオ・シチリア港
#   port_register {"dao_name":"...","account":"your.near",...}

# ソブリン令
#   sd_issue {"decree_id":"sd-001","title":"...","params":"..."}
#   sd_choose {"prefab":"prefab:sovereign-default"}

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

矛盾許容（パラコンシステント）決済アーキテクチャの完全解説

矛盾許容（パラコンシステント）決済アーキテクチャの完全解説

— 四値論理による決済不変条件とNEARブロックチェーン上の実装（ZXV）—

要旨（Abstract）

目次

1. はじめに：分散システムが直面する「真実の競合」

2. 矛盾許容論理の理論基盤

2.1 古典論理の限界

2.2 四値論理（Belnap型の拡張）

2.3 決済不変条件：only TRUE settles

3. アーキテクチャ設計

3.1 全体構成

3.2 単一マイクロコントラクト方式

3.3 状態互換アップグレード方式

4. コンポーネント詳細

4.1 ゲート（Gate）：決済の中核

4.2 トレジャリー（Treasury）：労働基盤型経済

4.3 レール（Rails）：カードネットワーク

4.4 レシート（Receipts）：ハッシュチェーン監査台帳

4.5 ヴェネツィア・ガスステーション（Venice Gas Station）

4.6 ネオ・シチリア港（Port of Neo-Sicily）：外部レジストリ

4.7 YHVH循環（YHVH Circulation）

4.8 流動性プール（Liquidity Pool）

4.9 ソブリン令（Sovereign Decrees）：フォークなきフォーク

4.10 ユニバーサルインターフェース（Universal Interface）

5. 実装詳細

5.1 スマートコントラクト構成

5.2 状態管理とストレージ

5.3 イベントと監査

5.4 ガス効率とコスト設計

6. 検証と品質保証

6.1 QCハーネス（カーネルCソースとの照合）

6.2 敵対的監査

6.3 ガス壁テスト

6.4 登録監査

7. NEARブロックチェーン上の展開

7.1 契約アドレスとルーティング

7.2 カノニカルアドレス：zedec.near

7.3 オンチェーン文書化

8. 今後の展望

9. 結論

10. 付録：検証コマンド集