# VXII. Auditing and Judging

## 17. Overview

在區塊生成後，進行分散式驗證與審核機制，確保工作報告（Work Reports）在被之前是 誠實產生且有效的。
### Flow
1. Data Submission（資料提交）
提交工作報告（WorkReport)。

2. Accumulation（累積）
系統對收到的工作報告進行處理與狀態更新上鏈。

3. Auditing（審計）
透過隨機與補審機制來審核前面累積過的報告是否合理正確。

4.Part of block Finalization（區塊封包）
審計完成最終被封裝進新的區塊。

### Auditing 流程

🟢 0. 前提
Audit 在每個 validator local 執行

待審的 work-reports 為當前 Block 所有的 reports，每個對應一個 core (有可能有空的 core)

🔢 1. Tranche 0 — 資料收集 & Deterministic Assignment & 審核

讀取 W（available work reports） → 得到 Q (需 audit 的 report array) (17.1–17.2)

assignmentMap: work_report → validator set - 每個 workreport 需審核的 Validators 集合

Local 計算自己的 assignments（CE144）
收集其他 node 廣播的 assignments（CE144)

### 計算自己的 assignments a0

$s0$ (random seed): 使用 validator 的 Bandersnatch key VRF 計算（17.3–17.4）

利用得到的 seed shuffle 後挑出前 10 筆 reports assignment a₀（最多審 10 筆）(17.5–17.7)

廣播自己的 assignment（CE144)

### CE

### CE144
🟠 目的：
當每個 tranche 開始時，每位審計者（通常是 posterior validator set 的成員）應該：

廣播一則公告，告訴其他節點他打算審哪些 work-reports。

如果該節點沒有要審任何報告，則不需要發送公告。

Note
不可以對同一個 work-report 在同一區塊中跨越多個 tranche 宣告要審它，最多只在一個 tranche 宣告。

Tranche = u8
Announcement = len++[Core Index ++ Work-Report Hash] ++ Ed25519 Signature

Bandersnatch Signature = [u8; 96]

First Tranche Evidence = s₀(w) 簽名（取自 GP）

No-Show = ValidatorIndex ++ 之前 tranche 中該 validator 的 announcement

Subsequent Tranche Evidence = [sₙ(w)] ++ len++[No-Show List] （一個 work-report 對應一筆）

Auditor -> Auditor
--> Header Hash ++ Tranche ++ Announcement
--> Evidence
--> FIN
<-- FIN


審核 a₀ 中的每一筆 report（根據 17.17）→ 得出 true / false

廣播 CE145 審核結果

### CE145
CE145 用來「廣播審查判定（judgment）」，目的是：

將某份 work-report 是否通過審核的結果告知其他節點。

給未來可能補審的節點一個審核依據。

支援 block 作者在打包 block 時能包含這些判定（作為 dispute 證據來源）。

Validity = 0 (Invalid) OR 1 (Valid) (Single byte)

Auditor -> Validator

--> Epoch Index 
 ++ Validator Index 
 ++ Validity 
 ++ Work-Report Hash 
 ++ Ed25519 Signature

--> FIN
<-- FIN

🔁 2. Tranche ≥ 1 — Stochastic Assignment (補審)
📌 目標
彌補 Tranche 0 中那些被 assign 到但 validator 沒有給出審核結果（即 no-show）的工作報告。

🔁 流程（對應 Graypaper §17.15–17.16）

💡 前提
我們知道哪些報告已被 assign（從 CE144）

我們知道哪些報告有收到 positive judgment（從 CE145）

所以可以推算哪些 validator 是 no-show

算出每個報告的 mₙ 這份 report w 被 assign 給哪些 validator（Aₙ₋₁），其中有哪些沒給正向審核（no-show）→ mₙ 就是這些人數。

利用自己 bandersnatch key 藉由 VRF output random number 決定該 validator 是否需要補審

guess := (VRFoutput[0] * ValidatorsCount) / (256 * BiasFactor)
if guess < m_n
    validator 補審

Positive judger map: 記錄每筆 report 被哪些 validator 給 positive

🔚 4. 審核完成判斷（17.19–17.20）

對每筆 report：

若沒有 negative judgment 且所有 assigned validators 都已給出 positive → ✅

或者 positive judgment 超過 2/3 * V → ✅

否則 → ❌

若所有 Q 中的報告都通過上述邏輯 → 認定此 block audited 完成（17.20）

### 如何審核 report

CE138


Auditor -> Assurer

--> Erasure-Root ++ Shard Index
--> FIN

<-- Bundle Shard
<-- Justification
<-- FIN

### 疑問整理
- tranche 實作上邏輯設計
- assignment map 同步邏輯設計
- Ξ 工作結果計算函數（Work Result Computation Function）
- 

- CE138和 17.17 的關係
- Auditor 跟 哪些 assuer 拿資料 (從某個 pool?
- 17.17 formula 細節上該如何比對 (把 pool 每個 candidate 都做 serialize 然後比對某個 field?



私鑰使用場合整理

17.17 研究

Formula (17.17) 的核心是：「驗證某個工作報告 w 是否正確由某個 core c 在某次 accumulation 中產生」

w = Ξ(p, c) ← report 是否可由 p 的核心 c 重建
F(w) = ℰ(p) ← 該 report hash 是否和 package hash 相符


## 🔍 審核流程與公式 17.17 說明（Audit Recovery）

JAM Protocol 中，審核者（Auditor）必須在對某個 Work-Package 做出 Judgment 之前，依據公式 **17.17** 的邏輯：

> **利用多個 shard（分片）、Merkle path 與 erasure decoding，還原出原始資料，並驗證其正確性**

### 🧩 邏輯步驟對應如下：

1. **收集分片**
- 發送 `CE 140` (Segment Shard Request) 給保證人 Assurer
- 接收 shard + Merkle co-path（用於驗證）

2. **驗證 shard 屬於正確資料**
- 使用 co-path 驗證 shard 是否對應到正確的 `Erasure Root`
- 根據公式中的 `T(s, i, H)` 驗證 Merkle 路徑

3. **聚合至少 k 片資料**
- 根據系統參數，需取得至少 `k` 片 shard（通常為 342）
- 若無法湊齊 `k` 片，視為資料不可審核

4. **還原原始 Work-Package Bundle**
- 使用 Reed-Solomon 解碼還原 bundle
- 驗證其內容（如 extrinsics hash, header, import segments 等）

5. **發布 Judgment**
- 若資料正確 → 發送 `CE 145`（Judgment Publication）標記有效
- 若資料錯誤 → 發布無效判定或提出爭議

---

### 📌 實際指令流程對應

| 步驟 | CE 協定指令 | 功能 |
|------|--------------|------|
| 1️⃣ 索取 shard | `CE 140` | Segment Shard Request |
| 2️⃣ 驗證 shard | Merkle Path + 公式 17.17 | 保證 shard 屬於 WP |
| 3️⃣ 聚合 k 片 | - | 收齊足夠可還原 |
| 4️⃣ 還原 bundle | Reed-Solomon 解碼 | 還原原始 WP 資料 |
| 5️⃣ 發布結果 | `CE 145` | 審核結果 Judgment 上鏈 |

---

> 📘 公式 17.17 並非單一計算，而是一套基於 **data availability + proof + erasure recovery** 的資料審核流程。