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