XIII. Validator Activity Statistics

# XIII Validator Activity Statistics 主要描述了如何追蹤並更新網路內驗證者 (Validator)、核心（Core）與服務（Service）的活動 (Activity) 統計數據 (Statistics)。這些統計資訊會被用來優化網路運作、調整獎懲機制，甚至影響治理決策。以下是詳細解析： - JAM 不直接處理驗證獎勵分配，而是由質押子系統進行處理 (polkadot 平行鏈，免費託管在 JAM 的網絡中) - JAM 收集並傳遞驗整者活動的數據給子系統，讓子系統進行獎勵或懲罰 - ==不太清楚 JAM, Polkadot 對於驗整者的獎勵處理流程是什麼== - 可以直接追蹤的活動 (==區塊上有相關資訊==) - Block production - Guarantor reports - Availability assurance - 無法直接追蹤的活動 (==還沒完全理解為什麼不好追蹤?==) - GRANDPA - BEEFY - Auditing - 對於無法直接追蹤的活動，JAM 使用投票機制，讓驗證者互相評估彼此的表現，然後取中位數作為每位驗證者的表現, 假設 50% 驗證者都是誠實的，這種方式能夠提供可靠的資訊。 --- ### 驗證人統計（Validator Statistics, πV 和 πL） ![image](https://hackmd.io/_uploads/H1J0RehYxe.png) :::info - π 是一個長度為 4 的序列，記錄了四個面向的統計資訊： - Validator Statistics ($π_V, π_L$)：驗證者的統計資訊（包含當前與上一個 Epoch 的狀態）。 - Core Statistics ($π_C$)：每個 Core 的統計資訊，例如資料載入大小、受歡迎度、輸入輸出數據量、gas 消耗等。 - Service Statistics ($π_S$)：每個服務的統計資訊，例如提供次數、gas 消耗、輸入輸出數據量等。 - Items： - $b$: 驗整者生產的 block 數量 - $t$: 驗整者提交的 ticket 數量 - $p$: 驗整者提交的 preimage 數量 - $d$: 驗證者提交的 preimage 序列化(octet) 後的資料大小 - $g$: 驗證者 guarantee reports 的數量 - $a$: 驗證者 availability assurances 的數量 ::: ![image](https://hackmd.io/_uploads/rkZfg-3Yex.png) ### 核心統計（Core Statistics, πC） :::info ==更新頻率：每個區塊都會更新。來源：這些數據是根據中間狀態變化，例如新接收或執行的工作報告（work-reports）計算出來。== - d：資料負載大小（bundle size）。 - p：該 Core 的受歡迎程度（popularity）。 - i：匯入的 segment 數量。 - x：extrinsic 的資料大小 - z：extrinsic 的數量。 - e：輸出的數據段數量（exports）。 - l：gas 使用量。 - u：refinement過程中使用的 gas。 ::: ### 服務統計（Service Statistics, πS） :::info ==更新頻率：同樣是每個區塊。用途：幫助了解不同 Service 的資源消耗與績效，進而優化設計與調度。== - p: 該服務被提供的次數。 - r: refinement 次數。 - i: imports 資料數量。 - x: extrinsic 數量。 - z: extrinsic 資料大小。 - e: 匯出資料數量。 - a: accumulate 次數 (accumulate count)。 ::: --- 如何統計驗整者在 epoch 的資料, 由以下定義： (13.2) $$ \text{let } e = \lfloor \frac {\tau}{\mathsf{E}} \rfloor \ , \quad e' = \lfloor \frac{\tau'}{\mathsf{E}} \rfloor $$ :::info - $\tau$: The most recent block's $\tau$imeslot. - $\mathsf{E}$: 600, The length of an epoch in timeslots. - $e$: 前一個 epoch (當前) (舊) - $e'$: 後一個 epoch (未來) (新) ==:robot_face: 定義兩個 epoch 時間點== ::: (13.3) $$ (\mathbf{a}, \pi^{\prime}_1) \equiv \begin{cases} (\pi_0, \pi_1) & \quad \text{if } e' = e \\ ([(0,...,[0,...]),...], \pi_0) & \quad \text{otherwise} \end{cases} $$ :::info - 此公式用來描述 $\pi$ 的數值更新, 以及初始化。 - 假如 epoch 相同，$(\mathbf{a}, \pi^{\prime}_1)$ 等同於 $(\pi_0, \pi_1)$ - 如果是新的一個 epoch $e'$, 那麼將會把初始化的數值賦予給 $\mathbf{a}$, 而原本 $\pi_0$ 的統計結果將會移動至 $\pi^{\prime}_1$ 位置 - $\mathbf{a}$: 為 $e'$ 時間點驗整者統計狀態 (資料結構等同於 $\pi_0$) ==:robot_face:: $\pi$ 有兩個位置儲存統計驗整者統計資料，(當前, 過去)== ::: --- 以下公式是定義如何計算驗證者的統計資訊 (13.4) $$ \forall{v} \in \mathbb{N}_{\mathsf{V}}: \begin{cases} \pi^{\prime}_0[v]_b \equiv \mathbf{a}[v]_b + (v = \mathbf{H}_i)\\ \pi^{\prime}_0[v]_t \equiv \mathbf{a}[v]_t + \begin{cases} |\mathbf{E}_T| &\text{if } v = \mathbf{H}_i \\ 0 &otherwise \end{cases} \\ \pi^{\prime}_0[v]_p \equiv \mathbf{a}[v]_p + \begin{cases} |\mathbf{E}_P| &\text{if } v = \mathbf{H}_i \\ 0 &otherwise \end{cases} \\ \pi^{\prime}_0[v]_d \equiv \mathbf{a}[v]_d + \begin{cases} \sum_{d \in \mathbf{E}_P}|d| &\text{if } v = \mathbf{H}_i \\ 0 &otherwise \end{cases} \\ \pi^{\prime}_0[v]_g \equiv \mathbf{a}[v]_g + (\kappa'_v \in \mathbf{R})\\ \pi^{\prime}_0[v]_a \equiv \mathbf{a}[v]_a + (\exists a \in \mathbf{E}_A : a_v = v)\\ \end{cases} $$ :::info :paperclip: $b$: 生產的區塊數量 $$ \pi^{\prime}_0[v]_b \equiv \mathbf{a}[v]_b + (v = \mathbf{H}_i) $$ - $v = \mathbf{H}_i$: 若驗證者是區塊生產者 - $\mathbf{H}_i$: a Bandersnatch block author index > $(v = \mathbf{H}_i$): boolean to int (0 or 1) ::: :::info :paperclip: $t$: 提交的 ticket 數量 $$ \pi^{\prime}_0[v]_t \equiv \mathbf{a}[v]_t + \begin{cases} |\mathbf{E}_T| &\text{if } v = \mathbf{H}_i \\ 0 &otherwise \end{cases} $$ - $v = \mathbf{H}_i$: 若驗證者是區塊生產者 - $\mathbf{H}_i$: a Bandersnatch block author index - $\mathbf{E}_T$: 是一個具有有效證明的 ticket 序列 ([6.7. The Extrinsic and Tickets](https://hackmd.io/hk0xabpQRrCb5OnM6upU7w#67-The-Extrinsic-and-Tickets)) - ==:question: $|\mathbf{E}_T|: 可能包含其他驗證者的 ticket, 為什麼加入統計？$== ::: :::info :paperclip: $p$: 提交的 preimage 數量 $$ \pi^{\prime}_0[v]_p \equiv \mathbf{a}[v]_p + \begin{cases} |\mathbf{E}_P| &\text{if } v = \mathbf{H}_i \\ 0 &otherwise \end{cases} $$ - $v = \mathbf{H}_i$: 若驗證者是區塊生產者 - $\mathbf{H}_i$: a Bandersnatch block author index - $\mathbf{E}_P \in [(\mathbb{N}_S, \mathbb{Y})]$ - $\mathbb{N}_S$: 某一個 Service - $\mathbb{Y}$: The set of octet strings/blobs (序列化後的內容) - ==12.4 Preimage Integration 尚未閱讀== ::: :::info :paperclip: $d$: 所有 preimage 的 octet 大小 $$ \pi^{\prime}_0[v]_d \equiv \mathbf{a}[v]_d + \begin{cases} \sum_{d \in \mathbf{E}_P}|d| &\text{if } v = \mathbf{H}_i \\ 0 &otherwise \end{cases} $$ - $v = \mathbf{H}_i$: 若驗證者是區塊生產者 - $\mathbf{H}_i$: a Bandersnatch block author index - $\mathbf{E}_P \in [(\mathbb{N}_S, \mathbb{Y})]$ - $\mathbb{N}_S$: 某一個 Service - $\mathbb{Y}$: The set of octet strings/blobs (序列化後的內容) - ==$d$ 定義於第 12 章, 有 $d$ 以及 $\mathbf{d}$ 出現, 還不確定內容為何。== ::: :::info :paperclip: $g$: guaranteed report 的數量 $$ \pi^{\prime}_0[v]_g \equiv \mathbf{a}[v]_g + (\kappa'_v \in \mathbf{R}) $$ - $\kappa'_v \in \mathbf{R}$: 該驗證者是 reporter - $\mathbf{R}$: The set of Ed25519 guarantor keys who made a work-report. See equation 11.25. (**reporters set**) >$(\kappa'_v \in \mathbf{R})$: boolean to int (0 or 1) ::: :::info :paperclip: $a$: assurance 的數量 $$ \pi^{\prime}_0[v]_a \equiv \mathbf{a}[v]_a + (\exists a \in \mathbf{E}_A : a_v = v) $$ - $(\exists a \in \mathbf{E}_A : a_v = v)$: 存在一個 $a$ (assurance) 屬於 $\mathbf{E}_A$, $a_v$ (assurance ticket 中的 validator index) 等於 $v$ (validator index) - $\mathbf{E}_A \in [(a \in \mathbb{H}, f \in \mathbb{B}_\mathsf{C}, v \in \mathbb{N}_{\mathsf{V}}, s \in \mathbb{E})]_{:\mathsf{V}}$ - 定義於 11.2 Package Availability Assurances. 的公式 11.8 ==:robot_face:: assurances Extrinsic 中的 validator index 等同於該 validator index, 就加 1== > $(a_v = v)$: boolean to int (0 or 1) ::: ![image](https://hackmd.io/_uploads/SypD6WnYlx.png) :::info ==(13.8) Core 統計向量: 每個 Core 都會有一個統計描述了該 Core 在目前區塊的各種狀態數據，包含資料傳輸量、gas 使用量，以及累積的統計值。== - i: 該 Core 的 incoming work-reports 數量 - x: 該 Core 的 extrinsic 資料大小 - z: 該 Core 的 extrinsic 數量 - e: 該 Core 的 export 數量 - u: 該 Core 在 refinement 過程中使用的 gas - l: 與該 Core 關聯的 lookup 統計量 (從公式 13.10 計算) - d: 該 Core 所提交的資料負載大小（從公式 13.11 計算） - p: 所有分配到該 Core 的 privileges 累積總和 ::: :::info ==(13.9) R\(c) 從所有與 Core c 關聯的 work-reports 中累加== - i: incoming reports - x: extrinsic size - z: extrinsic 數量 - e: exports 數量 - u: gas 使用量 ::: :::info ==(13.10) L\(c) 累加所有和該 Core 關聯的 lookup 統計量== ==(13.11) D\(c) 累加所有和該 Core 關聯的 lookup 統計量== 計算該 Core 的資料負載大小： - 累加與該 Core 相關的 load 值 - 加上經過加權計算的數值，反映整體的工作負載和資料量。 ::: ![image](https://hackmd.io/_uploads/ryjHyG3Kex.png) :::info ==(13.12) Service Statistics: 每個 service 都會記錄。== - i：segment 載入數 - x：extrinsic 資料大小 - z：extrinsic 數量 - e：輸出的 exports 數量 - rᵣ：累積的 refinement 計數與 gas - p：該 service 關聯的保證資訊 - a：使用情況（累積計數與總消耗） ::: :::info ==(13.13) 定義 service 集合結合三個來源。== - sᴿ：有報告的 service - sᴾ：有保證關聯的 service - K(S)：其他紀錄中出現的 service ==(13.14)從輸入集合 I 中提取 sᴿ 相關的 service。== ==(13.15)把所有存在保證資訊的 service 識別出來。== ==(13.16)將該 service 相關報告內所有統計項目進行加總，包含：計數、gas、segment 數量、extrinsic 資料大小、extrinsic 數量、exports 數量。== ::: ## 總結 Core Statistics (πᴄ) → 反映每個 core 的負載與使用狀況，主要是資源使用與報告數據。 Service Statistics (πˢ) → 聚焦於每個 service 的計數、gas、exports 與關聯記錄。更新頻率：每個區塊完成後會重新計算，保證統計數據與最新狀態同步。