# 操作順序への合意
**Agreement on Operation Order ($AO^3$)**

## **概要**

本稿は、分散システムにおける基本問題「操作順序への合意」に対し、集合と写像のみを用いた厳密な形式モデルを提示する。本モデルの革新的な提案は、プロトコル外部要因による **「合意履歴の書き換え」メカニズム**を陽に導入した点にある。この **「書き換え可能性」とそのトリガー、プロセスの性質を分析することのみによって** システムを非中央集権性（≒書き換え不能性、ブロックチェーン的理想）から、（健全な）中央集権性（例：司法介入による書き換え許容）まで、その本質に基づいて分類する新たな枠組みを提供する。

## **動機**

ブロックチェーン技術は分散合意の新たな可能性を示したが、その根底にある論理構造や、ハードフォーク等で観測される「合意の事後的な変更」の扱いは、技術実装の詳細に埋もれがちであった。我々は、特定の技術に依存しない、合意形成とその変更可能性に関する普遍的な理解を追求する。本稿の**着想の根源**は、「システムの真の分散性や信頼性は、内部の合意アルゴリズムだけでなく、むしろ **『一度なされた合意が、どのような根拠で、どのように書き換えられうるか（あるいは、られえないか）』** という点にこそ現れるのではないか」という問いにある。

## 1. 基本的な構成要素 (Basic Constituents)

我々のモデルは以下の集合を基礎とする。

* $A$: **主体 (Agents)** の有限集合。$A = \{a_1, a_2, \dots, a_n\}$。
* $O$: **操作 (Operations)** の可算集合。各操作 $o \in O$ は一意に識別可能であるとする。
* $S$: **状態 (States)** の集合。システムの（抽象的な）状態を表す。
* $M$: **メッセージ (Messages)** の集合。主体間で交換される情報単位。
* $\mathbb{N}$: 自然数（離散時間ステップ）の集合。$\mathbb{N} = \{0, 1, 2, \dots\}$。

さらに、以下の要素を定義する。

* $s_0 \in S$: システムの**初期状態**。
* $f: S \times O \to S$: **操作関数 (Operation Function)**。状態 $s \in S$ に操作 $o \in O$ を適用した結果の状態 $s' = f(s, o)$ を与える。

## 2. ローカルな観測と履歴 (Local Observations and Histories)

各主体は、システムに関するローカルな視点を持つ。

* $O^*$: $O$ の要素からなる全ての**有限シーケンス**の集合。空シーケンスを $\epsilon$ で表す。
* $h_a^t \in O^*$: 時刻 $t \in \mathbb{N}$ における主体 $a \in A$ の**ローカル履歴 (Local History)**。主体 $a$ が時刻 $t$ までに観測、提案、あるいは実行に合意したと（ローカルに）考えている操作の順序付きシーケンスである。初期状態として、全ての $a \in A$ に対し $h_a^0 = \epsilon$ とする。
* $s_a^t \in S$: 時刻 $t$ における主体 $a$ の**ローカル状態 (Local State)**。初期状態 $s_0$ にローカル履歴 $h_a^t$ に含まれる操作を $f$ を用いて順次適用することで得られる状態として定義される。（形式的には、$h_a^t = (o_1, o_2, \dots, o_k)$ に対し、$s_a^t = f(\dots f(f(s_0, o_1), o_2), \dots, o_k)$）。

## 3. 通信と情報交換 (Communication and Information Exchange)

主体はメッセージを交換することで情報を共有する。

* $\textit{Send}: A \times \mathbb{N} \times O^* \to \mathcal{P}(A \times M)$: **送信関数 (Send Function)**。主体 $a$ が、時刻 $t$ に、自身の現在の履歴 $h_a^t$ に基づいて、どの主体にどのようなメッセージを送信するかを決定する写像。$\mathcal{P}(X)$ は集合 $X$ の冪集合を表す。
* $\textit{Receive}: A \times \mathbb{N} \to \mathcal{P}(A \times M)$: **受信関数 (Receive Function)**。主体 $a$ が時刻 $t$ にどの主体からどのようなメッセージを受信するかを決定する写像。これは、ネットワークの特性（遅延、ロス、配信順序など）を抽象化する。

