為了說明狀態透過，我們先做個假設，兩個人 Alice 和 Bob，後面也可能簡稱 A 和 B。假設 Alice 在一開始的資產是10，Bob 在一開始的資產也是10，他們之間即將發生一系列高頻的微支付。我們開始模擬這個狀態通道。
圖: Alice 和 Bob 使用狀態通道交易的示意圖
整個過程大概分為以下幾步：1. Alice 或者 Bob 建立於一個狀態通道智慧合約 Contract，後面會簡稱 C，此時狀態通道處於 opening。這個過程是要上鍊的。2. Alice 將10個資產打入到合約中，接著 Bob 也將10個資產打入到合約之中，此時狀態通道就算是開啟，進入 open 狀態。這個過程中也是要上鍊的。這時候的分配方案是【A:10, B:10】。（分配方式是指交易雙方都能夠在鏈下都認可的資產分配方式，總量是一樣的的，要麼 A 多，要麼 B 多，如果這個時候合約終止，就會按照分配方案的資產打回到各自的賬戶上）3. 此後，由於 A 和 B 之間的狀態通道處於 Open 的狀態，A和B之間可以開始交易。如果 A 向 B 轉了1個資產，則分配方案為【A:9; B:11;N:1】，這時 B 拿到了 A 對分配狀態的簽名；而接著 B 又向 A 轉了3個資產，這時的分配方案變為【A:12; B:8; N:2】，這時 A 拿到了 B 對分配狀態。這裡 N 表示 Nonce。每次鏈下雙方按照約定改變資產分配，則雙方都要自增一次 Nonce 值。誠實的交易者都會以 Nonce 最大的分配方案作為當前的分配方案，而 Nonce 值較小的分配方案都是失效的方案，可以隨時拋棄。4. 狀態提交，在交易的過程中，交易雙方，Ａ 或者 Ｂ都可以隨時向智慧合約 Ｃ 發起狀態提交，如果 Ａ 發起了狀態提交，Ｃ 會驗證 Ｂ 的簽名；反之如果 Ｂ 發起了狀態的提交，Ｃ 會驗證 Ａ 的簽名，同時也會驗證 Nonce 值。智慧合約 C 只接收比上次鏈上分配的 nonce 值更大的方案，如果新提交的分配方案的 Nonce 和簽名都合法，則 C 接收新的分配方案，並更新合約中的 Nonce 值為新分配方案的 Nonce 值。雙方持續交易，... … 直到最後的分配方案，假設是【A:1; B: 19; N:50】，下面稱為最終狀態。假設該方案已被提交到智慧合約 C，且被智慧合約所接受。5. 關閉狀態通道請求，這時候可由任一方發起關閉狀態通道，即按照合約中的鏈上分配方案進行分配。一旦合約 C 接收到關閉通道的請求，合約會進入 Closing 狀態並維持一定的有效期，在該狀態下且在有效期內，另一方依然可以提交新的有效的分配方案來將狀態通道置回 Open 狀態。如果在有效期內另一方未能將狀態通道置回 Open 狀態，則狀態通道會在有效期過後，進入 Closed 狀態。比如，在這個案例中，B 是受益方，一般來說，是由 B 在這時候發起關閉狀態通道請求，然後狀態通道進入 Closing 狀態，並在一定有效期後按照鏈上最後的有效分配方案【A:1; B: 19; N:50】進行分配。此時，若B是一個作惡者，雖然現在鏈上的分配方案為【A:1; B: 19; N:50】，但其實鏈下最新的分配方案已是【A:4; B: 16; N:55】，但 B 嘗試用老的分配方案來分配資產，使自己獲益增大。此時由於合約在 Closing 狀態，只要A及時發現 B 的鏈上關閉通道請求的交易，則 A 可以立刻將更新的分配方案【A:4; B: 16; N:55】提交到合約，從而使得合約被置回到 Open 狀態，防止 B 的惡意提款。之後 A 如果想關閉合約，則可重新向合約發起關閉狀態通道的請求。之後只要 B 無法再給出比 N:55 更新的分配方案，那麼狀態通道最終將在有效期過後，進入 Close 狀態。（注：具體實現時也可以將”狀態提交”和“關閉狀態通道請求”合併成一步）6. 最終資產分配：當合約 C 進入 Closed 狀態後，任何一方都可以觸發最終的資產分配，即按照鏈上已確定的最後有效的分配方案進行實際的資產分配。回顧整個過程，需要寫入區塊鏈的步驟，只是和鏈上智慧合約 C 相關的部分，分別是開始建立的時候和分配方案的提交以及最終狀態的提交。其餘都是在鏈下操作，所以在狀態通道的設計中，專案一般設計為 只向區塊鏈智慧合約 C 提交一次，從而做到最高的效能。PPIO 的狀態通道機制的設計· PPIO 支援三個核心模組POSS 是 P2P Object Storage Service，對標 AWS 的 S3 儲存。· PCDN 是 P2P Content Delivery Network，對標傳統的 CDN，就像 AWS 的CloudFront。· PRoute，是基於 P2P 的自適應網路智慧路由，做到兩個節點之間，以最合理路徑到達，從而速度最快，延遲最低 。這是協議層的實現，在 AWS 中沒有對標的產品。其中除去 POSS 模組外，PCDN 和 PRoute 都是更多激勵頻寬的貢獻，其網路資料的傳遞非常頻繁且實時。如果每個 Piece 的傳輸，都要寫入區塊鏈，這將是非常大的浪費 。其實，網路資料高速傳輸激勵，本質上是高頻交易和微支付，所以在設計 PPIO 的時候，我們借鑑了傳統的傳統的狀態通道機制，來實現頻寬的激勵。1. U 建立了區塊鏈上的智慧合約 Contract（後面簡稱C）。然後 U 往 C 中轉入資產，假設轉入了10個資產。由於 PPIO 設計的是單向通道，只有 U 轉入資產後，即可進入Open 狀態，其分配方案是【U:10; M:0】2. 開始進行資料傳輸，U 向 M 請求資料，M 向 U 返回正確的資料後，U 會給予 M 一個 Voucher，即帶有 U 簽名的新的狀態分配方案。由於網路傳輸的實時性要求非常高，M 需要先給資料，再拿 Voucher。此時分配方案逐步變成 了【U:9; M:1】。3. 繼續傳輸資料，狀態通道的分配方案，U 的資產越來越少，M 的資產越來越多。直到U 把之前存入狀態通道的資產用完，即【U:0; M:10】； 4. 最終狀態提交：此時 M 用最新的 Voucher 去區塊鏈上的智慧合約用 Voucher 去提款。C 在驗證 Voucher 中有 U 的正確簽名後，接受了 Ｍ 的提款。之後狀態通道關閉，標記為 Close 狀態，之後該狀態通道不能再進行交易。5. 之後 U 在 M 請求資料，由於資產已經用完，M 將不再提供服務。除非 U 建立新的狀態通道合約 C1，再轉一定的資產進去，才能再次向 M 請求資料。圖：PPIO 的資料傳輸狀態通道設計
這就是 PPIO 整個狀態通道的過程。下面我們做一下簡單的攻防分析。1. 假設 User 作惡，作惡方式為 U 向 M 請求到了資料之後，不給 Voucher。處於網路效能的考慮，PPIO 的設計是 M 先給一定的資料，再要 Voucher。如果 U 不給 Voucher，M 給予一定量的資料發現收不到 Voucher，於是將不再對該 User 給予更多的資料了，並且標記為 U 為惡意使用者，已經給予的部分資料作為自己有限的損失。2. 假設 Miner 作惡，作惡方式是給予 User 錯誤的資料。User 收到一定量的資料後，就會發現資料異常，於是不給予 Voucher，並向區塊鏈智慧合約 C 發起關閉狀態通道，並標記該 Miner 為惡意礦工。如果網路中存在 Verifier，U 還可以向 Verifier 舉報 M，之後 Verfier 會對 M 重點驗證，分析 M 是否還存在其他作惡。圖：如果 User 發現 Miner 作惡的狀態通道示意圖
採用狀態通道的方式，在交易雙方存在作惡的情況下，可能存在一方有些輕微損失。但不影響整體的設計，因此，PPIO 中的頻寬激勵是不需要 Miner 做任何抵押的，這點和儲存場景不太一樣。1. 儲存場景具有長時性，使得 Miner 抵押成為必要。一次儲存少則幾天，多則數月，甚至幾年，如果在儲存期間 Miner 作惡，User 可能面臨檔案的風險，後果很嚴重，因此在儲存場景下，透過要求 Miner 抵押這一經濟手段還迫使 Miner 誠實可靠的為 User 提供儲存服務是必要的；2. 儲存資料具有確定性，使得驗證儲存的永續性變的可行。確定性的資料可用 Merkle樹來組織，然後利用葉子節點到 Merkle 根的路徑作為資料持有證明，而這種證明的驗證，利用智慧合約或者可信的第三方就可以完成。而頻寬則不同，頻寬具有瞬時性和不確定性。頻寬傳輸相對於儲存來說，交易時間很短，且傳輸什麼資料在傳輸前一般都不可知。這兩點導致了 User 很難在數學層面上限制 Miner 只傳輸正確的資料，也就很難透過證明來約束 Miner 使得 Miner 不作惡。一旦 Miner 作惡，可信的第三方或者智慧合約也無法準確的判斷出到底是 Miner 真的作惡，還是 User 在陷害 Miner，因此即使 Miner 做了抵押，可信的第三方或者智慧合約也不知在糾紛出現時如何處置該抵押。所以解決頻寬場景的思路和儲存場景不一樣，頻寬場景的思路是利用狀態通道實現“小步快跑”：每次都只做很小的交易，如果發現對方作惡，則立刻停止交易，轉而尋找新的交易者。這樣即使對方作惡，己方損失也不是很大。講到這裡，只是講解了 PPIO 裡面應用狀態通道的基本原理，在 PPIO 的一些場景設計中，狀態通道還有更復雜的用法，但基本原理是不變的。Owner 角色的引入PPIO 在設計的時候，我們還設計了一個 Owner 的角色，Owner 不是一個 P2P 傳輸角色，而是一個支付和結算角色。在 PCDN 架構中，每個 Peer 都需要指定一個 Owner。這個 Peer 產生的花費由它的 Owner 來承擔，而同樣該 Peer 賺取的收入也由它的 Owner 來接收。如下圖，同一個 Owner 可以對接多個 Peer。圖：Owner 和 Peer 的關係圖
這個角色可以簡單理解為，在需求端就是開發者，在供給端就是礦池；它本質就是 CoinPool。由狀態通道升級後的資料分發合約如下圖所示圖：PCDN 下最簡單的下載流程圖
關於引入 Owner 角色的分發智慧合約的描述。但其中 Peer 和 Peer，Peer 和 Miner 之間的通訊本質上還是走得狀態通道的機制。這是最基本的 PPIO 狀態通道邏輯，另外在具體應用場景中，如 PCDN 和 PRoute，還有更多的考慮。關於狀態通道在 PCDN 場景下應用，具體可見文章《讓智慧合約在資料分發中更智慧？PPIO 的設計小巧思》。另外，我後面還會介紹，PPIO 在具體場景中更深入的實現，請大家敬請期待。效率提升與價值落地一直以來都是 PPIO 實現技術不斷創新進步的標尺。這一期文章，我們分享瞭如何基於傳統的狀態通道機制，完成了 PPIO 的狀態通道機制的設計 ，從而實現資料傳輸的公正計量。我們又透過一個實際案例，分析了基於這樣的設計， User 和 Miner 的兩個角色如何進行有效的資料傳輸，避免雙方作惡帶來的不必要的損失。同時也解釋了，PPIO 中的頻寬激勵是不需要 Miner 做任何抵押的，這一點和儲存場景有本質區別。不知看到這裡，是否讓您對的 PPIO 的技術工程實現有了更深入的瞭解呢？如果您想更進一步的和我們一起學習探索，就快來關注 PPIO 公眾號，加入 PPIO 開發者社羣或 Discord 群組，和我們一起創造精彩。
