Appendix A. Polka Virtual Machine A.1. Basic Definition 使用 general PVM function $\Psi$ $\Psi_1$: single step invocation function 單步驟的呼叫函數 定義 full PVM 會一直呼叫直到 $\Psi_1$ 的 output 不是 CONTINUE 在這個 level 分不清楚 panic, page-fault 的差別 src所以也不需要知道造成 page-fault 的地址 v0.6.2 (A.1) v0.6.5 (A.1)

data 12.1 History and Queuing 主要講述 JAM 系統如何利用 accumulation history $(\xi)$ 和累積佇列 $(\theta)$ 來追蹤 work-package 的累積狀態和 dependencies，區分可立即累積 $(W^!)$ 和需延遲累積 $(W^Q)$ 的 work-reports。 Work-report accumulation 的執行過程: ::: info 檢查 dependencies: 當一個 work-report 被提交預備累積時，系統會檢查它的 dependencies work-report 是否已被 accumulation。 立即 accumulation: dependencies 都滿足，work-report 會被立即 accumulation。

[name=Yccinamoroll3741]節錄你們認為的重點供後進者學習 第一章 1.1 命名 Nomenclature [name=Yccinamoroll3741] 沒啥重點可略過 1.2 動機 Driving factors [name=Eugene] 一個 Web3 系統的應該要保持穩定不會輕易的中斷 (Resilience)，若希望提供大規模且多使用者的應用，通用性 (Generality) 非常重要，比特弊只針對代幣發行量進行管理，而乙太坊引入了智能合約，允許開發者在區塊鏈上撰寫程式邏輯 (Turing complete)，成為一個通用性的去中心化計算平台。 除了 Resilience 及 Generality 外，JAM 額外提出三個目標：

Chapter 10 Disputes, Verdicts, and Judgements Chapter 17 Auditing and Judging JAM 對於 work report 的 validity 進行 judgement 的 mechanism。藉由 validator 對於每個 report 做投票。 是 STF 的其中一小部分，主要解決鏈上的糾紛，並儲存在鏈上。並不會常常發生，因為如果有糾紛，代表有 validator 要被砍掉 (slashed) 了 :::info Disputes : 起源於兩個 validators 對於 report validity 的 judgement 相歧verdict set $\mathbf{V}$ 為大部分 validator 群體對於此 report 的 judgement 共識

[name=Eugene] ==TODO: 移動至 Note 4. Overview== 前情提要：建議先閱讀 4.9 The Core Model and services Ethereum 是使用 on-chain consensus, 所有節點都需要對所有的交易進行計算，確保網絡的狀態一致，但效能較差，系統缺乏擴展性。 JAM 提出一種新的方式 in-core consensus, 只有部份的節點進行計算，但由於共識不是所有節點進行驗證，因此透過 guaranteeing, assuring, auditing 以及有可能需要 judging, 來讓這個由部份節點所計算結果足夠被相信是有效的。 這些在 in-core 計算的結果, 都必須可以在已最終確定的區塊上重新執行，也拿到相同的結果, 將 in-core 設計為 stateless, 將不需要考同步性，並且可以很容易的將計算重現於任何區塊 (只要使用相同的輸入參數即可), 而為了達到這個需求，in-core 的執行需要以下內容： the refinement code (執行邏輯, 處理輸入、產生結果) the code of the authorizer (驗證這一個 in-core 執行是合法的) preimage lookups (可以在執行期間查詢到相關資料)

17. Overview 在區塊生成後，進行分散式驗證與審核機制，確保工作報告（Work Reports）在被之前是 誠實產生且有效的。 Flow Data Submission（資料提交） 提交工作報告（WorkReport)。 Accumulation（累積） 系統對收到的工作報告進行處理與狀態更新上鏈。 Auditing（審計） 透過隨機與補審機制來審核前面累積過的報告是否合理正確。