## 4. ローカル履歴の更新プロセス (Local History Update Process)

各主体は、受信したメッセージに基づいて自身のローカル履歴を更新する。

* $\textit{UpdateInternal}: A \times O^* \times \mathcal{P}(A \times M) \to O^*$: **内部更新関数 (Internal Update Function)**。主体 $a$ が、自身の現在のローカル履歴 $h_a^t$ と、時刻 $t+1$ に受信したメッセージ集合 $\mathcal{M}_a^{t+1} = \textit{Receive}(a, t+1)$ を入力として、次の時刻のローカル履歴 $h_a^{t+1} = \textit{UpdateInternal}(a, h_a^t, \mathcal{M}_a^{t+1})$ を計算する写像。（この段階ではまだ書き換えを考慮しない内部的な更新プロセス）

この $\textit{UpdateInternal}$ 関数の設計が、内生的な合意形成プロセスの核心である。

## 5. 合意の定義 (Definition of Agreement)

システム全体として「操作順序への合意」が達成された状態を（まずは書き換えを考慮せずに）定義する。

* システムの実行 (Execution) は、全ての主体 $a \in A$ と全ての時刻 $t \in \mathbb{N}$ におけるローカル履歴の族 $\mathcal{H} = (h_a^t)_{a \in A, t \in \mathbb{N}}$ である。
* **プレフィックス関係 (Prefix Relation):** $h_1, h_2 \in O^*$ **に対して、「$h_1$ が $h_2$ のプレフィックスである」とは、$h_1$ が $h_2$ の先頭部分を構成するシーケンスであることを意味する。例えば、シーケンス $h_2 = (o_1, o_2, o_3)$ に対して、$\epsilon$ (空シーケンス), $(o_1)$, $(o_1, o_2)$, および $(o_1, o_2, o_3)$ は全て $h_2$ のプレフィックスである。本稿では、この関係を $h_1 \preceq h_2$ と表記する。**
* **合意述語 (Agreement Predicate)** $\textit{Agreed}(\mathcal{H})$: 実行 $\mathcal{H}$ が（安定的な）合意に達したかどうかを示す述語。$\textit{Agreed}(\mathcal{H})$ が真であるとは、以下の条件が満たされることと定義する。
* **共通プレフィックスの存在 (Existence of Common Prefix):** ある操作シーケンス $h_{stable} \in O^*$ が存在する。
* **安定性 (Stability):** ある時刻 $t_0 \in \mathbb{N}$ が存在し、全ての（誠実な）主体 $a \in A$ と全ての時刻 $t \ge t_0$ に対して、$h_{stable} \preceq h_a^t$ が成り立ち、かつ $h_{stable}$ はそれ以降変化しない。（**ここで $\preceq$ は上で定義したプレフィックス関係を表す。つまり、$h_{stable}$ が全ての主体のローカル履歴 $h_a^t$ の先頭部分として共通して現れ、安定していることを意味する。**）
* (オプション) **極限合意 (Limit Agreement):** さらに強い条件として、$h_{stable}$ が時間とともに非減少し、ある極限シーケンス $h_{final} \in O^* \cup O^\omega$ に収束し、全ての誠実な主体のローカル履歴が $h_{final}$ に収束する。

## 6. 合意履歴の書き換えとシステム分類 (Rewriting Agreed History and System Classification)

現実のシステムでは、一度合意されたように見えた履歴が、プロトコル外部の要因によって事後的に書き換えられる場合がある。この現象をモデル化するために、以下の要素を導入する。

### 6.1 書き換えメカニズムの導入

