超級賬本 Fabric 新特性之細粒度隐私保護

超級賬本 Fabric 項目自 1.1 版本開始，關于增強通道内隐私保護的新特性引發不少讨論，如 FAB-1151、 FAB-2961、 FAB-4976、FAB-8718。本文将總結該特性設計過程和來龍去脈，以供後續開發者更好地了解最初的設計意圖和核心思想。

隐私保護問題

超級賬本 Fabric 1.x 系列版本中在增強隐私性方面做了很大改進，1.0 版本中一個重要特性就是多通道（Multiple-channel）的支援。使用該特性，賬本網絡中若幹成員可以協商建構一個專屬通道與外部隔離，通道外的節點無法看到其中的賬本和交易資料，極大地提高了隐私性。

然而，在有些場景下單純使用通道來保護資料安全仍然存在不足：

• 雖然外部 Peer 節點無法看到通道内交易資料，但排序（Ordering）服務可以看到所有通道的所有資料；
• 通道内的 Peer 節點能看到通道内所有資料，即使跟自己無關的交易，即粒度還是比較粗；
• 為了保護任意多方之間的隐私，需要建構大量（O(n^2)量級）的通道，而通道是比較重的資源，而且目前還不支援删除操作；
• 某些時候，成員對資料的通路控制需要一定的動态性，通道機制無法滿足。

總之，需要一些更靈活的方案，來實作更細粒度的資料安全保護。

現狀剖析

首先來看下，目前 Fabric 對交易的處理流程中，哪些環節有可能進一步改進隐私性。

• 背書過程：用戶端将交易提案發送給相關的 Peer 節點，Peer 節點利用鍊碼進行模拟執行，對結果的讀寫集合進行簽名，傳回給用戶端。在這個過程中，用戶端可以選擇将需要保護的私有提案隻發給選中的若幹節點（授權組）進行背書。但節點可能會動态加入或退出授權組，并且用戶端無法保證明時獲知授權組的變化，是以授權組内的節點之間要能互相傳播私有資料。
• 排序過程：用戶端根據背書結果構造合理的交易請求（帶有讀寫集），發送給排序服務，排序服務對交易進行排序和打包成塊。在這個過程中，排序節點顯然其實不需要通路交易内容。為了增強隐私性，用戶端不能将私有交易的内容直接發給排序服務。
• 送出過程：通道内的 Peer 們經由 Leader Peer 擷取到排序後的交易資訊，在各自本地賬本進行再次驗證，最後送出。這一環節中，完成交易送出的節點必須能獲知交易的讀寫集明文。為了避免所有節點看到明文，需要本地建立隔離的狀态資料庫和鍊結構來專門存放私有交易資料。

增強排序環節隐私性

首先來看相對獨立的排序環節。

為了避免排序服務看到明文交易資料，很自然地，可以将交易資料提前進行保護處理，讓排序服務隻拿到處理後的結果。但這個結果對于授權的部分節點來說，必須還要能對應回原先的交易資料，不然無法完成最終的送出操作。

最基本的兩種手段是加密和 Hash，主要的差異如下表所示。

比較	加密處理	Hash 處理
恢複	可以恢複	理論上無法恢複
額外資料（如密鑰）	需要密鑰加密	無需（加鹽除外）
破解	算法保證，一般較難破解	理論上除了窮舉碰撞很難破解

無論是哪種方案，都可以保證排序服務無法直接看到交易明文。從安全性上來看，采用 Hash 方法會更難破解。

注意：簡單 Hash 機制無法抵擋基于統計的破解，但實作中很容易通過結合加鹽或 HMAC 等機制來提高抗破解強度。

思考：實際上，映射表機制也可以滿足增強排序環節隐私性的需求，然而需要額外維護和存放表結構，并不比 Hash 機制更加安全。

增強背書環節隐私性

由于在背書過程，Peer 節點需要通過提案計算讀寫集，并通過簽名證明背書通過，這意味着：

• 執行背書的 Peer 節點應能看到交易明文，隻有這樣才能進行交易邏輯的模拟執行，并将結果傳回用戶端；
• 用戶端拿到的節點傳回的消息中，必須包含對處理（加密 or Hash）後結果進行的簽名，這是因為用戶端無法也不應該替 Peer 節點進行簽名。

下面分别讨論采用加密或 Hash 機制。

采用加密機制的設計

采用加密機制，用戶端發送明文的提案給背書 Peer，背書 Peer 驗證後執行提案，獲得結果讀寫集，對讀寫集使用某個密鑰加密，簽名并傳回用戶端。用戶端要比對不同的背書結果，是以，要麼能解密所有的響應結果（難實作），要麼所有背書節點采用同一密鑰加密（意味着密鑰需要由用戶端産生）。

注意隻有授權的 Peer 節點可以通路明文讀寫集（彼此通過 Gossip 傳播），并最終送出結果到本地的私有狀态資料庫。

整個過程中最關鍵的還是密鑰的分發和管理。

為了提高安全性，用戶端可以将加密密鑰通過授權 Peer 的公鑰進行加密後再傳播；為了避免關聯性，用戶端可以對于不同的交易采用不同的密鑰，當然這會增加網絡中加解密處理的計算量。授權 Peer 節點之間可以通過某種方式（如 Gossip）主動進行組内的密鑰分發。

一個不太好解決的問題是，交易處理完成後，密鑰是否需要儲存？如果儲存，可能将來會造成洩露；如果不儲存，後來授權的 Peer 可能無法根據公開的區塊鍊結構同步結果到私有狀态資料庫。另外，儲存在用戶端還是 Peer 節點。這些都是比較難解決的問題。

采用 Hash 機制的設計

采用 Hash 機制，用戶端發送明文的提案給背書 Peer，背書 Peer 驗證後執行提案，獲得結果讀寫集，對讀寫集計算 Hash 值，簽名并傳回用戶端。

在這個過程中，隻要背書節點的 Hash 過程一緻，對于相同讀寫集，用戶端可以容易驗證結果的一緻性。

同樣，明文讀寫集可以通過 Gossip 傳播在授權組内傳播。

這也是 1.1 版本開始支援的 sideDB 特性的基本實作思路。

增強送出環節隐私性

送出環節需要将讀寫集内容寫到本地狀态資料庫，并記錄交易到區塊鍊結構中。是以，對于授權組内節點來說必須要能獲知明文的讀寫集。

sideDB 中除了新的私有狀态資料庫、私有區塊鍊結構之外，還額外建立一個臨時的本地私有資料庫，儲存在背書環節中讀寫集明文以及到對應 Hash 值之間的映射關系。當對應交易送出時，将讀寫集明文内容更新到私有的狀态資料庫和區塊鍊結構中，将 Hash 後的交易更新到公共結構中。

授權管理

授權組是靜态情況下，可以通過對鍊碼進行執行個體化時指定；當授權組需要支援動态增删時，則要複雜的多。

一個典型的問題是，是否允許新加入的節點通路之前的私有資料？

另外，授權組的政策如何在網絡中同步？如何保證 Peer 能拿到最新的授權政策，而不至于将私有資料發給了過期的鄰居？

這些都是一些開放的問題，預計将在 1.2 版本中初步解決。

總結

超級賬本 Fabric 引入了 sideDB 機制，通過 Hash 處理和私有資料結構，在通道内部實作了更細粒度的隐私保護。Hash 後的交易内容仍然會發送到排序節點，并送出到公共的資料庫和賬本結構中。而授權組的 Peer 節點則在本地維護私有的狀态資料庫和區塊鍊結構，儲存交易的明文内容。這就保證了通道内其他節點無法看到授權組的交易内容。