# VIII. Authorization

主要說明的是 JAM 如何設計一種 彈性的授權系統
Authorization 在流程中的位置
所處階段：
🔽 發送 WorkPackage 之前
✅ 用來 決定誰有權使用 coretime、執行哪些任務

[1] 使用者買 coretime（或已有資源）    
    ↓
[2] 使用 authorization 授權誰可使用這些資源
    ↓
[3] 準備 WorkPackage 與 WorkItem
    ↓
[4] Guarantee（保證）
    ↓
[5] Erasure coding → Assurance → Available
    ↓
[6] Accumulation（改變 service 狀態）

### **1. Authorization 的核心概念**
在第4.9節討論了 **work-packages（工作包）** 和 **services（服務）** 的基礎模型後，本章進一步探討如何將核心資源（例如計算時間）分配給特定的工作包及其相關服務。

#### **兩種典型的分配模式：**
Ethereum 模式

使用者與執行內容高度綁定。

Polkadot 模式

執行資源來自預先抵押（如 parachain slot）。

購買者（通常是 parachain）與實際提交 workload 的人無直接關係。

JAM 的設計目標

支援兩種模式 → 引入 authorization system

把「資源的購買與分配」和「具體要做什麼事情」分離
- **Ethereum 模式**：
- Gas 由 發起交易者（也是工作包資料作者）即時購買並執行。
- 使用者與執行內容高度綁定。
- **Polkadot 模式**：
- 執行資源來自預先抵押購買（平行鏈插槽 parachain slot)
- 資源的購買者（如平行鏈團隊）與實際提交工作包的作者（parachain block producer）通常無直接關聯。
- **JAM 目標**
- 支援兩種模式 → 引入 authorization system
- 把「資源的購買與分配」和「具體要做什麼事情」分離

#### **Jam 的設計目標：**
Jam 希望支持靈活的交互模式，包括 Ethereum 和 Polkadot 的兩種風格，為此引入了一套授權系統：
- 將資源的使用意圖（intention of usage）與具體的工作定義（specification of workload）解耦。
- 支持將資源的購買與工作包的執行分離。

---

### **2. 授權系統的三個核心要素**

| 名稱 | 說明 |
| -------------- | ----------------------------------------------------------------------------------- |
| **Authorizer** | 一段邏輯程式碼（PVM code），負責判定 work-package 是否有權執行。需在 PVM 執行環境中執行並產出結果。 |
| **Token** | 附加在 work-package 上的一段資料，用來向 Authorizer 證明「我有權執行這份工作」。內容對鏈是 opaque（不可解讀），但對 PVM 有意義。 |
| **Trace** | 成功授權後產出的資料，用來描述授權成功的細節，同樣是 opaque。 |

[1] 使用者準備好 work-package
[2] 其中包含：
     - Token（授權證明）
     - Authorizer（授權邏輯）識別碼
[3] in-core 執行 Authorizer
     → 驗證 Token 是否有效
     → 若成功，產出 Trace

---

### **3. 授權者的管理機制**
#### **3.1 授權池（Pool）與授權隊列（Queue）**
- **授權池(Authorizer Pool) \( $\alpha[c]$ \)**：
- 定義了核心 \( $c$ \) 的有效授權者集合，工作包必須由該集合中的授權者驗證。
- **授權隊列(Authorizer Queue) \( $\varphi[c]$ \)**：
- 是未來將加入 pool 的 Authorizer 排隊序列（queue）。
- pool 是從 queue 中取出元素來填充的。

---

#### **3.2 授權更新的公式**
在每個塊的狀態轉換中，授權系統需要執行以下步驟：

1. **授權隊列的狀態改變**：
授權隊列 \( $\varphi$ \) 的更新僅能通過特權服務（privileged service）的積累邏輯（accumulate logic）進行。

2. **授權池更新公式**：
當新塊被處理時，授權系統從授權隊列 \( $\varphi$ \) 中取出新授權者 \( $a_{\text{new}}$ \)，並移除已使用的舊授權者 \( $a_{\text{old}}$ \)，更新授權池：

$$\alpha'[c] = (\alpha[c] - \{a_{\text{old}}\}) \cup \{a_{\text{new}}\}$$

- $\alpha'[c]$ ：核心 $c$ 的新授權池。
- $a_{\text{old}}$ ：授權池中已用於驗證工作包的授權者。
- $a_{\text{new}}$ ：從授權隊列中取出的新授權者。

3. **授權隊列更新公式**：
授權隊列移除已被使用的授權者 $a_{\text{new}}$ ：
$$
\phi'[c] = \phi[c] - \{a_{\text{new}}\}
$$

---

### **4. 流程總結與實際操作**
1. **更新授權池**：
- 從授權隊列中取出新授權者 $a_{\text{new}}$ 。
- 移除授權池中已用過的授權者 $a_{\text{old}}$ 。

