Polkadot研究分析

本文總結了與Polkadot專案相關的研究工作。

Polkadot提供了許多連線的規範狀態機。 已連線意味著一臺機器的狀態轉換可能會影響另一臺機器的轉換。狀態機是規範的，因為它們以全球一致的方式過渡。 我們還希望隨著時間的推移啟用新增，刪除和更改狀態機。 這將是治理過程的作用。

該研究的重點是如何在可能的對抗條件下實現這種公開可用的系統。 公眾可以透過網際網路與他們感興趣的狀態機互動來使用該系統。 每個狀態機可以提供不同的功能並以不同的方式進行執行（具有不同的狀態和狀態轉換方案）。

那麼讓我們從抽象狀態機開始吧。 狀態機具有特定的狀態型別和狀態轉換型別。 隨著時間的推移，狀態轉換髮生。

確定狀態轉換的資料被構造為事務束 - 由系統使用者觸發的各個小狀態轉換。每個捆綁稱為塊。為了實現其屬性，確保這些塊是雜湊連線形成聯合資料結構。

1. Polkadot執行時環境的規範

我們正在制定協議的實現級別規範。

2.識別參與者以執行網路

2.1Keys

為了識別將在網路上履行職責的獨特個人參與者，我們使用公鑰加密。 您可以在此處閱讀有關我們方法的更多資訊，並檢視Schnorrkel倉庫中首次實施的特定加密。

由放樣鍵指示的驗證器鍵是：

傳輸層：ed25519

GRANDPA和綜合報告：BLS

*塊生產（VRF）：Ristretto

2.2 PoS

為了確保某些方面對下面列出的各種負責，我們確保能夠透過取走一些資金來懲罰這些參與者（證明股權）。執行網路的主節點是驗證器。為確保大量參與者能夠為網路的安全做出貢獻，我們引入了一項指定的股權證明計劃（NPoS）。該方案允許不希望執行節點的參與者能夠幫助驗證器選擇。用於分配該樁的當前方法是SequentialPraragmén方法。

對於Polkadot，使用Phragmén的方法作為後備，但允許提交更好的解決方案。作為邊緣情況，如果沒有提交好的解決方案，請執行提供2近似的慢啟發式（TODO：publish）。

判斷NPoS解決方案：

從某個本地搜尋過程的角度檢查提交的解決方案是否在本地最優。本地最優解決方案是否具有公平性。因此，我們只接受公平的解決方案（TODO：釋出）。

在觀察第一個關於公平性的屬性的提交中，選擇最大化任何選定驗證者的最小權益提交。這確保了每個parachain驗證器組的最大安全閾值。

在制裁單中可以找到一份必須受到懲罰的錯誤行為的綜合清單。

2.3為什麼不為不同的任務使用不同的集合？

使用與BABE相同的驗證器

集和

GRANDPA，可以避免為塊生產+最終結果支付更多費用。

3.確保狀態轉換屬性

3.1實用性

每個狀態轉換都應該為系統參與者帶來一些實用性。 為了確保這種情況：

狀態機應該對參與者有用

由這些狀態機處理的狀態轉換很好地反映了參與者的狀態轉換需求。

為了確保狀態機是有用的，我們應該確保有一個機制，使參與者能夠決定應該包括哪些狀態機以及它們應該如何改變以反映參與者的需求。 這種機制是Polkadot治理方案。

為確保這些狀態機處理有用的狀態轉換，我們需要確保將有用的事務包含在Polkadot塊中。 Polkadot將在中繼鏈上設立交易費機制，以確保願意為其支付合理價格的各方發行交易。 每個塊的特定部分也將專用於特定高優先順序事務，例如錯誤行為報告。 必須透過給定鏈的狀態轉換函式來確保鏈狀態轉換的有用性。

3.2有效期

Polkadot中的有效性概念由狀態轉換驗證函式（STVF）確定。 生態系統中的每個鏈都必須實現一個。 為了使所有節點能夠執行此功能，它將作為確定性WebAssembly（Wasm）程式碼分發，該程式碼可由Polkadot執行時環境執行。

這些塊由parachain collators生成，然後由負責給定parachain的驗證器子集使用STVF進行驗證，最終包含在Polkadot Relay Chain中。 在此過程中，驗證人，分支機構和其他方可以自由地質疑有效性進行索賠，以觸發額外檢查，這些方被稱為漁民。閱讀這裡關於parachain有效性。

3.3規範性

Polkadot網路狀態機的規範性是透過塊生產機制與最終機率規範（BABE方案）和GRANDPA終結小工具的組合來實現的。 這種方法允許塊生產速度的（因此交易確認）快速，同時允許儘可能快的經濟終結與緊湊的證明。

3.4可用性

為了使所有鏈的關鍵資料能夠由使用者和後續塊生成器保持一致，Polkadot就利用基於擦除編碼的可用性方案。

4.確保狀態機之間的可靠訊息傳遞

除了確保所有parachain的所有屬性，Polkadot的一個關鍵要素是這些狀態機能夠影響彼此的狀態轉換。 這是透過鏈間訊息傳遞（ICMP）方案完成的。

5.控制資源使用

5.1合理的尺寸

為了確保網路可以處理和儲存狀態轉換，它們的大小必須合理。 諸如交易費和塊限制之類的機制限制了每個塊所需的儲存大小和計算。

5.2輕客戶

該協議的設計考慮了輕量級客戶端支援，現有的Substrate實現可以支援。

6.期望的品質

Minimal：Polkadot應具有儘可能少的功能。

Simple：基本協議中不應存在額外的複雜性。

General：Polkadot可以透過使擴充套件儘可能抽象的模型進行最佳化。

Robust：Polkadot應該提供一個基本穩定的基礎層。