---
Chapter 10 Disputes, Verdicts, and Judgements
Chapter 17 Auditing and Judging
---
# X. Disputes, Verdicts, and Judgements

JAM 對於 work report 的 validity 進行 judgement 的 mechanism。藉由 validator 對於每個 report 做投票。

是 STF 的其中一小部分，主要解決**鏈上**的糾紛，並儲存在鏈上。並不會常常發生，因為如果有糾紛，代表有 validator 要被砍掉 (slashed) 了
:::info

- Disputes : 起源於兩個 validators 對於 report validity 的 judgement 相歧
- verdict set $\mathbf{V}$ 為大部分 validator 群體對於此 report 的 judgement 共識
- Work reports : work package 計算後的結果
- Offenses : validators 做出不當的行為 (culprits or faults)
- 為何要上鏈?
1. remove 那些無效的垃圾 reports，並且不讓他們重新上傳
- 如果對於 report 有爭議，也需要紀錄下來，以便之後追查
2. ban 掉 culprits (移除其 key) 避免之後繼續提供 (高機率) 無效的 reports
- 紀錄在 JAM 的區塊上面讓更高 level 的應用可以讀取這些 $\psi_{\mathbf{o}}$
- i.e. 讓 Polkadot 上面的質押系統把這些 $\psi_{\mathbf{o}}$ 踢出
- 如果 verdict set $\mathbf{V}$ 的結果是 positive，那就不應該再拿出來說 report 是 invalid
- 如果 verdict set $\mathbf{V}$ 的結果是 negative，那區塊鏈需要
1. 移除無效的 $r$
2. 回滾到上一個安全的 state 然後 fork 新的鏈 (因為舊的已經被判定無效)
- accumulation 發生前的區塊
- more in ch.19
:::

==...後面代補 補完了~==

## 10.1. *Disputes* State


當 $\mathbf{V}$ 決定後 (有效、無效、不確定)，就會把 report 放到相對應的 state 裡
:::info

- $\psi^{\prime}$ : prime 代表被操作過(在此應該指 verdict )的 state
- $\psi_{\mathbf{g}}$ : 有效報告 (good)
- $\psi_{\mathbf{b}}$ : 無效報告 (bad)
- $\psi_{\mathbf{w}}$ : 待定報告 (wonky)
- $\psi_{\mathbf{o}}$ : 被發現做出錯誤 judgement validators 的公鑰 (punish)
- 確定是 valid 的 report 你說他是 invalid
- 卻是是 invalid 的 report 你說他是 valid
- 不用再被審查了
:::

## (QAQ)10.2. [Extrinsic](https://graypaper.fluffylabs.dev/#/911af30/124900124900) Eq. 10.2~10.20

:::info
看起來這邊的 Extrinsic 是在提供裁決時的結論 + 證據，主要解決區塊鏈內部 (validators) 的糾紛。將鏈下 audit 的結果帶到鏈上做裁決。
:::

### 定義 The disputes extrinsics, $\mathbf{E}_{D}$


- **Verdicts(裁決)** $\mathrm{v}$
- 由 2/3 + 1 的 validator set 對 $c, f$ 的作為所達成的結論
- 誰有資格可以在 validator set 裡面?
- $\kappa$ : 當前 active 的 vaidator set
- $\lambda$ : 前一個 epoch active 的 validator set
- 這些結論會被提交到鏈上，以確保一致性與透明性
- 提供 validator 的犯錯證據，以簽名的內容分成兩種 -> 為了追溯 validator 惡意或是錯誤的行為
- **Culprits(罪魁禍首)** $c$ : 發現工作報告無效的保證 (有效性)
- 對無效的 work report 說他是有效的，這兩個擔保人會被帶到鏈上
- 你擔保的人審查出錯了 !
- **Faults** $f$ : 簽署了跟工作報告有效性相違背的訊息 (正確性)
- 發出了無效的 judgement 的人
- 就是你審查(audit)出錯了 !

==有 validator 作亂 -> 哪一種形式( $c$ or $f$ ) -> 2/3 + 1 個 validators 就會來打擾對你做出裁決 $v$==
::: info 數學細節
**Double 中括號代表所有可能的排序**
$\mathrm{v}$ : 工作報告的 hash | 由哪一個 validator set 簽章 | 序列化後 judgement 的簽章

