---
Extrinsic 先關住在跟 import 區塊(Header), 或是跟 STF 有關的地方
「**Extrinsic**」是用來描述來自區塊鏈外部的數據，通常包括交易（transaction）和其他可能由用戶或節點提供的信息
**一般 Extrinsic 的作用**：
- **功能**：通常包括用戶提交的交易、智能合約的呼叫以及任何外部輸入數據。
- **作用**：這些數據會進入區塊的數據部分，成為共識機制處理的內容之一。

簡單來說 extrinsics就是後續要被追蹤和驗證的資料
在區塊鏈中，extrinsic data 包含了許多不同的部分，每一部分都像是會議中的一個活動： tickets：就像是出席票，管理著誰能夠參與並發言或提出建議。
judgments：就像是會議中的投票或表決，用於解決參與者之間的爭議。
preimages：就像是會議中提前準備的資料，當需要時可以取用和參考。
availability：像是參與者的保證書，表明他們已經準備好並擁有所有所需的資料。
reports：是完成的工作或決策的報告，由參與者提交並驗證其準確性。
---

[Extrinsic in Polkadot](https://spec.polkadot.network/id-extrinsics)
[10.2. 課程影片](https://graypaper.com/lectures/?section=10.2-Extrinsic)

# Extrinsic

## 4.1. [The Block](https://graypaper.fluffylabs.dev/#/364735a/088900088900)

區塊 $\mathbf{B}$ 可以被 restated 為 header $\mathbf{H}$ 與系統外部的一些輸入數據稱為 *extrinsic*, $\mathbf{E}$
$$
\mathbf{B}\equiv(\mathbf{H}, \mathbf{E})
$$

Extrinsic 就是後續要被追蹤和驗證的資料，包含了許多不同的部分，每一部分都像是會議中的一個活動。外部讀進來的資料 = Extrinsic，經過淬鍊與統整後變成 Header。Both 組成了 data structure of blockchain

$$
\mathbf{E}\equiv(\mathbf{E}_{T}, \mathbf{E}_{D}, \mathbf{E}_{P}, \mathbf{E}_{A}, \mathbf{E}_{G})
$$

- [x] ==Tickets== $\mathbf{E}_{T}$ 就像是出席票，管理著誰能夠參與並發言或提出建議。
> [name=Yccinamoroll3741] by yuki 2024.11.29 報告 w/ QAQ 3.8
- [x] Disputes $\mathbf{E}_{D}$ 就像是會議中的投票或表決，用於解決參與者之間的爭議。
> [name=Yccinamoroll3741] by QAQ 2024.11.24 報告
- [x] Preimages $\mathbf{E}_{P}$ 就像是會議中提前準備的資料，當需要時可以取用和參考。
> [name=Yccinamoroll3741] by Euegen 2024.11.25 報告
- [x] ==Availability== $\mathbf{E}_{A}$ 像是參與者的保證書，表明他們已經準備好並擁有所有所需的資料。
> [name=Yccinamoroll3741] by k7 2024.11.26 報告
- [x] Reports $\mathbf{E}_{G}$ 是完成的工作或決策的報告，由參與者提交並驗證其準確性。
> [name=Yccinamoroll3741] by Ycc 2024.11.27 報告

:::info
優先順序 : Tickets, Reports = Availability = Preimage > Judgement

- according to the baby steps to M1
:::

## 6.7. The Extrinsic and Tickets

定義了 **extrinsic** $\mathbf{E}_{T}$，是由多個有效(valid) **tickets** 證明的序列。決定下一個 epoch 的每一個 slot 是由誰生產區塊。

用 ringVRF 的輸出當作 tickets 的辨識符(identifier)

- 因為有不易預測(high entropy, unbias) 的特性
- 是 32-byte 的序列
- 也當作分數還有鏈上 VRF 的 input

在 epoch 快要結束時(剩下 $\mathsf{Y}$ 個 slots 時)，就會停止蒐集 tickets。並固定下個 epoch 的 sealing key 序列


:::info
tuple 序列 : 票券編號 + 有效證明

- $r$ : ticket entry index，是一個自然數 $\mathbb{N}_{\mathsf{N}}$
- 每一個 validator 都會有兩個 entry (==0 or 1 = 使用sealing or fallback mode==)
- N = 2: The number of ticket entries per validator.
- $p$ : ringVRF proof(應該是 hash)
- $\bar{\mathbb{F}}$ : ringVRF function，使用 key $\gamma_{z}$ 對 message $[]$ 與 conext $\langle\cdot\rangle$ 做簽章
- $\mathsf{X}_{T}$ : $jam_ticket_seal，Bandersnatch Ringvrf Ticket generation and regular block seal
- $\eta^{\prime}_{2}$ : entropy accumulator
- 這邊沒有要對任何 message $m$ 做簽章，而是為了證明簽章的人在 $\gamma_{z}$ set(ring root) 裡面(但你不知道確切是誰)
- 形式與 $\mathbf{H}_{s}$ 的 Seal 簽章完全一樣
- Entropy 也不一樣，因為驗證 tickets 這件事情會在 sealing 之前
:::

:::info

- ==$\mathsf{K}$ = 16==: 在單一區塊裡 $\mathbf{E}_{T}$ 中最多只能有 $\mathsf{K}$ 張 tickets 被提交
- $m^{\prime}<\mathsf{Y}$ : 在 lottery 之前才能提交 tickets
- 當前 slot index $m^{\prime}$ 應該要小於 500(可提交 tickets 的 slot 總數 $\mathsf{Y}$)
- 超過提交 tickets 的 slot 就不採記 -> 確保 $\gamma_{a}$ 不會被修改
- 在 $\mathsf{Y}$ 之後 $\gamma_{a}$ 就被鎖定了
:::

:::info
Define 一個好用的變數，新的 tickets set $\mathbf{n}$，用來提取 extrinsic 裡面正確的資訊

- 跟 tickets $\mathbb{C}$ 的形式一樣 : (ID, entry)
- $\mathcal{Y}$ : ringVRF 的 output -> 當成 tickets 的 ID(hash)
:::

:::info
確保 $n$ 根據 $\mathbf{y}$(ID) 被 re-order 成序列並刪除重複項
:::

:::info
確認這些新的 tickets ID 沒有在 tickets accumulator $\gamma_{\mathbf{a}}$ 裡面。
**比較兩邊 set 的 ID 有沒有重複**

- 溫度計符號 : disjoint set ==<- 不清楚如何確保這個條件? A: $\gamma_a$ 是舊的，確保不會有人拿舊票亂搞==
:::

:::info
定義新的 tickets accumulator $\gamma^{\prime}_{\mathbf{a}}$，舊的 + 新的裡面取分數最高的 600 個

- $x$ : 新的 tickets set
- 必須是新讀進來的 tickets $\mathbf{n}$ 與舊 tickets accumulator $\gamma_{\mathbf{a}}$ 的聯集
- 如果是新一輪 epoch $(e^{\prime}>e)$ : 就不用考慮
- 波浪號 : ordered by ID($\mathbf{y}$)
- $\mathsf{E} = 600$ : The length of an epoch in timeslots.
:::

:::info
確保這些新的 tickets $\mathbf{n}$ 真的有進到 tickets accumulator $\gamma^{\prime}_{\mathbf{a}}$ 中，而不是做白工

- 做了會怎麼樣? 記錄下來嗎?
- 高到低
:::

If $\mathbf{E}_{T}=[]$ 那

1. $m^{\prime}\ge \mathsf{Y}$
2. 或是沒有新的 tickets 進來, i.e. $e^{\prime}=e, \text{than } \gamma^{\prime}_{\mathbf{a}}=\gamma_{\mathbf{a}}$

:::warning
請看 [Chatper 6 Header](/ek3wRMPERIudG41mFuirfA?stext=6951%3A20%3A1%3A1732045518%3ANfSGcp&both=)
:::

# Chatper 10 Disputes, Verdicts, and Judgements

是 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)
- 為何要上鏈?
- remove 那些無效的垃圾 reports
- 如果對於 report 有爭議，也需要紀錄下來，以便之後追查
- ban 掉 culprits (移除其 key) 避免之後繼續提供 (高機率) 無效的 reports
- 如果 verdict set $\mathbf{V}$ 的結果是 positive，那就不應該再拿出來說 report 是 invalid
- 如果 verdict set $\mathbf{V}$ 的結果是 negative，那區塊鏈需要
1. 移除無效的 $r$
2. 回滾到上一個安全的 state
:::
==...後面代補==

## 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 的公鑰 (offenders)
- 確定是 valid 的 report 你說他是 invalid
- 卻是是 invalid 的 report 你說他是 valid
- 不用再被審查了
:::

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

:::info
看起來這邊的 Extrinsic 是在提供裁決時的結論 + 證據，主要解決區塊鏈內部 (validators) 的糾紛
:::

### 定義 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 \frac{\tau}{E} \rfloor - \mathbb{N}_{2}$ : 當前與上一個 epoch 的 set -> 決定使用 $\kappa$ or $\lambda$
- $\lfloor \frac{\tau}{E} \rfloor$ : current epoch
- $\tau$ 是最近的區塊的 timeslot(時間槽, 生成時間)
- $\mathbf{E}$ : constant, 當前 timeslots 中 epoch 的 length
- current time $\tau$ 除以 epoch length $\mathbf{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
用字典序
:::

:::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$ 無效，那誰丟上來的? 寫在小本本上
- ==為何 >2 ?? 因為要有爭議才會進到 Dispute 階段==
- $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 來確保此交易是否有效
:::

## (認領)12.4. [Preimage Integration](https://graypaper.fluffylabs.dev/#/911af30/185600185600) Eq. 12.28~12.33