2. **更新授權隊列**：
- 從授權隊列 $\phi$ 中刪除已加入授權池的授權者 $a_{\text{new}}$。

3. **依賴於積累邏輯（Accumulate Logic）**：
- 授權隊列的更新操作僅能通過特權服務進行，防止未經授權的操作改變資源分配狀態。

4. **保證機制（Extrinsic Guarantees, EG）**：
- 系統利用外部保證機制，移除已用的最舊授權者，避免重複使用。

---

### **5. 授權系統的價值**
1. **靈活性**：
支持 Ethereum 和 Polkadot 的交互模式，適應不同的資源管理需求。
2. **安全性**：
授權者和授權的驗證過程完全受控，避免未授權的資源使用。
3. **透明性與可追溯性**：
每次授權操作都基於可驗證的邏輯和數據，並記錄所有狀態變更。

---

### **公式 8.1、佇列 8.2 和 8.3 說明**
這些公式描述了 **授權池（Pool）** 和 **授權隊列（Queue）** 在系統中如何進行動態更新的數學模型：

#### **公式 8.1：授權池的定義**
公式 8.1 定義了授權池 ($\alpha[c]$) 的動態性：
$\alpha[c]$ = 從授權隊列 \( $\varphi[c]$ \) 中選擇的有效授權者集合

$$ \alpha \in [\![ [\![ H ]\!]_{: O} ]\!]_{C} \quad , \quad\quad\quad \varphi \in [\![ [\![ H ]\!]_{Q} ]\!]_{C} $$

==記得補CONSTANT==

**解釋：**
- **授權池 \( $\alpha[c]$ \)**：表示當前核心 \( c \) 的可用授權者集合，這些授權者可以驗證核心的工作包。
- **授權隊列 \( $\varphi[c]$ \)**：授權隊列是一個 FIFO（先進先出）結構，用來管理候選授權者，隨著狀態轉換，從佇列中移入池中。

#### **公式 8.2：更新授權隊列**
公式 8.2 描述了授權隊列 $\varphi[c]$ 的更新規則：

$$\forall c \in \mathbb N_\mathsf{C} : \alpha'[c] \equiv {\overleftarrow{F(c) ⧺ \varphi'[c] [ \mathbf{H}_t ]^{\circlearrowleft}}}^{\mathsf{O}}$$

$\varphi'[c] = \varphi[c] - \alpha_{\text{new}}$

**解釋：**
- 當新授權者 $a_{\text{new}}$ 被加入到授權池 $\alpha[c]$ 中時，授權隊列 $\phi[c]$ 需要將 $a_{\text{new}}$ 移除，保持狀態一致性。

#### **公式 8.3：更新授權池**
公式 8.3 描述了授權池 $\alpha[c]$ 的更新規則：