14.1. Honest Behavior 為鏈下活動定義 "誠實行為" Honest Behavior，預期至少 $\frac{2}{3}$ 驗證者表現誠實 work package 的 guarantee & report 行為 (詳見 15 章) 收到資料後確保 work package 可用性 決定要對哪個 work report 做 audit，包含 audit & judge 行為 提交其他驗證者執行的正確 auditing work (詳見 13 章) 14.2. Segments and the Manifest 基本 erasure-coding segment 大小 $\mathsf{W}_E$ = 684 (byte) octets

一個區塊的 header 會由以下資訊組成 [x] $\mathbf{H}_p$ : parent hash [x] $\mathbf{H}_r$ : prior state root [ ] $\mathbf{H}_x$ : extrinsic hash [x] $\mathbf{H}_t$ : a time slot index [x] $\mathbf{H}_e$ : the epoch [x] $\mathbf{H}_w$ : winning tickets [x] $\mathbf{H}_o$ : offenders markders [x] $\mathbf{H}_i$ : a Bandersnatch block author index

Extrinsic 先關住在跟 import 區塊(Header), 或是跟 STF 有關的地方 「Extrinsic」是用來描述來自區塊鏈外部的數據，通常包括交易（transaction）和其他可能由用戶或節點提供的信息 一般 Extrinsic 的作用： 功能：通常包括用戶提交的交易、智能合約的呼叫以及任何外部輸入數據。 作用：這些數據會進入區塊的數據部分，成為共識機制處理的內容之一。 簡單來說 extrinsics就是後續要被追蹤和驗證的資料 在區塊鏈中，extrinsic data 包含了許多不同的部分，每一部分都像是會議中的一個活動： tickets：就像是出席票，管理著誰能夠參與並發言或提出建議。 judgments：就像是會議中的投票或表決，用於解決參與者之間的爭議。

依靠 validator 的 assurance 判斷哪一個 core 的資料是可用的 代表 core 出問題，可能會有一些機制去重啟 core or what ? 待補充.. 目標 : 為了後續的 auditing 可以下載完整以及正確的資料，需要確認 report 的 availability 在 accumulation 前，確認 in-core 的計算結果無誤 方法 : 計算收到驗證者所提交的 assurance $\mathbf{E}_A$ 數量，只要收到超過 $\frac{2}{3}$ 個驗證者提交的 assurance，該 report 就會被視為 available

States Prior (derived from the header state root)reuglar states Posterior (will set into the new header) regular states Intermediates (only live during STF) states with dagger($\dagger$), double dagger($\ddagger$)

定義 區塊鏈由 初始狀態 ( σ_0 ) 和 區塊級狀態轉換函數 ( Υ ) 組成。 公式表示 $$ σ' ≡ \Upsilon(σ, B) $$ ( σ )：Prior State ( σ' )：Posterior State

各種奇怪符號請在這裡找~ 3.1. Typography 小寫字母：用於局部變量。($h$, $\mathbf{h}$) 大寫字母：用於布林值或局部函數。($\mathsf{H}$) 黑板粗體：用於表示集合（如 $\mathbb{N}$ 表示自然數）。 花體字母：引用外部函數（如 $\mathcal{H}$ 表示哈希函數）。 希臘字母：表示具有特定全局含義的變量。($\rho$, $\tau$, $\sigma$, $\kappa$, ...) 3.2. Functions and Operators

:::warning If you're interesting in our team, plz contact: mo0307b1006@gmail.com Discord ID: ycc3741 Instagram: ycc3741_ ::: :::info 麻煩各位創建文件時，Tags 先加類別（e.g. JAM 開發, JAM GrayPaper (灰皮書), Polkadot），再加狀態（on-going, commit, verified, issues, casual）。

本章節描述了 JAM 的區塊產生機制 Safrole，以及它是如何運作以限制新區塊產製的速率並防止分叉的。 Safrole 的目標 限制新區塊產製的速率。 防止分叉，即多個區塊有相同數量的 ancestors透過限制 timeslot=6 sec 的時間內產生任何區塊的作者數量來達成 確保區塊產製的匿名性，使攻擊者難以識別區塊的生產者 Safrole 的機制

