PPIO 的狀態通道設計

PPIO 是爲開發者打造的去中心化存儲與分發平臺，讓數據更便宜、更高速、更隱私。官方網站是https://pp.io。
​
PPIO 的定位不只僅是作存儲，還有數據分發和數據傳輸。在數據傳輸的時候，如何保證數據傳輸的流量也採用一種公正的，不可抵賴的方式來實現的。這就是我這篇文章要講解的狀態通道。PPIO 就是經過狀態通道的機制來實現數據傳輸的公正計量。

傳統意義的狀態通道機制

狀態通道在區塊鏈領域是個已經存在的名字，主要應用於高頻交易和微支付。由於在這兩個場景下，交易吞吐量會很是大， 若是全部的操做都是在須要共識的去中心化的鏈上操做，性能低會成爲重要問題。
狀態通道的解決思路，本質是在交易高吞吐量和驗證者的去中心化之間作一個平衡。具體來講，就是把兩兩交易的細節，放在鏈下去協商完成，當多步交易完成後，或者交易發生爭議，再經過區塊鏈來進行「仲裁」。
爲了說明狀態經過，咱們先作個假設，兩我的 Alice 和 Bob，後面也可能簡稱 A 和 B。假設 Alice 在一開始的資產是10，Bob 在一開始的資產也是10，他們之間即將發生一系列高頻的微支付。咱們開始模擬這個狀態通道。

圖: Alice 和 Bob 使用狀態通道交易的示意圖
整個過程大概分爲如下幾步：
Alice 或者 Bob 建立於一個狀態通道智能合約 Contract，後面會簡稱 C，此時狀態通道處於 opening。這個過程是要上鍊的。
Alice 將10個資產打入到合約中，接着 Bob 也將10個資產打入到合約之中，此時狀態通道就算是開啓，進入 open 狀態。這個過程當中也是要上鍊的。這時候的分配方案是【A:10, B:10】。（分配方式是指交易雙方都可以在鏈下都承認的資產分配方式，總量是同樣的的，要麼 A 多，要麼 B 多，若是這個時候合約終止，就會按照分配方案的資產打回到各自的帳戶上）
此後，因爲 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 值較小的分配方案都是失效的方案，能夠隨時拋棄。
狀態提交，在交易的過程當中，交易雙方，Ａ 或者 Ｂ均可以隨時向智能合約 Ｃ 發起狀態提交，若是 Ａ 發起了狀態提交，Ｃ 會驗證 Ｂ 的簽名；反之若是 Ｂ 發起了狀態的提交，Ｃ 會驗證 Ａ 的簽名，同時也會驗證 Nonce 值。智能合約 C 只接收比上次鏈上分配的 nonce 值更大的方案，若是新提交的分配方案的 Nonce 和簽名都合法，則 C 接收新的分配方案，並更新合約中的 Nonce 值爲新分配方案的 Nonce 值。雙方持續交易，... … 直到最後的分配方案，假設是【A:1; B: 19; N:50】，下面稱爲最終狀態。假設該方案已被提交到智能合約 C，且被智能合約所接受。
關閉狀態通道請求，這時候可由任一方發起關閉狀態通道，即按照合約中的鏈上分配方案進行分配。一旦合約 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 狀態。（注：具體實現時也能夠將」狀態提交」和「關閉狀態通道請求」合併成一步）
最終資產分配：當合約 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 的時候，咱們借鑑了傳統的傳統的狀態通道機制，來實現帶寬的激勵。
U 建立了區塊鏈上的智能合約 Contract（後面簡稱C）。而後 U 往 C 中轉入資產，假設轉入了10個資產。因爲 PPIO 設計的是單向通道，只有 U 轉入資產後，便可進入Open 狀態，其分配方案是【U:10; M:0】
開始進行數據傳輸，U 向 M 請求數據，M 向 U 返回正確的數據後，U 會給予 M 一個 Voucher，即帶有 U 簽名的新的狀態分配方案。因爲網絡傳輸的實時性要求很是高，M 須要先給數據，再拿 Voucher。此時分配方案逐步變成 了【U:9; M:1】。
繼續傳輸數據，狀態通道的分配方案，U 的資產愈來愈少，M 的資產愈來愈多。直到U 把以前存入狀態通道的資產用完，即【U:0; M:10】；
最終狀態提交：此時 M 用最新的 Voucher 去區塊鏈上的智能合約用 Voucher 去提款。C 在驗證 Voucher 中有 U 的正確簽名後，接受了 Ｍ 的提款。以後狀態通道關閉，標記爲 Close 狀態，以後該狀態通道不能再進行交易。
以後 U 在 M 請求數據，因爲資產已經用完，M 將再也不提供服務。除非 U 建立新的狀態通道合約 C1，再轉必定的資產進去，才能再次向 M 請求數據。