- $\mathbb{H}$ : 對 work report 的 hash
- $\lfloor \dfrac{\tau}{\mathsf{E}} \rfloor - \mathbb{N}_{2}$ : 當前與上一個 epoch 的 set -> 決定使用 $\kappa$ or $\lambda$
- $\lfloor \dfrac{\tau}{\mathsf{E}} \rfloor$ : current epoch
- $\tau$ 是最近的區塊的 timeslot(時間槽, 生成時間)
- $\mathsf{E}$ : constant, 當前 timeslots 中 epoch 的 length
- current time $\tau$ 除以 epoch length $\mathsf{E}$ 會得到 current epoch
- $\mathbb{N}_{2}$ : set of $\{0, 1\}$
- 序列化過的 judgement 簽章 set : 希望達到 2/3 + 1 validators 的簽章
- $\{T, F\}$ : Boolean，valdator 認為 work load 有沒有效
- $\mathbb{N}_{\mathrm{V}}$ : validator 的 set -> $\kappa$ or $\lambda$
- $\mathbb{E}$ : 對 judgement 的簽章

$c$ : 工作報告的 hash | 擔保人簽章的 hash | 擔保人的簽章

- $\mathbb{H}$ : 對 work report 的 hash
- $\mathbb{H}_{E}$ : 公鑰的 set
- $\mathbb{E}$ : Ed25519 簽章的 set

$f$ : 工作報告的 hash | 對此報告的 judgement | judgement 簽章的 hash | judgement 的簽章

- $\mathbb{H}$ : 對 work report 的 hash
- $\{T, F\}$ : Boolean，validator 認為 work load 有沒有效
- $\mathbb{H}_{E}$ : 公鑰的 set
- $\mathbb{E}$ : Ed25519 簽章的 set

:::

### 如何確認 judgement 簽名的有效性


- judgement 需要由 validator set ($\kappa, \lambda$) 中的 key 簽署才有效
- 不在乎到底是誰簽的, 有簽就好

==簽名的細節: 哪一個 epoch 裡 validator set 的誰對 report 簽了有效 or 無效的簽章==
:::info
對於所有 $(r, a, j)$ 屬於裁決 $v$

- $r$ : report 的 hash
- $a$ : age, 決定是由當前 epoch 還是上一個 epoch 來簽章
- $j$ : validator 簽章的 set

對於所有 $(v, i, s)$ 屬於 judgement $j$

- $v$ : boolean, 裁決有效或是無效
- $i$ : validator key 的 index
- $s$ : 簽章
- 簽章必須是 validator set($\kappa$ or $\lambda$) 裡面的第 $i$ 個所簽署
- 簽章包含 $X_{v}$ | report 的 hash

$k$ : 由 age $a$ 來決定是由當前 epoch 還是上一個 epoch 的 key 來簽章
:::

### 對於 Culprit and Fault 簽章的細節


==確保對於 $c$ or $f$ 的簽章不會被已經被懲罰的 validators 簽署==
:::info

- $\mathbf{k}$ : 排除 $\psi_{\mathbf{o}}$ 後, 還屬於 $\kappa$ and $\lambda$ validator set 中的金鑰
- $k_{e}$ : $e$ = epoch

對於所有 $(r, k, s)$ 屬於罪魁禍首 $c$