* $T_{rewrite}$: **書き換えトリガー (Rewrite Triggers)** の集合。システム外部のイベント（例：コミュニティ投票の結果、司法命令、管理者指示）を表す。
* $\textit{ReceiveRewriteTrigger}: A \times \mathbb{N} \to \mathcal{P}(T_{rewrite})$: **書き換えトリガー受信関数 (Rewrite Trigger Reception Function)**。主体 $a$ が時刻 $t$ に認識する書き換えトリガーの集合を与える。
* $\textit{Rewrite}: O^* \times T_{rewrite} \to O^*$: **書き換え関数 (Rewrite Function)**。現在の履歴 $h$ とトリガー $tr$ に基づいて、書き換え後の新しい履歴 $h' = \textit{Rewrite}(h, tr)$ を決定する。

### 6.2 書き換え発生時の更新プロセスと合意定義への影響

書き換えを考慮した場合、ローカル履歴の更新プロセスは以下のように修正される。

* $\textit{Update}: A \times O^* \times \mathcal{P}(A \times M) \times \mathcal{P}(T_{rewrite}) \to O^*$: **（拡張された）更新関数 (Extended Update Function)**。
$h_a^{t+1} = \textit{Update}(a, h_a^t, \mathcal{M}_a^{t+1}, \mathcal{T}_{rewrite, a}^{t+1})$
ここで $\mathcal{M}_a^{t+1} = \textit{Receive}(a, t+1)$, $\mathcal{T}_{rewrite, a}^{t+1} = \textit{ReceiveRewriteTrigger}(a, t+1)$。
* $\textit{Update}$ 関数のロジック: もし $\mathcal{T}_{rewrite, a}^{t+1}$ が空でなければ、対応する $\textit{Rewrite}$ 関数を適用して $h_a^{t+1}$ を決定する。空であれば、$\textit{UpdateInternal}(a, h_a^t, \mathcal{M}_a^{t+1})$ を用いて $h_a^{t+1}$ を計算する。（優先順位や競合解決ルールは具体的に定義する必要がある。）

書き換えが発生すると、第5節で定義した「安定性」は破られる可能性がある。合意は、書き換えイベント間の区間において一時的に達成されるもの、あるいは書き換えプロセス自体とその結果に対する（より高次の）合意として再定義する必要があるかもしれない。

### **6.3 書き換えメカニズムの性質に基づくシステム分類**

システムの基本的な特性は、一度形成された合意履歴が、どのような要因（トリガー $T_{rewrite}$）によって、どのように（書き換え関数 $\textit{Rewrite}$）変更されうるか、あるいは変更されえないかによって大きく左右される。ここでは、書き換えメカニズムの性質に基づきシステムを分類する。

#### 6.3.1 **厳密な非中央集権性：書き換え不能なシステム (Immutable Systems)**
* 理想的な非中央集権システム。$T_{rewrite}$ は実質的に空集合であり、合意履歴はプロトコル外部の要因によって書き換えられない。
* これはブロックチェーンの当初の理想（Immutability）に最も近い概念である。

#### 6.3.2 **プロトコル内準拠の書き換え：分散的ルールに基づく変更 (Protocol-Compliant Rewrites)**
* $T_{rewrite}$ の要素がプロトコル内部のルールによって、分散的に検証可能な形で生成され、対応する $\textit{Rewrite}$ がプロトコルに従って実行される場合。
* 例：特定の条件を満たした場合に自動的に過去のトランザクションを修正するルール（もし存在すれば）。
* 書き換えプロセス自体が分散的な合意に基づいているため、広義の非中央集権性を維持していると考えられる。