圖：PPIO 的數據傳輸狀態通道設計
這就是 PPIO 整個狀態通道的過程。下面咱們作一下簡單的攻防分析。
假設 User 做惡，做惡方式爲 U 向 M 請求到了數據以後，不給 Voucher。處於網絡性能的考慮，PPIO 的設計是 M 先給必定的數據，再要 Voucher。若是 U 不給 Voucher，M 給予必定量的數據發現收不到 Voucher，因而將再也不對該 User 給予更多的數據了，而且標記爲 U 爲惡意用戶，已經給予的部分數據做爲本身有限的損失。
假設 Miner 做惡，做惡方式是給予 User 錯誤的數據。User 收到必定量的數據後，就會發現數據異常，因而不給予 Voucher，並向區塊鏈智能合約 C 發起關閉狀態通道，並標記該 Miner 爲惡意礦工。若是網絡中存在 Verifier，U 還能夠向 Verifier 舉報 M，以後 Verfier 會對 M 重點驗證，分析 M 是否還存在其餘做惡。

圖：若是 User 發現 Miner 做惡的狀態通道示意圖
採用狀態通道的方式，在交易雙方存在做惡的狀況下，可能存在一方有些輕微損失。但不影響總體的設計，所以，PPIO 中的帶寬激勵是不須要 Miner 作任何抵押的，這點和存儲場景不太同樣。
存儲場景具備長時性，使得 Miner 抵押成爲必要。一次存儲少則幾天，多則數月，甚至幾年，若是在存儲期間 Miner 做惡，User 可能面臨文件的風險，後果很嚴重，所以在存儲場景下，經過要求 Miner 抵押這一經濟手段還迫使 Miner 誠實可靠的爲 User 提供存儲服務是必要的；
存儲數據具備肯定性，使得驗證存儲的持久性變的可行。肯定性的數據可用 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，（代理支付網關，詳情能夠參考文章《爲何 PPIO 要設計代理支付網關》）。
由狀態通道升級後的數據分發合約以下圖所示

圖：PCDN 下最簡單的下載流程圖

關於引入 Owner 角色的分發智能合約的描述，能夠見文章《讓智能合約在數據分發中更智能？PPIO 的設計小巧思》。但其中 Peer 和 Peer，Peer 和 Miner 之間的通訊本質上仍是走得狀態通道的機制。
這是最基本的 PPIO 狀態通道邏輯，另外在具體應用場景中，如 PCDN 和 PRoute，還有更多的考慮。關於狀態通道在 PCDN 場景下應用，具體可見文章《讓智能合約在數據分發中更智能？PPIO 的設計小巧思》。另外，我後面還會介紹，PPIO 在具體場景中更深刻的實現，請你們敬請期待。
效率提高與價值落地一直以來都是 PPIO 實現技術不斷創新進步的標尺。這一期文章，咱們分享瞭如何基於傳統的狀態通道機制，完成了 PPIO 的狀態通道機制的設計 ，從而實現數據傳輸的公正計量。咱們又經過一個實際案例，分析了基於這樣的設計， User 和 Miner 的兩個角色如何進行有效的數據傳輸，避免雙方做惡帶來的沒必要要的損失。同時也解釋了，PPIO 中的帶寬激勵是不須要 Miner 作任何抵押的，這一點和存儲場景有本質區別。不知看到這裏，是否讓您對的 PPIO 的技術工程實現有了更深刻的瞭解呢？若是您想更進一步的和咱們一塊兒學習探索，就快來關注 PPIO 公衆號，加入 PPIO 開發者社區或 Discord 羣組，和咱們一塊兒創造精彩。

想了解更多有關 PPIO 的信息，能夠移步官網：pp.io