flowchart TD %% 工具與輔助模塊 subgraph Tools_Module [工具與輔助] T1[NetAddr] T2[Utils] T3[Logging & Error Handling] end %% 加密與憑證處理模塊 subgraph Encryption_Module [加密與憑證處理]

Block Imported Flow flowchart TD A[Node Start] B{Is local Mode?} C[syncManager.waitForSyncCompletion] D[同步完成] E[validator.onSyncCompleted] F[onSyncCompleted 呼叫 scheduleForNextEpoch] G[計算下一個 epoch 並安排 onBeforeEpoch] H[onBeforeEpoch 執行 → 調用 scheduleNewBlocks]

https://www.blocktempo.com/polkadot-founder-gavin-wood-delivers-his-first-speech-in-taiwan/ HistoryApple, 麥金塔 Opensource web3: secure social OS Introduction of Polkadot Introduction of JAM Blockchain as a vector

Cryptocurrency cold wallets play a crucial role in securing digital assets by storing private keys offline, protecting them from potential cyber threats. Their security heavily relies on cryptographic principles, particularly public-key cryptography. Bitcoin and many other cryptocurrencies use Elliptic Curve Cryptography (ECC), where a private key generates a corresponding public key. This public key is then processed through a series of cryptographic hash functions to produce a unique address. This ensures that while funds can be received at a public address, only the holder of the private key can authorize transactions, maintaining both security and decentralization. Different blockchain networks implement various address formats based on their cryptographic and encoding choices. Bitcoin, for instance, has multiple address formats, each serving specific purposes. Legacy P2PKH (Pay-to-PubKey Hash) addresses start with "1" and use Base58Check encoding. P2SH (Pay-to-Script Hash) addresses, beginning with "3", enable multi-signature transactions and complex scripts. More recent SegWit Bech32 addresses, starting with "bc1", use Bech32 encoding, which enhances error detection and transaction efficiency. Solana takes a different approach, using the Ed25519 elliptic curve for key generation. Solana addresses are fixed at 32 bytes and encoded in Base58, similar to Bitcoin but without additional script variations. Meanwhile, the SS58 address format, used in Substrate-based blockchains like Polkadot and Kusama, is also Base58-encoded but incorporates a unique network prefix to distinguish different chains. Polkadot addresses typically begin with "1", while Kusama addresses often start with "F", "G", "H", "J", or "K", preventing users from accidentally sending assets to incompatible networks. Cryptography plays a fundamental role in protecting cold wallet addresses and private keys. Since private keys in a cold wallet never need to be exposed online, they remain shielded from hacking attempts.The security of ECC ensures that deriving a private key from a public key is computationally infeasible by traditional computers. Additionally, the cryptographic hash functions used in address generation, such as SHA-256 and RIPEMD-160, provide resistance against collision attacks, ensuring address uniqueness and security. Overall, cold wallets rely on robust cryptographic mechanisms to safeguard assets. The diverse address formats across different blockchains reflect their specific security and usability considerations, reinforcing the importance of cryptographic principles in the digital asset ecosystem.

Ch 18. BEEFY Distribution 📌 18. Beefy Distribution（Beefy 分發機制） 這段描述了 Beefy 協議的簽章與分發機制，主要目的是讓驗證者（Validator）對每個最終確定的區塊 BB 進行 BLS 簽章，並提供最簡潔的最終性證明給第三方系統。 🔹 逐步翻譯與解析 📖 主要內容翻譯 對於每個驗證者所導入的已最終確定的區塊 BB，該驗證者應使用 BLS 簽名（基於 BLS12-381 曲線，參見 Hopwood 等人 2020 年的研究），對該區塊的 最新的 Beefy MMR 之 Keccak 哈希值 進行簽名。這些簽名應當被公開發布與自由分發，連同所簽署的原始數據一起提供。 這些簽名可以被 聚合（Aggregated），以便於向第三方系統提供簡潔的最終性證明。簽名與聚合的完整機制由 Jeff Burdges、Ciobotaru 等人 2022 年的研究 定義。