#### 6.3.3 **調整された書き換え：ソーシャルコーディネーション (Coordinated Rewrites via Social Coordination)**
* 書き換えトリガー $T_{rewrite}$ が、単一の中央権力ではなく、コミュニティの多数派合意、開発者グループの判断、財団の決定といった、プロトコル外部の社会的な調整プロセスによって発生する場合。
* 例：「フレンドリー」なハードフォーク（バグ修正、機能改善のための計画的な分岐）。
* **特徴：**
* **非恣意性 (Non-Arbitrariness):** 書き換えは単一主体の恣意的な判断ではなく、多主体間の調整や合意形成の結果として行われる。**この点で非中央集権的な性格を持つ。**
* **合意の継続性 (Agreement Continuity):** 書き換えが行われたとしても、通常、**変更後の新しい履歴に対して再び操作順序の合意形成プロセスが機能し、安定状態を回復することを目指す。**
* このタイプは、純粋なプロトコル内ルール（6.3.2）とも、単一主体による指示（6.3.4）とも異なる、独特の位置づけを持つ。システムのガバナンス構造と密接に関連する。

#### 6.3.4 **中央集権的書き換え：外部権限による介入 (Centralized Rewrites via External Authority)**
* $T_{rewrite}$ に特定の外部主体（単数または少数。例：システム管理者、司法機関、政府）からの指示や命令を表す要素が含まれ、$\textit{Rewrite}$ 関数がそれに応じて履歴を書き換える場合。
* 内部的な合意形成に分散アルゴリズムを用いていても、最終的な権限が外部にあるため、実質的な中央集権性が存在する。
* この中央集権的な書き換えメカニズムは、その運用次第で「健全」にも「不健全」にもなりうる。
* **健全な中央集権性 (Sound Centralization):** 書き換えトリガーが、透明性、説明責任、法の支配、手続き的正当性といった原則に基づいて発生し、$\textit{Rewrite}$ 関数が予測可能かつ公平に実行される場合（例：裁判所の命令に基づく不正資金の凍結・移転）。
* **不健全な中央集権性 (Unsound Centralization):** 書き換えトリガーが、恣意的な権力、不透明なプロセス、強制などに基づいて発生する場合、または $\textit{Rewrite}$ の実行が不公平、不透明である場合。

#### 6.3.5 **考察：分類の含意と高次の合意 (Implications of Classification and Higher-Order Agreement)**
* 上記の分類は、システムの「非中央集権性」が単一の指標ではなく、書き換えの可否、トリガーの性質（内部/外部、単一主体/多主体）、プロセスの正当性など、複数の側面から評価されるべきであることを示唆する。
* 重要なのは、どのタイプの書き換えメカニズムを持つかだけでなく、**書き換えが発生した場合に、システムがどのように応答し、再び安定した合意状態を回復できるか（合意の回復力）** である。
* また、書き換えプロセス自体（誰が、どのような根拠で、どのように書き換えを決定・実行するのか）に対する**高次の合意**（ガバナンス）が、システムの信頼性や受容性にとって本質的な要素となる。

## **結論**

$AO^3$ モデルは、操作順序合意の構成的記述と、それを変更しうる「書き換えメカニズム」の形式化を通じて、分散システムの基礎理論を提供する。本研究が明らかにする**真の革新性**は、システムが外部からの介入（書き換え）にどう応答し、その後どのように振る舞うかを分析するための共通言語を与えた点にある。

この枠組みを用いることで、我々は **《ブロックチェーン的》と多くの人が直観的に感じる性質の根源**について、新たな原理を提示したい。それは、システムの書き換えタイプ（中央集権的か非中央集権的か）や書き換えの有無そのものよりも、むしろ **『たとえ（正当な理由や強制力により）書き換えが発生したとしても、その変更を受け入れた上で、システムが再び操作順序に関する安定した合意状態を自律的に再構築し、維持できる能力』** にあるのではないだろうか。

この **「合意の回復力」あるいは「合意形成プロセスの継続性」** こそが、技術や実装の詳細を超えて、分散システムに期待される信頼性や永続性の本質であり、$AO^3$ はこの能力をシステム間で比較・評価するための厳密な基盤を提供する。本視点は、システムのレジリエンス（回復力）設計や、実効性のあるガバナンスを議論する上で、新たな光を当てるものである。