$$\text { (8.3) } \quad F(c) \equiv\left\{\begin{array}{ll}
\alpha[c] 🔍\left\{\left(g_{w}\right)_{a}\right\} & \text { if } \exists g \in \mathbf{E}_{G}:\left(g_{w}\right)_{c}=c \\
\alpha[c] & \text { otherwise }
\end{array}\right.$$

$\alpha'[c] = (\alpha[c] - \{a_{\text{old}}\}) \cup \{a_{\text{new}}\}$

**解釋：**
- $a_{\text{old}}$ ：授權池中最早使用過的授權者，需要被移除，防止重複使用。
- $a_{\text{new}}$ ：從授權隊列中取出的新授權者，用來補充授權池。

### **公式 8.1、8.2、8.3 的定義與解釋**

這三個公式來自授權系統的數學模型，主要用於描述 **授權池（Pool, \( \alpha[c] \)）** 和 **授權隊列（Queue, \( \phi[c] \)）** 的關係，以及如何動態更新核心 \( c \) 的授權池狀態。以下逐一解釋：

---

### **公式 8.1：授權池與授權隊列的關係**

**解釋：**
1. **$\alpha[c]$ （授權池）**：
- 表示核心 $c$ 當前允許的授權者集合。
- 該集合是從某些授權狀態 $[\mathbb{H}]_{:o}$ 中提取的，其中 $o$ 表示與授權相關的特定運算規則。

2. **$\phi[c]$ （授權隊列）：**
- 表示核心 $c$ 的候選授權者列表，是授權池的補充來源。
- 該佇列基於授權狀態 $[\mathbb{H}]_{Q}$ ，其中 $Q$ 表示該狀態的隊列結構。

**公式的作用：**
- 定義了授權池與授權隊列的集合關係。
- $\alpha[c]$ 和 $\phi[c]$ 是基於某個共同的授權狀態 $[\mathbb{H}]$ 衍生出來的，用於管理資源的授權過程。

---

### **公式 8.2：授權池的更新規則**

**解釋：**
1. **$\alpha'[c]$：**
- 表示核心 $c$ 的新授權池（在塊狀態更新後）。

2. **$F(c)$：**
- 表示核心 \( c \) 當前授權池的基本狀態，考慮了移除過期授權者的機制（見公式 8.3）。

3. **$\phi'[c][\mathbb{H}_{t}]^{\circlearrowleft o}$：**
- 表示從更新後的授權隊列 $\phi'[c]$ 中補充到授權池的部分，基於授權狀態 $[\mathbb{H}_{t}]$ 和運算規則 $o$。

4. **$\uplus$：**
- 表示集合的非交集合併操作。

**公式的作用：**
- 定義了在每個狀態轉換（例如區塊生成）後，如何通過移除過期授權者並從隊列中補充新的授權者來更新授權池 $\alpha[c]$。

---

### **公式 8.3：移除過期授權者**
$$ F(c) \equiv\left\{\begin{array}{ll}
\alpha[c] 🔍\left\{\left(g_{w}\right)_{a}\right\} & \text { if } \exists g \in \mathbf{E}_{G}:\left(g_{w}\right)_{c}=c \\
\alpha[c] & \text { otherwise }
\end{array}\right.$$
**解釋：**
1. **$F(c)$：**
- 定義了核心 $c$ 的授權池在移除過期授權者後的狀態。

2. **$\mathbb{E}_{G}$：**
- 表示外部保證機制（Extrinsic Guarantees），用於追蹤授權者的使用狀態。

3. **$(g_{w})_{a}$：**
- 表示授權者 $a$ 與工作 $g_{w}$ 的關聯對象。
- 如果該授權者已經被用於當前核心 $c$ 的工作，則需要從授權池中移除。

4. **條件分支：**
- 如果 $g \in \mathbb{E}_{G}$ 並且 $(g_{w})_{c} = c$，則從 $\alpha[c]$ 中移除過期授權者。
- 否則，保持 $\alpha[c]$ 不變。

**公式的作用：**
- 保證每個授權者只在有效期內使用，避免重複使用或未經授權的行為。
- 與外部保證機制配合，動態清理過期授權者，確保授權池的準確性。

---

### **整體流程總結**
1. **授權池和隊列的關係（公式 8.1）：**
- 定義了授權池 $\alpha[c]$ 和授權隊列 $\phi[c]$ 的集合來源和基礎結構。

2. **授權池的更新（公式 8.2）：**
- 描述了如何通過移除舊授權者並補充新授權者來更新授權池 $\alpha[c]$。

3. **移除過期授權者（公式 8.3）：**
- 定義了移除授權池中已使用或過期授權者的規則，並依賴外部保證機制 $\mathbb{E}_{G}$。

---

### **特權服務（Privileged Service）**
#### **特權服務的角色**
特權服務是一種具有高級別權限的系統邏輯，負責管理授權隊列和授權池的狀態更新。它們可以執行一些一般服務無法執行的操作，例如：
- 修改授權隊列 $\phi[c]$。
- 調用積累邏輯（accumulate logic）來進行授權者的增刪更新。

#### **為什麼需要特權服務？**
- 防止惡意或未授權的操作干預資源管理。
- 確保系統的資源分配過程是可信、透明且受控的。
- 限制修改授權狀態的行為，只能由系統中的可信組件執行。

---

### **外部保證機制（Extrinsic Guarantees, EG）**
#### **外部保證的角色**
外部保證是一套由系統內部或外部提供的驗證機制，確保授權過程的完整性與可靠性。這些機制通常包括：
- **移除過期授權者：**
- 當授權者 $a_{\text{old}}$ 在當前塊中被使用後，外部保證機制負責將其從授權池中移除，避免資源的重複使用。
- **驗證授權者的合法性：**
- 確保授權者 $ a_{\text{new}}$ 是從授權隊列 $\phi[c]$ 中正確選取，並且具備預期的參數與邏輯。

#### **外部保證的實現方式**
- **內部保證**：利用系統內部的狀態檢查（例如交易驗證、狀態遷移規則）來進行授權管理。
- **外部監控**：通過外部系統（如智能合約或治理系統）實現資源分配的監管和審查。

#### **與積累邏輯的配合**
外部保證機制通常在積累邏輯階段發揮作用，確保：
1. 移除最舊的授權者 $a_{\text{old}}$。
2. 增加新授權者 $a_{\text{new}}$，保持授權池的更新。

---

### **總結：如何理解這一過程**
1. **授權池 $\alpha[c]$** 與 **授權隊列 $\phi[c]$** 的關係：
- 授權池從授權隊列中提取授權者，用於核心 $c$ 的當前工作包驗證。
- 使用完的授權者從授權池中移除，並由隊列補充。

2. **特權服務的作用：**
- 僅特權服務能修改授權隊列和執行積累邏輯，確保資源管理的可信性。

3. **外部保證機制的價值：**
- 提供額外的安全保障，移除過期授權者，並驗證新授權者的正確性。