- $r \in \psi^{\prime}_{\mathbf{b}}$ : (屬於被判定不正確) report 的 hash
- $k$ : 金鑰
- $s$ : 簽章必須由金鑰 $k$ 簽署，包含 [guarantee 論述](https://graypaper.fluffylabs.dev/#/911af30/145e01145e01) `cat` $r$ 的訊息

對於所有 $(r, v, k, s)$ 屬於 fault $f$

- $r \in \psi^{\prime}_{\mathbf{b}} \Leftrightarrow r \notin \psi^{\prime}_{\mathbf{g}} \Leftrightarrow v$
- 如果"屬於無效報告" -> 就"不屬於有效報告" -> verdict 為 F
- Vice versa: 如果 verdict 為 T -> 就"屬於有效報告" -> "不屬於無效報告"
- $v$ : verdicts, boolean, 此報告有效 or 無效
- $k$ : 金鑰
- $s$ : 簽章必須由金鑰 $k$ 簽署，包含此 verdict 有效 or 無效 `cat` $r$ 的訊息
:::

### ==這些 tuple 必須 unique and ordered，讓實作好進行==


:::warning
待確認
如何針對 report hash 進行排序 (怎麼排序法)?
已經詢問官方 Jam Chat
A: 字典序
:::

:::info
Eq. 10.7~8

- $symbol$ 波浪號 : 代表按 $symbol$ 的排序方式，有重複就會刪除
- Eq.10.7 代表 verdict $\mathrm{v}$ 按照 $r$ 做排列的 list
- 唯一性 : $r$, $k$ 必須是唯一，不可以重複或是用過去的
- hash 函數有防撞性
- ==Ed25519 金鑰...有可能一樣嗎? 或是同一個人簽很多條?==

Eq. 10.9 : 確保 $r$ 的唯一性

- 溫度計 : disjoint
- $r$ 不能跟後面集合 (有效報告 $\psi_{\mathbf{g}}$, 無效報告 $\psi_{\mathbf{b}}$, 待定報告 $\psi_{\mathbf{w}}$) 重疊
- 因為後面集合已經被 judged 過了，不需要重複做一次
- 假設已經被 judged 的那些 report 都是有效的
:::

:::info
ordered by validator index $i$
:::

### 定義 verdict $\mathbf{v}$ 的結果為 verdict set $\mathbf{V}$

:::info
==$\mathbf{V}$ 是一個序列 : report hash | {GOOD, BAD, WONKY}==

- report hash
- 對於 report 的投票 : 有效, 無效, 不確定
- 因為會把 2/3 + 1 個 validators 的 verdict $v$ `cat` 起來，結果有可能是 :
- 0 多數人都認為無效 (bad) -> $\psi_{\mathbf{b}}$
- 2/3 + 1 多數人都認為有效 (good) -> $\psi_{\mathbf{g}}$
- 1/3 有些人認為有效，有些人認為無效 (wonky) -> $\psi_{\mathbf{w}}$
- **基於 Polkadot 的安全性假設認為不會出現這種情形**

:::

#### 一些限制(constraints)，定義了 culprit 與 fault 的行為

:::info
Eq. 10.13 : 如果此 $r$ 為有效 -> 必定存在至少一個 fault

- 一定是有人錯，才需要審核
- all positive 就不會啟動審核機制，很耗資源
- 我們必須紀錄這些，大家認為有效的 $r$，你卻投了 invalid $(v=0)$ 的 validator

Eq. 10.14 : 如果此 $r$ 為無效 -> 必定至少存在兩個以上的 culprits

- 如果此 $r$ 無效，那誰丟上來的? 寫在小本本上
- $c$ 是抓老鼠屎，代表你們串供，兩個人以上聯合做偽證(一人送錯誤文件，另一人以上為他做擔保)
- 請看 Chapter 10 最前面: 因為 validator 對於 report 的 judgement 無法達到共識 or 有衝突，才會啟動這個機制
:::

### Intermediate state 中間態 $\rho^{\dagger}$ : 暫存"待裁定 report "的地方


==work report -> 先送到 $\rho^{\dagger}$ -> time-out 或是確認 report 有效 -> 有效的話才上鏈==

:::info
只要不被 $\mathbf{V}$ 裁定為有效的 report 從 $\rho^{\dagger}$ 中移除，因為不希望 intermediate state 堆積太多 report

- $\forall c \in \mathbb{N}_{\mathbf{C}}$ : 對於所有 core 屬於 core set 中
- $\rho[c]_{w} \neq \varnothing$ : 代表 core $c$ 正在處理 work report 的集合
- $w$ : work report
- $\mathcal{H}(\rho[c]_{w})$ : 想成特定 report 的 index (hash)
- $t$ : 前面 $\mathbf{V}$ 的判斷條件 (GOOD, BAD, WONKY)
- 這邊只要不是 GOOD 就不給過，全部清掉
- ==Consider: 為何條件不是 2/3V + 1==
- Still unknown
:::

### State Transition 定義了 states 更新的條件


:::info

- $\psi^{\prime}_{\mathbf{g}}$ : 添加被裁定為 GOOD 的 report
- $\psi^{\prime}_{\mathbf{b}}$ : 添加被裁定為 BAD 的 report
- $\psi^{\prime}_{\mathbf{w}}$ : 添加被裁定為 WONKY 的 report
- 希望很少發生 -> 有很大的意見分歧
- 因為要 1/3 的 validator 認為 report 是有效，但是剩下的 validator 卻認為是無效
- $\psi^{\prime}_{\mathbf{o}}$ : 添加 culprits $c$ 與 faults $f$ 的 key
:::

## 10.3. Offenders Header

:::info
標示 Offenders，這邊是添加 culprits $c$ 與 faults $f$ 的 key 進到 header 裡面，紀錄不當行為的 validators 等待之後做懲罰或是其他處置。

- 儲存在 header 裡面可以讓從外面讀取的服務 (light client) 很簡單就知道哪些 validator 可能有問題。
- Light client 只讀取 header，而不讀取過去所有交易的資料，自己不驗證，而是依靠讀取 header(較輕便) 更新後 validator set 來確保此交易是否有效
:::

---