加入PolkaWorld 社區，共建Web 3.0！
本文是由Polkadot 聯合創始人Robert 發布的關於Polkadot v1.0 的分片和經濟安全的技術文章，原文篇幅較長，PolkaWorld 將分四篇翻譯和發布！本篇是該文章的第三部分，介紹了批准檢查機制—— Polkadot 的主要欺詐檢測機制。
查看本文的前兩部分：
第一部分：Polkadot v1.0：分片和經濟安全（1）
第二部分：Polkadot v1.0：分片和經濟安全（2）
批准檢查和區塊終結
批准檢查（Approval Checking）是一種機制，即驗證人隨機選擇檢查可用的平行鏈區塊，並將其檢查的意圖和結果傳達給網絡的其餘成員。
現在，讓我們將批准檢查的實際過程看作一個黑匣子。我們將首先介紹一些背景知識，來了解我們希望這個協議做什麼，以便稍後你能清楚為什麼它要以這種方式運行。
正如我們已經了解的那樣，每個驗證節點都參與了GRANDPA，即區塊終結工具。 GRANDPA 以輪次進行，我們可以將每個驗證人在每個GRANDPA 輪次中所做工作進行高度簡化，視為以下步驟的重複：
下一輪開始選擇要終結的目標區塊：我們希望終結的最佳區塊對終結目標進行投票等待其他驗證人的投票找到出現在驗證人投票的至少2/3 鏈中的最高公共塊終結該區塊回合結束
驗證人在這個過程中唯一的靈活性是在第2 步：選擇要投票的區塊作為其終結目標。這種選擇被稱為投票規則。在基本的GRANDPA 中，每個驗證人只需選擇其所知的中繼鏈裡最長的分支，並提交該鏈的塊頭作為投票。但是，對於平行鏈共識，我們引入了新的投票規則。
GRANDPA 批准檢查的投票規則規定每個驗證人應該：
選擇中繼鏈最長的分支找到該鏈中最高的區塊B，使得當前終結的區塊和B 之間的每個區塊，僅觸發對平行鏈區塊的包含，並且驗證觀察到這些區塊已被足夠多的驗證人批准。
我們把這個過程分解一下。請記住，主要目標是讓網絡只終結真正好的平行鏈區塊，並且讓每個驗證人做盡可能少的工作，以便網絡可以擴展。拆分開來看就是：
找到該鏈中最高的區塊B：我們希望每個節點投票，選出符合其他標準的最高區塊，以便盡可能快地推進終結過程。使得當前終結的區塊與B 之間的每個區塊：投票規則需要驗證人對僅包含良好平行鏈區塊的鏈進行投票。在GRANDPA 中，對區塊的投票被視為對其所有祖先的投票，因此即使區塊100 僅包含良好的平行鏈區塊，區塊99 和98 也不一定如此。因此，投票規則需要找到通過其他標準的中繼鏈區塊的最高連續鏈。僅觸發對平行鏈區塊的包含：回到平行鏈擴展的部分，這裡所說的是，平行鏈區塊已通過中繼鏈區塊中的可用性證明變得可用，並且平行鏈區塊已添加到平行鏈。尚不可用的平行鏈區塊還不算作平行鏈的一部分。驗證人觀察到這些區塊已被足夠多的驗證人批准：這指的是我們將在下面描述的批准檢查機制，這種方法讓驗證人不必自己檢查，只需依靠別人的檢查就能高度相信某個平行鏈區塊是好的。
下面是3 個例子，說明如何應用投票規則，來選出要終結哪些區塊。
在第一個例子中，顯示了連續性的特性，以及我們選擇最佳鏈的祖先。
在第二個例子中，我們投給已終結的區塊，因為這兩條鏈都不可終結。
在第三個例子中，整條最佳鏈都是可終結的，因此我們選擇投票給它。
最後，值得注意的是，這個投票規則是一個在每個驗證人上運行的過程，並且他們都可能根據自己看到的中繼鏈區塊和批准消息，對終結目標持有不同的看法。但這很適合GRANDPA：如果所有誠實的驗證人都運行這個投票規則，那麼除非2/3 的節點都同意它可以終結，否則任何中繼鏈區塊都不能終結。
批准檢查會稍微減慢區塊終結速度，但只是一點點。平行鏈允許有大約3 秒的執行時間，恢復數據大約需要1 秒，擴散消息又需要幾秒。在樂觀的情況下，這意味著它給區塊終結增加了大約5 秒時間。這是真正的終結，背後承載Polkadot 的全部重量。
那麼，讓我們深入批准檢查的過程，以及節點實際都做了些什麼來了解哪些平行鏈區塊是好的，並且已經被足夠多的驗證人檢查過了。
批准檢查的特性及安全性
批准檢查是驗證人為每個平行鏈區塊而運行的子協議。
每個驗證人節點都在為每個中繼鏈區塊中的每個平行鏈區塊運行批准檢查過程。這個過程有幾個特點：
任何特定節點上的過程要么輸出“好”，要么停止。如果平行鏈區塊是有效的（即通過了檢查），那麼它最終會在誠實節點上輸出“好”。如果平行鏈區塊無效，那麼它在誠實節點上輸出“好”的概率很低
請注意，無效情況下的“低概率”大約是數十億分之一，具體取決於驗證人數量和最小檢查者數量等變量。這並不是密碼學意義上的低概率，但卻適用於加密經濟學。
Polkadot 的安全論點基於Gambler's Ruin（賭徒破產理論）。雖然攻擊者確實可以進行數十億次嘗試，來暴力破解該過程，並且最終會成功，但我們將此過程與Slash 懲罰系統相結合，以確保每次失敗的嘗試，都會罰掉攻擊者驗證人的全部抵押。 Polkadot 是一個權益證明網絡，在撰寫本文時，每個驗證人都有大約200 萬個DOT 的抵押。通常情況下，每次失敗的嘗試都會導致10 或20 個驗證人被slash。但即使只有1 個驗證人被slash，攻擊者的資金也明顯會在攻擊成功之前迅速耗盡。
我們通過批准檢查的其他一些特性來實現這一點：
驗證人檢查平行鏈區塊的任務是保密的，直到他們自己披露為止。驗證人的分配是確定性生成的。驗證人在恢復執行這些檢查所需的數據之前，會廣播其檢查平行鏈區塊的意圖。當驗證人廣播檢查平行鏈區塊的意圖然後消失時，這會導致更多誠實的驗證人開始檢查。
特性1 確保攻擊者不知道要DoS 攻擊誰來阻止他們檢查區塊。
特性2 確保就算攻擊者幸運地“中獎了”，並且有足夠多的惡意節點來說服誠實節點，使其相信已經檢查了某些內容，也很可能有誠實節點會與他們一起進行檢查，並且這些誠實節點將發出警報。
特性3 確保誠實節點不會因為向惡意節點請求數據，而意外地暴露自己的檢查者身份，然後在沒有人注意到的情況下被對方離線。即，如果攻擊者試圖讓檢查者保持沉默，它會被其他人注意到。
特性4 確保看似已被DoS 的節點將被更多節點替換。批准檢查就像九頭蛇：如果你砍掉一個頭，就會出現另外兩個頭。
下一節將更詳細地介紹批准檢查的實際工作原理。
驗證人會檢查什麼？
這裡驗證人的目標是確定支持驗證人是否參與了任何不當行為。這需要3 個步驟：
下載PoV 數據以檢查區塊。這是通過獲取1/3 的區塊並將它們組合以形成完整數據來完成的。確保PoV 數據對應有效的平行鏈狀態轉換。確保平行鏈區塊頭提交的所有輸出確實與平行鏈區塊執行的輸出相匹配。
假設> 2/3的節點是誠實的，並且已經承諾擁有數據塊，那麼恢復可用性永遠不會失敗。這就是為什麼僅對可用的平行鏈區塊進行批准檢查的原因。
但是，步驟(2) 和(3) 都可能失敗。當步驟（2）失敗時，表明狀態轉換本身就是垃圾。當步驟（3）失敗時，表示狀態轉換成功，但中繼鏈上記錄的狀態轉換輸出信息是錯誤的。
在步驟(3) 中要注意的一個重要情況，是平行鏈塊頭包含對所有糾刪碼塊的承諾。我們讓驗證人在恢復PoV 數據後進行額外檢查，即將PoV 轉換回其糾刪碼形式，並確保塊頭中的承諾與所有區塊匹配。如果沒有匹配，這可以避免一種攻擊，攻擊者可以有選擇地選擇哪些驗證人可以恢復數據。攻擊的工作方式是這樣的：攻擊者將數據分成很多部分，並用垃圾替換除1/3 之外的所有部分。它將1 個有效部分分配給誠實的驗證人，並給另外1/3 的驗證人垃圾數據。惡意的1/3 驗證人保留了其餘的帶有可用數據的部分。這意味著有足夠的驗證人(2/3 + 1) 會認為該數據有效，但如果惡意驗證人拒絕回答有關其1/3 好的部分的請求，則只有垃圾可用。檢查數據的重新編碼是否確實與承諾相匹配，可以徹底擊敗這種攻擊。
如果步驟(2) 或(3) 中的任何一個失敗，檢查者將提出爭議並將區塊升級到所有驗證人以執行相同的檢查。稍後我們將了解爭議問題，並探討它究竟意味著什麼。
何時檢查
了解批准檢查系統的關鍵見解之一，是每個驗證人都被分配檢查每個平行鏈區塊，但問題是何時檢查。如果驗證人在自己的檢查時間之前發現平行鏈區塊已獲得批准，那麼他們根本不檢查並繼續前進。
從Unix Epoch 開始，時間被劃分為0.5 秒的離散刻度。 0.5 秒的選擇是基於小消息通過gossip 網絡傳播的預期時間。
驗證人打算檢查平行鏈區塊的時間是在表示在delay tranche（延遲批次）中的，這與平行鏈區塊相關。 delay tranche 的範圍從0 到MAX_TRANCHES，並且對應節點意識到平行鏈區塊變得可用後的刻度數。節點對tranche 0 對應哪個刻度的看法略有不同。 MAX_TRANCHES 是一個協議參數，它確定檢查每個平行鏈區塊需要多長時間。將它設置得太小意味著我們可能會選擇比我們需要的數量更多的檢查者，從而浪費精力。設置太大意味著檢查平行鏈區塊需要很長時間。作為參考，在撰寫本文時，該參數在Polkadot 和Kusama 上設置為89。
刻度是時間的離散度量，基於從Unix Epoch 開始的半秒增量。
Delay tranche 是相對於產生中繼鏈區塊的刻度的偏移量。
Tranche 0 是特殊的，因為tranche 0 中的預期檢查者數量被設計為大致等於MIN_CHECKERS，這是一個協議參數，它指定了一個平行鏈區塊被批准檢查程序認定為“已批准”前的最小檢查數。
作為平行鏈區塊支持組之一的驗證人不允許參與批准檢查，因為他們的檢查是多餘的。所有其他驗證人在本地運行VRF 計算，以確定他們要檢查的delay tranche。
任務、批准和未出現
驗證人在批准檢查中會發送兩種消息：任務（Assignment）和批准（Approval）。分配用於傳達檢查平行鏈區塊的意圖和資格，並且批准消息表明平行鏈塊已通過所有檢查。
每個驗證人使用VRF 和平行鏈ID 和中繼鏈塊BABE 憑證作為輸入，立即生成一個任務來檢查平行鏈塊。驗證人將其任務保密，直到需要表明為止。每個任務都唯一且確定地與關聯一個延遲部分，延遲部分錶示當驗證人被分配檢查平行鏈區塊時的延遲部分。
VRF 很重要，因為它意味著接收者可以驗證任務，並且任務的驗證人對分配給他們的延遲部分沒有影響。驗證人確實會通過更複雜的攻擊產生一些間接影響，這些攻擊涉及在BABE 隨機性良好時故意分叉中繼鏈，但我將把它留到另一篇文章中來討論。
批准是一條簡單的消息，由發布的驗證人簽名，表明平行鏈區塊已通過檢查。
當驗證人開始檢查平行鏈區塊時，它所做的第一件事就是將其分配給其他驗證人。這會通知其他驗證人等待相應的批准消息。驗證人完成檢查後，會發出一條批准消息。如果批准消息不在NO_SHOW_DURATION 內，則其他節點認為初始驗證人未出現（no-show）。未出現旨在表明對手觀察到驗證人檢查平行鏈區塊的意圖，並試圖讓他們沉默。 NO_SHOW_DURATION 是一個協議參數，目前在Polkadot 上設置為12 秒。
下圖顯示了3 種情況：未出現、已完成的任務、延遲完成。最後一種情況尤其重要，因為它展示了驗證人如何“起死回生”，也就是即使在被認為沒有出現的情況下也能讓其批准算數。
獲得批准：調度和批准狀態機
批准檢查協議的最後一部分，將詳細說明用於批准平行鏈區塊的狀態機。
每個驗證人節點都為每個包含的（可用的）平行鏈區塊維護一個批准狀態。由於網絡中的時間和異步性，驗證人的狀態版本可能會有所不同。狀態會讓我們回答以下問題：
平行鏈區塊是否獲得批准？與tranche T 的分配是否對應？在沒有其他輸入的情況下，問題(1) 或(2) 的答案可能發生變化的下一個時間點是什麼時候？
批准狀態可以通過3 種方式更新：通過接收新任務、通過接收新批准或通過時間推進。
驗證人會一直運行狀態機，直到問題(1) 的答案為“是”。在每條輸入之後，他們會使用問題(2) 來檢查他們的任務是否對應，從而來確定他們是否應該開始自己檢查平行鏈區塊。問題(3) 僅用於優化目的：節點通常並行運行數千個這些狀態機（每個未終結的平行鏈區塊一個），並且在每個刻度都輪詢所有這些狀態機的話效率就太低了。
這是每個驗證人運行的邏輯，直到平行鏈區塊被批准
該狀態實際包含了兩部分：
所有收到的任務，按tranche 排序，並用第一次觀察到的刻度進行註釋。所有收到的批准。
驗證人在開始檢查之前不會在狀態中包含自己的任務。在產生批准後，驗證人會將其包含在狀態中。
這是狀態的可視化表示；它是一個中立的對象，可以根據收到的任務、經過的時間以及獲得的批准來回答問題。
批准狀態中最重要的操作之一是確定要計算哪些任務。我們將delay tranche 整體看待。任務總是與來自同一delay tranche 的所有其他任務捆綁在一起。節點永遠不會只算delay tranche 中的某個任務，而不算它知道的同一delay tranche 裡的所有其他任務。
任務處於以下三種狀態之一：
待定：該任務沒有相應的批准，但它是最近才下達的任務。已完成：任務有相應的批准。未出現：該任務沒有相應的批准，並且它不是最近下達的任務。
未出現的任務需要由至少一筆非空檔tranche 覆蓋。也就是說，每個未出現任務都需要被至少一個任務覆蓋，但期望不止一個（基於參數化）。
通過以下程序確定有多少tranche：
從tranche 0 開始算，直到其至少包含MIN_CHECKERS 個任務。每個非空的tranche，抵消一個未出現。如果這些非空tranche 中還有更多未出現，則重複步驟2。如果完成了所有非“未出現”的任務，則平行鏈區塊被批准。換句話說，如果有任何任務仍在等待中，那麼平行鏈區塊就不會被批准。
如果某個時候你用完了可取的tranche（最大值是協議設定的參數），則該區塊不會被批准。在該協議的實際使用的版本中，對於不取用“未來”的tranche，以及步驟2 的每次迭代的漂移時間，還有一些進一步的限制。
此流程圖捕獲了每個驗證人運行的，用來確定平行鏈區塊是否被批准的邏輯。需要注意的是，這僅基於驗證人實際看到的任務和批准。可能還有一些任務存在，從而改變計數過程的結果。但如果運行該過程的驗證人還未收到這些任務，則無法考慮它們。
如何對收到的任務和批准進行計數和解釋
此過程的關鍵點是，如果有足夠的早期任務，則根本不計算後期tranche 的任務，並且在秘密情況下消失的節點將被替換掉。
以下是批准計數程序結果的4 個例子：
每當驗證人運行此批准計數程序，並發現需要更多任務時，它會檢查是否應該觸發自己的任務並開始檢查。驗證人會在以下情況下觸發其任務：
驗證人尚未觸發其任務。任務的tranche 與狀態有關：要么它是狀態已經考慮的tranche 的一部分，要么計數程序取完了tranche，而且任務不在未來。
總結
批准檢查協議是Polkadot 的主要欺詐檢測機制。在任何東西到達此階段之前，我們已確保檢查所需的數據是可用的。這種機制導致每個平行鏈區塊的要么被批准要么被升級。並且該機制的設計，讓試圖消滅前來檢查的驗證人的DoS 攻擊者，反而被更多的檢查者所取代。
批准檢查是一條九頭蛇。它旨在吃掉攻擊者並在另一端將其吐出。它將它們發送到一個我們稱之為爭議（dipute）的系統：爭議是Polkadot 的共識法院。
直播預告：
明晚7 點，ParallelLaunch Event 即將在波卡世界直播間進行。 Parallel 市場負責人和核心開發者將做客直播間，和大家分享Parallel 上線相關的情況。還有Parallel 定制夕陽燈、帆布袋、衛衣、徽章等超豐富獎品等你來領！
點擊“預約” 按鈕立即預約直播。
PolkaWorld Telegram 群：t.me/polkaworldPolkaWorld Youtube 頻道：https://www.youtube.com/c/PolkaWorldPolkaWorld Twitter：@polkaworld_orgPolkaWorld 網站：https://polkaworld.pro/
APP 
